إعداد سجل SPF: الأمثلة والحدود والأخطاء الشائعة

إذا كنت تعد بنية البريد في 2026، فافحص سجل SPF بعناية. قد تؤدي الأخطاء إلى الرسائل المزعجة أو الرفض بحسب المستقبل ونتائج المصادقة الأخرى. السجل الصحيح وحده لا يضمن الوصول إلى الوارد.

منذ فبراير 2024 شددت Google وYahoo متطلبات المصادقة لفئات معينة من المرسلين. قد يؤثر غياب SPF أو خطؤه، لكنه لا ينتج تلقائيا SMTP 550 لدى كل مستقبل. راجع نطاق القواعد والرد الكامل.

قد يمنع خلل في نطاق واحد عرض مؤسس من الوصول إلى المستثمر. ولمزود خدمات مدارة يدير 500 نطاق لعملائه، قد يبدأ صباح الاثنين بطلبات دعم عن تعذر مراسلة Gmail. يقلل الإعداد والمراقبة هذا الخطر دون ضمان منع كل مشكلة.

يشرح الدليل وظيفة SPF وبناء السجل وأخطاء قد تؤثر في قابلية التسليم، وكيفية إدارة الإعدادات على نطاق واسع بصورة منظمة.

ما يفعله SPF وما لا يفعله

Sender Policy Framework (SPF) بروتوكول تفويض قائم على DNS موصوف في RFC 7208. يحدد الأنظمة المسموح لها بالإرسال لهوية الظرف الجاري تقييمها. ليس درعا أمنيا عاما ولا يصادق بمفرده على عنوان المرسل الظاهر.

كيف يجري التقييم فعليا

عندما يستقبل Gmail رسالة من alice@yourcompany.com، لا يعتمد SPF على From الظاهر. الهوية المعنية هي مرسل الظرف MAIL FROM المستخدم للارتدادات، والذي يسجل عادة في Return-Path بعد التسليم. عند خلو مرسل الظرف قد تقيم هوية HELO. يجلب المستقبل سياسة النطاق ويفحص عنوان الإرسال.

قد ينتج عن تطابق آلية مناسبة pass. وللعناوين غير المسموحة قد ينتج softfail مع ~all أو fail مع -all، كما يمكن ظهور neutral أو أخطاء. النتيجة لا تفرض القبول أو الرفض تلقائيا.

الفرق بين رأس From وReturn-Path

وصف هذه النقطة بأنها خطأ 90% من المبتدئين ليس إحصاء موثقا. الأساس التقني أن SPF لا يتحقق من From المعروض في Outlook أو Apple Mail، بل من هوية الظرف المعنية.

المأزق: قد تستخدم Mailchimp نطاق ارتداد خاصا مثل bounce-mc.us1.mailchimp.com. عندها يقيم المستقبل سجل Mailchimp، لا سجلك. قد يكون سجلك صحيحا دون أن يستخدم لهذه الرسالة؛ تحقق من الإعداد الفعلي.

لهذا لا يكفي SPF وحده للمصادقة على النطاق الظاهر. يشرح دليل ترتيب إعداد SPF وDKIM وDMARC العلاقة بينها.

لماذا يظل SPF مهما

حتى مع DKIM وDMARC، يظل SPF مهما ضمن شروط المرسل المنطبقة. يجب التحقيق في رد مثل 550 5.7.515 Access Denied ضمن قواعد Microsoft المحددة، لا اعتباره نتيجة عامة لكل سجل SPF مفقود لدى كل مستقبل.

الإعداد الأساسي: مزود إرسال واحد

إذا استخدم نشاط صغير مزودا رئيسيا واحدا، مثل TrekMail أو Google Workspace أو Microsoft 365، وأداة تسويق واحدة ربما، فليكن الإعداد واضحا. ادمج التفويضات التي تنطبق فعلا على نطاق الظرف نفسه.

القاعدة الأساسية: سياسة SPF واحدة بالضبط لكل اسم DNS يجري تقييمه.

