كيفية توثيق نطاق الإرسال: دليل إعداد SPF وDKIM وDMARC

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

النسخة المختصرة

1. تحقق مما هو موجود. ابحث عن سجلات SPF وDKIM وDMARC الحالية لديك كي تعدّلها بدلًا من تكرارها.
2. انشر سجل SPF واحدًا. سجل TXT واحد في جذر النطاق يتضمن كل خدمة ترسل باسمك.
3. انشر DKIM. سجل المحدِّد (selector) من لوحة التحكم، ليُوقَّع كل رسالة.
4. انشر DMARC بالسياسة p=none. ابدأ بوضع المراقبة مع عنوان لاستقبال التقارير.
5. تحقق. شغّل dig، ثم أرسل رسالة تجريبية واقرأ ترويستها.
6. فعّل الإنفاذ. راجع التقارير، ثم انتقل إلى p=quarantine ثم p=reject.

ماذا يعني توثيق نطاق الإرسال؟

صُمّم البريد الإلكتروني دون وسيلة للتحقق من هوية مرسِل الرسالة. إذ يستطيع أي شخص كتابة عنوانك في حقل From، وهذا سبب انتشار التصيّد وانتحال الهوية. يسد التوثيق هذه الثغرة بثلاثة فحوصات متكاملة، يجيب كل منها عن سؤال مختلف للخادم المستقبِل:

• هل يُسمح لهذا الخادم بالإرسال عن هذا النطاق؟ هذا هو SPF (إطار سياسة المرسِل، المعرَّف في RFC 7208).
• هل الرسالة صادرة فعلًا من هذا النطاق ولم تتغير؟ هذا هو DKIM (DomainKeys Identified Mail، وفق RFC 6376).
• ماذا يحدث إذا فشل أحد الفحصين، ومن يتلقى التقرير؟ هذا هو DMARC (RFC 7489).

تجمع الخوادم المستقبِلة الفحوصات الثلاثة في إشارة ثقة واحدة. فالرسائل التي تجتاز التوثيق وتتوافق مع نطاق From لديك تبني سمعة نطاق مستقرة مع الوقت. أما التي لا تفعل فتُفلتر أو تتأخر أو تُرفض، وتُرفض الآن صراحةً عند أحجام الإرسال الكبيرة لدى كبار مزوّدي البريد.

SPF وDKIM وDMARC في لمحة

	SPF	DKIM	DMARC
ما الذي يثبته	أن الخادم المرسِل مخوَّل للنطاق	أن الرسالة وُقّعت من النطاق ولم تتغير أثناء النقل	أن الفحوصات تتوافق مع نطاق From الظاهر، ويحدد السياسة
موضعه في DNS	سجل TXT في جذر النطاق	TXT أو CNAME عند selector._domainkey	سجل TXT عند _dmarc
ما الذي يُفحص	نطاق Return-Path (مرسِل المظروف) وعنوان IP المرسِل	التوقيع في ترويسة DKIM-Signature	نطاق ترويسة From مقابل نتائج SPF وDKIM
هل يصمد أمام إعادة التوجيه؟	عادةً لا	نعم، إذا لم يتغير المحتوى	ينجح إذا نجح DKIM وتوافق
السبب الرئيسي للفشل	مرسِل مفقود أو أكثر من 10 عمليات بحث	محدِّد خاطئ أو مفتاح منسوخ بشكل غير صحيح	عدم تطابق المحاذاة

قبل أن تبدأ: ما الذي تحتاج إليه

• صلاحية تعديل DNS للنطاق (لدى المسجّل أو Cloudflare أو cPanel أو مزوّد DNS).
• قائمة بكل خدمة ترسل بريدًا باسم نطاقك: حساب MigoSMTP، وبريد المكتب (Google Workspace أو Microsoft 365)، وأنظمة CRM والفوترة والدعم.
• صندوق بريد لاستقبال تقارير DMARC، ويفضّل عنوان مخصص مثل dmarc-reports على نطاقك.
• قيمتا SPF include وسجل DKIM من صفحة النطاقات (Domains) في لوحة تحكم MigoSMTP.

الخطوة 1: تحقق من سجلاتك الحالية

السجلات المكررة هي السبب الأكثر شيوعًا لفشل التوثيق. ابحث عمّا هو منشور بالفعل قبل إضافة أي شيء. على macOS أو Linux استخدم dig؛ وعلى Windows استخدم nslookup.

dig +short TXT example.com
dig +short TXT _dmarc.example.com

# Windows
nslookup -type=TXT example.com

ابحث عن أي سجل TXT يبدأ بـ v=spf1 (SPF) وأي سجل عند _dmarc يبدأ بـ v=DMARC1. إذا وُجد أحدهما فعدّله بدلًا من إضافة سجل آخر.

