سجل PTR والـDNS العكسي: لماذا يرفض Gmail رسائل سيرفرك

إذا كان سيرفر بريدك يرسل وGmail يرد برسالة تبدأ بـ550-5.7.25، فالسبب في الغالب سجل PTR مفقود أو غير مطابق. سجل PTR هو الاتجاه العكسي في DNS: بدل أن تسأل "ما آي بي هذا الاسم؟" تسأل "ما اسم هذا الآي بي؟". Gmail ومعظم مزودي البريد الكبار يشترطون ما يسمى FCrDNS (Forward-confirmed reverse DNS)، أي أن الآي بي المرسل يشير بسجل PTR إلى اسم مثل mail.example.sa، وأن هذا الاسم نفسه يشير بسجل A إلى الآي بي ذاته. إذا انكسرت الحلقة في أي طرف ترفض الرسالة أو تذهب بعيداً عن صندوق الوارد. الإصلاح يحتاج ثلاثة أشياء متطابقة: اسم السيرفر (hostname) الذي يقدمه في تحية SMTP، وسجل PTR للآي بي ويضبطه مالك الآي بي وهو مزود السيرفر لا أنت، وسجل SPF يسمح لهذا الآي بي بالإرسال باسم نطاقك. هذا المقال يشرح معنى رسائل الرفض الشائعة، ويعطيك أوامر dig التي تفحص بها الحلقة كاملة خلال دقيقة، ثم قائمة تحقق لأي نقل سيرفر بريد إلى آي بي جديد، وهي اللحظة التي تنكسر فيها هذه الإعدادات أكثر من أي وقت آخر.

FCrDNS بمثال واحد

لنفترض أن سيرفر بريدك على الآي بي 203.0.113.25 ونطاقك example.sa. الحلقة السليمة تبدو هكذا:

الخطوة	السؤال	الجواب المطلوب
1	ما اسم 203.0.113.25؟ (سجل PTR)	mail.example.sa
2	ما آي بي mail.example.sa؟ (سجل A)	203.0.113.25
3	بماذا يعرّف السيرفر نفسه في HELO؟	mail.example.sa
4	هل يسمح SPF لنطاق example.sa بهذا الآي بي؟	نعم، عبر ip4:203.0.113.25 أو سجل A أو mx

الخطوتان الأولى والثانية هما FCrDNS. لماذا يهتم Gmail بهما؟ لأن الأجهزة المخترقة في البيوت والآي بيهات الرخيصة بلا إدارة نادراً ما يكون لها PTR مضبوط، وغالباً تحمل أسماء عامة مثل 203-0-113-25.dynamic.isp.example. وجود PTR مطابق يقول للمستقبل إن مالك الآي بي ومالك النطاق تعاونا لتعريف هذا السيرفر كسيرفر بريد حقيقي، وهذا أحد أول الفحوص قبل قراءة الرسالة نفسها.

رسائل الرفض الشائعة ومعناها

رسالة الرفض نفسها أهم أداة تشخيص عندك، فاقرأها كاملة في سجل البريد قبل أن تغير أي شيء.

• 550-5.7.25: نصها يقول إن الآي بي المرسل ليس له سجل PTR، أو أن الاسم في PTR لا يشير إلى نفس الآي بي. هذه مشكلة FCrDNS صريحة، وحلها عند مزود الآي بي أولاً.
• 550-5.7.27: الرسالة لم تجتز فحص SPF، أي أن الآي بي المرسل غير مذكور في سجل SPF للنطاق الظاهر في عنوان المرسل. تظهر كثيراً بعد نقل السيرفر لآي بي جديد مع بقاء SPF على الآي بي القديم.
• 550-5.7.26: الرسالة فشلت في المصادقة بشكل لا يسمح بتسليمها حسب سياسة DMARC للنطاق، أي فشل SPF وDKIM معاً أو عدم توافقهما مع نطاق المرسل.
• 421-4.7.0: رفض مؤقت، والمعنى في الغالب أن Gmail لا يثق بالآي بي حالياً بسبب ضعف السمعة أو حجم إرسال مفاجئ من آي بي جديد. السيرفر يعيد المحاولة تلقائياً، لكن تكرارها لساعات يعني أن عندك مشكلة أعمق.