إضافة سجل SPF ثان بدلا من دمجه مع الموجود تسبب PermError عند التقييم. المشكلة في اختيار عدة سياسات SPF، لا في وجود عدة سجلات TXT غير مرتبطة. يقرر المستقبل التعامل مع النتيجة وفقا لسياسته.

مكونات سجل SPF

راجع دليل إعداد SPF للأمثلة التفصيلية. تحقق من قيم المزود الحالية والصياغة ومسارات الإرسال قبل نسخ أي قالب.

مقارنة TrekMail للنشاط الصغير

تستخدم المقارنة التوضيحية Google Workspace بسعر $6-$18 للمستخدم شهريا. لعشرة مستخدمين تكون الكلفة $720-$2,160 سنويا. وتصف Starter في TrekMail بمبلغ $3.50 شهريا وحتى 100 مستخدم. هذه أمثلة تاريخية؛ تحقق من الأسعار والشروط والخدمات الحالية. قد يناسب include:spf.trekmail.net مسارا مدعوما، لكنه لا يكمل تلقائيا كل إعداد DNS والمصادقة.

عدة مرسلين: منظور الوكالات

قد يدير مزود الخدمات المدارة أو الوكالة HubSpot للمبيعات وZendesk للدعم وKlaviyo للتسويق وTrekMail للبريد اليومي. لا تحتاج كل أداة تلقائيا إلى include في النطاق الرئيسي. حدد نطاق الظرف الذي تستخدمه كل خدمة فعليا.

ادمج التفويضات المنطبقة على النطاق نفسه في سياسة واحدة، مع مراعاة حد 10 عناصر DNS ذات الصلة.

إدارة حد 10 عناصر DNS

يحد RFC 7208 §4.6.4 الآليات والمعدلات ذات الصلة التي تستدعي DNS أثناء التقييم إلى 10، بما يشمل العناصر المتداخلة. ليس ذلك عدّا لجميع حزم DNS. يساعد الحد في منع إساءة استخدام البنية التحتية وقد يفاجئ أصحاب إعدادات شرعية أيضا.

عناصر تحتسب عند تقييمها: include:، a، mx، exists، redirect. تستخدم exists استعلام A، وتنقل redirect التقييم إذا لم تتطابق الآليات السابقة. تحتسب ptr غير الموصى بها أيضا.

آليات لا تستهلك هذا الحد: ip4:، ip6:، all

فخ include المتداخلة

تضيف include:bluehost.com فتبدو عنصرا 1. في مثال توضيحي، قد تشير السياسة إلى spf.protection.outlook.com وmail.bluehost.com، فتؤدي إضافة واحدة إلى تقييم ثلاثة عناصر. وقد يحتوي spf.protection.outlook.com سلسلة أخرى. لا يؤكد ذلك إعداد Bluehost الحالي؛ افحص القيم والمسار الفعلي.

إذا تجاوز المسار 10 عناصر ذات صلة، تعاد PermError. ليست نتيجة SPF fail نفسها، ولا تعني بالضرورة اختفاء البريد دون إشعار. افحص السجلات ورد SMTP ونتائج المصادقة الأخرى لتحديد الأثر.

حساب الاستهلاك

لا تخمن. استخدم أداة سطر أوامر أو أداة عرض موثوقة. على Mac وLinux ابدأ بـ:

dig +short txt yourdomain.com

افحص بعدها كل نطاق include: تكراريا، مع الآليات والمعدلات الأخرى ذات الصلة. استعلام TXT وحده ليس مقيما لـ SPF. يوضح دليل حدود البحث في SPF فحص المسارات ومعالجة التجاوزات.

تسطيح SPF أو الفصل بنطاقات فرعية

عند خطر تجاوز حد 10 عناصر، يمكنك النظر في خيارين. لا تتجاوزه كل وكالة حتما، والوصول إلى الحد ليس تجاوزا له.

الخيار 1: تسطيح SPF مع مخاطر الصيانة

يستبدل التسطيح سلاسل include: المختارة بعناوين حالية، مثل آليات ip4:. لا يستهلك ip4: حد عناصر DNS، لكن مئات العناوين قد تثير حدودا ومشكلات إدارة أخرى. راعِ عائلات العناوين ودلالة السياسة الأصلية.

