توقف SPF عن العمل بعد تغيير مزوّد البريد — إصلاح الترحيل (2026)

نُشر 2026-07-08

الأرقام بتاريخ 2026-06-29 · المنهجية v7. بيانات إحصاء مجمّعة عبر 261 مليون نطاق مُصنَّف. اطلع على طريقة التصنيف.

عادةً ما ينكسر SPF بعد تبديل مزوّد البريد لأن سجل المزوّد الجديد أُضيف جانباً للقديم. سجلَا v=spf1 يُمثِّلان خطأً دائماً — SPF يُبطَل كلياً. 1,013,416 نطاق — نحو واحد من كل 138 ممن يُحاوِل نشر SPF — في تلك الحالة، وفقاً لإحصاء Defaults.Exposed لـ 261 مليون نطاق. ادمجهما في واحد.

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

لماذا انكسر SPF فور الترحيل؟

لأن دليل إعداد المزوّد الجديد قال “أضف سجل TXT هذا” — وفعلت ذلك، جانباً للقديم. هذا بالضبط ما لا يسمح به معيار SPF. RFC 7208 (§3.2، نتيجة الخطأ مُقرَّرة في §4.5) يُجيز سجلاً واحداً فقط بـ v=spf1 لكل نطاق؛ المستقبِل الذي يجد اثنَين أو أكثر يُعيد PermError لا أن يخمّن أيهما تفويضي. PermError يعني أن SPF باطل: لا السجل القديم، لا الجديد، لا SPF على الإطلاق.

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

هذا هو النسخ-اللصق الذي يُبطل الحماية حين تُبدِّل المزوّدين، وليس نادراً: 1,013,416 نطاق ينشر سجلَين أو أكثر من SPF الآن — نحو واحد من كل 138 من 139 مليون نطاق يُحاول SPF، وفقاً لإحصاء Defaults.Exposed لـ 261 مليون نطاق (البيانات بتاريخ 2026-06-29). الأرقام الكاملة حول فخ السجلَين لها تقريرها الخاص؛ هذه الصفحة هي الإصلاح الإجرائي.

ما الذي تركه الترحيل خلفه؟

خمسة متخلَّفات تتسبب في تقريباً كل إخفاق SPF بعد الترحيل. افحصها بهذا الترتيب:

ما تُرك خلفه	ما تراه	الإصلاح
السجل القديم لـ SPF، لا يزال في DNS جانباً للجديد (سجلَا `v=spf1`)	المدقِّقات تُبلِّغ عن “سجلات SPF متعددة” أو PermError؛ SPF يتوقف عن العمل كلياً	ادمج في سجل واحد، احذف الباقي — الخطوات أدناه
include المزوّد القديم داخل سجلك الواحد	SPF يعمل، لكنك تهدر عمليات بحث DNS وخوادم المزوّد القديم لا تزال قادرة على الإرسال باسمك	أزله بمجرد استنزاف البريد من النظام القديم كلياً
include المزوّد الجديد لم يُضَف	البريد من المزوّد الجديد يفشل في SPF عند المستقبِلين	أضفه إلى السجل الواحد الموجود — ليس كسجل جديد أبداً
مُحدِّدات DKIM لم تُنشأ للمزوّد الجديد	`dkim=fail` أو توقيعات من النطاق الافتراضي للمزوّد؛ DMARC بلا ركيزة ثانية	انشر المُحدِّدات الجديدة — الخطوة 6 أدناه
السجل حُدِّث فقط عند خوادم الاسم القديمة	إجابات مختلفة حسب من تسأل؛ إخفاقات متقطعة	أصلح المنطقة عند خوادم الاسم التفويضية؛ تحقق من كلتا المجموعتَين أثناء الإطلاق

كيف أُصلح ذلك؟ قائمة مهام الترحيل

