لماذا لا تكفي علامات نجاح SPF وDKIM وDMARC لتسليم البريد

مصادقة البريد: لماذا لا يكفي إعداد SPF وDKIM وDMARC

لقد أنجزت الإعداد. قضيت ساعات في DNS تنسخ سلاسل نصية غامضة من مزودي خدمة البريد، ثم شغلت أدوات التحقق وحصلت على علامات خضراء في كل بند. فلماذا تنخفض معدلات الفتح؟ ولماذا تصل الرسائل التشغيلية، مثل إعادة تعيين كلمات المرور والفواتير والتنبيهات، إلى البريد المزعج أو تختفي تماما؟

الحقيقة المهمة بشأن مصادقة البريد باستخدام SPF وDKIM وDMARC هي أن الإعداد الصحيح لا يساوي سمعة جيدة. فبطاقة الهوية السارية لا تضمن وحدها السماح لصاحبها بالدخول. منذ فبراير 2024 شدد مزودون مثل Google وYahoo متطلبات المرسلين بكميات كبيرة، بينما يطبق Microsoft إشارات وسياسات خاصة به. إذا كانت لوحة التحكم تعرض مؤشرات خضراء لكن نتائج العمل تتراجع، فقد تكون الرسائل عالقة عند أحد الحواجز غير الظاهرة خارج بروتوكولات المصادقة الأساسية.

فخ المرسل بكميات كبيرة: الحد أقل مما تتوقع

من أخطر المفاهيم الخاطئة: "أرسل أقل من 5,000 رسالة يوميا، لذلك لا تنطبق علي قواعد الإرسال الجماعي".

هذا غير صحيح لسببين، ولن يحميك ضبط SPF وDKIM وDMARC من هذا الفخ. أولا، يحسب Google الحجم على مستوى النطاق الأساسي. إذا أرسلت 2,000 رسالة تسويقية من news.example.com و 2,000 رسالة تشغيلية من app.example.com و 1,500 تنبيه داخلي من corp.example.com، فستعامل كمرسل بكميات كبيرة. إذ تجمع أحجام النطاقات الفرعية تحت النطاق الجذر.

ثانيا، يؤخذ أعلى حجم بلغته في الحسبان. إذا تجاوز النطاق الأساسي عتبة 5,000 رسالة مرة واحدة، مثل حملة الجمعة السوداء أو تحديث لقاعدة البيانات لمرة واحدة، يستمر Google في معاملته كمرسل بكميات كبيرة. وتظل المتطلبات المشددة مطبقة حتى لو انخفض الحجم لاحقا إلى 50 رسالة يوميا.

يقيّم Microsoft المرسلين بمجموعة مختلفة من الإشارات. قد تكون سجلات SPF وDKIM وDMARC سليمة، لكن عمر عنوان IP وسمعته قد يؤثران أيضا. إذا بدأت بنطاق وعنوان IP جديدين ثم أرسلت 2,000 رسالة دفعة واحدة، فقد تتلقى أخطاء تقييد 4xx بصرف النظر عن نتيجة SPF. فالمرسل الجديد لم يبن سمعة بعد.

مواضع فشل SPF وDKIM وDMARC: المثلث الحديدي

يضبط كثير من المشغلين SPF وDKIM وDMARC، ويتحققون من الصياغة، ثم لا يعودون إليها. لكن صحة الصياغة لا تضمن صحة التشغيل. وفيما يلي أكثر المواضع شيوعا للمشكلات.

SPF: فجوة إعادة التوجيه

يشبه SPF قائمة عناوين IP المسموح لها، فهو يقول مثلا: "يحق لعنوان IP 1.2.3.4 الإرسال باسم example.com". يعمل ذلك جيدا إلى أن يضبط أحدهم إعادة توجيه تلقائية.

ترسل فاتورة إلى client@smallbiz.com، ويعيد العميل توجيه كل بريده إلى client@gmail.com. يرى Gmail اتصالا من عنوان IP الخاص بـ smallbiz.com لا من عنوانك. وعند فحص سجل SPF الخاص بك، لا يجد smallbiz.com فيه، لذلك قد يفشل SPF. إذا اعتمدت على SPF وحده، فقد تصل الرسالة المعاد توجيهها إلى البريد المزعج أو ترفض. تحتاج إلى توقيع DKIM صالح ومتوافق لاجتياز خطوة إعادة التوجيه. راجع دليل سجل SPF لمعرفة الإعداد كاملا.