المشكلة: قد تغير خدمات مثل HubSpot وKlaviyo عناوين الإرسال. قد تتقادم القائمة بعد بضعة أشهر مثلا، فتغفل عنوانا جديدا أو تستمر في تفويض عنوان أزيل. ليس لذلك موعد ثابت، لكنه يتطلب صيانة مستمرة.

اختر التسطيح فقط مع مراقبة موثوقة للمصدر وإدارة تغيير وتحقق وخطة استعادة. تساعد التحديثات الآلية لكنها لا تضمن صحة كل تغيير أو توقيته.

الخيار 2: الفصل بنطاقات فرعية

يمكن توزيع الإرسال على نطاقات ظرف بدلا من حشر كل خدمة في النطاق الرئيسي. يقيم SPF هوية MAIL FROM الفعلية، ويمكن تخصيص نطاق فرعي لها.

هل يحتاج التسويق إلى الإرسال الظاهر من team@company.com، أم يناسبه news@marketing.company.com؟ تغيير From الظاهر وحده لا يغير نطاق SPF.

النطاق الرئيسي (company.com): أبقِ التفويضات المعنية واضحة للبريد المؤسسي والحيوي. السجلات التالية أمثلة؛ تحقق من قيم المزود الحالية قبل النشر.

v=spf1 include:spf.trekmail.net -all

نطاق التسويق الفرعي (marketing.company.com): اضبط الخدمات لتستخدمه فعليا كنطاق ظرف.

v=spf1 include:servers.mcsv.net include:hubspot.com -all

لنطاق SPF المستقل المستخدم فعليا حد منفصل قدره 10 عناصر. تحقق أيضا من مطابقة DMARC المرنة أو الصارمة. لا تبقى مشكلة سمعة marketing.company.com معزولة بالضرورة؛ قد يجمع المستقبل إشارات النطاق التنظيمي وIP المشترك. الفصل يسهل الإدارة ولا يضمن حماية بريد المدير التنفيذي.

راجع قوالب إعداد SPF وإعداد عدة خدمات إرسال للأمثلة، ثم تحقق منها بحسب المزود الفعلي.

التحقق بعد النشر

الحفظ في محرر DNS ليس نهاية الإعداد. افحص النشر والصياغة والإرسال الحقيقي بالخطوات التالية.

1. فحص النشر وذاكرة DNS المؤقتة

قد تختلف رؤية التغيير لدقائق أو ساعات بسبب TTL والتخزين المؤقت. افحص الخوادم الموثوقة ومحللا عاما، لا الذاكرة المحلية فقط:

nslookup -type=txt yourdomain.com 8.8.8.8

يوجه 8.8.8.8 الاستعلام إلى محلل Google العام بدلا من محلل مزود الإنترنت. لدى Google ذاكرة مؤقتة أيضا. ظهور السجل هناك لا يثبت أن كل محلل أو مستقبل في العالم يرى القيمة الجديدة.

2. التحقق من الصياغة

افحص الصياغة وسلوك التقييم. من النقاط الشائعة:

• قد تمنع مسافة قبل v=spf1 التعرف على السجل
• ip4: 192.1.1.1: المسافة بعد النقطتين غير صحيحة
• تكرار all: تتطابق all دائما فلا يصل التقييم إلى الآليات اللاحقة
• قد تهدر عناصر include: المكررة الحد عند تقييمها؛ يعتمد الأثر على المسار والأخطاء

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

3. حد البحث بلا نتائج

يوصي RFC 7208 بتقييد void lookups إلى 2 من الاستعلامات بلا نتيجة، مثل NXDOMAIN أو الرد دون بيانات معنية. هذا حد منفصل وقد يكون قابلا للضبط في التطبيق.

قد ينتج عن include:spf.trekmaill.net، بحرف l إضافي، رد فارغ: أي 1 void lookup. لا تتجاوز نتيجتان فارغتان الحد الموصى به بعد؛ قد ينتج PermError عند تجاوزه. لكن include التي لا تملك سياسة SPF صالحة قد تسبب خطأ مستقلا في مرحلة أبكر.

افحص ردود DNS الحالية أيضا. لا يكشف مدقق الصياغة وحده كل خطأ في التقييم أو كل هدف فارغ.

