الرئيسية › أدلة

إعداد SPF وDKIM وDMARC: السجلات والأخطاء الشائعة وطرق التحقق

تاريخ النشر 2026-11-03 ／ آخر تحديث 2026-11-03 ／ الناشر Yuki Nakazawa

لم يعد إعداد SPF وDKIM وDMARC أمرًا اختياريًا إذا كنت ترسل البريد من نطاقك الخاص. نفّذه بهذا الترتيب: انشر سجل SPF واحدًا، وفعّل توقيع DKIM بمفتاح 2048 بت، ثم انشر سجل DMARC يبدأ بـ p=none مع تفعيل التقارير. وأثناء ذلك، تأكد من أن عنوان IP الذي يرسل بريدك له DNS عكسي (PTR) مطابق.

يصلح هذا الدليل سواء كنت ترسل من استضافة مشتركة، أو من VPS خاص بك، أو من Google Workspace، أو Microsoft 365، أو من خدمة بريد جماعي. ويقدّم لك سجلات يمكنك تكييفها، والأخطاء التي تُفسد المصادقة في أغلب الأحيان، وطريقة التأكد من أن كل شيء يعمل من خلال ترويسة رسالة حقيقية.

جرى التحقق من المعلومات الواردة أدناه بالرجوع إلى وثائق RFC والصفحات الرسمية لـ Google وYahoo وMicrosoft كما كانت في نوفمبر 2026. تتغير متطلبات مزوّدي البريد، لذا اعتبر صفحاتهم المرجع النهائي.

ما الذي يثبته كل من SPF وDKIM وDMARC، وترتيب إعدادها

يتيح SPF (Sender Policy Framework) للنطاق أن يحدد في DNS الخوادم المسموح لها بإرسال بريده. ينظر خادم الاستقبال إلى مرسِل المغلّف (عنوان SMTP MAIL FROM، الذي يظهر لاحقًا باسم Return-Path)، ويجلب سجل SPF لذلك النطاق، ويتحقق مما إذا كان عنوان IP المتصل مدرجًا في القائمة. وSPF وحده لا يقول شيئًا عن عنوان From الذي يراه القارئ.

يضيف DKIM (DomainKeys Identified Mail) توقيعًا تشفيريًا إلى كل رسالة. يوقّع نظام الإرسال بمفتاح خاص، ويتحقق المستلمون من التوقيع بمفتاح عام منشور في DNS. والتوقيع الصالح يثبت أن النطاق الموقِّع (قيمة d=) تحمّل مسؤولية الرسالة، وأن الترويسات الموقَّعة ونص الرسالة لم يُعدَّلا في الطريق.

يربط DMARC (Domain-based Message Authentication, Reporting and Conformance) الآليتين بنطاق From الظاهر. لا تجتاز الرسالة DMARC إلا إذا اجتازت SPF أو DKIM وكان النطاق الموثَّق متوافقًا مع نطاق From. ويخبر سجل DMARC المستلمين أيضًا بما تريد فعله بالرسائل الفاشلة (لا شيء، أو العزل، أو الرفض) وبالمكان الذي تُرسل إليه التقارير المجمّعة، وهي الطريقة التي تكتشف بها مصادر إرسال نسيتها.

ترتيب الإعداد

1. اذكر كل نظام يرسل البريد باسم نطاقك: خادمك الخاص، وGoogle Workspace أو Microsoft 365، وخدمات النشرات الإخبارية والبريد التفاعلي (transactional)، ونماذج الويب، وأدوات الفوترة ومكتب الدعم.
2. انشر سجل SPF واحدًا يغطيها جميعًا.
3. فعّل DKIM على كل نظام إرسال وانشر مفتاحه العام.
4. انشر DMARC بالقيمة p=none مع عنوان تقارير rua. تقترح Google الانتظار 48 ساعة بعد إعداد SPF وDKIM قبل إضافة DMARC.
5. اقرأ التقارير، وأصلح أي مصادر تفشل، ثم انتقل إلى p=quarantine وأخيرًا إلى p=reject.

إعداد SPF: سجل واحد وعشرة استعلامات

SPF سجل TXT على النطاق نفسه. إليك نطاقًا يرسل من خادمه الخاص عبر IPv4 وIPv6 ويستخدم أيضًا Google Workspace:

example.com.  3600  IN  TXT  "v=spf1 ip4:203.0.113.10 ip6:2001:db8::10 include:_spf.google.com ~all"

في معظم لوحات تحكم DNS تترك حقل المضيف فارغًا (أو تُدخل @)، وتختار TXT، وتلصق القيمة بدءًا من v=spf1. مكوّنات شائعة:

أخطاء SPF الشائعة

• سجل SPF واحد لكل اسم. يمنع RFC 7208 وجود عدة سجلات SPF للنطاق نفسه؛ إذ يعيد المستلمون permerror ويفشل SPF لكل الرسائل. عند إضافة خدمة، عدّل السجل الموجود وألحق به include: الخاص بها بدلًا من إنشاء سجل v=spf1 ثانٍ.
• حد 10 استعلامات. كل من الآليات include وa وmx وptr وexists والمُعدِّل redirect يستدعي استعلامات DNS، ويجب ألا يتجاوز المجموع في التقييم كله، بما في ذلك الاستعلامات داخل عبارات include المتداخلة، 10 استعلامات. وتجاوز ذلك يعطي permerror. أما ip4: وip6: وall فلا تكلّف شيئًا. ويذكر RFC 7208 أيضًا أن على المستلمين التوقف بعد استعلامين لا يعيدان أي إجابة، لذا أزل عبارات include الخاصة بخدمات لم تعد تستخدمها.
• ~all مقابل -all. تعني -all أن المصادر غير المدرجة غير مصرّح لها (fail)، وتعني ~all أنها على الأرجح غير مصرّح لها (softfail). توصي Google بـ ~all لنطاقات Workspace، وتوصي Microsoft بـ -all لنطاقات Microsoft 365 التي تستخدم DKIM وDMARC أيضًا. إذا لم تكن متأكدًا بعد من أنك وجدت كل المرسلين، فابدأ بـ ~all ودع DMARC يتولى الإلزام.
• النطاقات الفرعية تحتاج إلى سجلها الخاص. سجل SPF على example.com لا يغطي news.example.com. ووضع خدمة البريد الجماعي على نطاق فرعي خاص بها يمنحها أيضًا رصيدًا مستقلًا من 10 استعلامات، ويفصل سمعتها عن بريد موظفيك.
• أخطاء الصياغة. تذكر Microsoft الأخطاء المعتادة: include= بدلًا من include:، ومسافة بعد النقطتين، ونقطة زائدة في نهاية النطاق المضمَّن.

بالنسبة إلى النطاقات التي لا ترسل بريدًا أبدًا، انشر v=spf1 -all ليصعب انتحالها.

إعداد DKIM: مفاتيح 2048 بت والمحدِّدات

لـ DKIM شقّان: نظام الإرسال يوقّع بمفتاح خاص، وDNS ينشر المفتاح العام المقابل. مع Google Workspace وMicrosoft 365 ومعظم لوحات تحكم الاستضافة ومعظم خدمات البريد، تُنشئ المفتاح من لوحة الإدارة وتنسخ قيمة DNS التي تعرضها لك.

طول المفتاح والمحدِّدات

استخدم مفتاح RSA بطول 2048 بت. يجعل RFC 8301 طول 1024 بت حدًا أدنى، وينص على أن على الموقِّعين استخدام 2048 بت على الأقل؛ كما يحظر rsa-sha1. وتتفق إرشادات Google مع ذلك: اختر 2048 بت إذا كان مزوّد DNS يدعمه، ولا تلجأ إلى 1024 إلا إذا لم يكن يدعمه.

المحدِّد (selector) تسمية تحدد المفتاح الذي وقّع الرسالة، بحيث يمكن أن يكون للنطاق عدة مفاتيح في الوقت نفسه، مفتاح لكل خدمة إرسال أو لكل فترة تدوير. يوجد المفتاح العام عند selector._domainkey.yourdomain. يستخدم Google Workspace المحدِّد google افتراضيًا. أما Microsoft 365 فيستخدم سجلي CNAME هما selector1._domainkey وselector2._domainkey، يشيران إلى مفاتيح تستضيفها Microsoft؛ خذ الأهداف الدقيقة من بوابة Defender أو من Get-DkimSigningConfig، لأن الصيغة تختلف من مستأجر (tenant) لآخر.