DKIM: مشكلة توافق النطاق

يفحص DMARC أمرين: نجاح SPF أو DKIM وفقا لـ RFC 6376، ومدى توافق النطاقات. يعني التوافق أن يطابق نطاق ترويسة From النطاقات المستخدمة في الترويسات التقنية، أي Return-Path مع SPF وقيمة d= مع DKIM.

إليك حالة شائعة في الدعم الفني: تستخدم نظام CRM مثل Zendesk أو HubSpot للإرسال باسم support@yourcompany.com. يتولى النظام معالجة الرسائل المرتدة، ولذلك يكون Return-Path هو bounces.zendesk.com ويفشل توافق SPF. وإذا لم تضبط CNAME مخصصا، يوقع DKIM باستخدام d=zendesk.com ويفشل توافق DKIM أيضا. الرسالة موثقة تقنيا على أنها مرسلة من Zendesk، لكن DMARC لا يجد آلية ناجحة متوافقة مع نطاقك. وإذا كانت السياسة p=reject فقد ترفض الرسالة.

حد 10 استعلامات

يضع SPF، كما هو محدد في RFC 7208، سقفا صارما يبلغ 10 استعلامات DNS لكل عملية تقييم. وتظهر المشكلة كثيرا لدى الوكالات التي تدير عملاء يستخدمون أدوات SaaS عديدة. قد يستهلك Google Workspace وحده 4 استعلامات. ثم أضف Mailchimp وHubSpot ونظام تذاكر وأداة للموارد البشرية:

تجبر كل آلية include: النظام على إجراء استعلام DNS، وقد تحتوي السجلات المضمنة على سجلات أخرى. إذا تجاوز العدد الإجمالي 10، يعيد خادم الاستقبال PermError ولا يعطي SPF النتيجة الصالحة المتوقعة. وهكذا قد يجعل الحرص الزائد الإعداد غير صالح.

حواجز خفية بعد SPF وDKIM وDMARC

إلى جانب البروتوكولات الثلاثة المعروفة، توجد متطلبات تقنية بلا أسماء تسويقية لامعة يمكنها أن تمنع التسليم بالسرعة نفسها.

FCrDNS (نظام أسماء النطاقات العكسي المؤكد أماميا)

ينبغي أن يكون لكل عنوان IP مرسل سجل PTR يشير إلى اسم مضيف، وأن يحتوي اسم المضيف على سجل A يعود إلى عنوان IP الأصلي. يساعد هذا التحقق الدائري على إثبات اتساق هوية البنية التحتية. إذا أنشأت آلة افتراضية سحابية وثبت Postfix وأرسلت من دون سجل PTR، فقد يعد Gmail الحركة مريبة ويعيد مثلا 550 5.7.1.

RFC 8058: إلغاء الاشتراك بنقرة واحدة

منذ يونيو 2024 لم يعد رابط التذييل وحده كافيا لرسائل التسويق الصادرة عن فئات محددة من المرسلين بكميات كبيرة. ويجب أن تتضمن الرسائل المعنية ترويستين محددتين:

يجب أن تقبل نقطة HTTPS طلب POST، وألا تعتمد على GET. تفحص روبوتات مكافحة الرسائل المزعجة الروابط أحيانا بفتحها. فإذا ألغى طلب GET الاشتراك فورا، قد تلغي الروبوتات اشتراك مستخدمين حقيقيين بالخطأ. وإذا تعذر على المستخدم العثور على مخرج سهل، فقد يضغط "إبلاغ عن رسالة مزعجة" بدلا منه ويرتفع المعدل نحو عتبة 0.3%.

عتبة 0.3%: اقتصاد السمعة

لن تكفي نتائج SPF وDKIM وDMARC المثالية ولا FCrDNS والترويسات السليمة إذا كان المستلمون لا يريدون المحتوى.

