SPF وDKIM وDMARC: الدليل الكامل لمصادقة البريد الإلكتروني

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

الثلاثة جميعها تعيش في سجلات DNS الخاصة بنطاقك، ما يعني أنك تستطيع فحص إعداد المصادقة لأي نطاق، بما فيه نطاقك أنت، بمجرد بحث DNS. يشرح هذا الدليل وظيفة كل سجل، وكيف تقرؤه، وكيف تصل إلى سياسة DMARC صارمة دون أن تحجب فواتيرك أنت عن طريق الخطأ.

لفحص السجلات الثلاثة دفعة واحدة، بما في ذلك عدد استعلامات SPF وطول مفتاح DKIM، استخدم فاحص SPF وDKIM وDMARC لدينا.

لماذا تهم مصادقة البريد

تغيّر أمران في السنوات الأخيرة. صار المهاجمون أبرع في انتحال العلامات الموثوقة، وردّ كبار مزوّدي صناديق البريد بجعل المصادقة إلزامية عمليًا. يطلب Gmail وYahoo الآن SPF وDKIM وDMARC من المرسلين بكميات كبيرة، وحذت Microsoft حذوهما. وإذا كانت سجلاتك مفقودة أو معطوبة، فالعواقب فورية وعملية جدًا:

• تُفلتر رسائلك. الرسائل غير المصادَق عليها تُحجز في الحجر الصحي أكثر بكثير، وتُرفض أحيانًا قبل أن تصل إلى أي صندوق.
• بإمكان أي أحد انتحال نطاقك. بلا سياسة DMARC، لا يملك الخادم المستقبِل أي تعليمات لرفض بريد مزوّر يحمل اسمك.
• لا ترى إساءة الاستخدام. تقارير DMARC هي السبيل الوحيد لتعرف أن أحدًا يرسل تصيّدًا باسمك.
• تتعثر الصفقات. تسأل استبيانات الأمان ومراجعات المورّدين عن سياسة DMARC بانتظام، و«none» تُعامَل أكثر فأكثر كملاحظة سلبية.

السجلات الثلاثة في لمحة

هي طبقات لا بدائل. يفحص SPF الخادم المرسِل، ويفحص DKIM الرسالة نفسها، ويربط DMARC الاثنين بالنطاق الذي يراه الإنسان فعلًا في ترويسة From ثم يحدد ما يجب فعله عند الفشل. أنت بحاجة إلى الثلاثة.

SPF: من يحق له الإرسال باسم نطاقك

Sender Policy Framework قائمة منشورة بالخوادم المسموح لها بإرسال بريد باسم نطاقك. يأخذ الخادم المستقبِل عنوان IP الذي اتصل به، ويقرأ سجل SPF لديك، ويتحقق مما إذا كان ذلك العنوان ضمن القائمة.

كيف تقرأ سجل SPF

يبدو السجل النموذجي هكذا:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 ~all

يُقرأ من اليسار إلى اليمين. v=spf1 هو الإصدار ويجب أن يأتي أولًا. كل include: يسحب سجل SPF الخاص بنطاق آخر، وهكذا تُصرّح لمزوّد مثل Google Workspace أو لخدمة بريد معاملات. أما ip4: وip6: فتصرّح لعناوين أو نطاقات محددة، عادةً خادمك أنت. الآلية الأخيرة هي القاعدة الشاملة، وهي التي يخطئ فيها أكثر الناس:

• -all فشل صارم. كل ما ليس مُدرجًا غير مصرّح به، ويُتوقع من المستقبِل رفضه.
• ~all فشل مرن. المرسلون غير المدرجين مشبوهون لكن تُقبل رسائلهم، عادةً مع خصم في تقييم البريد العشوائي.
• ?all محايد ولا يخبر المستقبِل بشيء، ما يُفرغ نشر السجل من معناه.

ابدأ بـ~all بينما تتأكد أن كل مرسِل مشروع مُدرج، ثم شدّد إلى -all متى صارت تقارير DMARC نظيفة.

حد الاستعلامات العشرة