نشر مفتاح عام طويل

المفتاح العام بطول 2048 بت أطول من 255 حرفًا المسموح بها في سلسلة أحرف DNS واحدة، لذا يُكتب في صيغة ملف المنطقة (zone file) على شكل عدة سلاسل بين علامتي تنصيص ضمن سجل TXT واحد:

selector1._domainkey.example.com.  3600  IN  TXT  ( "v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA(first part of your key)"
    "(rest of your key)IDAQAB" )

استبدل الأجزاء التي بين قوسين بمفتاحك الفعلي. يدمج المستلمون السلاسل دون أي مسافات بينها، لذا يمكنك التقسيم في أي موضع داخل المفتاح. كثير من لوحات التحكم تقسّم القيم الطويلة تلقائيًا: الصق القيمة كاملة أولًا، ولا تقسّمها بنفسك إلا إذا رفضتها اللوحة. وتأكد من عدم ضياع أي جزء أثناء النسخ؛ فقيمة p= فارغة تعني أن المفتاح قد أُلغي.

على VPS خاص بك يعمل عليه Postfix أو MTA مشابه، يمكن لمرشِّح توقيع (milter) مثل OpenDKIM إنشاء زوج المفاتيح، على سبيل المثال opendkim-genkey -b 2048 -s selector1 -d example.com. انشر محتوى ملف المفتاح العام الناتج كما هو موضح أعلاه.

تحقق من أن الرسائل موقَّعة فعلًا

افتح رسالة أرسلتها وابحث عن ترويسة DKIM-Signature:. يجب أن يكون الوسم d= فيها نطاقك، وs= المحدِّد الذي نشرته. كثير من خدمات البريد توقّع بنطاقها الخاص افتراضيًا؛ وهذا يجتاز DKIM لكنه لا يتوافق مع نطاق From الخاص بك، فلا يفيد DMARC. فعّل ميزة مصادقة النطاق المخصص في الخدمة حتى يصبح d= نطاقك.

إعداد DMARC: ابدأ بـ p=none ثم انتقل إلى الإلزام

DMARC سجل TXT عند _dmarc تحت نطاقك. ابدأ بوضع المراقبة، الذي يطلب من المستلمين عدم تغيير طريقة تعاملهم مع بريدك، واطلب التقارير المجمّعة:

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

التقارير المجمّعة ملخصات قابلة للقراءة آليًا تبيّن عناوين IP التي أرسلت البريد باسم نطاقك وما إذا كان قد اجتاز الفحص؛ وتقترح Google صندوق بريد أو مجموعة مخصصة لاستقبالها. وبمجرد أن تُظهر التقارير أن كل مصدر مشروع يجتاز الفحص مع التوافق، شدّد السياسة بتعديل السجل نفسه بدلًا من إضافة سجل ثانٍ:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

التوافق (alignment) بعبارة بسيطة

لاجتياز DMARC، يجب أن يجتاز SPF أو DKIM على الأقل الفحص لنطاق يطابق نطاق From. في الوضع المرن يجب أن تتطابق النطاقات التنظيمية، فيتوافق توقيع DKIM بالقيمة d=example.com مع البريد المرسل من alerts@news.example.com. أما الوضع الصارم فيتطلب تطابقًا تامًا. كثيرًا ما تستخدم خدمات البريد نطاقها الخاص في Return-Path، فلا يتوافق SPF حتى لو اجتاز الفحص؛ ويكون DKIM المتوافق هو الطريقة العملية لتمرير تلك الرسائل عبر DMARC.

إذا أردت سياسة مختلفة للنطاقات الفرعية، فأضف sp=. على سبيل المثال، p=reject; sp=quarantine يرفض البريد الفاشل من النطاق الرئيسي بينما يكتفي بعزل الرسائل الفاشلة من النطاقات الفرعية.

ملاحظة حول المعيار المحدَّث

