شرح مصادقة البريد باستخدام SPF وDKIM وDMARC

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

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

النظرية بسيطة والتنفيذ يحتاج عناية. يصرح SPF لمسار الإرسال الفعلي، ويتحقق DKIM من التوقيع وبقاء البيانات الموقعة، وينشر DMARC السياسة المطلوبة عند الفشل ويفحص محاذاة نطاق From الظاهر. يساعد الإعداد الصحيح لكنه لا يضمن التسليم.

ما الذي تفعله SPF وDKIM وDMARC فعليا؟

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

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

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

SPF هو الطبقة الأولى. يستخدم الخادم المستلم نطاق MAIL FROM أو envelope الفعلي ويقرأ سجل SPF TXT ويفحص تصريح عنوان IP المتصل. تجعله إعادة التوجيه وسلاسل include الطويلة عرضة للفشل.

يوجد SPF في DNS كسجل TXT. مثال عادي:

v=spf1 include:_spf.google.com include:spf.trekmail.net -all

تعني هذه السلسلة:

1. يعلن v=spf1 نوع السجل.
2. يشير include: إلى بنية إرسال نشرها نطاق آخر.
3. يطلب -all نتيجة fail للمصادر الأخرى.

العقبة المعروفة هي حد 10 استعلامات DNS في RFC 7208. يحسب كل include وكذلك الآليات وmodifiers المتداخلة التي تستعلم DNS. قد ينتج عن التجاوز PermError، ولا تكون النتيجة نجاح SPF صالحا.

ألغيت CRM قبل عامين وتركت include:، ثم أضافت منصة التسويق ثلاثة واستحدث مكتب الدعم واحدا آخر. قد لا تظهر المشكلة حتى يقيم المستلم السلسلة كاملة.

قد يفشل SPF بعد إعادة التوجيه. فإذا أعادت جامعة توجيه الرسالة إلى Gmail، قد يرى Gmail خادم الجامعة كمصدر الاتصال. يمكن أن يفشل مسار SPF كان صحيحا قبل التوجيه، لذلك لا يكفي SPF وحده.

عند استخدام TrekMail توضح الوثائق الحالية قيمة include المطلوبة ودمجها بلا تكرار: سجلات DNS المطلوبة.

DKIM: من وقع الرسالة وهل بقيت البيانات سليمة؟

يوقع DKIM بمفتاح خاص ويتحقق المستلم بالمفتاح العام في DNS. قد يصمد أمام إعادة التوجيه إذا بقي توقيع صالح ومحاذ وبياناته الموقعة بعد canonicalization سليمة. وقد يؤدي تعديل body أو الترويسات الموقعة إلى الفشل.

توجد سجلات DKIM تحت selector مثل selector1._domainkey.example.com أو dkim._domainkey.example.com. يوقع المرسل بالـselector المطابق ويجلب المستلم المفتاح العام من DNS.

قيمة DNS نموذجية:

Host: dkim._domainkey
Type: TXT
Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4G...

أخطاء التشغيل الشائعة:

1. بعد تدوير المفاتيح يظل الخادم يستخدم selector القديم.
2. بعد تغيير المورّد لا ينشر المفتاح العام الجديد.
3. يتعامل مضيف DNS خطأ مع قيمة TXT الطويلة.
4. تعيد قائمة بريدية كتابة body فتكسر التوقيع.

استخدم مفاتيح 2048 بت كخيار افتراضي موصى به حيث تتوافق البيئة، ما لم يتطلب المورّد أو DNS خيارا آخر تم اختباره. لا تزال أنظمة قديمة تستخدم 1024 بت؛ اختبر التوافق قبل الترحيل في 2026.

في اشتراكات TrekMail التي تدعم SMTP المدار وDKIM الخاص بالنطاق، يمكن توقيع البريد بمفتاح النطاق بعد تفعيل الإعداد فعليا. راجع ذهاب رسائلي إلى البريد المزعج.

DMARC: السياسة المطلوبة من المستلمين

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

انشره في _dmarc.example.com. ابدأ ببساطة:

v=DMARC1; p=none; rua=mailto:dmarc@example.com

شدد السياسة بعد الجرد والاختبارات الحية:

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

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

لا يطلب p=none تقييد DMARC، ويطلب p=quarantine المعاملة كمشبوه، ويطلب p=reject الرفض. تبقى للمستلم سياسة محلية، فلا تضمن هذه القيم إجراء disposition موحدا..

المحاذاة هي الفخ الأكبر. مثال:

From الظاهر: newsletter@yourcompany.com
Return-Path: bounce.vendor.com
نطاق DKIM: vendor.com

قد ينجح SPF وDKIM تقنيا ويفشل DMARC لأن أيا منهما غير محاذ مع yourcompany.com.

يحدث ذلك مع Mailchimp وHubSpot وZendesk وCRM عندما لا تفعل مصادقة نطاق العميل فعليا. تطلب FAQ الحالية من Google للمرسلين بالجملة المنطبقين إلى حسابات Gmail الشخصية إعداد SPF وDKIM، ومحاذاة أحدهما على الأقل مع From للبريد المباشر، وسجل DMARC أدنى ولو كان p=none: الأسئلة الشائعة لإرشادات مرسلي Google.

SPF أم DKIM أم DMARC: أيها أهم؟

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