الخطوة 2: أضف سجل SPF

SPF هو سجل TXT واحد في جذر نطاقك. يسرد الخدمات المسموح لها بإرسال البريد باستخدام نطاقك في مرسِل المظروف (Return-Path).

صيغة سجل SPF

v=spf1 include:YOUR-MIGOSMTP-INCLUDE include:_spf.google.com ~all

الجزء	المعنى
v=spf1	مطلوب. يحدد أن السجل هو SPF الإصدار 1.
include:domain	يخوّل كل ما يخوّله سجل SPF الخاص بذلك النطاق. استخدم القيمة من لوحة تحكم MigoSMTP.
ip4:203.0.113.10	يخوّل عنوان IPv4 محددًا أو نطاقًا منه. ويستخدم IPv6 الصيغة ip6:.
a, mx	يخوّل عناوين IP الخاصة بسجلات A أو MX لنطاقك.
~all	فشل ناعم: أي مصدر غير مدرج يُعدّ مشبوهًا لكنه لا يُرفض صراحةً. شائع أثناء إضافة المرسِلين.
-all	فشل صارم: أي مصدر غير مدرج غير مخوَّل. استخدمه عندما تتأكد من إدراج كل مرسِل.

حد الـ 10 عمليات بحث

يجوز أن يتسبب تقييم SPF في 10 عمليات بحث DNS على الأكثر. يُحتسب كل من include وa وmx وexists وredirect، بما في ذلك عمليات البحث داخل السجلات التي تضمّنها. وإذا تجاوزت الحد تُرجع الخوادم المستقبِلة خطأً دائمًا فيفشل SPF لكل الرسائل. حافظ على العدد منخفضًا بإزالة الخدمات التي لم تعد تستخدمها، واستبدال a وmx بنطاقات ip4 صريحة حيث تكون ثابتة، ونقل الأدوات قليلة الاستخدام إلى نطاق فرعي خاص بها.

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

• سجلا SPF عند الاسم نفسه (ادمجهما في سجل واحد).
• استخدام +all الذي يخوّل الإنترنت بأكمله.
• كتابة قيمة include بمسافات زائدة أو بدون النقطتين الرأسيتين.
• نسيان مرسِل مثل نظام الفوترة أو مكتب الدعم، فتفشل رسائله في SPF.
• نشر SPF على اسم خاطئ، مثل مضيف www بدلًا من جذر النطاق.

الخطوة 3: انشر سجل DKIM

يضيف DKIM توقيعًا رقميًا إلى كل رسالة. تقوم منصة الإرسال بتوقيع البريد الصادر بمفتاح خاص تحتفظ به سرًا، وتنشر أنت المفتاح العام المقابل في DNS ليتمكن المستقبِلون من التحقق من التوقيع.

المحدِّدات (Selectors) وموضع السجل

يوجد كل مفتاح تحت اسم يسمى المحدِّد، بالصيغة selector._domainkey.yourdomain.com. يتيح لك المحدِّد نشر عدة مفاتيح في وقت واحد وتدويرها دون انقطاع. وتعرض لوحة تحكم MigoSMTP الاسم والقيمة الدقيقين لنطاقك.

Name:  selector1._domainkey.example.com
Type:  TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...(long public key)

TXT أم CNAME؟

تطلب بعض المنصات نشر المفتاح العام مباشرةً كسجل TXT. وتمنحك أخرى سجل CNAME يشير إلى سجل تستضيفه هي، مما يتيح لها تدوير المفاتيح نيابةً عنك. انشر النوع الذي تعرضه لوحة التحكم تمامًا. ولا تحوّل أحدهما إلى الآخر.

طول المفتاح والتنسيق

• استخدم مفاتيح RSA بطول 2048 بت عند توفرها. لا تزال كثير من الخوادم المستقبِلة تقبل مفاتيح 1024 بت لكنها تُعدّ ضعيفة.
• يتجاوز المفتاح بطول 2048 بت 255 حرفًا، ولا يجوز أن تتجاوز سلسلة DNS الواحدة 255 حرفًا. يجب أن يقسّم مزوّد DNS لديك القيمة إلى عدة سلاسل بين علامات اقتباس داخل سجل TXT واحد. تفعل معظم اللوحات ذلك تلقائيًا؛ وإذا لم تفعل لوحتك فقسّمها يدويًا.
• انسخ القيمة دون فواصل أسطر مضافة أو علامات اقتباس ذكية، ولا تحطها بعلامات اقتباس إضافية ما لم يتطلب مزوّد DNS ذلك.

التدوير

دوّر مفاتيح DKIM كل ستة إلى اثني عشر شهرًا، أو فورًا إذا احتُمل انكشاف مفتاح خاص. انشر المحدِّد الجديد أولًا، ثم حوّل التوقيع إليه، ولا تحذف المحدِّد القديم إلا بعد انتهاء وصول الرسائل الموقَّعة به.