4. تحليل رؤوس رسالة فعلية

أرسل إلى حساب Gmail تملكه واختر "عرض الرسالة الأصلية" من قائمة النقاط الثلاث. ابحث عن Authentication-Results، وثق فقط بالنتائج التي أضافها النظام المستقبل، لا برؤوس أرفقها المرسل عشوائيا. المثال التالي توضيحي:

spf=pass (google.com: domain of user@yourdomain.com designates 192.0.2.1 as permitted sender)

تستدعي spf=neutral أو spf=softfail فحص السياسة ونطاق الظرف وعنوان الإرسال، لكنها لا تثبت دائما خطأ الإعداد. افحص DKIM ومطابقة DMARC أيضا. راجع فحص حالة DNS للتحقق الإضافي.

الأخطاء الشائعة

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

1. SPF عند إعادة التوجيه

يقيم SPF عنوان الإرسال لهوية ظرف، ولهذا قد تواجه إعادة التوجيه التقليدية مشكلة.

ترسل Alice إلى Bob الذي يعيد التوجيه إلى Charlie. إذا بقي مرسل الظرف الأصلي، يرى Charlie عنوان خادم Bob أثناء تقييم سياسة النطاق الأصلي. قد يفشل الفحص رغم شرعية الرسالة، بحسب الإعداد الفعلي.

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

يوضح دليل إعادة توجيه بريد النطاق وقابلية التسليم هذه الفروق؛ لا يضمن أي منها الوصول إلى الوارد.

2. آلية ptr

في أوائل سنوات 2000 كانت ptr المعتمدة على DNS العكسي أكثر شيوعا:

v=spf1 ptr -all

ينصح RFC بعدم استخدام ptr لأسباب الموثوقية وحمل DNS، لكنه لم يلغها من الصياغة. لا تفترض أن Gmail يعاقب كل سجل يتضمنها أو يتجاهله. استبدل تفويضات ptr القديمة بعد الحصر والاختبار، وميّز ذلك عن أهمية سجلات PTR لخوادم البريد.

3. خطر +all

هذا مثال غير آمن، ولا ينبغي نشر قيم مزوده دون تحقق:

v=spf1 include:spf.google.com +all

تعني محددات النتيجة:

• -all = fail للعناوين التي لم تتطابق سابقا، لا أمر رفض تلقائي
• ~all = softfail للعناوين غير المتطابقة سابقا، لا ضمان قبول أو تعليم
• +all = pass لـ كل عنوان يصل إلى هذه الآلية

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

4. Return-Path لدى خدمات الإرسال الخارجية

قد تستخدم خدمة تسويق Return-Path خاصا بها دون إعداد ارتداد مخصص، فيقيم SPF نطاقها لا نطاقك. نطاق التتبع ليس نطاق الظرف أو الارتداد نفسه. قد ينجح DMARC بتوقيع DKIM صحيح ومتوافق رغم غياب مطابقة SPF؛ وتتبع مطابقة SPF المقارنة المرنة أو الصارمة.

افحص دعم ESP لنطاق Return-Path مخصص مثل bounce.yourcompany.com واضبط DNS المطلوب. راجع مطابقة DMARC وسمعة النطاق.

أدوات الإنشاء ومواطن الحذر

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

الأدوات المفيدة

تعرض أدوات التصور سلسلة include: المتداخلة. تحقق من احتسابها بقية العناصر والمسارات ذات الصلة. تتوفر الميزة في بعض أدوات قابلية تسليم البريد.

قد تكتشف مدققات الصياغة النقطتين المفقودتين والرموز غير الصحيحة. تتطلب النتائج الفارغة تقييم DNS أيضا؛ تحقق من نطاق الأداة بعد كل تعديل.

ما يحتاج حذرا إضافيا

لا تستخدم كل المعالجات بنقرة واحدة السياسة الافتراضية نفسها. تعطي ?all neutral للعناوين التي لم تتطابق سابقا. اختر السياسة بعد حصر المرسلين؛ تختلف نتائج -all و~all لكن أيا منهما لا يضمن التسليم.