قد يكون الإعداد بسيطا مع خادم واحد بلا مرسلي SaaS. أما مكتب الدعم والنشرات وCRM والتوجيه على نطاق واحد فتحتاج إلى التحقق من المسارات المحاذية فعليا. التقارير قد تكون جزئية، لذلك افحص الترويسات والسجلات.

لماذا تسبب إعادة التوجيه والقوائم أعطالا غريبة؟

قد تكسر إعادة التوجيه SPF لأن الوسيط يرسل الرسالة. يساعد DKIM إذا بقي التوقيع الصالح والمحاذي سليما، لكن تعديل body أو subject قد يكسره.

قد يبدو الإعداد صحيحا بينما يفشل المسار غير المباشر: يتغير IP وتضيف القائمة footer فتختفي إشارتا المحاذاة. يفسر ذلك فشل DMARC ولا يثبت نتيجة التسليم النهائية.

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

فحوص أخرى تؤثر في التسليم

لا تضمن السجلات الصحيحة صندوق الوارد. يراجع المستلمون reverse DNS وTLS والشكاوى والسمعة وإلغاء الاشتراك. SPF وDKIM وDMARC أساس وليست النظام كله.

1. Forward-confirmed reverse DNS: يحتاج IP المرسل إلى PTR يعيد اسم مضيفه إلى IP نفسه. تذكر Google DNS الأمامي والعكسي الصالح ضمن المتطلبات المنطبقة.
2. TLS: يتوقع مزودون كبار TLS، وتذكر FAQ من Google أن البريد بلا TLS قد يواجه أخطاء مؤقتة أو دائمة.
3. شكاوى البريد المزعج: تذكر إرشادات Google المنطبقة أقل من 0.1% وتحذر من بلوغ 0.3%. ليست هذه ضمانة تسليم عامة.
4. إلغاء الاشتراك بنقرة: يتطلب البريد الترويجي المنطبق ترويسات بأسلوب RFC 8058، لا رابط footer مخفيا فقط.

يحتاج النطاق الجديد إلى إرسال تدريجي قائم على الموافقة. قد تؤثر حملة مفاجئة أو قائمة سيئة في إشارات السمعة مبكرا.

إعداد المصادقة من دون الإضرار بالإنتاج

احصر كل المرسلين ثم انشر بدقة وتحقق برسائل حية وشدد DMARC تدريجيا. اختبر المسارات النادرة والمهمة خلال فترات ممثلة متعددة وجهز خطة تراجع.

1. سجل مضيف الصناديق وCRM والدعم والنشرات والنماذج والفوترة والخوادم.
2. ادمج المرسلين المدعومين في سجل SPF واحد ولا تنشر سجلين SPF TXT.
3. انشر DKIM لكل selector مستخدم فعليا.
4. ابدأ DMARC بـp=none وراجع التقارير والسجلات والترويسات.
5. فعل مصادقة النطاق المخصص واختبر المحاذاة للمرسلين الخارجيين.
6. انتقل بضبط إلى p=quarantine ثم p=reject عندما تدعم البيانات الممثلة ذلك.

قد تبدو السجلات الأساسية لنطاق TrekMail بإرسال مدار، حسب إعداد الحساب الحالي، هكذا:

MX  @                mail.trekmail.net.            priority 10
TXT @                v=spf1 include:spf.trekmail.net -all
TXT dkim._domainkey  v=DKIM1; k=rsa; p=...unique key from dashboard...
TXT _dmarc           v=DMARC1; p=quarantine; rua=mailto:dmarc@trekmail.net

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

الطريقة القديمة مقارنة بالجديدة

كان النهج التقليدي اشتراكا بسعر لكل مستخدم أو إدارة DNS وTLS وselectors والسمعة ذاتيا. يمكن لبيئة معيارية فصل استضافة الصناديق عن الإرسال وجمع التحقق والترحيل.

وفقا للعرض الحالي، قد يضم Nano حتى 10 نطاقات و5 غيغابايت من التخزين المشترك وBYO SMTP. تبدأ الخطط المدفوعة حاليا من $3.50 شهريا وقد تشمل SMTP مدارا. تعتمد النطاقات المخصصة وIMAP وcatch-all والتوجيه وترحيل IMAP وAPI على الخطة. قد تتوفر تجربة مجانية لمدة 14 يوما للخطة المدفوعة وتتطلب بطاقة ائتمان، وقد يبقى Nano مجانيا بلا بطاقة وفق الشروط الحالية. تحقق من الأسعار والميزات والحدود.

مع نطاقات كثيرة، قد تجمع لوحة واحدة وتخزين مشترك وقيم DNS خاصة بالحساب وترحيل من جهة الخادم العمل، بلا ضمان لخفض التكلفة. قارن استضافة بريد متعددة النطاقات وأسعار TrekMail.

الخلاصة: SPF وDKIM وDMARC هي الأساس

يصرح SPF لعناوين IP لنطاق envelope، ويتحقق DKIM من التوقيع وسلامة البيانات الموقعة، ويربط DMARC نتيجة محاذية بـFrom الظاهر وينشر السياسة المطلوبة.

انشر سجل SPF صالحا واحدا وDKIM عاملا وسجل DMARC يبدأ بـp=none. تحقق من كل مرسل ومسار نادر برسائل حية. انتقل إلى الفرض بعد فترات ممثلة متعددة ومع خطة تراجع. قد يقلل ذلك التشخيص الممكن تجنبه، لكنه لا يضمن التكلفة أو النتيجة.