كيف أتحقق من سجلات MX وSPF وDKIM وDMARC؟

كيف أتحقق من سجل MX؟

نفّذ dig MX مع نطاقك و+short، وقارن الأولويات وأسماء المضيفين بالقيم التي أعطاك إياها مزوّدك. تطبع الإجابة سطراً لكل سجل: الأولوية، ثم مسافة، ثم المضيف. لـ Proton Mail تتوقع 10 mail.protonmail.ch. و20 mailsec.protonmail.ch.؛ ولـ Fastmail 10 in1-smtp.messagingengine.com. و20 in2-smtp.messagingengine.com.؛ ولـ Mailbox.org أربعة مضيفين من نوع mxext.

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

كيف أتحقق من سجل SPF؟

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

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

كيف أتحقق من DKIM حين لا أعرف الـ selector؟

استخدم الـ selector الخاص بمزوّدك: لا يمكنك سرد الـ selectors من DNS، فخذها من شاشة DKIM لدى المزوّد. لا يسمح DNS بعرض قائمة الأسماء تحت _domainkey. الـ selectors هي protonmail وprotonmail2 وprotonmail3 لدى Proton Mail، وfm1 وfm2 وfm3 لدى Fastmail، وMBO0001 إلى MBO0004 لدى Mailbox.org.

اسم الاستعلام هو selector._domainkey.yourdomain. المزوّد الذي يستخدم سجلات CNAME، مثل هؤلاء الثلاثة، يجيب بـ CNAME يشير إلى مضيفه. والمزوّد الذي ينشر المفتاح مباشرة يجيب بسجل TXT يحتوي v=DKIM1 وp= متبوعة بالمفتاح العام. و p= الفارغة تعني أن المفتاح ملغى. وأقوى اختبار هو رسالة حقيقية، لأن سجلاً موجوداً قد لا يُستخدم: أرسل بريداً إلى مزوّد آخر واقرأ dkim=pass في الترويسات الكاملة.

كيف أتحقق من سجل DMARC؟

اطلب سجل TXT على _dmarc.yourdomain، وتأكد من سطر واحد يبدأ بـ v=DMARC1 ويحمل سياسة p=. إذا غابت p، يعامل المستقبِلون السياسة كأنها none. وإذا لم يحتوِ السطر على rua، فلا تُنتج تقارير مجمّعة، ومرحلة المراقبة في تطبيق DMARC لا تقول لك شيئاً. قد تحمل السجلات المكتوبة بالأسلوب القديم وسم pct، الذي أزالته RFC 9989.

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

لماذا ما زال استعلامي يُظهر القيمة القديمة؟

تحتفظ الذاكرة المؤقتة بالإجابة القديمة حتى ينتهي TTL، ويمكن تخزين غياب السجل مؤقتاً أيضاً. يستغرق انتشار التغيير تقريباً الـ TTL القديم للسجل في لحظة تغييره. وتضع إرشادات المزوّدين تغيير MX المعتاد بين ساعة وأربع ساعات، وحتى 24 إلى 48 ساعة في أسوأ الحالات. وتضيف RFC 2308 أن الإجابات السلبية تُخزَّن مؤقتاً بالـ TTL من سجل SOA للمنطقة، لذلك قد يبدو السجل الذي أنشأته للتو غائباً لدى بعض المحللين.

لتجاوز الذاكرة المؤقتة، اسأل خادم الأسماء الموثوق: اعثر عليه بـ dig NS، ثم أعد الاستعلام مع @ واسمه، كما في كتلة الشيفرة أعلاه. إذا أظهر الخادم الموثوق القيمة الجديدة ولم يُظهرها المحلِّل لديك، فانتظر. وإذا لم يُظهرها أيٌّ منهما، فالسجل لم يُحفظ أو اسم المضيف خاطئ، وغالباً لأن محرر DNS أضاف النطاق مرة ثانية.

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

ما أدوات الإنترنت التي تستطيع فحص سجلات البريد؟

أي أداة بحث DNS أو فاحص مصادقة بريد عبر الإنترنت يستعلم DNS العام يعطي الجواب نفسه الذي يعطيه dig، مع عرض أوضح. استخدم أداة تعرض نص السجل الخام، حتى تقارنه حرفاً بحرف بقيمة مزوّدك. لا تلصق فيها بيانات خاصة: اسم النطاق وحده يكفيها.

بحسب إحصاء Postelva بتاريخ 12 نوفمبر 2026، يتطلب إعداد Proton Mail كامل 8 سجلات (سجل تحقق TXT واحد، و2 MX، وSPF واحد، و3 DKIM، وDMARC واحد) و6 استعلامات، لأن سجلي MX يتشاركان استعلاماً واحداً، وسجل التحقق وسجل SPF يتشاركان استعلام TXT الجذر. احفظ الأوامر الستة مرة واحدة، وأعد تشغيلها بعد كل تغيير. تُقارن السجلات نفسها في SPF وDKIM وDMARC معاً.

قاعدة يمكن الاستشهاد بها: بعد كل تغيير في DNS، استعلم عن الأنواع الأربعة من السجلات وأرسل رسالة اختبار؛ السجل صحيح فقط حين يتفق الاستعلام مع الرسالة.