تصل رسائل مجال شركتك إلى البريد المزعج في أغلب الحالات لأن خوادم المستقبِل لا تستطيع التأكد من أن الرسالة صادرة فعلًا من جهة مخوّلة بالإرسال باسم المجال. الحل يبدأ بثلاثة سجلات DNS: سجل SPF يحدد الخوادم المسموح لها بالإرسال، وDKIM يوقّع الرسالة رقميًا، وDMARC يربط النتيجتين بعنوان المرسل الظاهر ويحدد ما يحدث عند الفشل. بعد ذلك تأتي هوية الخادم المرسِل وسمعته وسلوك المستلمين تجاه رسائلك.

لماذا تصل رسائل مجالك إلى البريد المزعج؟

الأسباب الشائعة قليلة ومتكررة، وكل منها يمكن فحصه:

  • غياب المصادقة أو كسرها: لا يوجد سجل SPF، أو يوجد سجلان متعارضان، أو سجل يتجاوز حد الاستعلامات.
  • رسائل بلا توقيع DKIM، أو بتوقيع يفشل لأن نظامًا وسيطًا عدّل الرسالة بعد توقيعها.
  • غياب DMARC، فلا يعرف المستقبِل ما سياستك، ولا تصلك أنت تقارير عمّن يرسل باسم مجالك.
  • هوية خادم ناقصة: عنوان IP بلا سجل PTR، أو اسم HELO لا يطابق شيئًا.
  • سمعة مشتركة: على الاستضافة المشتركة يرسل مئات المواقع من العنوان نفسه، وموقع WordPress مخترق واحد قد يضر بالجميع.
  • سلوك المستلمين: قوائم قديمة، وغياب رابط إلغاء الاشتراك، وشكاوى متكررة من المستلمين.

ابدأ بالمصادقة، فهي الجزء الذي تتحكم فيه بالكامل.

SPF: سجل واحد فقط يحدد من يرسل باسم مجالك

سجل SPF هو سجل TXT على المجال نفسه يبدأ بـ v=spf1. القاعدة الأولى: سجل واحد لكل اسم. وجود سجلين يبدآن بـ v=spf1 يعطي نتيجة permerror، أي أن SPF يفشل كليًا. عند إضافة خدمة إرسال جديدة لا تنشئ سجلًا جديدًا، بل أضف آلية إلى السجل الموجود.

الآليات الأكثر استخدامًا:

  • a وmx: تسمح لعناوين سجلات A وMX الخاصة بالمجال.
  • ip4: وip6:: تسمح لعنوان أو نطاق عناوين IP محدد.
  • include:: تستورد سجل SPF الخاص بخدمة أخرى، مثل مزود البريد أو خدمة الإرسال.

حد الاستعلامات العشرة

يحدد معيار SPF في RFC 7208 سقفًا من 10 استعلامات DNS أثناء تقييم السجل. الآليات include وa وmx وptr وexists والمعدِّل redirect تُحتسب كلها، وتُحتسب كذلك الاستعلامات داخل كل include متداخل. أما ip4 وip6 وall فلا تُحتسب. تجاوز الحد يعطي permerror حتى لو كان الخادم المرسِل مذكورًا في السجل.

لتقليل العدد: احذف خدمات لم تعد تستخدمها، واستبدل a وmx بعناوين ip4 ثابتة إن كانت عناوينك مستقرة، ولا تستخدم ptr إطلاقًا. انتبه إلى أن «تسطيح» السجل بنسخ عناوين خدمة خارجية يدويًا ينكسر بصمت عندما تغيّر الخدمة عناوينها.

الفرق بين ~all و-all

  • ~all (فشل مخفف): الرسائل من خوادم غير مذكورة تُعلَّم بأنها مشبوهة ولا تُرفض بالضرورة.
  • -all (فشل صريح): تعلن أن أي خادم آخر غير مخوّل.

ابدأ بـ ~all أثناء حصر جميع الجهات التي ترسل باسمك، وانتقل إلى -all عندما تتأكد من القائمة. لا تستخدم +all أبدًا، فهو يسمح لأي خادم في العالم بالإرسال باسمك.

تذكّر أن SPF يتحقق من مرسل الظرف (Return-Path أو MAIL FROM) وليس من عنوان From الذي يراه المستلم. لهذا تحتاج DMARC.

DKIM: توقيع رقمي يثبت أن الرسالة لم تُعدَّل

