الأدلةالمصادقة

DMARC يفشل مع أن SPF وDKIM ينجحان

الفحصان يقولان pass، وDMARC يقول fail مع ذلك. السبب نطاق لا يطابق عنوان From لديك. رسالة اختبار واحدة تبيّن أي نطاق هو، والإصلاح إعداد لدى من يرسل البريد.

آخر تحديث: 5 أكتوبر 2026مدة القراءة بالدقائق: 9

باختصار

DMARC ينجح فقط إذا نجح SPF أو DKIM للنطاق الذي في عنوان From لديك. والنجاح لنطاق مزودك لا يُحتسب.
افتح رسالة مرسلة في Gmail عبر Show original وقارن smtp.mailfrom وheader.i وheader.from في رأس Authentication-Results.
أصلح DKIM أولًا: فعّل التوقيع بنطاقك أنت لدى كل خدمة ترسل باسمك. توقيع DKIM يصمد عند إعادة التوجيه، وSPF لا يصمد.
النطاق الفرعي قريب بما يكفي افتراضيًا. وإذا كان سجل DMARC لديك يحتوي على adkim=s أو aspf=s، فليس كذلك.
التهيئة لا تصلح المطابقة (alignment). رسائل التهيئة تُرسل عبر صندوق بريدك وتفشل معه.

DMARC لا يسأل هل نجح SPF وDKIM. يسأل هل نجح أحدهما للنطاق الذي في عنوان From لديك. إذا نجح SPF لنطاق الارتداد لدى مزودك ونجح DKIM لنطاق التوقيع لدى مزودك، فالسطران يقولان «pass» وDMARC يقول «fail» مع ذلك. الإصلاح عند الجهة المرسِلة: اجعلها توقّع بنطاقك، أو استخدم عنوان ارتداد على نطاقك. وأحد الأمرين يكفي.

اسم هذا التطابق في المعيار alignment (المطابقة). وهو الجزء من DMARC الذي لا تستطيع أداة فحص DNS أن تراه. هل بريدك مطابق أم لا، لا يظهر إلا في رسالة أُرسلت فعلًا. وهذه الصفحة تبيّن كيف تقرأ واحدة.

ثلاثة نطاقات تسافر مع كل رسالة

تحمل الرسالة نطاقك في ما يصل إلى ثلاثة مواضع. وكل فحص ينظر إلى موضع مختلف.

راية كحلية عليها شعار ظرف، وكيس بريد عليه بطاقة نحاسية، ورسالة بختم شمع، جنبًا إلى جنب على رصيف. الختم يكرر شعار الراية، والبطاقة لا تكرره — الراية هي سطر From، والبطاقة على كيس البريد هي Return-Path، وختم الشمع هو توقيع DKIM. يريد DMARC أن تطابق البطاقة أو الختم الراية.

الموضع	يسمى أيضًا	من ينظر إليه
سطر From الذي يراه قارئك	Header From، `header.from`	DMARC. وهو المقياس للاثنين الآخرين.
Return-Path	مرسل المغلّف (envelope sender)، MAIL FROM، عنوان الارتداد، `smtp.mailfrom`	SPF. يتحقق هل يحق للخادم المرسِل استخدام هذا النطاق.
قيمة `d=` في رأس DKIM-Signature	نطاق التوقيع، `header.d` أو `header.i`	DKIM. يتحقق هل توقيع هذا النطاق صالح.

SPF (RFC 7208) وDKIM (RFC 6376) يجيب كل منهما عن سؤال ضيق، ولا يذكر أي من السؤالين سطر From لديك. تستطيع خدمة نشرات بريدية أن تنجح في SPF لنطاق الارتداد الخاص بها وأن توقّع بمفتاحها، وتدّعي الرسالة مع ذلك أنها منك. DMARC يسد هذه الثغرة. RFC 9989، وهو معيار DMARC منذ مايو 2026، لا يقبل نتيجة إلا إذا كان النطاق الذي وراءها يطابق نطاق From، ويذكر السبب في حالة DKIM بجملة واحدة:

يشترط DMARC تطبيق مطابقة المعرّف (Identifier Alignment) على المعرّف المصادَق عليه عبر DKIM، لأن الرسالة قد تحمل توقيعًا صالحًا من أي نطاق، حتى نطاق يستخدمه طرف سيئ النية.

