Defaults.Exposed

Defaults.Exposed › التقارير

هل يمكن أن يمتلك النطاق سجلَّي SPF؟ لا — مليون نطاق ألغى حمايته بنفسه للتو (2026)

نُشر 2026-07-03

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

لا — يجوز للنطاق أن ينشر سجل SPF واحدًا بالضبط، والوقوع في هذا الخطأ يُطفئ SPF بالكامل: 1,013,416 نطاقًا ينشرون حاليًا سجلَّين أو أكثر، وهو ما يجعل — بموجب RFC 7208 — جميع سجلات SPF الخاصة بالنطاق غير صالحة. لا الأحدث، ولا الأقدم — كلها بلا استثناء. المستقبِل الذي يجد أكثر من سجل v=spf1 واحد يجب أن يُرجع خطأً دائمًا، ما يعني انعدام حماية SPF بالكامل، على نطاق يبدو لمالكه وكأنه يمتلك ضعف الحماية.

لماذا يساوي سجلّا SPF صفرًا؟

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

وخطأ PermError ليس محايدًا. يعامله DMARC كإخفاق في ركن SPF — فالنطاق الذي كرّر سجله يكون قد ألغى حمايته و أعاق مصادقة بريده الشرعي في آنٍ واحد. إنه أحد أخطاء DNS النادرة جدًا التي تؤدي فيها إضافة الحماية إلى إزالتها (نشر سجلَّي DMARC يفعل الشيء ذاته بـ DMARC).

نحو نطاق واحد من كل 138 من النطاقات التي تحاول استخدام SPF فعل هذا بنفسه.

كيف يحدث ذلك؟ نسخ ولصق أثناء الإعداد

لا أحد تقريبًا يكتب سجل SPF ثانيًا عن قصد. يحدث ذلك يوم تضيف أداة بريد إلكتروني:

  1. نطاقك يمتلك بالفعل v=spf1 include:spf.protection.outlook.com -all من مزود صندوق بريدك.
  2. تسجّل في منصة نشرات بريدية، أو نظام CRM، أو أداة فوترة.
  3. يقول دليل إعدادها: “أضف سجل TXT هذا إلى DNS الخاص بك: v=spf1 include:newtool.example.com ~all.”
  4. تفعل تمامًا ما يقوله — فتُضيفه، بجوار السجل القديم.

يوجد الآن سجلان، وكلاهما باطل. قال الدليل “أضف”، والإضافة هي الشيء الوحيد الذي لا يسمح به المعيار؛ أما الخطوة الصحيحة — دمج include: الجديد في السجل القائم — فلا يذكرها أي تدفّق إعداد تقريبًا.

الإخفاق غير مرئي من لوحة DNS: كلا السجلين يبدوان مُصاغَين بشكل سليم كلٌّ على حدة، والبريد يصل في الغالب لأن المستقبِلات ترجع إلى إشارات أخرى. لا شيء ينبّهك حتى يهبط بريد منتحَل أو تتراجع قابلية التسليم.

كيف تفحصه وتصلحه — دقيقتان، مجانًا

  1. استعلم عن سجلات TXT الخاصة بنطاقك (dig TXT yourdomain.com، أو استخدم فحصنا المجاني).
  2. عُدّ السجلات التي تبدأ بـ v=spf1. الرقم الآمن الوحيد هو 1.
  3. إن كان لديك أكثر من ذلك: ادمجها — كل آليات include: وip4:/ip6: في سجل واحد بمُؤهِّل ختامي واحد (راجع ~all مقابل -all) — واحذف الباقي.
قبل:  v=spf1 include:spf.protection.outlook.com -all
      v=spf1 include:servers.mcsv.net ~all

بعد:   v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net -all

أثناء الدمج، انتبه إلى حد الـ 10 استعلامات — فكثرة آليات include: تُعطِّل SPF بطريقة أخرى.

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

هل يُسمح بسجلات SPF متعددة؟ لا. يسمح RFC 7208 بسجل v=spf1 واحد بالضبط لكل نطاق؛ وسجلان أو أكثر يسبّبان خطأً دائمًا يُبطل SPF بالكامل. 1,013,416 نطاقًا في هذه الحالة حتى 2026-06-29.

هل يتجاوز سجل SPF الثاني الأول؟ لا يفوز أيٌّ منهما. المستقبِل الذي يجد سجلات متعددة يجب أن يُفشل التقييم بدلًا من الاختيار — فتتوقف كلها عن العمل دفعة واحدة.

كيف أدمج سجلَّي SPF في سجل واحد؟ سجل واحد يبدأ بـ v=spf1، يحتوي كل آليات include: وآليات IP من جميع السجلات، وينتهي بـ -all أو ~all واحد. احذف الزوائد، ثم تحقق من صمود عدد استعلاماتك بعد الدمج.

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

تحقّق مما إذا كان نطاقك أحد المليون

نظرة من 30 ثانية إما أن تُبرِّئك أو تُسلّمك عملية دمج تستغرق دقيقتين.

افحص نطاقك ← · أصلح SPF ← · تقرير SPF PermError ← · نموذج نضج SPF ← · بيانات تجميعية فقط. البيانات مُخزَّنة ومُعالَجة في الاتحاد الأوروبي.