يوقّع الخادم المرسِل أجزاء من الرسالة بمفتاح خاص، وينشر المفتاح العام في DNS. يستخدم المستقبِل المفتاح العام للتحقق من التوقيع.

  • المحدِّد (Selector): يُنشر المفتاح تحت اسم بالشكل selector._domainkey.example.com. يستخدم cPanel عادةً المحدد default، وكل خدمة إرسال تستخدم محددها الخاص، لذلك يمكن أن تتعايش عدة مفاتيح DKIM على المجال نفسه دون تعارض.
  • طول المفتاح: استخدم مفاتيح RSA بطول 2048 بت. مفاتيح 1024 بت تُعد ضعيفة اليوم. المفتاح الطويل يتجاوز 255 حرفًا في سلسلة TXT الواحدة، فيُقسَّم إلى عدة سلاسل داخل السجل نفسه. أغلب واجهات DNS تتولى ذلك تلقائيًا، لكن تحقق من النتيجة بأمر dig.
  • تدوير المفاتيح: أنشئ مفتاحًا بمحدد جديد، وانشره في DNS، وانتظر انتشاره، ثم حوّل التوقيع إليه. أبقِ المفتاح القديم منشورًا بضعة أيام حتى تُسلَّم الرسائل الموقّعة به، ثم احذفه. حدّد دورية للتدوير ضمن سياسة الأمان لديكم، ودوّر فورًا عند أي شك في تسرّب المفتاح.

في cPanel تجد حالة DKIM وSPF لكل مجال في صفحة Email Deliverability، وتعرض الصفحة السجل المقترح ومشكلات السجلات الحالية.

DMARC: سياسة تربط النتائج بعنوان المرسل الظاهر

سجل DMARC هو سجل TXT على _dmarc.example.com. ينجح DMARC إذا تحقق أحد الشرطين:

  1. نجح SPF وكان مجال مرسل الظرف متوافقًا مع مجال عنوان From.
  2. نجح DKIM وكان المجال في الوسم d= من التوقيع متوافقًا مع مجال From.

هذا هو مفهوم التوافق (Alignment). في الوضع المرن، وهو الافتراضي، يكفي أن يشترك المجالان في المجال الأساسي نفسه، فيتوافق mail.example.com مع example.com. في الوضع الصارم (aspf=s وadkim=s) يجب أن يتطابقا حرفيًا. خدمة إرسال توقّع باسم مجالها هي لا باسم مجالك تنجح في DKIM لكنها تفشل في DMARC.

التدرج من none إلى reject

  1. p=none مع rua: لا يتغير شيء في التسليم، لكن المستقبِلين يرسلون إليك تقارير مجمّعة بصيغة XML تبين من يرسل باسم مجالك ونتيجة كل مصدر.
  2. اقرأ التقارير لأسابيع، وأصلح كل مصدر مشروع يفشل: نظام الفواتير، ونموذج الاتصال في الموقع، وخدمة الرسائل التسويقية.
  3. p=quarantine: الرسائل الفاشلة تذهب إلى البريد المزعج.
  4. p=reject: الرسائل الفاشلة تُرفض. هذه السياسة تحمي مجالك من الانتحال.

إذا كان عنوان التقارير على مجال آخر، فيجب أن ينشر ذلك المجال سجلًا يأذن باستقبال تقارير مجالك، وإلا يتجاهلها المستقبِلون. التفاصيل في RFC 7489. استخدم الوسم sp= لتحديد سياسة المجالات الفرعية إن احتجت إلى سياسة مختلفة لها.

سجل PTR واسم HELO: هوية الخادم نفسه

يتحقق كثير من المستقبِلين من أن لعنوان IP المرسِل سجل PTR (DNS العكسي) يشير إلى اسم مضيف، وأن سجل A لهذا الاسم يعود إلى العنوان نفسه. ويجب أن يعلن الخادم الاسم نفسه في أمر HELO أو EHLO.

سجل PTR لا يُضاف من Zone Editor (محرر منطقة DNS) في حسابك، لأنه يتبع مالك عنوان IP، أي مركز البيانات أو مزود الاستضافة. على الاستضافة المشتركة اطلب من مزودك التحقق منه. على الخادم الخاص اضبطه من لوحة مزود الخادم.

الإرسال من خادم الاستضافة أم من خدمة إرسال مخصصة؟

المعيارخادم الاستضافةخدمة إرسال مخصصة
الاستخدام المناسبحسابات البريد الإلكتروني للموظفين ورسائل الموقع القليلةالرسائل التسويقية والتنبيهات بكميات كبيرة
السمعةمشتركة مع بقية الحسابات على العنوانمنفصلة أو مُدارة من الخدمة
معالجة الارتداداتيدوية في الغالبتلقائية مع تقارير
ما تحتاجه في DNSسجلات cPanel الافتراضيةinclude إضافي، ومحدد DKIM خاص، ومجال ارتداد متوافق