والأمر نفسه يصح في SPF، فأي شخص يستطيع نشر سجل SPF لنطاق يملكه. فالقاعدة إذن: ينجح DMARC إذا نجح SPF وكان نطاقه مطابقًا، أو إذا نجح DKIM وكان نطاقه مطابقًا.

اعثر على عدم التطابق في رسالة حقيقية واحدة

تحتاج إلى رسالة واحدة مرسلة بالطريقة التي يُرسل بها بريدك الحقيقي، وإلى عنوان Gmail يستقبلها.

أرسل رسالة من صندوق البريد أو الأداة المعنية إلى عنوان Gmail تستطيع فتحه.
افتحها في Gmail على حاسوب. بجانب Reply (رد)، انقر More ثم Show original (عرض الأصل). تصف Google الخطوات نفسها في Trace an email with its full header (تتبّع رسالة برأسها الكامل).
ابحث عن الرأس Authentication-Results، وفيه يدوّن الخادم المستقبِل نتيجة فحوصه (RFC 8601). قارن ثلاث قيم: النطاق بعد smtp.mailfrom=، والنطاق بعد header.i=@ (بعض المستقبِلين يكتبون header.d=)، والنطاق بعد header.from=. ودليل كيف تقرأ رؤوس الرسالة يمر على ذلك السطر خطوة بخطوة.

هذا نمط رسالة تنجح في SPF وDKIM وتفشل في DMARC. الرأس مختصر ويستخدم نطاقات أمثلة:

From: anna@example.com
Return-Path: <bounces@send.vendor-mail.example>

Authentication-Results: mx.google.com;
       dkim=pass header.i=@vendor-mail.example header.s=s1;
       spf=pass smtp.mailfrom=bounces@send.vendor-mail.example;
       dmarc=fail header.from=example.com

اقرأه من الأسفل. نطاق From هو example.com. نجح SPF، لكن للنطاق send.vendor-mail.example. ونجح DKIM، لكن التوقيع يعود إلى vendor-mail.example. لا أحد منهما example.com، فلا شيء يشهد للاسم الذي في سطر From.

بعد إعداد الخدمة لتوقّع بنطاقك، تبدو الرسالة نفسها هكذا:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=s1;
       spf=pass smtp.mailfrom=bounces@send.vendor-mail.example;
       dmarc=pass header.from=example.com

ما زال SPF يشير إلى الشركة صاحبة الخدمة. ولا بأس بذلك. DKIM صار مطابقًا، ونجاح واحد مطابق هو كل ما يحتاجه DMARC.

ما القرب الكافي: المتساهل والصارم

لا يلزم أن يكون النطاقان متماثلين. المطابقة افتراضيًا متساهلة (relaxed): يكفي أن ينتمي الاثنان إلى النطاق المسجّل نفسه، ويسميه المعيار النطاق التنظيمي (organizational domain). أما المطابقة الصارمة (strict) فتشترط تماثلًا تامًا. وتختار بالوسمين adkim لفحص DKIM وaspf لفحص SPF في سجل DMARC لديك.

نجح SPF أو DKIM للنطاق	نطاق From	متساهل (افتراضي)	صارم
`example.com`	`example.com`	مطابق	مطابق
`mail.example.com`	`example.com`	مطابق	غير مطابق
`example.com`	`news.example.com`	مطابق	غير مطابق
`vendor-mail.example`	`example.com`	غير مطابق	غير مطابق

يذكر المعيار أن «كل مالكي النطاقات تقريبًا وجدوا المطابقة المتساهلة كافية لتلبية حاجاتهم». ومع ذلك راجع سجلك أنت. السجل المثال في أعلى صفحة Set up DMARC لدى Google ينتهي بالوسمين adkim=s; aspf=s، فالسجل المنسوخ من هناك صارم. وإذا كان في سجلك هذان الوسمان وأداة ترسل من نطاق فرعي، فاحذفهما. وGoogle نفسها تحذّر في تلك الصفحة من أن المطابقة الصارمة «قد تؤدي إلى رفض الرسائل الصادرة عن النطاقات الفرعية المرتبطة أو إرسالها إلى البريد المزعج».