الخطوة 4: انشر سجل DMARC

يربط DMARC كلًا من SPF وDKIM بالنطاق الذي يراه مستلموك فعليًا في سطر From، ويخبر الخوادم المستقبِلة بما يجب فعله بالبريد الفاشل. وهو سجل TXT عند _dmarc.yourdomain.com. ابدأ بوضع المراقبة لترى من يرسل باسمك قبل أن تفرض أي إنفاذ.

Name:  _dmarc.example.com
Type:  TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; fo=1

الوسم	وظيفته	القيمة المعتادة
v	الإصدار. يجب أن يكون الأول.	DMARC1
p	السياسة المطبقة على البريد الفاشل: none (مراقبة) أو quarantine (مجلد الرسائل غير المرغوبة) أو reject (رفض).	none في البداية
rua	وجهة إرسال التقارير التجميعية اليومية.	mailto:dmarc-reports@example.com
ruf	وجهة إرسال عينات الفشل. قلة من الخوادم المستقبِلة ترسلها.	اختياري
pct	النسبة المئوية من البريد الفاشل التي تُطبَّق عليها السياسة، وتُستخدم أثناء التطبيق التدريجي.	25, 50, 100
sp	سياسة النطاقات الفرعية إذا اختلفت عن النطاق الأصلي.	مثل p ما لم تدعُ الحاجة
adkim, aspf	وضع المحاذاة: r (مرن) أو s (صارم).	r (مرن) هو الافتراضي
fo	متى تُنشأ تقارير الفشل.	1

ماذا تعني "المحاذاة" فعليًا

ينجح DMARC عندما ينجح SPF أو DKIM ويتوافق النطاق الناجح مع نطاق From. ففي المحاذاة المرنة يُعدّ النطاق الفرعي لنطاق From متوافقًا، لذا يتوافق Return-Path بالقيمة bounce.example.com مع From بالقيمة news@example.com. أما في المحاذاة الصارمة فيجب أن يتطابق النطاقان تمامًا. والسبب الأكثر شيوعًا لحالة "ينجح SPF ويفشل DMARC" هو أن نطاق Return-Path أو DKIM يعود إلى منصة الإرسال بدلًا من أن يكون لك. فعّل Return-Path مخصصًا ونطاق توقيع DKIM خاصًا بك لحل المشكلة.

الخطوة 5: تحقق من أن كل شيء يعمل

افحص السجلات في DNS

dig +short TXT example.com
dig +short TXT selector1._domainkey.example.com
dig +short TXT _dmarc.example.com

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

أرسل رسالة تجريبية واقرأ الترويسات

1. أرسل رسالة من نطاقك الموثَّق إلى عنوان Gmail تملكه.
2. افتح الرسالة واختر قائمة النقاط الثلاث ثم إظهار الرسالة الأصلية (Show original).
3. سترى في الأعلى SPF وDKIM وDMARC مع PASS أو FAIL لكل منها.
4. تأكد من أن النطاق الظاهر بجانب كل PASS يطابق نطاق From لديك.

طبّق DMARC بأمان: من p=none إلى p=reject

الهدف هو p=reject، لأنها السياسة الوحيدة التي تمنع الآخرين من انتحال نطاقك. لكن القفز إليها دون تدرج قد يحجب بريدًا مشروعًا من أدوات نسيتها. انتقل على مراحل ودع التقارير ترشدك.

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

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

متطلبات Gmail وYahoo وMicrosoft للمرسِلين بكميات كبيرة

بدءًا من فبراير 2024 بدأت Gmail وYahoo بفرض قواعد التوثيق وإلغاء الاشتراك على كل من يرسل بكميات كبيرة، وبدأت Microsoft بتطبيق متطلبات مماثلة على صناديق Outlook.com الاستهلاكية اعتبارًا من مايو 2025. وفي الخلاصة:

المتطلب	جميع المرسِلين	المرسِلون بكميات كبيرة (نحو 5,000 رسالة أو أكثر يوميًا إلى المزوّد)
SPF أو DKIM	مطلوب	كلاهما مطلوب
سجل DMARC	موصى به	مطلوب، بالسياسة p=none على الأقل، ومتوافق مع From
إلغاء الاشتراك بنقرة واحدة	غير مطلوب للرسائل التفاعلية	مطلوب للرسائل التسويقية والمشترك بها (ترويسات RFC 8058)؛ ويجب تنفيذ الطلبات خلال يومين
معدل شكاوى الرسائل غير المرغوبة	أبقِه منخفضًا	ابقَ دون 0.10 بالمئة ولا تبلغ 0.30 بالمئة أبدًا (Google Postmaster Tools)
DNS صحيح للبحث الأمامي والعكسي، وTLS	مطلوب	مطلوب