قاعدة عملية: لا ترسل حملات تسويقية من خادم الاستضافة. افصل البريد التسويقي على مجال فرعي مثل news.example.com، فتبقى سمعة المجال الرئيسي بعيدة عن أثر الحملات.

ماذا يشترط كبار مزودي البريد على المرسلين بكميات كبيرة؟

أعلن كبار مزودي البريد الإلكتروني متطلبات واضحة للمرسلين بكميات كبيرة، وأغلبها مفيد لأي مرسل:

  • مصادقة كاملة: SPF وDKIM، وسجل DMARC بسياسة p=none على الأقل، مع توافق مجال From.
  • سجل PTR صحيح، واتصال مشفّر عبر TLS.
  • إلغاء اشتراك بنقرة واحدة في الرسائل التسويقية عبر الترويستين List-Unsubscribe وList-Unsubscribe-Post، وتنفيذ طلبات الإلغاء بسرعة.
  • معدل شكاوى منخفض. راقبه عبر أدوات المرسلين التي يوفرها المزودون، ولا تعتمد على حدسك.

راجع صفحات المزودين أنفسهم للحدود الحالية، فهي تتغير.

كيف تتحقق بنفسك باستخدام dig وترويسات الرسالة؟

bash
dig +short TXT example.com
dig +short TXT default._domainkey.example.com
dig +short TXT _dmarc.example.com
dig +short MX example.com
dig +short -x 203.0.113.10
dig +short A mail.example.com

ثم أرسل رسالة إلى صندوق خارجي واعرض الرسالة الأصلية بترويساتها. ابحث عن الترويسة Authentication-Results:

text
Authentication-Results: mx.receiver.example;
       spf=pass smtp.mailfrom=example.com;
       dkim=pass header.d=example.com header.s=default;
       dmarc=pass header.from=example.com

إذا لم تصل الرسالة أصلًا، افتح تتبع التسليم في cPanel. ستعرف هل غادرت الرسالة الخادم، وما رد الخادم المستقبِل، مثل رفض برمز 550 مع سبب نصي.

مثال على سجلات DNS لمجال شركة

dns
example.com.                     3600 IN MX  10 mail.example.com.
mail.example.com.                3600 IN A   203.0.113.10
example.com.                     3600 IN TXT "v=spf1 a mx ip4:203.0.113.10 include:_spf.mailer.example.net ~all"
default._domainkey.example.com.  3600 IN TXT ( "v=DKIM1; k=rsa; "
                                               "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
                                               "...IDAQAB" )
_dmarc.example.com.              3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r"

; يُضبط عند مالك عنوان IP وليس في منطقة المجال
10.113.0.203.in-addr.arpa.       3600 IN PTR mail.example.com.

أضف هذه السجلات من Zone Editor. وإذا كانت خوادم الأسماء للمجال لدى جهة أخرى، فأضفها هناك، لأن السجلات في منطقة cPanel لن تُقرأ حينها. هذا خطأ شائع بعد النقل، وقد شرحناه في الاستعداد للنقل من cPanel دون توقف.

قائمة تحقق قبل أن تعتبر بريدك سليمًا

  • سجل SPF واحد فقط، وعدد استعلاماته أقل من 10.
  • كل جهة ترسل باسم المجال مذكورة في SPF ولها توقيع DKIM متوافق.
  • مفاتيح DKIM بطول 2048 بت، مع خطة مكتوبة لتدويرها.
  • سجل DMARC منشور ومعه rua، وهناك من يقرأ التقارير فعلًا.
  • خطة زمنية للانتقال من none إلى quarantine ثم reject.
  • سجل PTR للعنوان المرسِل يطابق سجل A واسم HELO.
  • البريد التسويقي يمر عبر خدمة مخصصة وعلى مجال فرعي، ومعه إلغاء اشتراك بنقرة واحدة.
  • ترويسة Authentication-Results تُظهر pass للثلاثة في رسالة اختبار.

كيف يساعدك bPanel في إعداد SPF وDKIM وDMARC؟

يوفّر bPanel إعدادًا موجّهًا لسجلات SPF وDKIM وDMARC لكل مجال: يقترح السجلات، ويحسب استعلامات SPF، وينبّه عند تعارضها. جرّبه على مجالاتك من ابدأ مع bPanel.

الخلاصة

  • ابدأ بالمصادقة: سجل SPF واحد، وتوقيع DKIM بطول 2048 بت، وسجل DMARC بتقارير.
  • التوافق مع عنوان From هو ما يجعل DMARC ينجح، وليس مجرد نجاح SPF أو DKIM.
  • تدرّج من p=none إلى p=reject بناءً على التقارير لا على التخمين.
  • افصل الإرسال التسويقي عن بريد العمل، وتحقق دائمًا بأمر dig وترويسات الرسائل.