من أين يأتي عدم التطابق في العادة

خدمة ترسل من خوادمها هي

منصات النشرات البريدية وأنظمة CRM وأدوات الفوترة ومكاتب المساعدة ترسل بريدك من بنيتها هي. وإلى أن تربط نطاقك، تستخدم في العادة عنوان ارتداد على نطاقها وتوقّع بمفتاحها. ووثائق Amazon تقول بوضوح لماذا تندر مطابقة SPF هنا: Return-Path «يُستخدم للارتدادات والشكاوى التي يتتبّعها المزود (SES) بعنوان يملكه» (Amazon SES). والإعداد الذي يصلح ذلك له اسم مختلف في كل خدمة، وينتهي ببضعة سجلات DNS من جهتك.

الخدمة	قبل أن تربط نطاقك	الإعداد الذي تبحث عنه
Twilio SendGrid	يظهر البريد مرسلًا «».	Domain authentication: سجلات CNAME لنطاق فرعي للارتداد ومفتاحَي DKIM.
Amazon SES	Return-Path نطاق فرعي من `amazonses.com`.	Easy DKIM للتوقيع، وcustom MAIL FROM domain لأجل SPF.
Mailchimp	النطاق متحقَّق منه لكنه غير مصادَق عليه.	Email domain authentication: سجلا CNAME لأجل DKIM.

هذه أوصاف الشركات نفسها حتى أكتوبر 2026. والخدمات الأخرى تعمل على المنوال نفسه. ابحث في مساعدتها عن «authenticate domain» أو «custom DKIM» أو «branded sending domain».

مزود بريدك يوقّع بنطاقه هو، أو لا يوقّع إطلاقًا

مع صندوق بريد على نطاقك الخاص، يكون Return-Path عادة عنوانك أنت، فيطابق SPF حالما يذكر سجل SPF لديك المزود. والقيمة بعد smtp.mailfrom= تخبرك. DKIM هو الجزء الذي يحتاج إلى تفعيل.

Google Workspace. إلى أن تفعّل DKIM لنطاقك، ظلت Google توقّع بأحد نطاقاتها. نسخة سابقة من صفحة المساعدة لدى Google كانت تقول إن Gmail يوقّع عندها «بمفتاح نطاق DKIM الافتراضي هذا: ». الصفحة الحالية لم تعد تذكر النطاق، فراجع رأس رسالتك أنت: قيمة header.i تنتهي بالنطاق gappssmtp.com تعني أن مفتاحك غير مفعّل. أنشئه في Admin console تحت Apps ثم Google Workspace ثم Gmail ثم Authenticate email، وأضف سجل TXT الذي يعرضه لك، ثم انقر Start authentication (Set up DKIM).
Microsoft 365. وثائق Microsoft، المحدَّثة في أغسطس 2026، تنص: «حاليًا لا يجري أي توقيع DKIM للبريد الصادر من النطاقات المخصصة». تنشر سجلَي CNAME وتفعّل التوقيع في Defender portal (How to use DKIM for email in your custom domain).

السجل الذي تضيفه لمفتاح DKIM يقع دائمًا تحت _domainkey، باسم يختاره المزود. وفي Google Workspace يبدو هكذا، والمفتاح مختصر:

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

الأداة التي تتصل بصندوق بريدك وترسل عبره لا تضيف توقيعًا من عندها. بريد أداة كهذه يشبه تمامًا البريد الذي تكتبه بيدك، فالإصلاح عند مزود البريد لا في الأداة.

الرسالة أُعيد توجيهها

حين يعيد مستلم توجيه بريدك تلقائيًا، يصل من خادم لا يذكره سجل SPF لديك. فيفشل SPF أو ينجح لنطاق من أعاد التوجيه. أما توقيع DKIM فيصمد في الرحلة ما دام لا أحد يغيّر الرسالة. والقوائم البريدية التي تضيف تذييلًا أو وسمًا في الموضوع تكسر التوقيع أيضًا. لا تستطيع إصلاح ذلك من جهتك. وتقول أسئلة المرسلين الشائعة لدى Google إنه في Gmail «مطابقة DMARC غير مطلوبة للرسائل المعاد توجيهها أو رسائل القوائم البريدية». وهذا سبب لأن يكون DKIM مطابقًا وألا تعتمد على SPF وحده.

