ما هو SPF، وكيف يعمل سجل SPF؟

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

ما هو سجل SPF؟

SPF اختصار Sender Policy Framework (إطار سياسة المرسل). وهو معرَّف في RFC 7208، وهي وثيقة من فئة Standards Track صدرت في أبريل 2014 وحلت محل RFC 4408 التجريبي. وبعبارة الـ RFC، فهو يتيح لمالكي النطاقات «تخويل المضيفين استخدامَ أسماء نطاقاتهم في هويتَي 'MAIL FROM' أو 'HELO'».

السجل عبارة عن سجل DNS واحد من نوع TXT على النطاق نفسه:

example.com.  3600  IN  TXT  "v=spf1 include:spf.protection.outlook.com ip4:203.0.113.10 -all"

• v=spf1 يعرّف سجل TXT بأنه سجل SPF. يتجاهل المستقبِلون سجلات TXT التي لا تبدأ بهذه القيمة تحديدًا.
• include: وip4: هي آليات (mechanisms): كل منها يصف خوادم يجوز لها الإرسال.
• -all هي القاعدة الشاملة في النهاية، وتحدد النتيجة لكل خادم غير مدرج.

ينص القسم 3.1 من RFC 7208 على أن سجلات SPF «يجب (MUST) أن تُنشر بوصفها سجل مورد DNS من نوع TXT (النوع 16)» فقط. أما نوع سجل SPF المنفصل من المرحلة التجريبية فقد أُوقف. ولا يجوز للنطاق نشر أكثر من سجل SPF واحد؛ فوجود سجلين أو أكثر يؤدي إلى PermError (القسم 4.5).

كيف يفحص الخادم المستقبِل SPF؟

يجري فحص SPF عادةً أثناء محادثة SMTP، قبل وصول نص الرسالة؛ إذ ينص RFC 7208 على أن الفحص «ينبغي (SHOULD) أن يُجرى» في ذلك الوقت. يعرف الخادم المستقبِل ثلاثة أمور عندها: عنوان IP الذي اتصل، والاسم الذي قدّمه الخادم في HELO/EHLO، ومرسل المغلف في MAIL FROM.

1. فحص اسم HELO اختياريًا. ينص القسم 2.3 من RFC 7208 على أنه «يُوصى (RECOMMENDED)» بفحص هوية HELO أيضًا. وقد تغني نتيجة HELO الحاسمة عن فحص MAIL FROM الأكثر تعقيدًا.
2. فحص نطاق MAIL FROM. «يجب (MUST)» على أدوات التحقق «فحص هوية 'MAIL FROM'» إذا لم يُجرَ فحص HELO أو لم تكن نتيجته حاسمة (القسم 2.4). وفي رسائل الارتداد، التي يكون فيها MAIL FROM فارغًا، يستخدم SPF بدلًا منه postmaster@ مع اسم HELO.
3. جلب سجل TXT لذلك النطاق والاحتفاظ بالسجل الذي يبدأ بـ v=spf1.
4. تقييم الآليات من اليسار إلى اليمين. أول آلية تطابق عنوان IP المتصل تحدد النتيجة وفق المؤهِّل (qualifier) الخاص بها، ولا يُقرأ شيء بعدها.
5. تسجيل النتيجة، عادةً في رأس Authentication-Results أو Received-SPF، وتطبيق السياسة المحلية.

تُرجع الدالة واحدة من سبع نتائج (القسم 2.6):

يترك RFC 7208 المعالجة للمستقبِل عن قصد: «لا يضع البروتوكول أي متطلبات معيارية لمعالجة أي نتيجة بعينها». وتقولها Microsoft صراحةً بشأن -all و~all: «ما يحدث فعليًا للرسالة يعتمد على نظام البريد في الوجهة».

ما هي آليات SPF ومؤهِّلاته؟

تطابق الآليات عنوان IP المرسِل. وأكثرها شيوعًا ip4 وip6 وinclude وa وmx وall. ويمكن أن تحمل كل منها مؤهِّلًا: + للنجاح (الافتراضي)، و- للفشل، و~ للفشل المخفف (softfail)، و? للحياد. وتكتمل الصياغة بمعدِّلين (modifiers) هما redirect= وexp=.

تجد كل آلية، مع أمثلة جاهزة للنسخ وأكثر الأخطاء التي نصادفها، في صياغة سجل SPF وأمثلته.

ما هي حدود عمليات البحث في SPF؟

قد يؤدي SPF إلى استعلامات DNS كثيرة، لذا يضع RFC 7208 حدًا لها. يحدد القسم 4.6.4 ثلاثة حدود:

• 10 عناصر تستعلم DNS. تُحتسب الآليات include وa وmx وptr وexists والمعدِّل redirect، بما في ذلك ما يرد داخل السجلات التي تضمّنها. «يجب (MUST)» على التطبيقات «أن تقصر العدد الإجمالي لهذه العناصر على 10»، وتجاوزه «يجب (MUST) أن يُرجع 'permerror'».
• عمليتا بحث فارغتان (void lookups). عملية البحث التي لا تُرجع أي سجلات، أو النطاق غير الموجود، تُسمى «عملية بحث فارغة». «ينبغي (SHOULD)» على التطبيقات «أن تقصر عمليات البحث الفارغة على اثنتين»، وتجاوز الحد يؤدي إلى PermError. والسبب المعتاد هو include يشير إلى نطاق مزوّد توقف عن العمل.
• 10 سجلات عناوين لكل عنصر mx أو ptr. إذا تطلّب حلّ مضيفي آلية mx أكثر من 10 عمليات بحث A أو AAAA، فإنها تُرجع PermError.

لا تُحتسب ip4 وip6 وall. وتنبّه Microsoft إلى أن وجود أقل من 10 عبارات include «لا يضمن أقل من 10 عمليات بحث DNS»، لأن عبارات include قد تكون متداخلة (Microsoft Learn).

ولا تسلم المؤسسات الكبيرة من هذا الحد أيضًا. ففي فحصنا في أكتوبر 2026 لأعلى 1,000 نطاق في قائمة Tranco، نشر 22 نطاقًا سجل SPF يتجاوز حد العمليات العشر، ونشر 4 نطاقات أكثر من سجل SPF واحد. ويوضح دليلنا عن SPF PermError: عمليات بحث DNS كثيرة جدًا كيفية عدّ عمليات البحث وتقليلها.

ما الذي لا يفعله SPF؟

SPF مفيد لكن نطاقه ضيق. تعرّف على نقاط ضعفه قبل أن تعتمد عليه.

لا يفحص عنوان From

يصادق SPF نطاق MAIL FROM (وHELO اختياريًا). أما سطر From: الذي يقرؤه الناس في برنامج البريد فهو رأس مختلف ويمكن أن يحمل أي نطاق. يستطيع مرسل البريد العشوائي اجتياز SPF للنطاق attacker.example بينما يعرض نطاقك في From. والربط بين الاثنين هو مهمة DMARC.

يتعطل عند إعادة توجيه البريد

عند إعادة توجيه رسالة، تصل من عنوان IP الخاص بمُعيد التوجيه، وهو غير مدرج في سجلك. ينص القسم 7.4 من RFC 9989 على أن هذا البريد «سيفشل على الأرجح في فحوصات SPF» ما لم يُعِد مُعيد التوجيه كتابة عنوان MAIL FROM، بينما «تظل توقيعات DKIM صالحة عمومًا». ويصف الملحق D من RFC 7208 حلول إعادة الكتابة. ويتناول دليلنا عن سبب تعطيل إعادة التوجيه لـ SPF وDMARC آليتَي SRS وARC.

لا يشمل النطاقات الفرعية

يُفحص SPF للنطاق المطابق تمامًا في MAIL FROM. فالنطاق news.example.com يحتاج إلى سجل خاص به؛ ولا يرث سجل example.com. وتقول Microsoft إن كل نطاق فرعي يرسل البريد «يتطلب سجل SPF TXT خاصًا به».

لا يقول شيئًا عن المحتوى

قد تظل الرسالة القادمة من خادم مخوَّل بريدًا عشوائيًا أو رسالة تصيّد احتيالي. فـ SPF يثبت مصدر الرسالة فقط، لا ما إذا كانت مرغوبة.

كيف يعمل SPF مع DMARC؟

يستخدم RFC 9989، وهو معيار DMARC الحالي، SPF بوصفه أحد مُدخلَيه الاثنين. وهو صريح بشأن الهوية المعنية: «يعتمد DMARC فقط على تحقق SPF من هوية MAIL FROM». ولا تُحتسب نتائج HELO.

لا يفيد نجاح SPF في DMARC إلا عندما يتوافق (aligns) نطاق MAIL FROM مع نطاق From. ففي الوضع المرن الافتراضي، يتوافق bounce.example.com مع example.com؛ أما mailer-vendor.net فلا يتوافق. ويشرح RFC 9989 سبب الحاجة إلى التوافق: «يستطيع أي مالك نطاق، حتى الجهة الخبيثة، أن ينشر سجل SPF لنطاقه ويرسل بريدًا يحصل على نتيجة SPF 'pass'».

هذه هي المفاجأة الأكثر شيوعًا مع المرسلين الخارجيين. فكثير من أدوات النشرات البريدية وأنظمة CRM ومكاتب الدعم تستخدم افتراضيًا نطاق الارتداد الخاص بها. ينجح SPF، لكن لنطاقها هي، فلا يُحتسب ضمن نتيجة DMARC لديك. والحل هو مسار إرجاع مخصص (يُسمى غالبًا custom MAIL FROM أو نطاق الارتداد) على نطاق فرعي تابع لك، أو DKIM متوافق. ويستعرض دليلنا عن أسباب فشل DMARC هذه الحالات.

