مصادقة SPF: لمحة عامة وأفضل الممارسات
طائر
19/12/2016
البريد الإلكتروني
1 min read
النقاط الرئيسية
إطار سياسة المرسل (SPF) هو بروتوكول مصادقة البريد الإلكتروني المعتمد على المسار الذي يتحقق مما إذا كان الخادم المرسل مخولًا لإرسال البريد لنطاق معين.
تعيش سياسات SPF كـ سجلات DNS TXT، منسقة بآليات تحدد أي الخوادم، أو العناوين IP، أو الشبكات مُصرح لها بالإرسال نيابة عن نطاق معين.
ترتبط مصادقة SPF بـ نطاق Return-Path (نطاق الارتداد) أو اسم المضيف HELO - وليس عنوان From المرئي.
نظرًا لأن SPF يتحقق من مسار الإرسال فقط، يمكن التحقق منه في وقت مبكر من معاملة SMTP، مما يجعله مفيدًا لرفض البريد غير المصرح به بسرعة.
SPF فعال ولكنه غير مثالي - فهو عرضة لـ إيجابيات زائفة، خاصة مع إعادة توجيه البريد والقوائم البريدية.
تستند سجلات SPF إلى آليات مثل
mx،a،ipv4،ipv6،include،redirect،exists، ويجب أن تنتهي بمعدلall(-all،~all،?all،+all).تنطبق حدود البحث في DNS: لا يمكن أن يتجاوز تقييم SPF 10 استفسارات DNS، مما يجعل تخطيط السجلات أمرًا مهمًا.
يعتبر آلية
ptrالآن "لا تستخدم"، لكن يجب على المدققين قبوله. لا يزال بعض المرسلين يستخدمونه بسبب فجوات التوافق.SPF بمفرده لا يضمن أن البريد الإلكتروني شرعي - فقط أنه تم إرساله من خادم مُخَوَّل. يعمل بشكل أفضل عند الجمع بينه وبين DKIM، DMARC، وغيرها من تقنيات مكافحة الاحتيال.
أهم النقاط في الأسئلة والأجوبة
ما هو SPF بلغة بسيطة؟
يسمح SPF للنطاق بإعلان أي خوادم مُصرح لها بإرسال البريد الإلكتروني نيابة عنه. تتحقق الخوادم المستقبِلة من ذلك للكشف عن المرسلين غير المصرح لهم.
لماذا يُطلق على SPF اسم "معتمد على المسار"؟
لأن SPF يتحقق من المسار الذي اتخذه الرسالة - تحديدًا، عنوان IP للخادم المرسل - بدلاً من أي شيء في محتوى الرسالة.
أين يتم تخزين سياسة SPF؟
أ: كـ سجل نصي DNS، يبدأ بـ
v=spf1، يليه آليات تحدد المرسلين المسموح بهم.أي نطاق يتحقق منه SPF؟
مسار العودة (يسمى أيضًا مجال الارتداد).
إذا كان مسار العودة فارغًا (مرسل NULL)، فستتحقق SPF من مجال HELO بدلاً من ذلك.
هل يمكن التحقق من SPF مبكرًا في معاملة SMTP؟
نعم. لأنه يعتمد فقط على عنوان IP الخاص بالخادم المرسل ونطاقه، يمكن التحقق من SPF قبل استلام محتوى الرسالة - مما يجعله فعالاً في التصفية.
لماذا يفشل SPF أحيانًا حتى مع البريد الإلكتروني الشرعي؟
تشمل الأسباب الشائعة ما يلي:
إعادة توجيه البريد الإلكتروني (لم يكن المرسل في سجل SPF الخاص بالنطاق الأصلي)
القوائم البريدية (يتم إعادة إرسال الرسائل بواسطة خادم مختلف)
يؤدي هذا إلى سلبية خاطئة، وهي أمر متأصل في المصادقة المستندة إلى المسار.
ما هو دور الآليات مثل الإدراج، وإعادة التوجيه، والوجود؟
include— تفويض سجل SPF الخاص بمجال آخر (على سبيل المثال، موفر خدمة البريد الإلكتروني الخاص بك)redirect— إعادة استخدام سياسة SPF الخاصة بمجال آخرexists— تفويض ديناميكي بناءً على بحث DNS (مفيد للبنية التحتية المعقدة)
كيف تعمل جميع المحددات؟
-all→ رفض أي شيء غير مدرج (صارم)~all→ فشل ناعم (قبول ولكن مع علامة)?all→ محايد+all→ قبول كل شيء (يوقف SPF بفاعلية)
لماذا يتم تثبيط استخدام آلية ptr؟
إنه بطيء وغير موثوق، وقد تم استبعاده في المواصفات الحديثة — ولكن يجب على مُحقق SPF دعمه حتى الآن.
هل SPF كافٍ بمفرده للمصادقة على البريد الإلكتروني؟
لا. يتحقق SPF من بنية الإرسال، ولكن:
لا يضمن سلامة الرسالة
لا يتوافق مع نطاقات From الظاهرة
يتعطل مع إعادة التوجيه
SPF هو الأقوى عندما يقترن بـ DKIM و DMARC.
قبل الخوض في التنفيذ الفني، من المفيد فهم تطور وتنوع تقنيات التحقق من البريد الإلكتروني المتاحة. من التحقق البسيط من الصياغة إلى الأساليب الحديثة المعتمدة على البيانات، توفر طرق التحقق المختلفة مستويات متفاوتة من الدقة والموثوقية.
عندما نتحدث عن “مصادقة البريد الإلكتروني”، فإننا نشير إلى تقنية تهدف إلى توفير مستوى من اليقين لمتلقي الرسالة بأن الرسالة قد صدرت فعلاً من المصدر المزعوم للرسالة. الفكرة هي تحقيق مستوى من الدفاع ضد البريد الإلكتروني الاحتيالي، مثل التصيد والاحتيال، الذي قد يقوض ثقة المتلقي في استقبال البريد الإلكتروني. بالنسبة للمنظمات التي تتطلب تشفيرًا على مستوى الرسالة يتجاوز المصادقة، توفر S/MIME أمانًا شاملاً، مع جمع مفتاح المستلم العام بشكل آلي مما يجعل التنفيذ أكثر قابلية للتوسع. ومع ذلك، فإن فعل إرسال البريد الإلكتروني المعتمد لا يعني بذاته أن البريد جيد أو مرغوب فيه؛ إنه يعني فقط أن البريد هو بذلك الشكل الذي يمكن أن يُؤسس فيه سمعة للطرف المعتمد ويمكن استخدامها في قرارات قبول البريد الإلكتروني وتوزيعه.
هناك شكلان رئيسيان من مصادقة البريد الإلكتروني قيد الاستخدام اليوم—إطار عمل سياسة المرسِل (SPF) وبريد مؤهل من خلال مفاتيح النطاق (DKIM). في هذا المنشور، سأشرح ما هو SPF، وكيف يعمل.
قبل الخوض في التنفيذ الفني، من المفيد فهم تطور وتنوع تقنيات التحقق من البريد الإلكتروني المتاحة. من التحقق البسيط من الصياغة إلى الأساليب الحديثة المعتمدة على البيانات، توفر طرق التحقق المختلفة مستويات متفاوتة من الدقة والموثوقية.
عندما نتحدث عن “مصادقة البريد الإلكتروني”، فإننا نشير إلى تقنية تهدف إلى توفير مستوى من اليقين لمتلقي الرسالة بأن الرسالة قد صدرت فعلاً من المصدر المزعوم للرسالة. الفكرة هي تحقيق مستوى من الدفاع ضد البريد الإلكتروني الاحتيالي، مثل التصيد والاحتيال، الذي قد يقوض ثقة المتلقي في استقبال البريد الإلكتروني. بالنسبة للمنظمات التي تتطلب تشفيرًا على مستوى الرسالة يتجاوز المصادقة، توفر S/MIME أمانًا شاملاً، مع جمع مفتاح المستلم العام بشكل آلي مما يجعل التنفيذ أكثر قابلية للتوسع. ومع ذلك، فإن فعل إرسال البريد الإلكتروني المعتمد لا يعني بذاته أن البريد جيد أو مرغوب فيه؛ إنه يعني فقط أن البريد هو بذلك الشكل الذي يمكن أن يُؤسس فيه سمعة للطرف المعتمد ويمكن استخدامها في قرارات قبول البريد الإلكتروني وتوزيعه.
هناك شكلان رئيسيان من مصادقة البريد الإلكتروني قيد الاستخدام اليوم—إطار عمل سياسة المرسِل (SPF) وبريد مؤهل من خلال مفاتيح النطاق (DKIM). في هذا المنشور، سأشرح ما هو SPF، وكيف يعمل.
قبل الخوض في التنفيذ الفني، من المفيد فهم تطور وتنوع تقنيات التحقق من البريد الإلكتروني المتاحة. من التحقق البسيط من الصياغة إلى الأساليب الحديثة المعتمدة على البيانات، توفر طرق التحقق المختلفة مستويات متفاوتة من الدقة والموثوقية.
عندما نتحدث عن “مصادقة البريد الإلكتروني”، فإننا نشير إلى تقنية تهدف إلى توفير مستوى من اليقين لمتلقي الرسالة بأن الرسالة قد صدرت فعلاً من المصدر المزعوم للرسالة. الفكرة هي تحقيق مستوى من الدفاع ضد البريد الإلكتروني الاحتيالي، مثل التصيد والاحتيال، الذي قد يقوض ثقة المتلقي في استقبال البريد الإلكتروني. بالنسبة للمنظمات التي تتطلب تشفيرًا على مستوى الرسالة يتجاوز المصادقة، توفر S/MIME أمانًا شاملاً، مع جمع مفتاح المستلم العام بشكل آلي مما يجعل التنفيذ أكثر قابلية للتوسع. ومع ذلك، فإن فعل إرسال البريد الإلكتروني المعتمد لا يعني بذاته أن البريد جيد أو مرغوب فيه؛ إنه يعني فقط أن البريد هو بذلك الشكل الذي يمكن أن يُؤسس فيه سمعة للطرف المعتمد ويمكن استخدامها في قرارات قبول البريد الإلكتروني وتوزيعه.
هناك شكلان رئيسيان من مصادقة البريد الإلكتروني قيد الاستخدام اليوم—إطار عمل سياسة المرسِل (SPF) وبريد مؤهل من خلال مفاتيح النطاق (DKIM). في هذا المنشور، سأشرح ما هو SPF، وكيف يعمل.
حماية الشمس ليست مضمونة بشكل كامل
بينما يبدو أنه طريق سهل نسبيًا للتحقق من صحة البريد الإلكتروني، فإن SPF vulnerable للفشل في شكل سلبية زائفة. يمكن أن تحدث هذه الإخفاقات بشكل أكثر تكرارًا مما يشعر به الكثيرون بالراحة.
هنا حالتان شائعتان حيث يمكن أن يفشل البريد الشرعي تمامًا في تحقق SPF ويظهر بذلك ك fraudulent:
إعادة التوجيه التلقائي، حيث يتم إرسال رسالة إلى jsmith@alumni.university.edu، صندوق بريد تم تعيينه لإعادة توجيه جميع البريد تلقائيًا إلى jsmith@isp.com
قوائم البريد، حيث يتم إرسال البريد إلى talk-about-stuff@listserv.foo.com ويتم
بينما يبدو أنه طريق سهل نسبيًا للتحقق من صحة البريد الإلكتروني، فإن SPF vulnerable للفشل في شكل سلبية زائفة. يمكن أن تحدث هذه الإخفاقات بشكل أكثر تكرارًا مما يشعر به الكثيرون بالراحة.
هنا حالتان شائعتان حيث يمكن أن يفشل البريد الشرعي تمامًا في تحقق SPF ويظهر بذلك ك fraudulent:
إعادة التوجيه التلقائي، حيث يتم إرسال رسالة إلى jsmith@alumni.university.edu، صندوق بريد تم تعيينه لإعادة توجيه جميع البريد تلقائيًا إلى jsmith@isp.com
قوائم البريد، حيث يتم إرسال البريد إلى talk-about-stuff@listserv.foo.com ويتم
بينما يبدو أنه طريق سهل نسبيًا للتحقق من صحة البريد الإلكتروني، فإن SPF vulnerable للفشل في شكل سلبية زائفة. يمكن أن تحدث هذه الإخفاقات بشكل أكثر تكرارًا مما يشعر به الكثيرون بالراحة.
هنا حالتان شائعتان حيث يمكن أن يفشل البريد الشرعي تمامًا في تحقق SPF ويظهر بذلك ك fraudulent:
إعادة التوجيه التلقائي، حيث يتم إرسال رسالة إلى jsmith@alumni.university.edu، صندوق بريد تم تعيينه لإعادة توجيه جميع البريد تلقائيًا إلى jsmith@isp.com
قوائم البريد، حيث يتم إرسال البريد إلى talk-about-stuff@listserv.foo.com ويتم
نظرة عامة على SPF
إطار سياسة المرسل (SPF)، لتلخيص RFC 7208، هو بروتوكول لا يتيح فقط للمنظمة تفويض المضيفين والشبكات لاستخدام أسماء نطاقها عند إرسال البريد الإلكتروني، ولكن يوفر أيضًا طريقة للتحقق من هذا التفويض من قبل المضيف المستلم.
عند الانتهاء من قراءة هذه التدوينة، آمل أن تكون قد تعلمت ما يلي:
SPF هو نظام مصادقة "مستند إلى المسار".
يتم الإعلان عن سياسات SPF في سجلات DNS TXT.
يتم التحقق من الصحة مرجحًا إلى مجال Return-Path (ما نسميه هنا في SparkPost "نطاق الارتداد") أو مجال HELO.
يمكن إجراء التحقق من الصحة مبكرًا في معاملة SMTP، لذا فهي فحص جيد لاستخدامه لرفض البريد غير المصدق بسرعة.
إنه عرضة لنسبة عالية نسبيًا من السلبيات الكاذبة.
إطار سياسة المرسل (SPF)، لتلخيص RFC 7208، هو بروتوكول لا يتيح فقط للمنظمة تفويض المضيفين والشبكات لاستخدام أسماء نطاقها عند إرسال البريد الإلكتروني، ولكن يوفر أيضًا طريقة للتحقق من هذا التفويض من قبل المضيف المستلم.
عند الانتهاء من قراءة هذه التدوينة، آمل أن تكون قد تعلمت ما يلي:
SPF هو نظام مصادقة "مستند إلى المسار".
يتم الإعلان عن سياسات SPF في سجلات DNS TXT.
يتم التحقق من الصحة مرجحًا إلى مجال Return-Path (ما نسميه هنا في SparkPost "نطاق الارتداد") أو مجال HELO.
يمكن إجراء التحقق من الصحة مبكرًا في معاملة SMTP، لذا فهي فحص جيد لاستخدامه لرفض البريد غير المصدق بسرعة.
إنه عرضة لنسبة عالية نسبيًا من السلبيات الكاذبة.
إطار سياسة المرسل (SPF)، لتلخيص RFC 7208، هو بروتوكول لا يتيح فقط للمنظمة تفويض المضيفين والشبكات لاستخدام أسماء نطاقها عند إرسال البريد الإلكتروني، ولكن يوفر أيضًا طريقة للتحقق من هذا التفويض من قبل المضيف المستلم.
عند الانتهاء من قراءة هذه التدوينة، آمل أن تكون قد تعلمت ما يلي:
SPF هو نظام مصادقة "مستند إلى المسار".
يتم الإعلان عن سياسات SPF في سجلات DNS TXT.
يتم التحقق من الصحة مرجحًا إلى مجال Return-Path (ما نسميه هنا في SparkPost "نطاق الارتداد") أو مجال HELO.
يمكن إجراء التحقق من الصحة مبكرًا في معاملة SMTP، لذا فهي فحص جيد لاستخدامه لرفض البريد غير المصدق بسرعة.
إنه عرضة لنسبة عالية نسبيًا من السلبيات الكاذبة.
مصادقة قائمة على المسار
يعتبر SPF نظام مصادقة قائم على المسار لأنه مرتبط فقط بالطريق الذي سلكته الرسالة للوصول من أصلها إلى وجهتها. عندما يبدأ خادم الإرسال عملية SMTP مع خادم الاستلام، سيحدد خادم الاستلام ما إذا كان خادم الإرسال مصرحًا له بإرسال تلك الرسالة بناءً على سياسة SPF للنطاق. إنه قرار يعتمد فقط على مصدر الرسالة، دون أي علاقة بمحتوى الرسالة.
يعتبر SPF نظام مصادقة قائم على المسار لأنه مرتبط فقط بالطريق الذي سلكته الرسالة للوصول من أصلها إلى وجهتها. عندما يبدأ خادم الإرسال عملية SMTP مع خادم الاستلام، سيحدد خادم الاستلام ما إذا كان خادم الإرسال مصرحًا له بإرسال تلك الرسالة بناءً على سياسة SPF للنطاق. إنه قرار يعتمد فقط على مصدر الرسالة، دون أي علاقة بمحتوى الرسالة.
يعتبر SPF نظام مصادقة قائم على المسار لأنه مرتبط فقط بالطريق الذي سلكته الرسالة للوصول من أصلها إلى وجهتها. عندما يبدأ خادم الإرسال عملية SMTP مع خادم الاستلام، سيحدد خادم الاستلام ما إذا كان خادم الإرسال مصرحًا له بإرسال تلك الرسالة بناءً على سياسة SPF للنطاق. إنه قرار يعتمد فقط على مصدر الرسالة، دون أي علاقة بمحتوى الرسالة.
إعلان سياسة SPF
سجل سياسة SPF لنطاق معين هو مجرد سجل TXT DNS مصمم بشكل خاص، وعادة ما يحتوي على واحد أو أكثر من "الآليات" التالية:
v=spf1 – الرمز الأول المطلوب للإشارة إلى أن سجل TXT هو سجل SPF (يمكن أن يحتوي النطاق على سجلات TXT متعددة)
ipv4، ipv6 – يستخدم لتحديد عناوين IP والشبكات المسموح لها بإرسال البريد للنطاق
a – إذا كان لدى النطاق المرسل سجل DNS "A" يحل إلى عنوان IP المرسل، يُسمح بالـ IP
mx – إذا كان عنوان IP المرسل هو أيضًا واحد من سجلات MX للنطاق المرسل، يُسمح بالـ IP
all – الرمز الأخير المطلوب، دائماً ما يُعدل:
-all – فقط ما هو مدرج هنا يمكنه المرور؛ رفض الفشلات.
~all – الأمور التي ليست هنا يجب أن تفشل برفق؛ قبولها ولكن تسجيلها.
?all – غير متأكد ما إذا كانت الأمور التي ليست هنا يجب أن تمر.
+all – نعتقد أن SPF عديم الفائدة؛ سمح لكل شيء.
آليات أقل شيوعًا لا تزال مستخدمة على نطاق واسع هي:
include – يستخدم عندما لا يمتلك النطاق خوادمه الخاصة فقط، بل يستخدم أيضًا خوادم شخص آخر. يجب استخدامه بحذر. كل إدراج هو استعلام DNS آخر، ولا يمكن لسجلات SPF أن تتطلب أكثر من عشرة استعلامات DNS لحلها.
redirect – عندما يكون النطاق A والنطاق B مملوكين من نفس الجهة ويستخدمان نفس البنية التحتية. عادةً ما يرغب المالكون في الحفاظ على نسخة واحدة فقط من سجل SPF لكليهما، وتكوين B لإعادة توجيه الاستفسارات إلى A.
exists – إذا كان لدى نطاق الكثير من الكتل الشبكية الصغيرة وغير المتصلة، يمكنه استخدام هذه الآلية لتحديد سجله SPF، بدلاً من إدراجها جميعًا. مفيد للبقاء ضمن حد الحجم (512 بايت) لاستجابة DNS.
ملاحظة حول آلية “ptr”
آلية نهائية، "ptr" كانت موجودة في المواصفة الأصلية لـ SPF، ولكن تم الإعلان عنها "لا تستخدم" في المواصفة الحالية. تم استخدام آلية ptr للإعلان أنه إذا كان عنوان IP المرسل لديه سجل DNS PTR يحل إلى اسم النطاق المعني، فإن عنوان IP هذا كان مصرحًا له بإرسال البريد للنطاق.
الحالة الحالية لهذه الآلية هي أنها يجب ألا تُستخدم. ومع ذلك، فإن المواقع التي تجري التحقق من SPF يجب أن تقبلها كصالحة.
الآلية | ما الذي تفعله | ملاحظات / إرشادات استخدام |
|---|---|---|
v=spf1 | يعلن أن سجل TXT هو سياسة SPF | الرمز الأول المطلوب |
ipv4 / ipv6 | تفويض عناوين IP أو كتل CIDR محددة | أكثر طرق التفويض صراحة وموثوقية |
a | يسمح بعناوين IP المطابقة لسجل A الخاص بالنطاق | جيد للبنية التحتية البسيطة |
mx | يسمح بعناوين IP المدرجة في سجلات MX الخاصة بالنطاق | مفيد عندما ترسل خوادم MX البريد أيضًا |
include | استيراد سياسة SPF لنطاق آخر | يحسب ضمن حد 10 استعلام DNS؛ استخدمه بحذر |
redirect | تفويض سياسة SPF لنطاق آخر | يستخدم عندما تشارك عدة نطاقات تعريف SPF واحد |
exists | تفويض عبر قاعدة استعلام DNS مخصصة | مفيد لمدى IP الكبيرة والمجزأة؛ يجب أن يدعم المدقق ذلك |
ptr | تصريح بناءً على تخطيط DNS العكسي | ملغاة ("لا تستخدم") ولكن يجب أن يتم احترامها من قبل المدققين |
all | يحدد كيفية التعامل مع كل شيء غير المسموح به صراحة | الأنواع: -all الرفض، ~all الفشل برفق، ?all محايد، +all السماح للجميع (غير موصى به) |
سجل سياسة SPF لنطاق معين هو مجرد سجل TXT DNS مصمم بشكل خاص، وعادة ما يحتوي على واحد أو أكثر من "الآليات" التالية:
v=spf1 – الرمز الأول المطلوب للإشارة إلى أن سجل TXT هو سجل SPF (يمكن أن يحتوي النطاق على سجلات TXT متعددة)
ipv4، ipv6 – يستخدم لتحديد عناوين IP والشبكات المسموح لها بإرسال البريد للنطاق
a – إذا كان لدى النطاق المرسل سجل DNS "A" يحل إلى عنوان IP المرسل، يُسمح بالـ IP
mx – إذا كان عنوان IP المرسل هو أيضًا واحد من سجلات MX للنطاق المرسل، يُسمح بالـ IP
all – الرمز الأخير المطلوب، دائماً ما يُعدل:
-all – فقط ما هو مدرج هنا يمكنه المرور؛ رفض الفشلات.
~all – الأمور التي ليست هنا يجب أن تفشل برفق؛ قبولها ولكن تسجيلها.
?all – غير متأكد ما إذا كانت الأمور التي ليست هنا يجب أن تمر.
+all – نعتقد أن SPF عديم الفائدة؛ سمح لكل شيء.
آليات أقل شيوعًا لا تزال مستخدمة على نطاق واسع هي:
include – يستخدم عندما لا يمتلك النطاق خوادمه الخاصة فقط، بل يستخدم أيضًا خوادم شخص آخر. يجب استخدامه بحذر. كل إدراج هو استعلام DNS آخر، ولا يمكن لسجلات SPF أن تتطلب أكثر من عشرة استعلامات DNS لحلها.
redirect – عندما يكون النطاق A والنطاق B مملوكين من نفس الجهة ويستخدمان نفس البنية التحتية. عادةً ما يرغب المالكون في الحفاظ على نسخة واحدة فقط من سجل SPF لكليهما، وتكوين B لإعادة توجيه الاستفسارات إلى A.
exists – إذا كان لدى نطاق الكثير من الكتل الشبكية الصغيرة وغير المتصلة، يمكنه استخدام هذه الآلية لتحديد سجله SPF، بدلاً من إدراجها جميعًا. مفيد للبقاء ضمن حد الحجم (512 بايت) لاستجابة DNS.
ملاحظة حول آلية “ptr”
آلية نهائية، "ptr" كانت موجودة في المواصفة الأصلية لـ SPF، ولكن تم الإعلان عنها "لا تستخدم" في المواصفة الحالية. تم استخدام آلية ptr للإعلان أنه إذا كان عنوان IP المرسل لديه سجل DNS PTR يحل إلى اسم النطاق المعني، فإن عنوان IP هذا كان مصرحًا له بإرسال البريد للنطاق.
الحالة الحالية لهذه الآلية هي أنها يجب ألا تُستخدم. ومع ذلك، فإن المواقع التي تجري التحقق من SPF يجب أن تقبلها كصالحة.
الآلية | ما الذي تفعله | ملاحظات / إرشادات استخدام |
|---|---|---|
v=spf1 | يعلن أن سجل TXT هو سياسة SPF | الرمز الأول المطلوب |
ipv4 / ipv6 | تفويض عناوين IP أو كتل CIDR محددة | أكثر طرق التفويض صراحة وموثوقية |
a | يسمح بعناوين IP المطابقة لسجل A الخاص بالنطاق | جيد للبنية التحتية البسيطة |
mx | يسمح بعناوين IP المدرجة في سجلات MX الخاصة بالنطاق | مفيد عندما ترسل خوادم MX البريد أيضًا |
include | استيراد سياسة SPF لنطاق آخر | يحسب ضمن حد 10 استعلام DNS؛ استخدمه بحذر |
redirect | تفويض سياسة SPF لنطاق آخر | يستخدم عندما تشارك عدة نطاقات تعريف SPF واحد |
exists | تفويض عبر قاعدة استعلام DNS مخصصة | مفيد لمدى IP الكبيرة والمجزأة؛ يجب أن يدعم المدقق ذلك |
ptr | تصريح بناءً على تخطيط DNS العكسي | ملغاة ("لا تستخدم") ولكن يجب أن يتم احترامها من قبل المدققين |
all | يحدد كيفية التعامل مع كل شيء غير المسموح به صراحة | الأنواع: -all الرفض، ~all الفشل برفق، ?all محايد، +all السماح للجميع (غير موصى به) |
سجل سياسة SPF لنطاق معين هو مجرد سجل TXT DNS مصمم بشكل خاص، وعادة ما يحتوي على واحد أو أكثر من "الآليات" التالية:
v=spf1 – الرمز الأول المطلوب للإشارة إلى أن سجل TXT هو سجل SPF (يمكن أن يحتوي النطاق على سجلات TXT متعددة)
ipv4، ipv6 – يستخدم لتحديد عناوين IP والشبكات المسموح لها بإرسال البريد للنطاق
a – إذا كان لدى النطاق المرسل سجل DNS "A" يحل إلى عنوان IP المرسل، يُسمح بالـ IP
mx – إذا كان عنوان IP المرسل هو أيضًا واحد من سجلات MX للنطاق المرسل، يُسمح بالـ IP
all – الرمز الأخير المطلوب، دائماً ما يُعدل:
-all – فقط ما هو مدرج هنا يمكنه المرور؛ رفض الفشلات.
~all – الأمور التي ليست هنا يجب أن تفشل برفق؛ قبولها ولكن تسجيلها.
?all – غير متأكد ما إذا كانت الأمور التي ليست هنا يجب أن تمر.
+all – نعتقد أن SPF عديم الفائدة؛ سمح لكل شيء.
آليات أقل شيوعًا لا تزال مستخدمة على نطاق واسع هي:
include – يستخدم عندما لا يمتلك النطاق خوادمه الخاصة فقط، بل يستخدم أيضًا خوادم شخص آخر. يجب استخدامه بحذر. كل إدراج هو استعلام DNS آخر، ولا يمكن لسجلات SPF أن تتطلب أكثر من عشرة استعلامات DNS لحلها.
redirect – عندما يكون النطاق A والنطاق B مملوكين من نفس الجهة ويستخدمان نفس البنية التحتية. عادةً ما يرغب المالكون في الحفاظ على نسخة واحدة فقط من سجل SPF لكليهما، وتكوين B لإعادة توجيه الاستفسارات إلى A.
exists – إذا كان لدى نطاق الكثير من الكتل الشبكية الصغيرة وغير المتصلة، يمكنه استخدام هذه الآلية لتحديد سجله SPF، بدلاً من إدراجها جميعًا. مفيد للبقاء ضمن حد الحجم (512 بايت) لاستجابة DNS.
ملاحظة حول آلية “ptr”
آلية نهائية، "ptr" كانت موجودة في المواصفة الأصلية لـ SPF، ولكن تم الإعلان عنها "لا تستخدم" في المواصفة الحالية. تم استخدام آلية ptr للإعلان أنه إذا كان عنوان IP المرسل لديه سجل DNS PTR يحل إلى اسم النطاق المعني، فإن عنوان IP هذا كان مصرحًا له بإرسال البريد للنطاق.
الحالة الحالية لهذه الآلية هي أنها يجب ألا تُستخدم. ومع ذلك، فإن المواقع التي تجري التحقق من SPF يجب أن تقبلها كصالحة.
الآلية | ما الذي تفعله | ملاحظات / إرشادات استخدام |
|---|---|---|
v=spf1 | يعلن أن سجل TXT هو سياسة SPF | الرمز الأول المطلوب |
ipv4 / ipv6 | تفويض عناوين IP أو كتل CIDR محددة | أكثر طرق التفويض صراحة وموثوقية |
a | يسمح بعناوين IP المطابقة لسجل A الخاص بالنطاق | جيد للبنية التحتية البسيطة |
mx | يسمح بعناوين IP المدرجة في سجلات MX الخاصة بالنطاق | مفيد عندما ترسل خوادم MX البريد أيضًا |
include | استيراد سياسة SPF لنطاق آخر | يحسب ضمن حد 10 استعلام DNS؛ استخدمه بحذر |
redirect | تفويض سياسة SPF لنطاق آخر | يستخدم عندما تشارك عدة نطاقات تعريف SPF واحد |
exists | تفويض عبر قاعدة استعلام DNS مخصصة | مفيد لمدى IP الكبيرة والمجزأة؛ يجب أن يدعم المدقق ذلك |
ptr | تصريح بناءً على تخطيط DNS العكسي | ملغاة ("لا تستخدم") ولكن يجب أن يتم احترامها من قبل المدققين |
all | يحدد كيفية التعامل مع كل شيء غير المسموح به صراحة | الأنواع: -all الرفض، ~all الفشل برفق، ?all محايد، +all السماح للجميع (غير موصى به) |
بعض سجلات SPF مثال
إليك بعض سجلات المثال ومعانيها. يُظهر هذا المثال عناوين RFC 1918، لكنني أدرك أن مثل هذه العناوين لن تظهر أبدًا في سجلات SPF الفعلية.
سجل MX، عنوان IP واحد، شبكة IP واحدة، فشل ناعم في كل شيء آخر:
“v=spf1 mx ipv4:10.0.0.1 ipv4:192.168.24.0/24 ~all”
سجل A، شبكتان IP، رفض كل شيء آخر:
“v=spf1 a ipv4:10.0.3.0/23 ipv4:192.168.55.0/26 -all”
نحن لا نرسل أي بريد:
“v=spf1 -all”
نحن نعتقد أن SPF غبي:
“v=spf1 +all”
سجل SPF للنطاق sparkpostmail.com (آلية إعادة التوجيه المستخدمة)
“v=spf1 redirect=_spf.sparkpostmail.com”
سجل SPF لـ _spf.sparkpostmail.com (يوجد وآليات ptr مستخدمة):
“v=spf1 exists:%{i}._spf.sparkpostmail.com ptr:sparkpostmail.com ptr:spmta.com ptr:flyingenvelope.com ~all”
في SparkPost، نحن نستخدم حاليًا آلية ptr في سجل SPF الخاص بنا. لقد وجدنا أنه من الضروري بسبب عدم وجود دعم عالمي للتحقق من آلية exists. وحتى الآن، لم نر أي فشل في SPF نتيجة لاستخدامنا لآلية ptr.
إليك بعض سجلات المثال ومعانيها. يُظهر هذا المثال عناوين RFC 1918، لكنني أدرك أن مثل هذه العناوين لن تظهر أبدًا في سجلات SPF الفعلية.
سجل MX، عنوان IP واحد، شبكة IP واحدة، فشل ناعم في كل شيء آخر:
“v=spf1 mx ipv4:10.0.0.1 ipv4:192.168.24.0/24 ~all”
سجل A، شبكتان IP، رفض كل شيء آخر:
“v=spf1 a ipv4:10.0.3.0/23 ipv4:192.168.55.0/26 -all”
نحن لا نرسل أي بريد:
“v=spf1 -all”
نحن نعتقد أن SPF غبي:
“v=spf1 +all”
سجل SPF للنطاق sparkpostmail.com (آلية إعادة التوجيه المستخدمة)
“v=spf1 redirect=_spf.sparkpostmail.com”
سجل SPF لـ _spf.sparkpostmail.com (يوجد وآليات ptr مستخدمة):
“v=spf1 exists:%{i}._spf.sparkpostmail.com ptr:sparkpostmail.com ptr:spmta.com ptr:flyingenvelope.com ~all”
في SparkPost، نحن نستخدم حاليًا آلية ptr في سجل SPF الخاص بنا. لقد وجدنا أنه من الضروري بسبب عدم وجود دعم عالمي للتحقق من آلية exists. وحتى الآن، لم نر أي فشل في SPF نتيجة لاستخدامنا لآلية ptr.
إليك بعض سجلات المثال ومعانيها. يُظهر هذا المثال عناوين RFC 1918، لكنني أدرك أن مثل هذه العناوين لن تظهر أبدًا في سجلات SPF الفعلية.
سجل MX، عنوان IP واحد، شبكة IP واحدة، فشل ناعم في كل شيء آخر:
“v=spf1 mx ipv4:10.0.0.1 ipv4:192.168.24.0/24 ~all”
سجل A، شبكتان IP، رفض كل شيء آخر:
“v=spf1 a ipv4:10.0.3.0/23 ipv4:192.168.55.0/26 -all”
نحن لا نرسل أي بريد:
“v=spf1 -all”
نحن نعتقد أن SPF غبي:
“v=spf1 +all”
سجل SPF للنطاق sparkpostmail.com (آلية إعادة التوجيه المستخدمة)
“v=spf1 redirect=_spf.sparkpostmail.com”
سجل SPF لـ _spf.sparkpostmail.com (يوجد وآليات ptr مستخدمة):
“v=spf1 exists:%{i}._spf.sparkpostmail.com ptr:sparkpostmail.com ptr:spmta.com ptr:flyingenvelope.com ~all”
في SparkPost، نحن نستخدم حاليًا آلية ptr في سجل SPF الخاص بنا. لقد وجدنا أنه من الضروري بسبب عدم وجود دعم عالمي للتحقق من آلية exists. وحتى الآن، لم نر أي فشل في SPF نتيجة لاستخدامنا لآلية ptr.
كيف تعمل مصادقة SPF؟
إليكم ما يبدو عليه معاملة SMTP النموذجية عندما يكون SPF مشمولاً:
سيرفر الإرسال (العميل) يتصل بسيرفر الاستقبال
سيرفر الاستقبال يسجل عنوان IP الخاص بالعميل المتصل
يتبادلون التحيات، بما في ذلك اسم مضيف HELO الخاص بالعميل
العميل يصدر أمر SMTP MAIL FROM
يمكن الآن لسيرفر الاستقبال البحث في سجل SPF إما لنطاق MAIL FROM أو اسم مضيف HELO لتحديد ما إذا كان عنوان IP المتصل مخولًا بإرسال البريد للنطاق، واتخاذ القرار بشأن قبول الرسالة أم لا.
إليكم ما يبدو عليه معاملة SMTP النموذجية عندما يكون SPF مشمولاً:
سيرفر الإرسال (العميل) يتصل بسيرفر الاستقبال
سيرفر الاستقبال يسجل عنوان IP الخاص بالعميل المتصل
يتبادلون التحيات، بما في ذلك اسم مضيف HELO الخاص بالعميل
العميل يصدر أمر SMTP MAIL FROM
يمكن الآن لسيرفر الاستقبال البحث في سجل SPF إما لنطاق MAIL FROM أو اسم مضيف HELO لتحديد ما إذا كان عنوان IP المتصل مخولًا بإرسال البريد للنطاق، واتخاذ القرار بشأن قبول الرسالة أم لا.
إليكم ما يبدو عليه معاملة SMTP النموذجية عندما يكون SPF مشمولاً:
سيرفر الإرسال (العميل) يتصل بسيرفر الاستقبال
سيرفر الاستقبال يسجل عنوان IP الخاص بالعميل المتصل
يتبادلون التحيات، بما في ذلك اسم مضيف HELO الخاص بالعميل
العميل يصدر أمر SMTP MAIL FROM
يمكن الآن لسيرفر الاستقبال البحث في سجل SPF إما لنطاق MAIL FROM أو اسم مضيف HELO لتحديد ما إذا كان عنوان IP المتصل مخولًا بإرسال البريد للنطاق، واتخاذ القرار بشأن قبول الرسالة أم لا.
البريد من أو مرحبًا – أيهما يجب التحقق منه؟
تحدد مواصفة SPF أن المواقع المستقبلة يجب أن تتحقق من SPF لمجال MAIL FROM، وتوصي بالتحقق منه لاسم مضيف HELO. في الممارسة العملية، يحدث التحقق فقط على مجال MAIL FROM، باستثناء ربما تلك الأوقات التي يكون فيها عنوان MAIL FROM هو المرسل NULL (أي، “<>”)، وفي هذه الحالة يكون اسم مضيف HELO هو الهوية الوحيدة المتاحة.
تحدد مواصفة SPF أن المواقع المستقبلة يجب أن تتحقق من SPF لمجال MAIL FROM، وتوصي بالتحقق منه لاسم مضيف HELO. في الممارسة العملية، يحدث التحقق فقط على مجال MAIL FROM، باستثناء ربما تلك الأوقات التي يكون فيها عنوان MAIL FROM هو المرسل NULL (أي، “<>”)، وفي هذه الحالة يكون اسم مضيف HELO هو الهوية الوحيدة المتاحة.
تحدد مواصفة SPF أن المواقع المستقبلة يجب أن تتحقق من SPF لمجال MAIL FROM، وتوصي بالتحقق منه لاسم مضيف HELO. في الممارسة العملية، يحدث التحقق فقط على مجال MAIL FROM، باستثناء ربما تلك الأوقات التي يكون فيها عنوان MAIL FROM هو المرسل NULL (أي، “<>”)، وفي هذه الحالة يكون اسم مضيف HELO هو الهوية الوحيدة المتاحة.