شغّل الفحص المجاني على defaults.exposed أولاً. يقرأ DNS الحي الخاص بك ويُخبرك هل لديك سجلات SPF متعددة أو include مفقود أو فجوة DKIM — شخِّص قبل أن تلمس أي شيء.
أدرج كل سجلات SPF عند خوادم الاسم التفويضية. dig +short NS yourdomain.com، ثم dig +short TXT yourdomain.com @<nameserver> مقابل أحدها. عُدّ السلاسل التي تبدأ بـ v=spf1. العدد الآمن الوحيد هو 1.
ادمج في سجل واحد. سجل واحد يبدأ بـ v=spf1، يحتوي include مزوّدك الجديد وأي مرسِل آخر لا تزال تستخدمه (أداة الفواتير، CRM، منصة النشرة)، آلية -all أو ~all إنهائية واحدة. مثال — Google Workspace القديم، Microsoft 365 الجديد، في مرحلة الاستنزاف:
```
قبل:  "v=spf1 include:_spf.google.com ~all"
      "v=spf1 include:spf.protection.outlook.com -all"

بعد:  "v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all"
لاحقاً: "v=spf1 include:spf.protection.outlook.com -all"
```
قيم المزوّدين وتفاصيل لوحات DNS في أدلة الإعداد لـ Google Workspace وMicrosoft 365.
احذف السجلات الزائدة. الدمج بلا حذف لا يُصلح شيئاً — PermError يأتي من العدد.
ابقِ include المزوّد القديم فقط بينما النظام القديم لا يزال يرسل — تقارير مجدولة، موصِّل CRM قديم، صندوق بريد منسي. بمجرد انتهاء الاستنزاف، أزله: include متقادم يترك البنية التحتية القديمة مُفوَّضةً للإرسال باسمك، وكل include يكلف عمليات بحث DNS مقابل سقف SPF الصارم البالغ 10 — ما لا يقل عن 797,263 نطاق أبطل SPF بتجاوز ذلك السقف (الإحصاء، 2026-06-29).
أعدّ DKIM للمزوّد الجديد — ولا تحذف المُحدِّدات القديمة بعد. المُحدِّدات الجديدة تُوقِّع البريد الجديد؛ المُحدِّدات القديمة يجب أن تظل منشورة حتى يُسلَّم كل رسالة موقَّعة بها وتستقر أي توجيهات. التفصيل الكامل في DKIM الفاشل بعد تبديل أدوات البريد.
إن غيّرت خوادم الاسم أيضاً، افحص كليهما. ترحيلات DNS كثيراً ما ترافق ترحيلات البريد. استعلم مجموعة NS القديمة والجديدة مباشرةً (dig TXT yourdomain.com @ns-قديم و@ns-جديد) — حتى يتكامل تفويض المُسجِّل، بعض المستقبِلين لا يزالون يسألون الخوادم القديمة، فيجب أن يوجد السجل المُصحَّح عند أي مجموعة تُجيب.
أعد تشغيل الفحص وأكّد أن SPF يُظهر سجلاً واحداً صالحاً مع نجاح.

أي نطاق يفحصه SPF فعلاً؟

يُقيِّم المستقبِلون SPF مقابل نطاق Return-Path (RFC5321.MailFrom) — عنوان الارتداد — لا ترويسة From التي يراها متلقّوك. بعد الترحيل هذا مهم مرتَين: قد يستخدم مزوّدك الجديد نطاق ارتداده الخاص حتى تُهيِّئ نطاقاً مخصصاً، و”نجاح” SPF على نطاق ليس نطاقك لن يتوافق مع DMARC. الإصلاح لذلك هو DKIM للمزوّد الجديد، موقَّعاً بنطاقك.

ترحيل وإعادة علامة تجارية في آنٍ واحد؟

غيّرت النطاق أيضاً مع المزوّد؟ عاملهما كمهمتَين. النطاق الجديد يحتاج الحزمة الكاملة — SPF وDKIM وDMARC — من اليوم الأول؛ استخدم قائمة مهام البريد للنطاق الجديد. النطاق القديم يظل موثَّقاً طالما يجري من خلاله توجيه أو حركة ردود، ويُقيَّد صراحةً (لا يُهجَر فحسب) بمجرد تحويله لنطاق مُوقَف. نطاق قديم بـ SPF متخلَّف ونصف معطوب هو هدف تزوير يرتدي اسمك السابق.

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

هل يمكنني الاحتفاظ بسجلَي SPF أثناء الترحيل؟ لا. لا توجد فترة سماح في المعيار — سجلَا v=spf1 يُمثِّلان PermError من لحظة وجود الثاني، و1,013,416 نطاق يجلس في تلك الحالة بتاريخ الإحصاء (2026-06-29). النمط الآمن للترحيل هو سجل واحد يحمل includes كلا المزوّدَين خلال فترة التداخل.

كم أُبقي include المزوّد القديم؟ حتى لا يُرسِل شيء عبر المزوّد القديم — عادةً طول نافذة التداخل، أياماً إلى بضعة أسابيع. راقب Return-Path لأي شيء لا يزال يصل عبر النظام القديم؛ حين تتوقف تلك الحركة، أزل include وأعد فحص عدد عمليات البحث.

لماذا يُظهر مدقِّق سجلي القديم بعد إصلاحه؟ تخزين DNS المؤقت يُكرِّم TTL السجل، وإن تغيّرت خوادم الاسم، بعض المُحلِّلين لا يزالون يستعلمون المجموعة القديمة. تحقق مباشرةً عند خوادم الاسم التفويضية بـ dig TXT yourdomain.com @<ns> — إن كانت الإجابة صحيحة هناك، الإصلاح تمَّ والذاكرات المؤقتة ستلحق. إن كانت خاطئة عند مجموعة NS واحدة، انظر سجل SPF غير موجود — الأسباب الحقيقية.

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

أرسل للمالك التقرير

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

افحص نطاقك ← · DKIM الفاشل بعد تبديل أدوات البريد ← · ‘سجل SPF غير موجود’ — الأسباب الحقيقية ← · طريقة التصنيف ← · بيانات إجمالية فقط. البيانات مخزّنة ومعالَجة في الاتحاد الأوروبي.