يسمح SPF بعشرة استعلامات DNS كحد أقصى أثناء تقييم السجل. يُحسب كل include: وa وmx وredirect، بما في ذلك المتداخلة. وتجاوز الحد ينتج خطأً دائمًا يعامله معظم المستقبِلين كأن لا SPF لديك إطلاقًا. وغالبًا يكفي ثلاثة أو أربعة مزوّدي بريد لتجاوزه، فراجع السجل كلما أضفت خدمة إرسال جديدة واحذف المزوّدين الذين توقفت عن استخدامهم.

وثمة قاعدة أخرى تفاجئ الكثيرين: لا يجوز للنطاق نشر أكثر من سجل SPF واحد. وجود سجلَّي TXT يبدآن بـv=spf1 على الاسم نفسه خطأ دائم، وليس دمجًا.

DKIM: توقيع رسائلك

يضيف DomainKeys Identified Mail توقيعًا تشفيريًا إلى كل رسالة صادرة. يحتفظ خادمك بمفتاح خاص ويوقّع به ترويسات مختارة إضافة إلى متن الرسالة؛ ويُنشر المفتاح العام المقابل في DNS. يجلب المستقبِل المفتاح العام ويتحقق من التوقيع فيعرف أمرين: أن الرسالة وقّعها نطاقك فعلًا، وأن ما غطّاه التوقيع لم يُعدَّل في الطريق.

يوجد المفتاح العام على اسم مبني من مُحدِّد، مثل google._domainkey.example.com أو s1._domainkey.example.com. وُجدت المُحدِّدات لتتمكن من تشغيل عدة مفاتيح معًا، وهذا ما يجعل تدوير المفاتيح سهلًا: انشر مُحدِّدًا جديدًا، وانقل التوقيع إليه، ثم اسحب القديم لاحقًا.

ولأن التوقيع يسافر مع الرسالة، يصمد DKIM أمام إعادة التوجيه حيث يفشل SPF. فإذا أعادت قائمة بريدية بثّ رسالتك، تغيّر عنوان IP المتصل وفشل SPF، لكن توقيع DKIM يظل صالحًا ما دامت القائمة لم تُعِد كتابة الترويسات الموقّعة ولا المتن. هذه المتانة هي السبب الرئيس في أهمية DKIM حتى مع وجود SPF.

DMARC: إخبار المستقبِل بما يفعل

ينتج SPF وDKIM نجاحًا أو فشلًا، لكن أيًّا منهما لا يقول للمستقبِل ماذا يفعل، ولا ينظر أيٌّ منهما إلى عنوان From الذي يقرؤه مراسلك فعلًا. يسدّ DMARC الثغرتين. ويبدو السجل هكذا:

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100; adkim=s; aspf=r

p= هي السياسة: none (مراقبة فقط)، أو quarantine (معاملة الفشل كبريد عشوائي)، أو reject (الرفض عند الباب). وrua= هو العنوان الذي يستقبل التقارير المجمّعة اليومية، وهو أثمن أجزاء السجل. أما pct= فيتيح تطبيق السياسة على نسبة من البريد أثناء التدرج.

المحاذاة، الجزء الذي يغفله الجميع

لا يكتفي DMARC باشتراط نجاح SPF أو DKIM، بل يشترط أن يكون النطاق الناجح متحاذيًا مع النطاق الظاهر في ترويسة From. قد تنجح رسالة في SPF لنطاق mailer.vendor.com وتفشل مع ذلك في DMARC لنطاق example.com، لأن الاثنين لا يتطابقان. وهذا أكثر الأسباب شيوعًا لفشل إعداد يبدو سليمًا.

يتحكم adkim وaspf في صرامة التطابق. فالوضع المرن (r، وهو الافتراضي) يقبل نطاقًا فرعيًا مثل mail.example.com، بينما الصارم (s) يطلب تطابقًا تامًا. ابدأ بالمرن. وينجح DMARC إذا نجح أيٌّ من SPF أو DKIM وكان متحاذيًا، فتوقيع DKIM متحاذٍ واحد يكفي.

تطبيق السياسة بأمان