في مايو 2026 أُعيد نشر DMARC بوصفه RFC 9989، الذي يحل محل RFC 7489. السجلات الحالية تظل تعمل، ولا تزال تبدأ بـ v=DMARC1. ويُسقط المعيار الجديد الوسم pct، الذي نادرًا ما طُبّق بدقة إلا عند القيمتين 0 أو 100، ويضيف وسومًا مثل t=y (وضع الاختبار) وnp (سياسة النطاقات الفرعية غير الموجودة). لا تزال بعض صفحات المساعدة لدى المزوّدين تعرض pct، لذا فإن الطريقة الأقل لبسًا لتطبيق الإلزام هي التدرج عبر قيم p=.

DNS العكسي (PTR) لعنوان IP المُرسِل

يربط DNS العكسي عنوان IP باسم مضيف. تشترط Google على كل من يرسل إلى حسابات Gmail الشخصية أن يكون لديه سجل PTR يُحَلّ اسم المضيف فيه مرة أخرى إلى عنوان IP المُرسِل نفسه، وتشترط Yahoo وجود DNS أمامي وعكسي صالح لعناوين IP المُرسِلة وتوصي بسجل PTR ذي معنى وغير عام.

203.0.113.10       PTR  mail.example.com.
mail.example.com.  A    203.0.113.10

سجل PTR ليس جزءًا من منطقة نطاقك. فمالك عنوان IP هو من يتحكم فيه، لذا تضبطه على VPS من لوحة تحكم المزوّد (وكثيرًا ما يُسمى reverse DNS أو rDNS)، ثم تنشئ سجل A مطابقًا (أو AAAA في حالة IPv6) في DNS الخاص بك. إذا كنت ترسل عبر IPv6، فعنوان IPv6 يحتاج إلى المعالجة نفسها. ومع Google Workspace وMicrosoft 365 وخدمات البريد ومعظم الاستضافات المشتركة، يدير المزوّد عناوين IP المُرسِلة وDNS العكسي الخاص بها نيابة عنك.

كيف تتحقق من إعدادك

اقرأ Authentication-Results

أرسل رسالة اختبار إلى صندوق بريد خارجي واعرض الترويسات الكاملة. في Gmail، افتح الرسالة واختر "عرض الرسالة الأصلية". وتشير مساعدة Google الخاصة بـ DKIM إلى أن عليك الإرسال إلى مستخدم آخر بدلًا من نفسك. ابحث عن ترويسة مثل هذه:

Authentication-Results: mx.example.net;
       dkim=pass header.i=@example.com header.s=selector1;
       spf=pass smtp.mailfrom=example.com;
       dmarc=pass header.from=example.com

يختلف التنسيق الدقيق من مستلم لآخر. المهم هو spf=pass وdkim=pass وdmarc=pass، مع ظهور نطاقك في header.i أو header.d وفي header.from. إذا اجتاز SPF الفحص لنطاق خدمة ما بينما يُظهر DKIM نطاقًا آخر، فسيفشل DMARC: أصلح توافق DKIM أولًا.

استعلم عن DNS مباشرة

dig +short TXT example.com
dig +short TXT selector1._domainkey.example.com
dig +short TXT _dmarc.example.com
dig +short -x 203.0.113.10

على Windows، يؤدي الأمر nslookup -type=TXT _dmarc.example.com المهمة نفسها. قد يستغرق انتشار تغييرات DNS بعض الوقت؛ إذ تذكر Google أن كلًا من SPF وDKIM قد يستغرق ما يصل إلى 48 ساعة ليبدأ العمل. ويمكن لأدوات الفحص المجانية على الإنترنت أيضًا تحليل سجلاتك وعدّ استعلامات SPF نيابة عنك.

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

متطلبات المرسلين لدى Gmail وYahoo وOutlook.com

يُلزم كبار مزوّدي البريد الآن بالمصادقة. وحتى نوفمبر 2026، تنص صفحاتهم الرسمية على ما يلي.

