لماذا تصل رسائل بريدك إلى مجلد Spam (وكيف تحل سجلات SPF وDKIM وDMARC وPTR المشكلة)

تصل رسائلك إلى مجلد Spam لسببين: إما أن السيرفرات المستقبِلة مثل Gmail وOutlook.com لا تستطيع التأكد من أن السيرفر الخاص بك مسموح له بالإرسال باسم نطاقك، وإما أن نطاقك وعنوان IP الخاص بك ليست لهما سمعة إرسال كافية أو ليست لهما سمعة على الإطلاق. يمكنك حل المشكلة بنشر أربعة سجلات: SPF يحدد السيرفرات المسموح لها بإرسال بريدك، وDKIM يوقّع كل رسالة توقيعًا تشفيريًا، وDMARC يخبر السيرفرات المستقبِلة بما يجب فعله عند فشل هذه الفحوصات، وPTR (reverse DNS) يربط عنوان IP الخاص بسيرفرك باسم مضيف (hostname) مطابق. يوضح هذا الدليل كيفية فحص هذه السجلات الأربعة وإنشائها والتحقق منها على استضافة cPanel أو على VPS يعمل بنظام Ubuntu، ثم كيفية بناء السمعة حتى يصل بريدك إلى صندوق الوارد.

المتطلبات المسبقة

• صلاحية الوصول إلى منطقة DNS الخاصة بنطاقك. تكون هذه الصلاحية من خلال Zone Editor في cPanel إذا كانت خوادم الأسماء (nameservers) تشير إلى استضافتك، وإلا فمن خلال مزود DNS الخاص بك مثل Cloudflare.
• بيانات تسجيل الدخول إلى cPanel في حالة الاستضافة المشتركة، أو صلاحية وصول root/sudo عبر SSH في حالة VPS أو سيرفر مخصص.
• قائمة بكل خدمة ترسل بريدًا باسم نطاقك: استضافتك، وGoogle Workspace، وMicrosoft 365، وأدوات النشرات البريدية، وأنظمة CRM، وغيرها.
• صندوق بريد لاستقبال تقارير DMARC، مثل dmarc@example.com.

ما الدور الفعلي لسجلات SPF وDKIM وDMARC وPTR؟

• SPF: سجل TXT على نطاقك يحدد عناوين IP والخدمات المسموح لها بإرسال البريد باسمه.
• DKIM: مفتاح عام منشور في DNS تستخدمه السيرفرات المستقبِلة للتحقق من توقيع يضيفه سيرفرك إلى كل رسالة صادرة.
• DMARC: سياسة تشترط نجاح فحص SPF أو DKIM وتطابقه مع النطاق الظاهر في حقل From. وتخبر السيرفرات المستقبِلة كذلك بأن تراقب الرسائل الفاشلة أو تعزلها أو ترفضها، وبالعنوان الذي ترسل إليه التقارير.
• PTR: سجل reverse DNS يربط عنوان IP المستخدم في الإرسال باسم مضيف. يجب أن يشير اسم المضيف هذا بدوره إلى عنوان IP نفسه، وأن يطابق الاسم الذي يعلنه سيرفر البريد في أمر HELO.

1. كيف أفحص سجلات DNS الحالية الخاصة بالبريد؟

على Ubuntu 22.04 أو 24.04، ثبّت أداة dig إن لم تكن موجودة، ثم استعلم عن كل سجل:

sudo apt update && sudo apt install -y bind9-dnsutils
dig +short MX example.com
dig +short TXT example.com | grep spf1
dig +short TXT default._domainkey.example.com
dig +short TXT _dmarc.example.com
dig +short -x 203.0.113.10

يستخدم cPanel محدِّد DKIM (selector) باسم default. ويستخدم المزودون الآخرون محدِّدات مختلفة، مثل google وselector1 وselector2. وإذا كنت تفضل استخدام المتصفح، فإن موقع MXToolbox (mxtoolbox.com) يتيح فحص SPF وDKIM وDMARC وreverse DNS والقوائم السوداء. ويُنصح بتشغيل فحص القوائم السوداء على عنوان IP الخاص بسيرفرك.

2. كيف أنشئ سجل SPF صحيحًا؟

البريد المرسل من cPanel

في cPanel انتقل إلى Email > Email Deliverability، وابحث عن نطاقك ثم اضغط Manage. يعرض قسم SPF سجلًا مقترحًا. إذا كانت DNS الخاصة بنطاقك مستضافة على السيرفر، فاضغط Install the suggested record. أما إذا كانت مستضافة في مكان آخر، فانسخ السجل إلى مزود DNS الخاص بك. وهذه نتيجة نموذجية:

example.com.  TXT  "v=spf1 +a +mx +ip4:203.0.113.10 ~all"

Google Workspace أو Microsoft 365

إذا كانت صناديق البريد لدى Google أو Microsoft وكان موقعك يرسل بريدًا من السيرفر أيضًا، فأدرج الاثنين في السجل نفسه:

# Google Workspace + web server
v=spf1 ip4:203.0.113.10 include:_spf.google.com ~all

# Microsoft 365 + web server
v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com ~all

ابدأ بـ ~all (softfail). ولا تنتقل إلى -all إلا بعد أن تؤكد تقارير DMARC أن كل جهات الإرسال المشروعة مدرجة في السجل.

3. كيف أفعّل DKIM في cPanel؟

انتقل إلى Email > Email Deliverability > Manage الخاص بنطاقك. يوضح قسم DKIM ما إذا كان هناك مفتاح موجود، وما إذا كان السجل المنشور صالحًا.

• إذا كانت DNS على السيرفر: اضغط Install the suggested record، أو Repair في قائمة النطاقات.
• إذا كانت DNS في مكان آخر: انسخ اسم السجل default._domainkey.example.com وقيمة TXT كاملة إلى مزود DNS الخاص بك كما هي تمامًا. إذا كانت القيمة طويلة فقد يقسمها المزود إلى عدة نصوص بين علامات تنصيص، وهذا لا يسبب مشكلة.

على السيرفر الذي يحتوي على WHM، تتوفر الأداة نفسها من خلال WHM > Email > Email Deliverability. ولكل من Google Workspace وMicrosoft 365 إعداد DKIM خاص به في لوحة الإدارة. فعّل DKIM هناك أيضًا، لأن cPanel لا يوقّع إلا البريد الذي يرسله بنفسه.

4. ما سياسة DMARC التي يجب أن أبدأ بها؟

ابدأ بوضع المراقبة حتى لا يُحظر أي بريد مشروع أثناء جمع التقارير. في cPanel انتقل إلى Domains > Zone Editor > Manage الخاص بنطاقك، وأضف سجل TXT باسم _dmarc، وأدخل القيمة التالية:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1"

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

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com
v=DMARC1; p=reject; rua=mailto:dmarc@example.com

5. كيف أضبط reverse DNS (PTR) واسم مضيف HELO مطابقًا؟

في الاستضافة المشتركة، تتولى Cloudesta بالفعل إدارة سجلات PTR لعناوين IP الخاصة بالسيرفرات المشتركة. أما على VPS سحابي أو سيرفر مخصص، فعليك إعدادها بنفسك:

• أنشئ سجل A لاسم مضيف خاص بالبريد، مثل mail.example.com يشير إلى 203.0.113.10.
• افتح تذكرة دعم تطلب فيها من Cloudesta ضبط سجل PTR للعنوان 203.0.113.10 ليشير إلى mail.example.com. سجلات PTR تخص مالك عنوان IP، لذلك لا يمكنك ضبطها من خلال DNS الخاصة بك.
• اضبط اسم مضيف السيرفر والاسم الذي يعلنه سيرفر البريد في HELO على القيمة نفسها.

على Ubuntu مع Postfix:

sudo hostnamectl set-hostname mail.example.com
sudo postconf -e 'myhostname = mail.example.com'
sudo systemctl reload postfix
postconf myhostname smtp_helo_name

أما على سيرفر cPanel/WHM، فاستخدم WHM > Networking Setup > Change Hostname بدلًا من ذلك. الهدف هو الوصول إلى reverse DNS مؤكَّد بالاتجاه الأمامي (forward-confirmed reverse DNS): أي أن عنوان IP يشير إلى mail.example.com، وأن mail.example.com يشير بدوره إلى عنوان IP نفسه.

6. لماذا لا يزال Gmail وOutlook.com يضعان بريدي في مجلد Junk أو يرفضانه؟

المصادقة شرط أساسي، لكنها لا تضمن وصول البريد إلى صندوق الوارد. وهذه هي الأسباب المعتادة:

• سجلات مفقودة أو فاشلة. أصبحت Gmail وYahoo وOutlook.com تشترط وجود SPF وDKIM وDMARC لدى جهات الإرسال الجماعي، وأصبحت ترفض البريد غير الموثَّق مباشرةً بشكل متزايد.
• ضعف سمعة عنوان IP أو النطاق. من أسباب ذلك وجود عنوان IP في القوائم السوداء، أو حداثة النطاق، أو سكريبت أو صندوق بريد مخترق أرسل رسائل Spam.
• المحتوى التسويقي. انتبه للرسائل المكونة من صور فقط، وأدوات اختصار الروابط، وعناوين الرسائل التي تشبه Spam، ونصوص الروابط التي لا تطابق وجهتها الفعلية.
• عدم وجود خيار لإلغاء الاشتراك. يجب أن يتضمن البريد الجماعي ترويسة List-Unsubscribe تدعم إلغاء الاشتراك بنقرة واحدة، ويجب أن تنفذ طلبات إلغاء الاشتراك فورًا.
• الشكاوى. يشترط Gmail ألا يتجاوز معدل الإبلاغ عن الرسائل كـ Spam نسبة 0.3%. والإرسال إلى قوائم مشتراة أو قديمة يتخطى هذا الحد بسرعة.