رسالة مختومة تنتقل من قارب بريد إلى آخر. لكل قارب كيس بريده وبطاقته، وختم الشمع على الرسالة سليم — إعادة التوجيه تبدّل كيس البريد وبطاقته. والختم على الرسالة يبقى سليمًا.

ليس بريدك

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

أصلح DKIM أولًا، ثم SPF

أي منهما يمنحك نتيجة pass. لكن DKIM هو الأفضل، لأنه يسافر مع الرسالة. أفضل الممارسات لدى M3AAWG تصوغها قاعدة: «وقّع كل البريد الصادر بمفتاح DKIM يطابق نطاق رأس RFC5322.From». وRFC 9989 يوصي باستخدام الاثنين.

عدّد كل ما يرسل باسم نطاقك. صناديق البريد، وأداة النشرات البريدية، ونظام CRM، والفواتير، ونموذج الاتصال في موقعك. وتقارير DMARC تذكر ما نسيته.
اختبر كل واحد بفحص الرأس أعلاه ودوّن أي النطاقين ليس نطاقك.
فعّل التوقيع بنطاقك حيثما أظهر header.i اسمًا آخر، وانشر السجلات التي تعطيك إياها الخدمة. اختر مفتاحًا من 2048 بت إذا كان مزود DNS لديك يقبله. Gmail يشترط 1024 بت على الأقل ويوصي بمفتاح من 2048.
اضبط نطاق ارتداد مخصصًا حيث تتيحه الخدمة، على نطاق فرعي مثل bounce.example.com. فيصير SPF مطابقًا أيضًا.
أرسل الاختبار من جديد وابحث عن dmarc=pass. تغييرات DNS قد تأخذ وقتًا. وتمهل Google حتى 48 ساعة ليبدأ مفتاح DKIM جديد في العمل.

ما لا ينفع هو إضافة الشركة إلى سجلاتك أنت. وجود include: للشركة في سجل SPF لديك لا يغيّر شيئًا إذا كان Return-Path على نطاق الشركة، لأن SPF يبحث عن سجل ذلك النطاق لا سجل نطاقك. وسجل DMARC لا يستطيع أيضًا أن يعدّد أطرافًا ثالثة موثوقة. يقول المعيار إنه «لا توجد آلية مقبولة عمومًا» لذلك.

إذا أظهر الرأس dmarc=pass وما زالت الرسالة تصل إلى البريد المزعج، فالمصادقة لم تعد السبب. ودليل SPF وDKIM وDMARC ناجحة، لكن الرسالة ما زالت تصل إلى البريد المزعج يكمل من هناك.

ما كلفة فشل DMARC وسياستك

مع p=none تطلب من المستقبِلين ألا يتخذوا إجراء عند الفشل، فلا شيء يُرفض بسبب سياستك. ومع ذلك يُحتسب عليك بطريقتين.

قواعد المرسلين بكميات كبيرة. Gmail وYahoo وOutlook.com تشترط بريدًا مطابقًا على المرسلين بكميات كبيرة، ومعناه لدى Gmail و من 5,000 رسالة يوميًا. وأسئلة المرسلين الشائعة لدى Google تذكر الخطأ المؤقت 4.7.32 للبريد الذي رأس From فيه «لا يطابق النطاق التنظيمي المصادَق عليه في SPF ولا في DKIM»، وتذكر العاقبة: «رموز فشل مؤقت أو دائم، أو الإحالة إلى مجلد البريد المزعج».
يسد الخطوة التالية. حالما تنتقل إلى p=quarantine أو p=reject، يصير كل بريد غير مطابق من بريدك أنت عرضة لأن يُعامل كبريد مزعج أو يُرفض. وفي Gmail نص الارتداد هو «Unauthenticated email from domain-name is not accepted due to domain's DMARC policy»، الخطأ 5.7.26 (Troubleshoot DMARC issues).

إذا لم يكن لديك سجل DMARC إطلاقًا، فابدأ من السجل الذي تضيفه. وهو يفعّل أيضًا التقارير التي تعرض المطابقة لكل مرسليك دفعة واحدة.

