رسائل موقعك تذهب إلى السبام: SPF وDKIM وDMARC

يسجل عميل في موقعك أو يطلب منتجاً من متجرك، لكن رسالة تفعيل الحساب أو تأكيد الشراء لا تصل إلى صندوق الوارد الرئيسي، بل يجدها بعد عناء في مجلد البريد غير الهام (Spam / Junk) أو تُرفض تماماً وتختفي. المشكلة هنا نادراً ما تكون في نص الرسالة؛ فالمشكلة الأساسية هي غياب الهوية والمصادقة الرقمية لنطاقك لدى خوادم الاستقبال الكبرى مثل Gmail وYahoo وOutlook.
منذ مطلع عام 2024، شددت Google وYahoo متطلبات استقبال البريد: كل مرسل مطالب بتطبيق SPF أو DKIM على الأقل، أما من يرسل بكميات كبيرة (عند Google: أكثر من 5,000 رسالة يومياً إلى حسابات Gmail) فمطالب بالمعايير الثلاثة معاً: SPF وDKIM وDMARC، ويكفي في DMARC أن تكون السياسة p=none. إذا كنت تريد ضمان وصول إشعارات موقعك إلى صندوق الوارد (Inbox) لعملائك، فهذا الشرح يوضح لك دور كل معيار وكيف تضبط سجلاته بشكل عملي وصحيح.
لماذا يشك مزودو البريد في رسائل موقعك؟#
بروتوكول إرسال البريد الأساسي في الإنترنت (SMTP) صُمم في ثمانينيات القرن الماضي دون أي نظام تحقق أمني؛ مما يسمح لأي خادم في العالم بأن يرسل رسالة ويدعي زوراً في ترويستها أنها صادرة من admin@yourdomain.com. ولهذا السبب، إذا لم تخبر خوادم العالم صراحة بالخوادم المسموح لها بالإرسال باسمك وبكيفية إثبات صحة الرسالة، فسيعتبر خادم المستلم أن الرسالة محاولة احتيال أو سبام.
ولحل هذه المعضلة، تم ابتكار ثلاثة سجلات متكاملة تعمل معاً كفريق حراسة:
1. سجل SPF: قائمة الخوادم المصرح لها#
سجل SPF (اختصار Sender Policy Framework) هو سجل نصي من نوع TXT تضيفه في إعدادات الـ DNS لنطاقك. هذا السجل يعلن للعالم قائمة بعناوين IP أو الخوادم المعتمدة التي تملك تصريحاً رسمياً بإرسال رسائل بريد تنتهي باسم نطاقك.
عندما يستقبل خادم Gmail رسالة تدعي أنها من موقعك، يتصل بسجل الـ DNS لنطاقك ويفحص سجل SPF: إذا وجد أن عنوان IP الخادم المرسل مدرج في القائمة، تجتاز الرسالة فحص SPF بنجاح (SPF Pass)؛ وإذا كان العنوان غير مدرج، تُصنف الرسالة كمشكوك فيها.
صيغة سجل SPF النموذجي#
v=spf1 ip4:198.51.100.25 include:_spf.google.com ~all
v=spf1: تعريف بأن هذا السجل يتبع إصدار بروتوكول SPF1.ip4:198.51.100.25: عنوان IPv4 لخادم الاستضافة أو الـ VPS الخاص بك.include:_spf.google.com: تصريح لخوادم شركة خارجية (مثل Google Workspace) بالإرسال باسمك.~all(SoftFail): إذا جاءت الرسالة من خادم خارج هذه القائمة، فاستقبلها ولكن صنفها كمشبوهة (الخيار المفضل)، بينما يعني رمز-all(HardFail) رفض استلام الرسالة كلياً.
خطأ فادح شائع: لا تُنشئ أبداً أكثر من سجل SPF واحد للنطاق نفسه. دمج كافة خوادمك في سطر واحد هو الإجراء الصحيح. إذا وجد خادم الاستقبال سجلين يبدآن بـ v=spf1، فسيُعلن فوراً عن خطأ فادح (PermError) ويسقط التحقق بالكامل.
2. سجل DKIM: التوقيع الرقمي ضد التلاعب#
إذا كان SPF يثبت أن الخادم مرخص له بالإرسال، فإن DKIM (اختصار DomainKeys Identified Mail) يضمن أن محتوى الرسالة وترويستها لم يتم التلاعب بها أو تزويرها أثناء انتقالها عبر الشبكة.
يعمل DKIM بنظام المفاتيح المشفرة (Public/Private Keys):
- يمتلك خادم الإرسال مفتاحاً سرياً خاصاً (Private Key) يقوم بتوقيع كل رسالة بريد إلكتروني تخرج منه تلقائياً برمز مشفر في الترويسة يسمى
DKIM-Signature. - تضع أنت المفتاح العام المقابل (Public Key) في سجل DNS لنطاقك من نوع
TXT. - عندما يستلم Gmail الرسالة، يقرأ التوقيع المشفر ويفك شفرته باستخدام المفتاح العام المنشور في DNS نطاقك؛ فإذا تطابقا، يتأكد الخادم يقيناً أن الرسالة صادرة من نطاقك ولم تتغير فيها نقطة واحدة أثناء النقل (DKIM Pass).
3. بروتوكول DMARC: السياسة وتوحيد القرار#
بروتوكول DMARC (اختصار Domain-based Message Authentication, Reporting, and Conformance) هو المشرف الإداري الذي يربط بين SPF وDKIM. يقوم DMARC بوظيفتين حاسمتين:
- التحقق من المحاذاة (Alignment): يتأكد من أن عنوان النطاق الظاهر للمستخدم في حقل «من» (From Header) يتطابق فعلياً مع النطاق الموثق بسجل SPF والموقع بـ DKIM.
- إصدار التعليمات للطرف المستقبل: يخبر DMARC خوادم الاستقبال ماذا تفعل إذا فشلت رسالة ما في اجتياز فحص SPF أو DKIM.
مستويات سياسة DMARC (وسم p):#
p=none(وضع المراقبة): استقبل الرسائل كالمعتاد حتى لو فشلت، ولكن أرسل لي تقريراً يومياً بالأخطاء على بريدي. (ابدأ بهذا الخيار دائماً).p=quarantine(وضع العزل): الرسائل التي تفشل في الفحص تُحول تلقائياً إلى مجلد الـ Spam.p=reject(وضع الرفض الحاسم): الخيار الأكثر أماناً؛ يُمنع أي خادم غير مرخص من إرسال بريد باسمك وتُحذف الرسالة دون وصولها للضحية.
صيغة سجل DMARC في الـ DNS#
يُضاف سجل DMARC دائماً كسجل TXT بالاسم _dmarc.example.com (أو _dmarc فقط في حقل المضيف):
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com
حيث يعني rua عنوان البريد الذي ترغب في استقبال التقارير الإحصائية المجمعة عليه. ولا تضف الوسم pct الذي تجده في أمثلة قديمة: فقد أزاله معيار DMARC الحالي RFC 9989 الصادر عام 2026.
خطوات تفعيل السجلات عملياً في cPanel#
توفر معظم الاستضافات المشتركة ولوحات cPanel أداة مدمجة تجهز هذه السجلات بضغطة زر واحدة:
- سجل الدخول إلى لوحة تحكم cPanel.
- في قسم البريد (Email)، اضغط على خيار Email Deliverability.
- ابحث عن اسم نطاقك في القائمة. إذا كانت السجلات ناقصة، ستظهر بجانبه حالة تحذيرية حمراء أو برتقالية.
- اضغط على زر إدارة (Manage) بجانب الدومين.
- ستعرض لك cPanel قيماً جاهزة لسجل SPF وسجل DKIM مع المفتاح العام الخاص به. اضغط على زر Install / Repair لتثبيتها تلقائياً، أو انسخ السجلات وألصقها في إدارة DNS الخاصة بنطاقك (إذا كنت تستخدم خوادم أسماء خارجية مثل Cloudflare).
كيف تتأكد أن رسائلك أصبحت تجتاز الفحص وتصل للـ Inbox؟#
بعد إضافة السجلات في DNS، تأكد من صحة الإعداد عبر الخطوتين التاليتين:
1. فحص ترويسة الرسالة في بريد Gmail#
- أرسل بريداً إلكترونياً تجريبياً من موقعك أو بريدك الرسمي إلى حساب شخصي لك على Gmail.
- افتح الرسالة، ثم اضغط على زر النقاط الثلاث في زاوية الرسالة، واختر عرض الرسالة الأصلية (Show original).
- افحص الجدول العلوي؛ يجب أن تشاهد علامة المرور الخضراء (PASS) أمام كل من:
- SPF: PASS
- DKIM: PASS
- DMARC: PASS
2. اختبار التقييم عبر أداة Mail-Tester#
ادخل إلى موقع mail-tester.com، سيعطيك عنوان بريد تجريبي عشوائي. أرسل رسالة من موقعك إلى هذا العنوان، ثم اضغط في الموقع على «Check your score». سيفحص الموقع سجلاتك ويعطيك تقييماً من 10 درجات، موضحاً أي ثغرة أو نقص في سجلات النطاق أو سمعة خادمك.
أسباب إضافية قد تضع رسائلك في السبام رغم صحة السجلات#
- غياب سجل rDNS (سجل PTR): يجب أن يرتبط عنوان IP خادمك باسم نطاق حقيقي يعود إليه؛ وخوادم البريد العالمية ترفض البريد الصادر من عناوين IP مجهولة الهوية.
- إدراج IP الخادم في القوائم السوداء (Spam Blacklists): إذا كان خادمك مشتركاً وقام موقع آخر على نفس السيرفر بإرسال حملات سبام، فقد يدخل الـ IP في قوائم مثل Spamhaus. افحص عنوان خادمك عبر أداة
mxtoolbox.com/blacklists.aspx. - الإرسال عبر دالة PHP mail() العادية في ووردبريس: ترسل دالة PHP الافتراضية البريد بدون مصادقة SMTP وباسم خادم محلي؛ استبدلها دائماً بإضافة SMTP (مثل FluentSMTP أو WP Mail SMTP) لإرسال رسائل المتجر والموقع عبر حساب SMTP حقيقي.
المصادر#
- IETF RFC 7208: Sender Policy Framework (SPF)
- IETF RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
- IETF RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC)، ويلغي RFC 7489 وRFC 9091
- Google Workspace Admin: Email sender guidelines
- Yahoo Sender Hub: Sender Best Practices



التعليقات