معدل شكاوى الرسائل المزعجة من أهم المقاييس. يوصي Google بإبقائه دون 0.3%، أي أقل من 3 شكاوى لكل 1,000 رسالة مسلمة، ويفضل أن يكون أقل بكثير. وقد يؤدي تجاوز المعدل باستمرار إلى تقييد النطاق أو حظره.

فخ المقام في تقارير Yahoo

قد يختلف معدل الشكاوى الظاهر باختلاف الرسائل التي يدرجها المزود في مقام الحساب. لنفترض أنك أرسلت 1,000 رسالة. كانت سمعة نطاقك ضعيفة، فوصلت 900 رسالة إلى البريد المزعج و 100 إلى صندوق الوارد. اشتكى شخص واحد. في هذه المجموعة التوضيحية لصندوق الوارد تصبح النتيجة 1/100 = 1.0%، أي 3x عتبة التطبيق. لذلك افحص تعريف المقياس في لوحة المزود ولا تعتمد على إجمالي حجم الإرسال وحده.

مشكلة الجار المزعج

حتى مع صحة SPF وDKIM وDMARC، قد تخرج رسائلك في الاستضافة المشتركة أو منصات البريد الرخيصة "غير المحدودة" من عنوان IP نفسه الذي يستخدمه آلاف العملاء. إذا أساء أحدهم الاستخدام وأدرج Spamhaus العنوان في قائمة حظر، فقد يتراجع تسليم رسائلك أيضا. لم ترتكب خطأ، لكنك تشارك الآخرين سمعة البنية التحتية. ويعتمد حجم الخطر على رقابة المزود ومستوى العزل لديه.

قائمة الجمعة لفحص SPF وDKIM وDMARC

1. افحص الترويسات: أرسل رسالة إلى حساب Gmail شخصي. افتحها واضغط النقاط الثلاث واختر "عرض النسخة الأصلية"، ثم ابحث عن Authentication-Results. هل نجح SPF؟ هل نجح DKIM؟ هل يطابق نطاق dkim= نطاق header.from؟ إذا لم يتطابقا، فتحقق من إعدادات التوافق.

2. تحقق من FCrDNS: شغل dig -x <your-sending-ip>. هل يعيد اسم مضيف؟ ثم شغل dig <that-hostname>. هل يعيد عنوان IP؟ إذا لم تكتمل الدائرة، أصلح DNS قبل زيادة حجم الإرسال.

3. افصل حركة البريد: يفضل ألا ترسل التسويق من نطاق الشركة الأساسي. استخدم team@company.com للمراسلات بين الأشخاص، وnewsletter@marketing.company.com للحملات. إذا بلغ التسويق عتبة 0.3%، يساعد الفصل على حماية سمعة النطاق الأساسي، لكنه لا يقدم ضمانا مطلقا.

4. اقرأ المزيد: راجع دليل سمعة مرسل البريد للخطوات العملية، واقرأ شرحنا المفصل عن سمعة نطاق البريد.

خطط TrekMail

تتضمن الخطط المدفوعة المذكورة تجربة لمدة 14 يوما تتطلب بطاقة. أما Free فلا تتطلب بطاقة. تحقق من الأسعار والشروط الحالية قبل الاشتراك.

الخلاصة

مصادقة البريد باستخدام SPF وDKIM وDMARC ليست مهمة تضبطها مرة ثم تنساها، بل متطلب تشغيلي مستمر. اجتياز الفحوص هو الأساس فقط. ولرفع احتمال الوصول إلى صندوق الوارد، تحتاج إلى توافق دقيق بين النطاقات وإدارة سليمة للشبكة تشمل FCrDNS وترويسات إلغاء الاشتراك بنقرة واحدة واستراتيجية لحماية السمعة. لا يضمن أي إعداد منفرد الوصول إلى صندوق الوارد. راقب النتائج وتحكم في بنيتك التحتية.

علامات النجاح في SPF وDKIM وDMARC هي تذكرة الدخول وليست خط النهاية. جرب TrekMail مجانا وأدر مصادقة بريدك بصورة مدروسة.