يبدأ استكشاف أخطاء سجلات DNS للبريد الإلكتروني بحقيقة غير مريحة: حين يتعذر التحقق من SPF أو DKIM أو سجل CNAME للتتبع، فنادرًا ما يكون السبب هو السجل الذي أردت نشره. السبب عادةً هو الطريقة التي خزّنت بها لوحة DNS لديك هذا السجل: مفتاح أطول من 255 محرفًا، أو اسم نطاق أُضيف مرتين، أو زوج من علامات الاقتباس صار جزءًا من القيمة، أو سجل SPF ثانٍ، أو إجابة قديمة لم تنتهِ صلاحيتها بعد في ذاكرة تخزين مؤقت. سنستعرض كل واحدة من هذه الحالات، ونبيّن كيفية فحصها باستخدام dig وnslookup، ونختم بجدول يمكنك استخدامه بحسب العَرَض.
كيف تعيش سجلات البريد في DNS
تستند كل طرق مصادقة البريد الإلكتروني إلى عدد قليل من أنواع السجلات. يُنشر SPF وDKIM كسجلات TXT، ويُنشر DMARC كسجل TXT عند اسم يبدأ بـ _dmarc، وتطلب كثير من منصات الإرسال سجلات CNAME لاسم مضيف مسار الإرجاع أو التتبع. وتوجّه سجلات MX البريد الوارد. يطلب المحلل اسمًا ونوعًا، وتحمل الإجابة مدة صلاحية TTL تخبر كل ذاكرة تخزين مؤقت بالمدة التي يجوز لها إعادة استخدام الإجابة خلالها.
ثلاث نقاط تفسّر معظم المشكلات. أولًا، لوحات DNS واجهات ودّية فوق منطقة DNS، وكل لوحة تتخذ خياراتها الخاصة بشأن الأسماء وعلامات الاقتباس والتقسيم. ثانيًا، توجد ذاكرات تخزين مؤقت على عدة مستويات، لذا قد يعطي الاسم نفسه إجابات مختلفة في أماكن مختلفة لفترة. ثالثًا، بعض أنواع السجلات يستبعد بعضها بعضًا عند الاسم نفسه. نغطي المجموعة الكاملة من السجلات في دليل المصادقة ومسار التحقق في التحقق من نطاق الإرسال. وهذه المقالة هي الرفيق التشخيصي لهما.
افحص المكان الصحيح أولًا: خوادم الأسماء المعتمدة
قبل تغيير أي شيء، اعرف ما هو منشور فعلًا. قد يحتفظ محلل عام، مثل الذي يستخدمه حاسوبك، بإجابة أقدم. خوادم الأسماء المعتمدة هي الخوادم التي تحتفظ بمنطقتك وتعطي الإجابة النهائية، ولذلك نسألها دائمًا أولًا.
# 1. Find the authoritative nameservers for the domain
dig NS example.com +short
# 2. Ask one of them directly for the record (no cache involved)
dig TXT selector1._domainkey.example.com @ns1.dns-host.example +noall +answer
# 3. Compare with what a public resolver says
dig TXT selector1._domainkey.example.com @9.9.9.9 +noall +answer
# 4. Check the TTL and the negative caching value
dig SOA example.com @ns1.dns-host.example +noall +answer
# nslookup equivalent
nslookup -type=TXT selector1._domainkey.example.com ns1.dns-host.exampleإذا كانت الإجابة المعتمدة خاطئة، فالمشكلة في اللوحة: أصلح السجل. وإذا كانت الإجابة المعتمدة صحيحة وكان المحلل العام يعطي إجابة مختلفة، فالمشكلة في ذاكرة تخزين مؤقت: انتظر. وإذا كانت الإجابتان صحيحتين ولا يزال التحقق يفشل، فالأرجح أنك تفحص اسمًا خاطئًا، أو أن المنصة تتوقع نوع سجل مختلفًا. هذه المقارنة الواحدة تزيل من التخمين أكثر مما يفعل أي شيء آخر في هذه المقالة.
نصيحة: افحص من جهاز لا يستخدم ذاكرة DNS المؤقتة الخاصة بك، وتذكّر أن نتيجة أداة فحص عبر الويب تعكس محلل تلك الأداة لا محللك.
سلاسل TXT التي تتجاوز 255 محرفًا ومفاتيح DKIM بطول 2048 بت
يحمل سجل TXT سلسلة محارف واحدة أو أكثر، وتُحدَّد كل سلسلة بـ 255 بايت. يعود ذلك إلى صيغة DNS الأصلية في RFC 1035، التي تخزّن كل سلسلة مع طول من بايت واحد. ويمكن للسجل أن يحتوي على عدة سلاسل، وفي SPF وDKIM يصل المستقبِل هذه السلاسل بالترتيب دون إضافة فراغات. وتنص مواصفات كل منهما على ذلك (RFC 7208 لـ SPF وRFC 6376 لـ DKIM).
يظهر الأثر العملي في DKIM. فمفتاح RSA العام بطول 1024 بت بترميز base64 يقترب من الحد بعد إضافة وسمَي الإصدار ونوع المفتاح، بينما يبلغ طول مفتاح 2048 بت نحو الضعف تقريبًا، لذا فإن قيمة p= وحدها تتكون من عدة مئات من المحارف. ويجب تخزينها في أكثر من سلسلة واحدة. يشرح دليلنا حول تدوير مفاتيح DKIM والمحددات وطول المفتاح لماذا تستحق مفاتيح 2048 بت هذا الجهد.
| سلوك لوحتك | ما ينبغي أن تفعله | كيف تتحقق |
|---|---|---|
| تقسّم القيم الطويلة تلقائيًا | الصق القيمة الكاملة مرة واحدة، دون علامات اقتباس ودون فواصل أسطر | يعرض dig عدة سلاسل محاطة بعلامات اقتباس تُقرأ معًا كالمفتاح الكامل |
| تتوقع منك إدخال أجزاء محاطة بعلامات اقتباس | قسّم عند أي نقطة دون 255 محرفًا، وضع كل جزء بين علامات اقتباس، وافصل بينها بمسافة واحدة | النص الموصول يطابق المفتاح الأصلي تمامًا |
| ترفض القيم التي تتجاوز 255 محرفًا | ابحث عن إعداد للسجلات الطويلة أو وضع محرر مختلف؛ واسأل المضيف إن لم يوجد | يعيد الاستعلام المفتاح كاملًا لا مبتورًا |
| تبتر القيمة بصمت | أعد الإدخال على أجزاء واقرأ النتيجة | المفتاح الذي ينتهي مبكرًا يفشل في DKIM بخطأ في المفتاح أو في الصياغة |
كيف يبدو التقسيم الصحيح
يعرض المثال التالي شكل سجل مقسّم. نص المفتاح مُختلَق ومختصر للتوضيح. في السجل الحقيقي تُشكّل الأجزاء مجتمعةً المفتاح الكامل الذي تزوّدك به منصتك.
selector1._domainkey.example.com. 3600 IN TXT (
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA"
"q1x2example0invented0key0chunk0one0aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
"bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb"
"IDAQAB" )هناك فخّان شائعان. لا تضف مسافة داخل المفتاح عند تقسيمه، لأن المستقبِل يصل السلاسل ببعضها وستصبح المسافة جزءًا من المفتاح. ولا تقطع السجل في منتصف اسم المحدد أو أسماء الوسوم. وإذا فشل مفتاح مقسّم، فقارن الناتج الموصول بالأصل حرفًا بحرف باستخدام أداة مقارنة نصوص بدلًا من الاعتماد على عينيك.
خصائص مزوّدي النطاقات ولوحات DNS
يمكن إدخال السجل نفسه بأربع طرق مختلفة في أربع لوحات. هذه هي الخصائص التي نصادفها أكثر من غيرها.
إضافة النطاق مرتين
تضيف كثير من اللوحات اسم المنطقة تلقائيًا. فإذا كتبت selector1._domainkey.example.com في حقل المضيف، فقد تخزّن اللوحة selector1._domainkey.example.com.example.com. والعَرَض أن السجل موجود في اللوحة لكن استعلام الاسم الصحيح لا يعيد شيئًا. أدخل الجزء النسبي فقط، selector1._domainkey، واستخدم @ أو اترك الحقل فارغًا للنطاق الجذر بحسب اللوحة. تشير النقطة الأخيرة عادةً إلى أن الاسم مؤهَّل بالكامل في ملفات المنطقة، لكن لوحات الويب تختلف، لذا اقرأ الاسم المحفوظ باستخدام dig.
علامات الاقتباس وفواصل الأسطر والمحارف غير المرئية
قد يجلب نسخ قيمة من صفحة ويب أو مستند علامات اقتباس منحنية أو مسافات غير قابلة للكسر أو فاصل سطر. وإذا كانت اللوحة تضيف علامات اقتباس خاصة بها أيضًا، فقد تنتهي بمحرف اقتباس حرفي في بداية القيمة، والسجل الذي يبدأ بعلامة اقتباس لا يبدأ بـ v=spf1 أو v=DKIM1، فلا يُعترف به. الصق أولًا في محرر نصوص عادي، ثم في اللوحة، واقرأ النتيجة.
نوع السجل الخاطئ أو الاسم الخاطئ
تطلب المنصات أحيانًا سجل TXT حيث تتوقع CNAME، أو العكس. استخدم النوع تمامًا كما هو مطلوب. وتأكد أيضًا من أنك في المنطقة الصحيحة: فإذا كان النطاق يستخدم خوادم أسماء لدى مزوّد ما بينما عدّلت المنطقة لدى مسجّل النطاق، فلن يُقدَّم التعديل أبدًا. ويخبرك استعلام NS الموضح سابقًا بمكان المنطقة الفعلية.
| العَرَض في اللوحة | السبب المحتمل | الإصلاح |
|---|---|---|
| يظهر النطاق مرتين في اسم السجل | أضافت اللوحة المنطقة إلى اسم كامل | أدخل الاسم النسبي فقط |
| تبدأ القيمة وتنتهي بمحرفَي اقتباس في ناتج الاستعلام فقط مرة واحدة | هذا طبيعي في ناتج TXT من dig | لا حاجة إلى تغيير |
| تحتوي القيمة على علامات اقتباس مُهرَّبة أو علامة اقتباس في البداية | أضفت علامات اقتباس وأضافت اللوحة علاماتها | أزل علامات الاقتباس التي أضفتها |
| حُفظ السجل لكن الاستعلام لا يعيد شيئًا | عدّلت منطقة لا تقدّمها خوادم الأسماء الفعلية | عدّل المنطقة لدى المزوّد المذكور في سجلات NS |
| لا تقبل اللوحة شرطة سفلية في الاسم | قاعدة التحقق من الأسماء في اللوحة | استخدم وضع محرر آخر أو اسأل مزوّد DNS |
CNAME على النطاق الجذر والتسطيح وتعارض السجلات
يعني سجل CNAME أن اسمًا ما هو اسم مستعار لاسم آخر، لذا ينبغي للمحلل أن يتبعه ويستخدم الإجابات الموجودة هناك. ولهذا السبب لا يمكن أن يتعايش CNAME مع أي سجل آخر عند الاسم نفسه (RFC 1034 وRFC 2181). يجب أن يحمل جذر نطاقك، أي النطاق الجذر، سجلَّي SOA وNS، وعادةً ما يحمل MX وTXT أيضًا، لذا فإن CNAME عند الجذر غير صالح.
يتحايل بعض مزوّدي DNS على ذلك بالتسطيح أو بنوع سجل اسم مستعار. يبحث المزوّد عن الهدف بنفسه ويعيد سجلات عناوين عادية عند الجذر. ويفيد ذلك في توجيه عنوان الويب الجذري إلى خدمة مستضافة. لكنه لا يفيد في مصادقة البريد الإلكتروني. فإذا طلبت منصة سجل CNAME على اسم مضيف مثل نطاق فرعي، فضعه على ذلك النطاق الفرعي. وإذا طلبت منصة سجل CNAME على النطاق المجرد، فاطلب منها بديلًا مثل سجلات TXT وسجلات العناوين.
ويحدث التعارض في الاتجاه المعاكس أيضًا. فإذا أضفت CNAME لاسم يحتوي بالفعل على سجل TXT، مثل محدد DKIM نشرته سابقًا كسجل TXT، فسيُرفض أحدهما أو يُتجاهل بحسب اللوحة. احذف السجل القديم قبل إضافة CNAME. وهذا الوضع شائع أثناء تغيير المزوّد، ويغطي دليل الترحيل لدينا ترتيب الخطوات.
سجلات SPF المكررة وتكرارات أخرى
لا يجوز للنطاق أن ينشر أكثر من سجل SPF واحد، وهو سجل TXT يبدأ بـ v=spf1. وإذا وجد المستقبِلون سجلين، فالنتيجة خطأ دائم (RFC 7208)، ويفشل SPF لكل الرسائل لا لرسائل مزوّد واحد فقط. يحدث هذا حين يضيف فريقان كلٌّ منهما السجل الذي طلبه مزوّده.
| الحالة | ما يراه المستقبِلون | الإصلاح |
|---|---|---|
| سجلا TXT يبدأ كلاهما بـ v=spf1 | خطأ دائم، ولا يجتاز SPF | ادمجهما في سجل واحد يضم كل آليات include |
| سجل واحد بأكثر من 10 استعلامات | خطأ دائم بعد تجاوز حد الاستعلامات | سطّح أو أزل بعض include؛ راجع دليل استعلامات SPF |
| سجلا DMARC عند _dmarc | قد تُتجاهل السياسة | احتفظ بسجل واحد |
| المحدد نفسه منشور مرتين بمفتاحين مختلفين | اختيار غير متوقع للمفتاح | احذف المفتاح القديم أو استخدم محددًا جديدًا |
الدمج بسيط من حيث المبدأ: خذ آليتي include وip4 من كل سجل، وضعهما في سجل v=spf1 واحد، وأنهِه بمؤهِّل all واحد. أما الجزء الأصعب فهو عدّ الاستعلامات، وهو ما نشرحه في دليل خطأ SPF الدائم وإدارة عدة مزوّدين على نطاق واحد.
السجلات عبر وكيل: أوقف وكيل DNS للبريد
يقدّم بعض مزوّدي DNS وضع وكيل، يظهر غالبًا كأيقونة سحابة ملوّنة بجانب السجل. في هذا الوضع يجيب المزوّد عن استعلامات الاسم بعناوينه الخاصة ويمرر حركة الويب عبر شبكته. هذا مفيد لمواقع الويب لكنه غير مفيد للبريد.
إذا كان سجل CNAME متعلق بالبريد يمر عبر وكيل، فلن يعيد الاستعلام الهدف الذي تتوقعه منصة الإرسال. يفشل التحقق، ولا تُحَلّ أسماء مضيفي مسار الإرجاع أو التتبع إلى الخادم الصحيح، وقد لا تُصدَر شهادات HTTPS لنطاقات التتبع. أما اسم مضيف خادم بريد يمر عبر وكيل فلن يقبل اتصالات SMTP إطلاقًا، لأن الوكيل يتعامل مع منافذ الويب لا البريد. لذا اضبط كل سجل متعلق بالبريد على وضع DNS فقط: أهداف MX وسجلات A لخوادم البريد وسجلات CNAME لأسماء مضيفي مسار الإرجاع والتتبع وسجلات CNAME الخاصة بـ DKIM. أما سجلات TXT فلا تمر عبر وكيل أبدًا، فلا تتأثر. يشرح دليلنا حول مسار الإرجاع ونطاقات التتبع سبب وجوب أن تُحَلّ هذه الأسماء مباشرة إلى المنصة.
تحقق: يعيد استعلام dig لاسم يمر عبر وكيل عناوين لا تخص منصتك مع أنك حفظت سجل CNAME. هذه علامة على أن الوكيل مفعّل.
اختيارات TTL وتخطيط التغيير
TTL هو عدد الثواني التي يجوز للمحلل أن يحتفظ فيها بالإجابة. تقلّل مدة TTL الطويلة عدد الاستعلامات وتجعل السجل أكثر مرونة إذا تعذّر الوصول إلى خوادم الأسماء لديك لوقت قصير. وتتيح مدة TTL القصيرة التعافي سريعًا من الخطأ. والنهج المعقول هو تغييرها بحسب المرحلة.
| المرحلة | TTL المقترح | السبب |
|---|---|---|
| إنشاء سجل جديد أو اختباره | 300 إلى 600 ثانية | تظهر التصحيحات بسرعة |
| قبل تغيير مخطط له | اخفض TTL قبل التغيير بوقت كافٍ، وبمدة لا تقل عن TTL الحالية | تنتهي صلاحية الذاكرات القديمة قبل أن تبدّل |
| يوم التغيير | أبقِه قصيرًا | يمكنك التراجع |
| السجلات المستقرة | من 3600 ثانية إلى يوم | استعلامات أقل وتعرّض أقل لانقطاع الخدمة |
النقطة الأساسية في تخطيط التغيير أن خفض TTL لا يفيد فورًا. فالذاكرات التي تحتفظ بالسجل بالفعل تبقيه طوال مدة TTL القديمة. وإذا كانت مدة TTL لسجل ما 86400 ثانية، فاخفضها قبل التغيير بيوم على الأقل. ثم غيّر القيمة، وانتظر، وتحقق، وارفع TTL مرة أخرى.
الانتشار والتخزين المؤقت السلبي
لا تنتشر تغييرات DNS من نقطة واحدة. لا يوجد دفع عام. ما يسميه الناس الانتشار هو ببساطة الوقت اللازم لانتهاء صلاحية الذاكرات المؤقتة. تجيب الخوادم المعتمدة بالقيمة الجديدة بمجرد حفظ المنطقة وتحميلها، ويتحول كل محلل عندما تنتهي نسخته المخزّنة. وبعض المحللات تتجاهل قيم TTL المنخفضة جدًا أو تحتفظ بالإجابات مدة أطول قليلًا، لذا اترك هامشًا.
وهناك ذاكرة مؤقتة ثانية يسهل نسيانها: الذاكرة المؤقتة السلبية. فإذا طلب محلل اسمًا لم يكن موجودًا بعد، فإنه يتذكر إجابة «غير موجود»، وينص RFC 2308 على أن المدة تستند إلى سجل SOA (الأصغر بين TTL الخاص بـ SOA وحقله الأدنى). وإذا فحصت منصتك السجل قبل إضافته بدقائق، فقد يبقى الفشل مخزّنًا حتى تنتهي هذه المدة، رغم أن السجل موجود الآن.
مثال تطبيقي
تخيّل نطاقًا نُشر سجل DKIM TXT الخاص به في الساعة 10:00 بمدة TTL قدرها 3600 ثانية وزمن تخزين مؤقت سلبي في SOA قدره 900 ثانية. في الساعة 10:05 تفحص المنصة مبكرًا جدًا وتحصل على «غير موجود»، فيخزّن ذلك المحلل الفشل حتى نحو الساعة 10:20. وفي 10:10 تلاحظ خطأً مطبعيًا، فتصحح المفتاح وتحفظه. تعطي الخوادم المعتمدة الآن الإجابة الجديدة. أما المحلل الذي خزّن السجل الأول في 10:00 فقد يستمر في تقديم القديم حتى 11:00. والذي خزّن «غير موجود» قد يقدمه حتى 10:20. لذا قد تستغرق النتيجة النظيفة تمامًا من كل المحللات حتى الساعة 11:00، لكن الفحص الذي يتجه مباشرة إلى الخوادم المعتمدة ينجح في 10:10. في هذه الحالة تستخدم النتيجة المعتمدة للتأكد من صحة تعديلك، ثم تنتظر أطول زمن تخزين مؤقت، وهو 60 دقيقة، قبل الضغط على زر التحقق مرة أخرى.
وعندما تعيد المنصة المحاولة تلقائيًا، فقد لا تحتاج إلى فعل شيء. وعندما لا تفحص إلا عند الضغط على الزر، فانتظر أطول مدة تخزين مؤقت حسبتها. لا تغيّر السجل مرة أخرى أثناء الانتظار، لأن كل تغيير يعيد تشغيل العداد للذاكرات التي تُحدِّث نسختها.
جدول تشخيصي بحسب العَرَض
| العَرَض | السبب الأرجح | الفحص الأول | الإصلاح |
|---|---|---|---|
| تقول المنصة إن سجل DKIM غير موجود | تكرار الاسم، أو منطقة خاطئة، أو لم ينتشر بعد | نفّذ dig على اسم المحدد بالضبط لدى الخادم المعتمد | صحّح حقل المضيف أو انتظر الذاكرات المؤقتة |
| يجتاز DKIM التحقق لكن التوقيع يفشل بخطأ في المفتاح | المفتاح مبتور أو قُسّم بمسافة | صِل سلاسل TXT وقارنها بالأصل | أعد الإدخال على أجزاء بلا مسافات |
| يعيد SPF خطأ دائمًا | سجلا SPF أو أكثر من 10 استعلامات | نفّذ dig لسجل TXT عند الجذر وعدّ سجلات v=spf1 | ادمج السجلات وقلّل الاستعلامات |
| يبدو أن سجل SPF متجاهَل | علامة اقتباس حرفية أو مسافة في بداية القيمة | ابحث عن قيمة لا تبدأ بـ v=spf1 | أزل المحارف الزائدة |
| يرفض CNAME الحفظ | يوجد سجل آخر عند ذلك الاسم، أو الاسم هو الجذر | اعرض كل أنواع السجلات عند الاسم | أزل التعارض أو استخدم نطاقًا فرعيًا |
| CNAME موجود لكن التحقق يفشل | وكيل DNS مفعّل، أو خطأ في كتابة الهدف | هل يعيد dig الهدف المتوقع؟ | اضبطه على DNS فقط وصحّح الهدف |
| يعمل على حاسوبك ويفشل على المنصة | اختلاف الذاكرات المؤقتة بين المحللات | استعلم من الخادم المعتمد ومن محللين عامين | انتظر انتهاء TTL الأقدم |
| السجل موجود لكن الفحص ما زال يبلغ بأنه غير موجود | التخزين المؤقت السلبي | انظر قيم SOA ووقت الفحص الأول | انتظر زمن التخزين المؤقت السلبي |
| يُظهر تقرير DMARC عدم وجود سياسة | السجل عند اسم خاطئ | تحقق من أن الاسم يبدأ بـ _dmarc | انقله إلى _dmarc.yourdomain |
مشكلات مستوى الترويسة، بخلاف مشكلات مستوى السجل، يسهل تأكيدها في الرسالة نفسها. راجع كيفية قراءة ترويسات البريد الإلكتروني لمعرفة ما تعنيه نتائج المصادقة بعد أن يصبح DNS سليمًا.
روتين عملي يمكنك تكراره
- حدّد. دوّن الاسم والنوع بالضبط اللذين تطلبهما منصتك.
- حدّد الموقع. اعثر على خوادم الأسماء الفعلية باستعلام NS وتأكد من أنك تعدّل تلك المنطقة.
- أدخل. استخدم اسم المضيف النسبي، والصق القيمة دون علامات اقتباس مضافة، وقسّم السلاسل الطويلة فقط إذا كانت لوحتك تحتاج إلى ذلك.
- اقرأ مجددًا. استعلم من الخادم المعتمد وقارن النتيجة بالأصل.
- نظّف. أزل التكرارات والمحددات القديمة ذات الاسم نفسه وأنواع السجلات المتعارضة.
- أوقف الوكيل. تأكد من ضبط السجلات المتعلقة بالبريد على DNS فقط.
- انتظر بذكاء. احسب الأطول بين TTL القديمة وزمن التخزين المؤقت السلبي.
- تحقق. شغّل فحص المنصة وأرسل رسالة اختبار. راجع حسابك على MigoSMTP أو وثائق API لمعرفة أسماء السجلات وقيمها بالضبط التي ينبغي نشرها.
قائمة تحقق قبل طلب المساعدة
- قُرئ اسم السجل من خادم الأسماء المعتمد ويطابق تمامًا ما طلبته المنصة.
- لا يظهر لاحقة النطاق مرتين في الاسم المخزّن.
- لا تحتوي القيمة على علامات اقتباس ملصوقة أو فواصل أسطر أو مسافات داخل المفاتيح الطويلة.
- قيم TXT الطويلة موجودة كاملة عند وصل السلاسل.
- يوجد سجل SPF واحد فقط عند الاسم، وعدد الاستعلامات ضمن الحد.
- لا يتشارك أي CNAME الاسم مع سجل آخر، ولا يوجد CNAME عند الجذر.
- كل سجل متعلق بالبريد مضبوط على DNS فقط، وليس عبر وكيل.
- انتظرت انتهاء TTL القديمة وزمن التخزين المؤقت السلبي قبل إعادة الفحص.
- المنطقة التي عدّلتها هي التي تشير إليها سجلات NS.
هل علقت عند سجل لا يمر التحقق منه؟ أرسل إلينا اسم السجل والقيمة الدقيقة التي نشرتها وناتج استعلام dig من خادم الأسماء المعتمد لديك، وسنساعدك على إيجاد الفرق.
قراءات إضافية ومصادر
الأسئلة الشائعة
لماذا يظهر أن سجل DKIM الخاص بي طويل جدًا؟
يمكن لسلسلة محارف DNS الواحدة أن تتسع لـ 255 بايت على الأكثر، بينما يزيد طول مفتاح RSA العام بطول 2048 بت بترميز base64 على ذلك. أما السجل نفسه فيمكن أن يحتوي على عدة سلاسل، ويقوم المستقبِلون بوصلها دون فراغات. بعض اللوحات تقسّم القيمة نيابةً عنك، وبعضها يطلب منك إدخال أجزاء محاطة بعلامات اقتباس، وبعضها يرفض القيمة الطويلة تمامًا. تحقق من طريقة تعامل لوحتك مع ذلك، ثم تأكد من النتيجة باستعلام TXT.
هل أضع علامات اقتباس حول قيمة TXT؟
يعتمد ذلك على اللوحة. كثير من النماذج على الويب تضيف علامات الاقتباس تلقائيًا، فإضافتك لها تُنتج محرف اقتباس حرفيًا داخل القيمة ويفشل تحليل السجل. أما محررات ملفات المنطقة وبعض أدوات سطر الأوامر فتتوقع علامات الاقتباس. اقرأ السجل بعد الحفظ باستخدام dig، وإذا رأيت علامات اقتباس مضاعفة أو مُهرَّبة فأزل علامات الاقتباس التي أضفتها أنت.
لماذا انتهى سجلي باسم selector._domainkey.example.com.example.com؟
تضيف اللوحة نطاقك إلى أي نص تكتبه في حقل المضيف. فإذا أدخلت الاسم الكامل أُضيف النطاق مرتين. أدخل الجزء الذي يسبق نطاقك فقط، مثل selector._domainkey، أو اتبع التلميح الظاهر في اللوحة. تدل النقطة الأخيرة عادةً على أن الاسم مكتمل، لكن ليست كل اللوحات تتعامل معها بهذه الطريقة، لذا اختبر ذلك باستعلام.
هل يمكنني وضع CNAME على النطاق الجذر؟
لا يسمح DNS القياسي بذلك، لأن سجل CNAME لا يمكن أن يتشارك الاسم مع سجلات أخرى، ويجب أن يحمل النطاق الجذر سجلَّي SOA وNS. يقدّم بعض المزوّدين ميزة تسطيح (flattening) أو اسمًا مستعارًا (alias) تُعيد سجلات عناوين عند الجذر. استخدمها لحركة الويب إن احتجت إليها، لكن لا تستخدمها بديلًا عن سجلات TXT وMX التي يحتاجها البريد الإلكتروني عند الجذر.
لدي سجلا SPF. هل هذه مشكلة فعلًا؟
نعم. يجب أن ينشر النطاق سجل SPF واحدًا فقط، وعندما يجد المستقبِلون أكثر من سجل يُرجعون خطأً دائمًا بدلًا من اختيار أحدها. ادمج الآليات في سجل واحد. يشرح دليلنا حول استخدام عدة مزوّدين على نطاق واحد كيفية ذلك دون تجاوز حد الاستعلامات.
ما قيمة TTL التي ينبغي أن أحددها؟
استخدم قيمة TTL قصيرة مثل 300 إلى 3600 ثانية أثناء إنشاء السجلات أو تغييرها، وقيمة أطول مثل عدة ساعات إلى يوم واحد بعد استقرار الأمور. الرقم المناسب موازنة بين سرعة التراجع عن التغيير ومقدار الحمل الذي تضعه على خوادم الأسماء لديك.
أصلحت السجل لكن الفحص ما زال يفشل. لماذا؟
إما أن أحد المحللات (resolvers) ما زال يحتفظ بالإجابة القديمة حتى تنتهي مدة TTL، أو أنه يحتفظ بإجابة «غير موجود» مخزّنة مؤقتًا حتى ينتهي زمن التخزين المؤقت السلبي، أو أنك تفحص اسمًا مختلفًا عن الاسم الذي تبحث عنه المنصة. استعلم من خوادم الأسماء المعتمدة لترى الحقيقة، ثم انتظر انتهاء ذاكرات التخزين المؤقت.
لماذا يجب ألا تكون سجلات CNAME الخاصة بالبريد عبر وكيل؟
يجيب وكيل DNS عن الاستعلامات بعناوينه الخاصة بدلًا من الهدف الحقيقي لسجلك. تحتاج منصة البريد إلى رؤية هدف CNAME أو عنوان الخادم الحقيقي، لذا يفشل التحقق من السجل الذي يمر عبر وكيل، وقد يتعطل التتبع أو معالجة الارتدادات. اضبط هذه السجلات على وضع DNS فقط.
أي أداة أثق بها: dig أم nslookup أم أداة فحص عبر الويب؟
كلها مناسبة إذا كنت تعرف ما الذي تسأل عنه. يتيح لك dig وnslookup اختيار الخادم، وهذا هو المفتاح للتمييز بين مشكلة في النشر ومشكلة في التخزين المؤقت. أما أدوات الفحص عبر الويب فتستعلم عادةً من موقع واحد عبر محلل عام، لذا فإن اختلاف نتيجتها عن نتيجتك المحلية يعني في الغالب أن ذاكرات التخزين المؤقت مختلفة.