ما تستطيعه التهيئة هنا وما لا تستطيعه

التهيئة لا تصلح المطابقة. WarmupBay يتصل بصندوق بريدك ويرسل منه، فرسائل التهيئة يرسلها مزودك ويوقّعها تمامًا كالبريد الذي تكتبه بنفسك. وإذا فشل صندوق بريدك في DMARC، فشلت معه. أصلح السجلات أولًا.

WarmupBay يساعد في ما قبل ذلك وما بعده. عند ربط صندوق بريد، يفحص SPF وDKIM وDMARC للنطاق، ويوقف التهيئة إن بقيت ناقصة بعد 72 ساعة. وحين تصير في مكانها، يتبادل صندوق بريدك بضع رسائل يوميًا مع صناديق بريد أخرى في شبكة مشتركة، وتعرض لوحة المتابعة أين وصلت: البريد الوارد، أو تبويب في Gmail، أو البريد المزعج، لدى Google ولدى المزودين الآخرين كل على حدة. لا يختبر بريد أداة النشرات أو نظام CRM لديك، لأن ذلك البريد لا يمر بصندوق بريدك أبدًا، ولا يستطيع بعد ربط صناديق بريد Microsoft 365 أو . وهو مجاني لعشر رسائل تهيئة يوميًا. اربط صندوق بريدك حين يُظهر الرأس dmarc=pass.

أسئلة شائعة

SPF ينجح وهو مطابق، وDKIM غير مطابق. هل يكفي ذلك؟

في DMARC، نعم. نجاح واحد مطابق يكفي. لكنه لا يعود كافيًا حين يعيد مستلم توجيه بريدك، لأن SPF لا يطابق عندها. وتكتب Google أيضًا في أسئلة المرسلين الشائعة أن المطابقة مع SPF وDKIM معًا ستصير على الأرجح متطلبًا، فأعدّ DKIM لنطاقك على أي حال.

لماذا يفشل DMARC عند بعض المستلمين وينجح عند آخرين؟

لأن البريد يصلهم بطرق مختلفة أو من مرسلين مختلفين. المستلم الذي يعيد التوجيه إلى صندوق بريد آخر، أو القائمة البريدية، يغيّر ما يراه SPF وأحيانًا DKIM. وقد يكون السبب أيضًا خدمة واحدة من عدة خدمات إرسال لم تُعدّ بعد. التقارير المجمّعة تعرض النتائج بحسب الخادم المرسِل وتبيّن أي حالة هي.

هل لعنوان Reply-To دور في DMARC؟

لا. DMARC يستخدم فقط النطاق الذي في رأس From. عنوان Reply-To والاسم المعروض ورأس Sender ليست جزءًا من الفحص.

كيف أرى مشاكل المطابقة دون فتح الرؤوس؟

في تقارير DMARC المجمّعة. في كل سجل كتلة policy_evaluated فيها نتيجة dkim ونتيجة spf، وهما النتيجتان بعد اختبار المطابقة. وكتلة auth_results تحتها تعرض النتائج الخام والنطاقات التي تخصها. نتيجة pass خام بجانب fail بعد التقييم هي بالضبط الحالة التي تتناولها هذه الصفحة. وتحصل على التقارير بإضافة عنوان rua إلى سجل DMARC.

الرأس يقول dkim=fail أو dkim=neutral. هل هذه المشكلة نفسها؟

لا. عندها التوقيع نفسه لم يجتز التحقق، وهذا عطل مختلف. إذا كان النص body hash did not verify، فصفحة حل المشاكل لدى Google تذكر السبب: الرسالة غُيّرت بعد توقيعها، مثلًا عبر بوابة تضيف تذييلًا. أما المطابقة فتخص توقيعًا صالحًا لكنه يعود إلى نطاق آخر.

هل أحتاج إلى مفتاح DKIM مستقل لكل خدمة ترسل باسمي؟

عمليًا، نعم. كل خدمة توقّع بمفتاحها وتنشره تحت اسم المحدِّد (selector) الخاص بها أسفل _domainkey على نطاقك، فتوجد عدة مفاتيح جنبًا إلى جنب دون تعارض. وهذا يختلف عن SPF، حيث لا يجوز أن يكون للنطاق إلا سجل واحد.