بالنسبة للنشرات البريدية، استخدم مزود خدمة بريد إلكتروني متخصصًا بدلًا من سيرفر الويب الخاص بك. وبالنسبة لصناديق بريد الموظفين، فإن خدمة مُدارة مثل Cloudesta Business Email تتولى البنية التحتية للإرسال نيابةً عنك.

7. كيف أُهيّئ (warm up) نطاقًا أو عنوان IP جديدًا؟

• انشر سجلات SPF وDKIM وDMARC وPTR قبل أن ترسل أي رسالة.
• ابدأ بإرسال بضع عشرات من الرسائل يوميًا إلى مستلمين متفاعلين يُرجَّح أن يفتحوا الرسائل ويردوا عليها.
• ضاعف حجم الإرسال تقريبًا كل بضعة أيام على مدى ثلاثة إلى ستة أسابيع، وراقب الرسائل المرتدة والشكاوى.
• سجّل في Google Postmaster Tools وMicrosoft SNDS لمراقبة سمعتك.

تحقق من أن الإعداد يعمل

أرسل رسالة إلى عنوان Gmail. افتحها، ثم اختر More > Show original. يجب أن ترى SPF: PASS وDKIM: PASS وDMARC: PASS. ومن أي جهاز يعمل بنظام Ubuntu، تأكد من تطابق سجل PTR مع الاستعلام الأمامي:

dig +short -x 203.0.113.10        # expect mail.example.com.
dig +short A mail.example.com     # expect 203.0.113.10

موقع mail-tester.com مفيد أيضًا: أرسل رسالة إلى العنوان الذي يعطيك إياه لتحصل على تقييم شامل يغطي المصادقة والمحتوى والقوائم السوداء.

مشكلات شائعة

• يظهر في SPF الخطأ "permerror: too many DNS lookups" ← يسمح SPF بـ 10 استعلامات كحد أقصى، ويُحتسب كل من include وa وmx، بما في ذلك الاستعلامات المتداخلة. احذف الخدمات التي لم تعد تستخدمها، واستبدل a/mx بإدخالات ip4:.
• يفشل DKIM مع الخطأ "no key" أو "body hash did not verify" ← افحص قيمة s= في ترويسة DKIM-Signature الخاصة بالرسالة. يجب أن تطابق اسم سجل DNS، فمثلًا s=default تعني أن السجل يجب أن يكون default._domainkey. وتأكد أيضًا من لصق قيمة TXT كاملة، دون مسافات أو علامات تنصيص زائدة.
• البريد المُعاد توجيهه يفشل في فحص SPF ← إعادة التوجيه ترسل رسالتك من عنوان IP الخاص بالجهة التي أعادت التوجيه، وهذا العنوان غير موجود في سجل SPF الخاص بك. أما DKIM فيظل صالحًا بعد إعادة التوجيه، لذلك تأكد من نجاح DKIM وتطابقه. فهذا يضمن نجاح DMARC حتى عند فشل SPF.
• يوجد سجلا SPF ← احذف أحدهما وادمج جميع الآليات في سجل v=spf1 واحد.
• يرفض Outlook.com البريد مع رمز الخطأ S3150 أو رمز مشابه ← افحص عنوان IP الخاص بك على MXToolbox. إذا كان مدرجًا في قائمة حظر، فأزل السبب أولًا، ثم أرسل نموذج طلب الإزالة من القائمة الخاص بـ Microsoft.

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

كم من الوقت تستغرق تغييرات DNS الخاصة بـ SPF وDKIM وDMARC حتى تعمل؟

عادةً من بضع دقائق إلى بضع ساعات، حسب قيمة TTL للسجل. أما تغييرات PTR فتسري بمجرد أن يؤكد فريق دعم Cloudesta تنفيذ التحديث في تذكرتك.

هل أستخدم ~all أم -all في SPF؟

استخدم ~all ما دمت لا تزال تحصر جميع جهات الإرسال لديك. وانتقل إلى -all بعد أن توضح تقارير DMARC أن كل مصدر مشروع ينجح في الفحص.

هل يمكنني ضبط reverse DNS بنفسي على VPS الخاص بي لدى Cloudesta؟

لا. سجلات PTR يتحكم فيها مالك عنوان IP، لذلك افتح تذكرة دعم تذكر فيها عنوان IP واسم المضيف الذي تريده، وتأكد من أن لاسم المضيف هذا سجل A مطابقًا بالفعل.

تحتاج إلى مساعدة؟ افتح تذكرة من خلال https://cloudesta.com/submitticket.php واذكر فيها نطاقك وعنوان IP الخاص بسيرفرك، مع نسخة كاملة من ترويسات رسالة مرتدة أو رسالة وصلت إلى مجلد Junk.