قد يغيّر المزوّدون الحدود، لذا راجع إرشادات المرسِلين الحالية لديهم. الروابط في قائمة المراجع في نهاية هذا الدليل.

افصل الرسائل التسويقية عن التفاعلية بالنطاقات الفرعية

تُتتبَّع السمعة لكل نطاق مرسِل وعنوان IP. فإذا تسببت حملة ترويجية في شكاوى، فلا تريد أن تصل رسائل إعادة تعيين كلمات المرور إلى مجلد الرسائل غير المرغوبة. والنمط المعتاد هو نطاق فرعي لكل مسار:

المسار	مثال لعنوان From	سبب الفصل
الرسائل التفاعلية	noreply@mail.example.com	يجب أن تصل دائمًا وبسرعة. يحافظ الحجم المنخفض والتفاعل العالي على سمعة مرتفعة.
التسويق	hello@news.example.com	حجم أكبر وشكاوى أكثر. تبقى المشكلات محصورة.
البريد المؤسسي	name@example.com	تبقى صناديق بريد موظفيك بمنأى عن مخاطر الإرسال بكميات كبيرة.

يحتاج كل نطاق فرعي إلى سجلات SPF وDKIM خاصة به. ويحمي سجل DMARC في النطاق الأصلي النطاقات الفرعية افتراضيًا؛ أضف وسم sp= أو سجلًا منفصلًا عند النطاق الفرعي إذا احتجت إلى سياسة مختلفة.

أخطاء التوثيق الشائعة وكيفية إصلاحها

العَرَض	السبب المحتمل	الحل
SPF permerror أو "too many DNS lookups"	أكثر من 10 عمليات بحث، أو خطأ في الصيغة	أزل عناصر include غير المستخدمة، وحوّل النطاقات الثابتة إلى ip4، وانقل المرسِلين النادرين إلى نطاق فرعي.
Multiple SPF records found	سجلا TXT يبدآن بـ v=spf1	ادمجهما في سجل واحد.
DKIM: no key for signature	اسم المحدِّد خاطئ أو السجل غير منشور	تحقق من المحدِّد في ترويسة DKIM-Signature وقارنه باسم DNS لديك.
DKIM: body hash did not verify	تغيّرت الرسالة بعد التوقيع (تذييلات، أو إعادة كتابة الروابط بواسطة نظام آخر)	عطّل الخطوة المعدِّلة أو انقلها لتسبق التوقيع.
فشل DMARC مع نجاح SPF	نطاق Return-Path لا يتوافق مع From	استخدم Return-Path مخصصًا على نطاقك.
فشل DMARC مع نجاح DKIM	نطاق DKIM d= لا يتوافق مع From	وقّع بنطاقك أنت لا بالنطاق الافتراضي للمنصة.
Record not found	اسم مضيف خاطئ، أو نقطة في النهاية، أو إلحاق لوحة DNS للنطاق مرتين	تضيف لوحات كثيرة النطاق تلقائيًا. أدخل الجزء الذي يسبقه فقط، مثل selector1._domainkey.
السجلات لا تتحدث	السجل القديم مخزَّن مؤقتًا	انتظر حتى تنتهي صلاحية TTL. اخفض TTL قبل التغييرات المخطط لها.

قائمة مراجعة التوثيق

• سجل SPF واحد في جذر النطاق، بأقل من 10 عمليات بحث، وينتهي بـ ~all أو -all.
• نشر سجل محدِّد DKIM، بطول 2048 بت إذا سمح مزوّد DNS لديك.
• سجل DMARC عند _dmarc بالسياسة p=none وعنوان rua يعمل.
• Return-Path مخصص ونطاق DKIM مخصص بحيث يتوافق كلاهما مع نطاق From لديك.
• تُظهر الرسالة التجريبية SPF وDKIM وDMARC بالنتيجة PASS.
• مراجعة تقارير DMARC أسبوعيًا أثناء التطبيق التدريجي.
• فصل الرسائل التسويقية عن التفاعلية بالنطاقات الفرعية.
• تذكير في التقويم لتدوير مفاتيح DKIM.

قراءات إضافية ومصادر

• RFC 7208: إطار سياسة المرسِل (SPF)
• RFC 6376: توقيعات DomainKeys Identified Mail (DKIM)
• RFC 7489: المصادقة والإبلاغ والمطابقة للرسائل المبنية على النطاق (DMARC)
• RFC 8058: الإشارة إلى وظيفة النقرة الواحدة في ترويسات قوائم البريد
• Google: إرشادات مرسِلي البريد الإلكتروني
• Yahoo: أفضل ممارسات المرسِلين
• أدلة ذات صلة: دليل تسخين البريد الإلكتروني وشرح رموز ارتداد SMTP.