1. انشر p=none مع عنوان للتقارير. لا يتغير شيء في تدفق بريدك، لكن التقارير تبدأ بالوصول.
2. اقرأ التقارير مدة أسبوعين إلى أربعة. ستكشف خدمات إرسال نسيتها: نظام العملاء، ومكتب الدعم، وأداة الفوترة، ومنصة التسويق القديمة.
3. سُدّ الثغرات. أضف كل مرسِل مشروع إلى SPF، وفعّل توقيع DKIM بنطاق متحاذٍ، وتحقق من التغيير في التقرير التالي.
4. انتقل إلى p=quarantine. استخدم pct= للتدرج إن كنت ترسل بكميات كبيرة.
5. اختم بـp=reject. فقط حين لا تُظهر التقارير أي بريد مشروع فاشل. هذه هي السياسة التي توقف الانتحال فعليًا.

كيف تفحص سجلاتك بنفسك

السجلات الثلاثة سجلات TXT عامة، ففحصها لا يستغرق سوى ثوانٍ:

1. SPF. نفّذ استعلام TXT على نطاقك المجرّد بأداة بحث DNS وابحث عن السلسلة التي تبدأ بـv=spf1. تأكد أنها واحدة فقط، واحسب عدد الاستعلامات.
2. DMARC. نفّذ استعلام TXT على _dmarc. متبوعًا بنطاقك. إن لم يعد شيء فليست لديك سياسة ولا تقارير.
3. DKIM. نفّذ استعلام TXT على selector._domainkey. متبوعًا بنطاقك. ويذكر توثيق مزوّد بريدك المُحدِّد المستخدم.
4. تحقق من الطرف إلى الطرف. أرسل رسالة إلى حساب لدى مزوّد كبير وافحص الترويسات الواردة. يعرض عرض «إظهار الأصل» في Gmail نتائج SPF وDKIM وDMARC للرسالة التي أرسلتها للتو، وهو الاختبار الوحيد الذي يغطي السلسلة كاملة.

وما دمت داخل DNS، تأكد من بقية إعداد بريدك: تحقق أن سجلات MX تشير حيث تتوقع، وأن الاسم في شهادة خادمك مطابق، وهو ما يمكنك التحقق منه بـمدقق شهادات SSL.

أخطاء شائعة يجب تجنبها

• سجلّا SPF. ادمجهما في واحد. وجود اثنين خطأ دائم.
• ترك DMARC على p=none إلى الأبد. المراقبة نقطة بداية لا وجهة. ولا يمنع الانتحال سوى quarantine أو reject.
• غياب عنوان التقارير. سجل DMARC بلا rua= يهدر المعلومات التي تحتاجها لتشديد السياسة بأمان.
• نسيان النطاقات المركونة. النطاقات التي لا ترسل بريدًا ينبغي أن تنشر v=spf1 -all وp=reject، تحديدًا لأن المهاجمين يفضّلون النطاقات غير المستخدمة.
• القفز مباشرة إلى المحاذاة الصارمة. وضع adkim=s وaspf=s قبل أن تنظف تقاريرك سيكسر بريدًا مشروعًا قادمًا من نطاقات فرعية.
• تجاهل TTL. قيمة TTL طويلة على سجل TXT تعني أن الإصلاح يحتاج ساعات لينتشر. اخفضها قبل الترحيل وارفعها بعده.

صادِق بريدك اليوم

مصادقة البريد واحدة من مهام الأمان القليلة ذات العائد الذي لا لبس فيه: تسليم أفضل، ورؤية لإساءة الاستخدام، ونطاق لا يُنتحل باستهتار. وهي كذلك مقروءة بالكامل من الخارج، فلا داعي للتخمين بشأن إعدادك أنت. ابدأ باستعلام TXT على نطاقك عبر أداة بحث DNS المجانية، واقرأ ما هو منشور فعلًا، ثم امضِ في خطوات التطبيق أعلاه واحدة تلو الأخرى.

أدوات وأدلة ذات صلة:

• بحث DNS — استعلم عن سجلات TXT وMX وSPF وغيرها لأي نطاق.
• بحث DNS: الدليل الكامل — شرح لكل نوع سجل.
• مدقق شهادات SSL — افحص شهادة خادم البريد أو الويب لديك.
• رموز حالة HTTP — مرجع سريع لكل رمز استجابة.
• لماذا يفشل سجل SPF لديك مرارًا، وكيف تُصلحه - حد الاستعلامات العشرة، وعبارات include المعطّلة، وأسباب أخرى لفشل SPF.

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