بالنسبة إلى DMARC، فإن fail وsoftfail وneutral وnone وpermerror كلها سواء: لا يوجد نجاح SPF متوافق. وعندها يجب أن يتكفل DKIM بالرسالة. راجع ما هو DMARC وكيف يعمل، وSPF مقابل DKIM مقابل DMARC لمعرفة ما يثبته كل سجل.

هل ينبغي أن ينتهي سجل SPF بـ ~all أم -all؟

كلاهما خيار له ما يبرره لنطاق يرسل البريد، والمصادر تختلف:

سبب الحذر مذكور في القسم 7.1 من RFC 9989: بعض المستقبِلين يفحصون SPF مبكرًا، لذا فإن فشل -all «قد يؤدي إلى رفض الرسالة في مرحلة مبكرة من معاملة SMTP، قبل أن تجري أي معالجة لـ DMARC»، حتى لو كان DKIM المتوافق سيجيزها.

الخيار الافتراضي المعقول: استخدم ~all ما دمت لا تزال تحصر جميع المرسلين لديك، وفكّر في -all بعد تفعيل DKIM على كل خدمة وخلوّ تقارير DMARC من المشكلات. أما النطاق الذي لا يرسل البريد أبدًا، فانشر له v=spf1 -all؛ إذ توصي Microsoft وM3AAWG كلتاهما بذلك للنطاقات المركونة (parked domains). لا تستخدم +all أبدًا، ولا تترك ?all في بيئة الإنتاج. تجد المقارنة الكاملة في SPF softfail مقابل hardfail.

كيف أنشئ سجل SPF؟

1. أدرج كل خدمة ترسل باسم نطاقك: منصة صناديق البريد، والموقع الإلكتروني والنماذج، ونظام CRM، ومكتب الدعم، وأدوات الفوترة والنشرات البريدية. تشترط إرشادات المرسلين من Google وجود SPF أو DKIM لدى كل من يرسل إلى Gmail.
2. احصل على القيمة الموثَّقة لدى كل مزوّد. تسرد صفحاتنا عن سجلات SPF حسب مزوّد البريد قيمة include الدقيقة للخدمات الشائعة، مثل Microsoft 365 وGoogle Workspace، مع كلفتها المقيسة من عمليات البحث.
3. انقل المرسلين بالجملة إلى نطاق فرعي متى أمكن. توصي Microsoft بذلك للخدمات التي لا تتحكم فيها مباشرة، ويحصل النطاق الفرعي على رصيد خاص به من 10 عمليات بحث.
4. أنشئ سجلًا واحدًا. تجمعه لك أداة SPF Record Generator (مولّد سجل SPF) من خدماتك وتعدّ عمليات البحث.
5. انشره أو عدّله لدى مزوّد DNS. استبدل السجل الحالي؛ ولا تضف أبدًا سجل v=spf1 ثانيًا.
6. افحصه باستخدام SPF Checker (أداة فحص SPF) للتحقق من الصياغة وعدد عمليات البحث ونهاية all.
7. اختبر بريدًا حقيقيًا. أرسل من كل خدمة إلى صندوق بريد خارجي وابحث عن spf=pass في الرؤوس، مستخدمًا Email Header Analyzer (محلّل رؤوس الرسائل).
8. أضف DKIM وDMARC. SPF وحده لا يحمي عنوان From.

أدلتنا عن SPF

الخطوات التالية

1. افحص نطاقك باستخدام SPF Checker لترى سجلك وعدد عمليات البحث فيه ونهاية all.
2. إذا كان هناك شيء ناقص أو معطوب، فأعد بناء السجل باستخدام SPF Record Generator واستبدل به السجل القديم.
3. انشر v=spf1 -all على كل نطاق تملكه ولا يرسل البريد.
4. اضبط DKIM على كل خدمة إرسال، ثم انشر DMARC؛ وابدأ بـ ما هو DMARC.
5. احصل على الصورة الكاملة دفعة واحدة باستخدام Email Health Check (فحص سلامة البريد). وإذا أردت أن تعرف عندما يغيّر أحدهم سجل SPF لديك، فإن مراقبة النطاق من iBlockSpam ترسل إليك تنبيهات التغيير.

تميل سجلات SPF إلى التعطل عندما يضيف أحدهم خدمة بعد أشهر. تفحص خدمة Free Domain Watch (المراقبة المجانية للنطاق) سجلات SPF وMX وDMARC وMTA-STS العامة لديك أسبوعيًا، وتنبّهك بالبريد الإلكتروني عندما يتغير أحدها؛ ولا تحتاج إلى حساب.

تصفّح أدلتنا الأخرى عن SPF وDKIM وDMARC.