منذ فبراير 2024 صارت متطلبات Gmail للمرسلين أشد وضوحاً: كل مرسل يحتاج SPF أو DKIM وPTR صالحاً، ومن يرسل أكثر من 5,000 رسالة يومياً إلى حسابات Gmail يحتاج SPF وDKIM وDMARC معاً. لهذا فإعداد كان يعمل قبل سنتين قد يتوقف اليوم دون أي تغيير من جهتك.

افحص الحلقة كاملة بأوامر dig

هذه الأوامر تعطيك الصورة كاملة خلال دقيقة، ويمكن تشغيلها من أي جهاز:

# 1) سجل PTR للآي بي
dig -x 203.0.113.25 +short

# 2) سجل A للاسم الناتج
dig +short A mail.example.sa

# 3) اسم السيرفر كما يعرفه النظام
hostname -f

# 4) سجل SPF للنطاق
dig +short TXT example.sa | grep spf

# 5) سجل SPF لاسم HELO نفسه (بعض المستقبلين يفحصه)
dig +short TXT mail.example.sa

# 6) سجلات MX
dig +short MX example.sa

النتيجة السليمة: الأمر الأول يعيد mail.example.sa.، والثاني يعيد 203.0.113.25، والثالث يطابقهما. في سجل SPF يجب أن ترى الآي بي صراحة أو آلية تشمله، مثل:

v=spf1 ip4:203.0.113.25 mx -all

لا تنسَ أن SPF له سقف 10 عمليات بحث DNS، وكل include أو a أو mx يحسب واحدة، فتجاوزها ينتج خطأ permerror يعامله كثير من المستقبلين كفشل. لاختبار تحية SMTP مباشرة من جهاز خارجي:

openssl s_client -connect mail.example.sa:25 -starttls smtp -quiet
EHLO test.example

سطر الترحيب الأول يجب أن يحمل نفس الاسم، مثل 220 mail.example.sa ESMTP.

ضبط الاسم وPTR وSPF على الاسم نفسه

اسم السيرفر

hostnamectl set-hostname mail.example.sa

تأكد أيضاً أن ملف /etc/hosts يحتوي سطراً يربط الآي بي بالاسم الكامل. في Postfix القيمة المسؤولة هي myhostname = mail.example.sa في ملف main.cf، وفي Exim على cPanel يظهر الاسم في إعداد Hostname في لوحة WHM. اختر اسماً فرعياً مخصصاً للبريد ولا تستخدم النطاق العاري، فالنطاق الرئيسي غالباً يشير لسيرفر الموقع وسينكسر سجل A عند أول نقل للموقع.

سجل PTR

هنا يقع الخطأ الأشهر: كثيرون يحاولون إضافة PTR في منطقة DNS الخاصة بنطاقهم فلا يحدث شيء. سجلات PTR تعيش في منطقة in-addr.arpa التابعة لمالك نطاق الآي بي، وهو مزود السيرفر. يعني ذلك أنك تطلب الضبط من المزود عبر لوحة التحكم إن كانت تتيحه، أو عبر تذكرة دعم تذكر فيها الآي بي والاسم المطلوب. قبل الطلب تأكد أن سجل A للاسم موجود ويشير للآي بي، لأن بعض المزودين يرفضون ضبط PTR لاسم لا يشير إليهم.

سجل SPF

حدّث سجل SPF للنطاق ليشمل الآي بي الجديد، وإن أردت الحماية الكاملة أضف سجل SPF بسيطاً لاسم HELO نفسه: v=spf1 a -all على mail.example.sa، ثم فعّل DKIM وأضف سجل DMARC يبدأ بسياسة p=none مع عنوان تقارير، ثم ارفعها تدريجياً إلى quarantine بعد أسبوعين من تقارير نظيفة.