• Gmail (ساري المفعول منذ 1 فبراير 2024): كل من يرسل إلى حسابات Gmail الشخصية يحتاج إلى SPF أو DKIM، وDNS أمامي وعكسي متطابقين، واتصال TLS، ونسبة بريد عشوائي أقل من 0.3% في Postmaster Tools. ومن يرسلون أكثر من 5,000 رسالة يوميًا يحتاجون أيضًا إلى SPF وDKIM معًا، وسجل DMARC (القيمة p=none مقبولة)، ونطاق From متوافق مع SPF أو DKIM، وإلغاء اشتراك بنقرة واحدة للبريد التسويقي. ويجب ألا يقل طول مفاتيح DKIM عن 1024 بت، مع التوصية بـ 2048.
• Yahoo (الإلزام اعتبارًا من فبراير 2024): يحتاج كل المرسلين إلى SPF أو DKIM، وDNS أمامي وعكسي صالح، ونسبة بريد عشوائي أقل من 0.3%. ويحتاج المرسلون بالجملة إلى SPF وDKIM معًا، وسياسة DMARC لا تقل عن p=none وتجتاز الفحص، وتوافق From (الوضع المرن كافٍ)، وإلغاء اشتراك يعمل بنقرة واحدة، وDNS أمامي وعكسي صالح لعناوين IP المُرسِلة.
• Outlook.com (الخدمة الاستهلاكية التي تقف وراء outlook.com، hotmail.com، live.com): النطاقات التي ترسل أكثر من 5,000 رسالة يوميًا يجب أن تجتاز SPF وDKIM وتنشر DMARC لا يقل عن p=none، متوافقًا مع SPF أو DKIM. وذكرت Microsoft أنه اعتبارًا من 5 مايو 2025 ستُرفض الرسائل غير المتوافقة بالخطأ 550; 5.7.515.

اقرأ النص الكامل في إرشادات Google لمرسلي البريد الإلكتروني، وأفضل ممارسات المرسلين لدى Yahoo، وإعلان Microsoft بشأن Outlook.com. وحتى إن كنت ترسل رسائل أقل بكثير، فإن إعداد الآليات الثلاث الآن يعني أن خفض الحد لاحقًا لن يفاجئك. ولحل المشكلات الخاصة بـ Gmail، راجع عدم وصول بريدك إلى Gmail.

أخطاء شائعة

• سجل SPF ثانٍ. إضافة سجل v=spf1 جديد لكل خدمة يُبطل SPF للنطاق كله. ادمج كل شيء في سجل واحد.
• عبارات include كثيرة جدًا. الخدمات القديمة المتروكة في SPF تستهلك من رصيد 10 استعلامات. أزل ما لم تعد تستخدمه وانقل البريد الجماعي إلى نطاق فرعي.
• المفتاح منشور لكن التوقيع غير مفعّل. في Google Workspace لا يزال عليك النقر على "بدء المصادقة" بعد أن يصبح سجل DNS فعّالًا؛ ولدى المنصات الأخرى مفتاح تشغيل مشابه.
• الخدمة توقّع بنطاقها الخاص. يجتاز SPF وDKIM كلاهما الفحص، ويفشل DMARC. فعّل التوقيع بالنطاق المخصص.
• القفز مباشرة إلى p=reject. يتوقف نموذج ويب منسي أو نظام فوترة عن التسليم بين ليلة وضحاها. ابدأ بـ p=none واقرأ التقارير.
• أضرار النسخ واللصق. علامات تنصيص زائدة داخل القيمة، أو مفتاح مبتور، أو اسم مضيف ينتهي إلى _dmarc.example.com.example.com لأن اللوحة تضيف النطاق تلقائيًا. والفحص السريع بالأمر dig يكشف كل ذلك.

الأسئلة الشائعة

الصفحات الرسمية المعتمدة

جرى التحقق من المعلومات الواردة في هذه المقالة بالرجوع إلى الصفحات الرسمية أدناه وقت النشر. قد تتغير السياسات وطريقة العمل دون إشعار، لذا راجع الصفحات الرسمية قبل الاعتماد على أي أمر مهم.

• RFC 7208: Sender Policy Framework (SPF)
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
• RFC 8301: Cryptographic Algorithm and Key Usage Update to DKIM
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 9989: DMARC (obsoletes RFC 7489)
• Google: Email sender guidelines
• Google Workspace: Set up SPF
• Google Workspace: Set up DKIM
• Google Workspace: Set up DMARC
• Yahoo Sender Hub: Sender Best Practices
• Microsoft Community Hub: Outlook's New Requirements for High-Volume Senders
• Microsoft Learn: Set up SPF for your Microsoft 365 domain
• Microsoft Learn: How to use DKIM for email in your custom domain

أدلة ذات صلة

جميع الأدلة →