ترسل رسالة إلى عميل فتصل، وأخرى إلى عميل آخر فلا تصل — بلا خطأ ولا إشعار. هذا ليس عطلاً في البريد بل قرار اتخذه خادم المستقبل بناءً على ثلاثة سجلات في نطاقك. حين تكون غائبة أو خاطئة، تصبح رسائلك مشبوهة افتراضياً، ولا يعود ينفعها أن الموضوع مكتوب بعناية.
كيف يُحكم على رسالتك
خادم الاستلام يسأل ثلاثة أسئلة: هل المرسل فعلاً يملك الحق في الإرسال نيابة عن هذا النطاق؟ هل الرسالة لم تُعدَّل في الطريق؟ وهل نطاقك يعلن سياسة واضحة لما يجب فعله بالرسائل المشبوهة؟ الأسئلة الثلاثة تقابلها سجلات SPF وDKIM وDMARC. الغياب يعني «لا أعرف»، و«لا أعرف» ليست إجابة جيدة.
SPF: من يحق له الإرسال
سجل TXT على نطاقك يعدد الخوادم المسموح لها بالإرسال. مثال مبسط: v=spf1 include:_spf.provider.com -all. الجزء الأخير مهم: -all يعني ارفض كل ما ليس في القائمة، أما ~all فيعني علّمه كمشبوه واقبله غالباً. الخطأ الشائع: أكثر من سجل SPF واحد على النطاق؛ المعيار يسمح بواحد فقط، ووجود اثنين يجعلهما غير صالحين معاً. خطأ ثانٍ: تجاوز حد الاستعلامات (عشرة)، وهو يحدث بصمت في النطاقات التي تضيف خدمات كثيرة.
DKIM: التوقيع الذي يثبت السلامة
DKIM يضيف توقيعاً رقمياً لكل رسالة، ويُتحقق منه بسجل عام على النطاق. مزوّد البريد يعطيك المفتاح والسجل، وأنت تنسخه كما هو دون تعديل. أهم ما ينكسر هنا: إعادة صياغة الرسالة بعد التوقيع — بعض الأدوات تضيف ترويسات تجعل التوقيع غير صالح. لذلك راجع النتيجة بعد أي إضافة جديدة على مسار الإرسال.
DMARC: ماذا نفعل بالرسائل المشبوهة
DMARC يجمع نتيجتي SPF وDKIM ويقول للمستقبل: إن فشل التحقق فماذا تفعل، وإلى أين ترسل التقارير. ابدأ دائماً بـp=none مع بريد تقارير، وراقب أسبوعين، ثم انتقل إلى الحجر. من يبدأ مباشرة بالرفض القاطع قد يقطع رسائله المشروعة بسبب سجل SPF منسي.
كيف تفحص نطاقك الآن
افحص سجلات TXT وMX من الخارج، وتأكد أن SPF واحد لا اثنان، وأن مفتاح DKIM موجود، وأن DMARC يعلن سياسة. أداة فحص DNS في الموقع تعرض السجلات كما يراها العالم: فحص سجلات DNS. ثم أرسل رسالة اختبار إلى بريد خارجي وافحص ترويساتها: يجب أن تظهر SPF=pass وDKIM=pass.
ثلاثة أخطاء تتكرر
الأول: نسخ سجل SPF يحتوي include لنطاق لا تعرفه، فيصبح السجل بلا معنى. الثاني: نسيان تحديث DKIM بعد تغيير المزوّد، فتتوقف الرسائل عن التوقيع بصمت. الثالث: استخدام بريد «من» مختلف عن النطاق الموثّق، وهو أشهر سبب لاعتبار الرسالة تزويراً.
كيف تقرأ تقرير DMARC
بعد أسبوع من تفعيل التقارير ستصل ملفات XML تبدو معقدة، لكن ما تحتاجه فيها ثلاثة أشياء: من أي عنوان IP أُرسلت الرسائل، وهل اجتازت SPF أو DKIM، وهل كانت باسم نطاقك. إن وجدت عناوين لا تعرفها فإما خدمة تستخدمها دون أن تدري، أو محاولة انتحال. ابدأ بإضافة الخدمات الشرعية إلى SPF، ثم راقب أسبوعين آخرين قبل تشديد السياسة. لا تشدد أبداً في يوم وصول أول تقرير.
الخدمات المشتركة والحدود الخفية
حين تستخدم خدمة خارجية للإرسال نيابة عنك، فهي تضيف استعلامات إلى SPF وتحتاج مفتاح DKIM خاصاً بها. كل خدمة جديدة قد تنكسر بصمت إن نسيت إضافتها. والأسوأ أن تجاوز حد الاستعلامات يجعل SPF غير صالح للجميع دفعة واحدة. لذلك اجعل لكل خدمة توثيقاً منفصلاً، وراجع السجل بعد كل إضافة، لا بعد أن تبدأ الشكاوى.
رسالة اختبار واحدة لا تكفي
اختبار على عنوان واحد عندك لا يثبت شيئاً؛ فقد يكون مستقبله متسامحاً. أرسل إلى ثلاثة: Gmail، وOutlook، وعنوان شركة. لكل رسالة افحص الترويسات وسجّل النتيجة. إن نجح اثنان وفشل الثالث فالمشكلة في السياسة لا في النطاق، والفرق يظهر عادة عند التحقق من DMARC. كرر الاختبار بعد كل تغيير في مزوّد الإرسال. واحفظ نتائج الاختبارات في ملاحظة واحدة بتاريخها: بعد شهر ستعرف أي تغيير كسر أي نتيجة، بدل أن تعيد التجربة من الصفر وتظن أن العطل جديد.
ما لا تفعله
لا تعتمد على أن «الرسالة وصلت مرة» دليلاً. ولا ترسل نشرات من بريد شخصي. ولا تكرر إرسال الاختبارات إلى المهملات وتظن أن المشكلة في المستقبل. ابدأ بالسجل، ثم التوقيع، ثم السياسة، بهذا الترتيب. ترتيب الأدوار موضح في شرح سجلات DNS، وإعداد البريد نفسه في البريد الاحترافي.