ما هو SPF وDKIM وDMARC؟ ولماذا تذهب رسائلك إلى البريد المزعج؟

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

لماذا تصل الرسائل إلى مجلد السبام؟

يطرح خادم المستلم (Gmail أو Outlook أو Yahoo أو خادم شركة أخرى) على كل رسالة واردة ثلاثة أسئلة تقريبًا:

1. هل الخادم الذي أرسل الرسالة مسموح له من مالك النطاق بالإرسال؟ (SPF)
2. هل عُدّلت الرسالة في الطريق، وهل وقّعها النطاق فعلًا؟ (DKIM)
3. ماذا يريد مالك النطاق أن نفعل إذا فشلت هذه الفحوص؟ (DMARC)

إذا كانت الإجابة “غير معروف” أو “لا”، تذهب الرسالة إلى السبام أو تُرفض كليًا. وأكثر الرسائل تضررًا هي تلك التي تخرج من خدمات طرف ثالث: إشعارات نموذج التواصل في موقعك، ورسائل تأكيد الطلبات في متجرك الإلكتروني، والنشرات البريدية، ورسائل أنظمة CRM.

متطلبات Google وYahoo وMicrosoft

منذ فبراير 2024 تشترط Google وYahoo على من يرسل أكثر من نحو 5,000 رسالة يوميًا إلى مستخدميهما: اجتياز SPF وDKIM، ونشر سجل DMARC (ولو بسياسة p=none)، وتوافق نطاق From: مع أحدهما، ووجود رابط إلغاء اشتراك بنقرة واحدة في الرسائل التسويقية، وإبقاء معدل الإبلاغ عن السبام دون 0.3%. وفي نوفمبر 2025 شدّدت Gmail التطبيق فصارت ترفض جزءًا من الرسائل المخالفة. أما Microsoft فطبّقت منذ 5 مايو 2025 متطلبات مماثلة على Outlook.com وHotmail وLive للمرسلين بالكميات نفسها. حتى لو كنت ترسل أقل من ذلك، فهذه السجلات أصبحت معيارًا أساسيًا للوصول إلى صندوق الوارد.

SPF: من يحق له الإرسال باسم نطاقك؟

SPF (Sender Policy Framework) هو قائمة بالخوادم المسموح لها بإرسال البريد باسم نطاقك. يُضاف كسجل TXT على النطاق الجذري:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all

• v=spf1 يعرّف السجل على أنه SPF.
• include: يضمّ قائمة خدمة أخرى (Google Workspace، Microsoft 365، Zoho Mail، Mailchimp، Brevo…).
• ip4: وip6: يسمحان بعنوان IP محدد، مثل خادم الاستضافة الذي يرسل إشعارات الموقع.
• ~all في النهاية تعني “ما ليس في القائمة مشبوه” (softfail)، و-all تعني “ارفضه” (fail).

أخطاء شائعة:

DKIM: هل الرسالة سليمة وموقّعة؟

DKIM (DomainKeys Identified Mail) يضيف إلى كل رسالة صادرة توقيعًا رقميًا بالمفتاح الخاص لخادمك. يبحث المستلم عن المفتاح العام في DNS ليتحقق من التوقيع. يُنشر المفتاح تحت اسم يُسمّى المحدِّد (selector):

google._domainkey.example.com  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

لا تُنشئ مفتاح DKIM بنفسك؛ تحصل عليه من لوحة مزوّد البريد (في Google Workspace: التطبيقات ← Gmail ← مصادقة البريد الإلكتروني؛ وفي Microsoft 365: بوابة Defender ← إعدادات DKIM) ثم تضيفه إلى DNS. لكل خدمة إرسال محدِّد خاص بها، لذا من الطبيعي أن يكون لنطاقك أكثر من سجل DKIM. يُفضَّل استخدام مفتاح بطول 2048 بت إن كان مزوّدك يدعمه.

DMARC: ماذا يحدث عند الفشل؟

DMARC هو السياسة التي تربط SPF وDKIM معًا. يؤدي وظيفتين: يخبر المستلم بما يفعله بالرسائل التي تفشل، ويطلب منه إرسال تقارير إليك. يُضاف كسجل TXT على النطاق الفرعي _dmarc:

_dmarc.example.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

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

قراءة تقارير DMARC

تقارير rua ملفات XML مجمّعة تصلك يوميًا من المزوّدين الكبار، وتُظهر عناوين IP التي أرسلت باسم نطاقك ونتيجة SPF وDKIM لكل منها. قراءتها يدويًا مرهقة، لذا استخدم خدمة تحليل مجانية أو صندوقًا مخصصًا لها. ما تبحث عنه بسيط: هل توجد خدمة مشروعة (مثل نظام الفواتير أو منصة المتجر) تفشل؟ أصلحها قبل تشديد السياسة.

الإعداد خطوة بخطوة

1. افحص الوضع الحالي. أدخل نطاقك في أداة فحص SPF وDMARC لترى السجلات الناقصة أو الخاطئة.
2. اجمع قائمة بكل الجهات التي ترسل باسمك: البريد المؤسسي (Google أو Microsoft أو Zoho)، خادم الاستضافة (نماذج الموقع)، أداة النشرات، منصة المتجر (Shopify أو سلة أو زد مثلًا)، نظام CRM أو الفوترة.
3. أنشئ سجل SPF واحدًا يتضمن قيم include لهذه الخدمات، وتأكد أنه دون حد 10 استعلامات.
4. فعّل DKIM لكل خدمة وأضف السجلات التي تعطيك إياها إلى DNS.
5. انشر DMARC بسياسة p=none مع عنوان تقارير، وراقب التقارير بضعة أسابيع.
6. شدّد السياسة تدريجيًا: quarantine ثم reject. يمكنك استخدام pct= لتطبيق السياسة على نسبة من الرسائل أولًا.
7. تحقق من الانتشار: استخدم أداة استعلام DNS للتأكد من ظهور سجلات TXT الجديدة.

مشكلات خاصة بالمواقع والمتاجر

• دالة mail() في PHP: كثير من قوالب ووردبريس ترسل النماذج عبر خادم الاستضافة مباشرة دون مصادقة. استخدم إضافة SMTP واربطها بحساب بريد على نطاقك.
• نطاق المرسل في أداة النشرات: إذا كانت الأداة ترسل من نطاقها الخاص، فعّل خيار “النطاق المخصص” وأضف سجلات DKIM التي تطلبها.
• إعادة التوجيه (forwarding): قد يكسر SPF عند المستلم النهائي، ولهذا يبقى DKIM هو الضمانة الأقوى لاجتياز DMARC.
• تغيير مزوّد DNS أو الاستضافة: انقل كل سجلات TXT معك؛ ضياعها من أكثر أسباب انهيار التسليم المفاجئ. اطّلع على دليل سجلات DNS لفهم أنواعها.

قائمة تحقق سريعة

• للنطاق سجل v=spf1 واحد فقط، وهو دون حد 10 استعلامات DNS.
• DKIM مفعّل لكل خدمة ترسل باسم نطاقك.
• سجل _dmarc موجود بسياسة p=none على الأقل مع عنوان تقارير.
• نموذج التواصل في موقعك يرسل عبر حساب SMTP على نطاقك لا عبر mail().
• الرسائل التسويقية تحتوي رابط إلغاء اشتراك واضحًا بنقرة واحدة.
• تاريخ انتهاء النطاق ومزوّد DNS معروفان، ويمكن التحقق منهما عبر استعلام WHOIS.
• إذا كان موقعك يعمل لكن الرسائل لا تصل، راجع أيضًا دليل تعطل المواقع لاستبعاد مشكلات DNS العامة.