أدوات تقسيم السلاسل: حد كل سلسلة في DNS TXT هو 255 أوكتتا، وليس دائما عدد محارف Unicode نفسه. يمكن تقسيم SPF الطويل إلى سلاسل ضمن سجل واحد، لا إلى سجلَي SPF منفصلين:

• البنية الصحيحة: "v=spf1 include:a..." "include:b... -all" (سلسلتان وسجل واحد؛ مثال تخطيطي يحتاج إضافة المسافة المناسبة عند الحد في السجل الفعلي)
• خطأ: سجلا SPF TXT منفصلان يسببان PermError عند الاختيار

تجمع السلاسل دون إدخال مسافة تلقائيا. تحقق من القيمة النهائية والمسافات والصياغة قبل النشر، ثم أكدها في DNS. لا تقسّم كل أداة السلاسل بشكل صحيح.

راجع دليل أدوات إنشاء SPF وإعداده للمزيد عن تقييم الأدوات.

توحيد الإعدادات في TrekMail

ليست الحزم الكبيرة منتجات سيئة بالضرورة. تجمع وظائف وتفرض غالبا سعرا لكل مستخدم. قيّم فائدة تلك الوظائف لعملائك بحسب احتياجاتهم والعقود الحالية.

قد يناسب السجل التوضيحي التالي نطاقا يستخدم مسار TrekMail المدار المعني. تحقق من القيم الحالية والخدمات الإضافية:

v=spf1 include:spf.trekmail.net -all

ليس هذا السطر إعدادا كاملا لكل نطاق تلقائيا، خصوصا مع SMTP خاص أو خدمات إضافية. تعتمد إدارة IP وrDNS وحلقات الملاحظات على المسار والخدمة الفعليين. حتى مع SMTP المدار تبقى الموافقة والجمهور والزيادة المناسبة في الحجم ومعالجة الشكاوى ضرورية؛ التفويض لا يضمن التسليم.

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

عند النقل، يساعد عرض ترحيل IMAP ودليل سجلات DNS المطلوبة في تخطيط بيانات الصناديق وMX وSPF وDKIM وDMARC واختبارها بشكل منفصل. لا ينقل IMAP إعداد DNS أو التطبيقات، وMX يتعلق أساسا بتوجيه الوارد. خطط التحويل بعد فحوص المصادقة والمزامنة، وراجع ميزات اللوحة الحالية في استيراد النطاقات جماعيا.

منهج سليم لإدارة SPF

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

الخلاصة العملية:

1. افحص السياسات. نفذ dig +short txt yourdomain.com وعد سجلات SPF المختارة فقط، لا جميع TXT. وجود أكثر من سياسة واحدة للاسم نفسه يسبب PermError.
2. ادمج التفويضات المعنية. استخدم سجل SPF TXT واحدا للخدمات التي ترسل فعليا بنطاق الظرف نفسه.
3. قيّم حد DNS. إذا تجاوز المسار 10 عناصر، افحص التبسيط أو نطاقات ظرف فرعية فعلية. يتطلب التسطيح صيانة موثوقة.
4. اختر -all بوعي. راجع الانتقال من ~all بعد الحصر والاختبار. عالج +all بأولوية مع تغيير آمن؛ يظل القرار للمستقبل.
5. افحص مطابقة Return-Path. راجع نطاق ارتداد مخصصا تدعمه Mailchimp أو HubSpot، وتحقق أيضا من DKIM صحيح ومتوافق لـ DMARC.
6. لا تتوقف عند SPF. قد يفشل مع التوجيه وقد يبطل DKIM إذا تغير المحتوى. اضبط الثلاثة: SPF وDKIM وDMARC، واختبر المسارات الفعلية.

حجم 50 بايت مثال لسجل SPF، وليس حجما ثابتا. يساعد الإعداد الجيد في تقليل مخاطر العلاقات مع العملاء. افحص عند كل تغيير للإرسال وبانتظام؛ قد لا يكفي فحص سنوي وحده.

نظم إدارة DNS. راجع عرض TrekMail المجاني والأسعار والشروط الحالية ونطاق دعم SPF وDKIM وDMARC.