لا تنسَ IPv6

إذا كان سيرفرك يملك عنوان IPv6 مفعّلاً، فـPostfix وExim سيفضلانه عند الإرسال لـGmail لأن Gmail يستقبل عبر IPv6 أيضاً. هنا تظهر مشكلة صامتة: تضبط PTR للعنوان IPv4 بعناية، ثم تخرج الرسائل من عنوان IPv6 بلا PTR فتُرفض بنفس الرمز 550-5.7.25. Gmail أشد صرامة مع IPv6 تحديداً، لأن عدد العناوين فيه ضخم ولا يمكن تقييم سمعتها واحداً واحداً. أمامك خياران: إما أن تطلب PTR للعنوان IPv6 أيضاً وتضيفه إلى SPF بآلية ip6: مع سجل AAAA للاسم نفسه، وإما أن تجبر سيرفر البريد على الإرسال عبر IPv4 فقط. في Postfix يكفي السطر inet_protocols = ipv4 في main.cf ثم إعادة تحميل الخدمة. افحص الوضع بالأمر ip -6 addr show scope global، فإن ظهر عنوان عام فاحسم القرار قبل أن تحسمه رسائل الرفض نيابة عنك.

قائمة تحقق بعد نقل سيرفر بريد إلى آي بي جديد

النقل هو اللحظة التي ينكسر فيها كل ما سبق دفعة واحدة، لأن الآي بي القديم كان يحمل PTR وسمعة بنيت عبر سنوات. اتبع هذا الترتيب:

1. قبل النقل بـ48 ساعة: خفّض TTL لسجلات A وMX إلى 300 ثانية حتى يكون التبديل سريعاً.
2. اطلب PTR للآي بي الجديد قبل أول رسالة ترسلها منه، وافحصه بـdig -x.
3. أضف الآي بي الجديد إلى SPF مع إبقاء القديم مؤقتاً خلال فترة الانتقال.
4. انقل مفاتيح DKIM كما هي، أو أنشئ selector جديداً وانشر سجله قبل التبديل.
5. بدّل سجل A لاسم البريد ثم أعد تشغيل الحلقة كاملة بأوامر dig من القسم السابق.
6. افحص قوائم الحظر للآي بي الجديد قبل الإرسال، فقد يكون عليه أثر من مستخدم سابق.
7. ابدأ الإرسال تدريجياً: لا ترسل 20,000 رسالة في الساعة الأولى من آي بي بلا سمعة، ابدأ بمئات قليلة وارفع الحجم خلال أيام.
8. راقب السجلات 72 ساعة عبر grep -E "5\.7\.(25|26|27)" /var/log/maillog أو ما يعادله على توزيعتك.
9. بعد أسبوع مستقر احذف الآي بي القديم من SPF وأعد TTL لقيمته الطبيعية.

كيف نتعامل مع ذلك في كلاود

على الخادم السحابي من كلاود نضبط سجل PTR للآي بي الخاص بك عند الطلب عبر تذكرة دعم، بشرط أن يكون سجل A للاسم مضبوطاً مسبقاً. إذا احتجت آي بي مستقلاً لسيرفر البريد بعيداً عن آي بي الموقع، فالآي بي الإضافي بـ400 ريال سنوياً. أما إذا كان هدفك بريداً مؤسسياً يصل صندوق الوارد عند الجهات الحكومية دون إدارة سيرفر بريد كامل، فـالاستضافة السحابية المُدارة تبدأ بـ2,900 ريال سنوياً وتشمل حسابات بريد بإعدادات PTR وSPF وDKIM مضبوطة من جهتنا. قارن الخيارين في صفحة الأسعار، وابدأ بفحص dig -x لآي بي سيرفرك الحالي اليوم، فهو أمر واحد قد يفسر لك أسابيع من الرسائل المفقودة.