عثرت على مولد سجل SPF مجاني، وحددت كل الخيارات - Google Workspace وMailchimp ونظام CRM - ثم لصقت الناتج مباشرة في DNS. بعد أسبوعين، ترفض Gmail فواتيرك بالرمز 550 5.7.26، وتعيد Outlook الرمز 550 5.7.515. وتمتلئ قائمة طلبات الدعم.
أعطاك مولد سجل SPF ناتجا صحيح البنية، لكنه لم يعطك بالضرورة سجلا عاملا. عند هذه الفجوة تتضرر قابلية التسليم. إذا كنت لا تزال تبني إعداد DNS الكامل، فابدأ بدليل إعداد البريد على نطاقك؛ إذ يمثل SPF جزءا من منظومة أوسع تشمل MX وDKIM وDMARC.
يشرح هذا الدليل أسباب فشل المولدات الآلية في بيئة الإنتاج، وكيفية تدقيق ناتجها في خمس دقائق بأدوات متاحة لديك، والشكل الفعلي لسجل SPF الجاهز للإنتاج.
ما الذي يفعله مولد سجل SPF فعليا
مولد سجل SPF أداة ويب تنشئ سجل TXT في DNS بجمع آليات include: الخاصة بالمزودين وفقا للخيارات التي تحددها. تختار المرسلين فتحصل على نص. لكنه لا يستعلم من DNS الفعلي، ولا يحسب عمليات البحث المتداخلة، ولا يعرف عدد سجلات SPF الموجودة أصلا على نطاقك.
معظم مولدات SPF المجانية ليست أكثر من أدوات متقدمة لجمع النصوص؛ تنتج شيئا يبدو صحيحا من دون التحقق من عمله في بيئة DNS الحقيقية. صحة البنية لا تعني الصحة التشغيلية.
أنماط الفشل الـ3 التي يفوتها كل مولد SPF
ترجع معظم أعطال SPF المهمة في الإنتاج إلى واحدة من ثلاث مشكلات. ولا يرى مولد SPF المعتاد أيا منها لأنه يعمل من دون بيانات DNS الفعلية أو منطق حساب عمليات البحث الذي تستخدمه الخوادم المستلمة أثناء التقييم.
1. خطأ PermError بسبب سجل مزدوج
يجب أن يملك النطاق سجل SPF واحدا بالضبط. ينص RFC 7208 بوضوح على أن عثور الخادم المستلم على سجلي TXT يبدآن بـ v=spf1 يعيد PermError، أي فشل دائم. قد تعامل Gmail وYahoo هذا الخطأ معاملة غياب SPF. عندها ترتد الرسائل أو تنقل بصمت إلى البريد المزعج.
لا تتحقق المولدات من وجود سجل سابق. إذا كان نطاقك نشطا منذ أكثر من بضعة أشهر، فمن المرجح وجود سجل أنشأه المسجل أو المضيف السابق أو من أعد Google Workspace قبل ثلاث سنوات. نشر ناتج المولد من دون فحص ينشئ سجلا مكررا ويعطل إعدادا كان يعمل.
2. حد عمليات البحث المتداخلة
يقصر RFC 7208 تقييم SPF على 10 عمليات بحث DNS بالضبط. ويشمل العدد كل include: وa وmx وexists وredirect، إلى جانب كل عملية متداخلة تطلقها include. يحسب مولد SPF الآليات التي تختارها، لكنه لا يحسب ما بداخلها.
| المزود المحدد | عدد المولد | عمليات البحث الفعلية |
|---|---|---|
| Google Workspace | 1 | 4 (تتضمن _netblocks.google.com المتداخلة وغيرها) |
| Zendesk | 1 | 2-3 |
| Mailchimp | 1 | 2 |
| Salesforce | 1 | 2-3 |
| الإجمالي | 4 | 10-12 → PermError |
يعرض المولد 4 عمليات بحث، لكن الخادم المستلم يصل إلى #11 ويتوقف. تفشل رسائل نطاقك كلها في SPF. لا يظهر تحذير في الواجهة، وقد لا تصلك رسالة ارتداد. وربما لا تعرف بالمشكلة حتى يشكو العملاء.
3. حد عمليات البحث الفارغة (RFC 7208 §11.1)
هناك قيد ثانوي: لا يجوز أن تعيد أكثر من 2 من استعلامات DNS نتيجة فارغة (NXDOMAIN). يسبب خطأ مطبعي واحد في include: عملية بحث فارغة. ومع خطأين من هذا النوع يفشل سجل SPF كله، حتى لو اجتاز فحص البنية في المولد.
مثال:
include:spf.trekmaill.net(حرف 'l' زائد). البنية صحيحة ويضع مولد SPF علامة الصحة. يجري الخادم المستلم البحث ولا يجد شيئا - عملية البحث الفارغة #1. وعند وجود include ثانية معطوبة يفشل السجل بالكامل.
كيفية تدقيق ناتج مولد SPF قبل النشر
قبل نشر أي ناتج من مولد SPF، أجر هذه الفحوص الثلاثة على DNS الفعلي. تستغرق خمس دقائق وتكشف المشكلات الحرجة التي فاتها المولد: السجلات المكررة، والعمق الزائد لعمليات البحث، والبنية المعطوبة. وتعمل على macOS وLinux وموجه أوامر Windows.
الخطوة 1: تحقق من وجود سجل
نفذ هذا الأمر قبل إجراء أي تغيير في DNS:
nslookup -type=txt yourdomain.comإذا رأيت سطرين يبدآن بـ v=spf1، فلديك سجل مكرر. ادمجهما يدويا في سجل واحد قبل نشر أي شيء جديد.
# Broken - two records, PermError guaranteed:
"v=spf1 include:_spf.google.com -all"
"v=spf1 include:spf.trekmail.net -all"
# Fixed - merged into one:
v=spf1 include:_spf.google.com include:spf.trekmail.net -allالخطوة 2: احسب عمليات البحث المتداخلة
استعلم عن محتوى كل include: في سجلك:
dig +short txt _spf.google.comالناتج:
"v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"تطلق include:_spf.google.com الواحدة 4 عمليات بحث فعلية. كرر ذلك لكل مزود في سجلك واجمع النتائج. إذا تجاوز الإجمالي 10، فعليك إعادة الهيكلة، وعادة يكون ذلك بنقل بريد المعاملات إلى نطاق فرعي (send.yourdomain.com) له سجل أقصر مستقل.
الخطوة 3: دقق الآليات
قارن النص الذي أنشأه مولد SPF بالجدول التالي:
| الآلية | الحالة | الإجراء |
|---|---|---|
ptr | مهملة | احذفها - ينصح RFC 7208 صراحة بعدم استخدامها، فهي بطيئة وغير موثوقة. |
+all | غير آمنة | احذفها - تسمح للإنترنت كله بالإرسال باسم نطاقك. |
ip4: 1.2.3.4 | بنية غير صالحة | احذف المسافة. يجب أن تكون ip4:1.2.3.4. |
?all | ضعيفة | تجنبها - فالسياسة المحايدة لا توفر حماية من الانتحال. |
~all | مقبولة | SoftFail - استخدمها خلال الترحيل فقط، لا كإعداد دائم. |
-all | صحيحة | HardFail - ترفض المرسلين غير المصرح لهم. استخدمها في الإنتاج. |
قائمة تدقيق بنية SPF
سواء استخدمت مولد SPF للمسودة الأولى أو كتبت النص يدويا، راجع هذه القائمة قبل لمس DNS. تغطي الفحوص كل خطأ لا يستطيع المولد اكتشافه، من السجلات المكررة وحدود البحث المتداخل إلى محددات السياسة غير الآمنة.
- سجل واحد لكل نطاق. ادمج السجلات عند وجود تكرار. لا تنشر سجلين.
- يبدأ بـ
v=spf1. لا تستخدم أي صيغة مختلفة. النص دقيق. - ينتهي بـ
-allأو~all. لا تستخدم+allأو?all. - عناوين IP قبل include. لا تكلف آليات
ip4:وip6:أي عمليات بحث DNS - ضعها أولا لتسريع التقييم. - لا توجد إحالة ذاتية. تنشئ
include:yourdomain.comحلقة لا نهائية. احذفها. - لا تسطح عناوين IP يدويا إلا إذا حافظت أتمتة على تحديثها. إذا غيرت Google العناوين ولم تحدث السجل، فقد يتعطل بريدك بصمت.
- إجمالي عمليات البحث ≤ 10. احسب كل شيء، بما فيه include المتداخلة.
سجل جاهز للإنتاج:
v=spf1 ip4:192.0.2.1 include:spf.trekmail.net include:_spf.google.com -allعناوين IP أولا (لا تكلفة بحث)، ثم include، ثم hard fail في النهاية. هذا كل المطلوب.
لماذا تتجاوز الوكالات والشركات الصغيرة مولدات SPF
يناسب مولد SPF نطاقا واحدا بمرسل أو اثنين. لكن عند التوسع - وكالة تدير عشرات العملاء أو شركة تستخدم مجموعة SaaS كاملة - يتحول إلى خطر تشغيلي متكرر بلا رؤية مركزية لعدد عمليات البحث أو السجلات المكررة في المحفظة.
الطريقة القديمة: سجل SPF فريد لكل عميل، ناتج من جلسة مولد مختلفة، ومن دون سجل تدقيق. يبلغ نطاق ما حد البحث. تمر ثلاثة أيام قبل أن يلاحظ أحد. وتتضرر سمعة التسليم لدى العميل.
لرؤية متكاملة لحماية بنية البريد على مستوى الشركة، راجع دليل تأمين البريد التجاري، فهو يغطي الأساس الكامل الذي يتجاوز SPF وحده.
كيف يزيل TrekMail مشكلة مولد SPF
ينشأ تعقيد SPF من إدارة عدة مرسلين خارجيين والبقاء تحت سقف 10 عمليات بحث. يقلل TrekMail المشكلتين في بنية بريدك الأساسية، بحيث لا تحتاج إلى تشغيل مولد SPF أو حساب العمليات المتداخلة أو تدقيق آليات نطاق الإرسال الرئيسي.
للشركات الصغيرة: Include واحدة بلا صيانة
في خطة Starter من TrekMail ($3.50/شهر)، يمر التسليم الصادر عبر SMTP المدار من TrekMail. يصبح سجل SPF سطرا واحدا:
v=spf1 include:spf.trekmail.net -allيدير TrekMail تدوير IP وسمعة المرسل خلف include. لا تحتاج عادة إلى تغيير السجل مجددا من أجل TrekMail. لا جلسة مولد مطلوبة، ولا تدقيق عمليات بحث بعد ستة أشهر عند إضافة أداة SaaS جديدة.
للوكالات: قالب واحد لكل عميل
الطريقة القديمة: 100 عميل و100 سجل SPF من 100 تشغيل مختلف للمولد، لكل منها خطره في البحث المتداخل. وقد يفشل أي واحد دون تنبيه مباشر.
طريقة TrekMail: قالب واحد عبر كل نطاقات العملاء:
v=spf1 include:spf.trekmail.net -allفي خطة Agency ($23.25/شهر)، تدير 1,000+ نطاق من لوحة واحدة. توحيد بريد الشركة على TrekMail يزيل مشكلة البحث المتداخل من قناة الاتصال الأساسية. إذا كنت توسع إعدادا متعدد النطاقات، فاقرأ كيف تغير استضافة البريد متعدد النطاقات صورة الإدارة.
لإعداد DNS الكامل الذي يتوقعه TrekMail مع SPF - MX وDKIM وDMARC - توضح وثيقة سجلات DNS المطلوبة الأربعة في مكان واحد.
الأسئلة الشائعة عن مولد سجل SPF
تظهر هذه الأسئلة بعد أن تنتج جلسة مولد SPF الأولى سجلا لا يعمل. وترجع كلها إلى الفجوة بين التحقق البنيوي الذي يجريه المولد والتحقق التشغيلي الذي يتطلب فحص DNS الفعلي.
هل يمكنني استخدام مولدين لمقارنة الناتج؟
يمكنك ذلك، لكن تشغيل مولد ثان لا يحل المشكلة الأساسية. قد تمنحك أداتان نصين مختلفين، ولا تكتشف أي منهما السجلات المكررة في DNS الفعلي أو تحسب البحث المتداخل دائما بدقة. خطوات CLI أعلاه هي الفحص الأكثر موثوقية.
يقول المولد إن السجل صالح. لماذا يرتد البريد؟
تعني كلمة "صالح" لدى مولد SPF أن البنية صحيحة، لا أن السجل يعمل في بيئتك. السببان الأكثر شيوعا لهذه الفجوة هما سجل مكرر يطلق PermError، أو عدد عمليات بحث متداخلة يزيد على 10. يتطلب كلاهما فحص DNS الفعلي لا مجرد تحقق في الواجهة.
متى أستخدم -all بدلا من ~all؟
استخدم -all (HardFail) في الإنتاج لرفض المرسلين غير المصرح لهم مباشرة. استخدم ~all (SoftFail) فقط أثناء الترحيل عندما لا تكون متأكدا من إدراج كل مرسل. إنها حالة مؤقتة وليست غاية. مولد SPF الذي يختار ?all أو +all افتراضيا يهتم بمظهر العمل أكثر من قابلية التسليم الفعلية.
الخلاصة
مولد SPF المجاني نقطة بداية معقولة لصياغة النص، لكنه نهاية سيئة للاستخدام في الإنتاج. أنماط الفشل الثلاثة التي يفوتها - السجلات المكررة، وتجاوز البحث المتداخل، وأخطاء البحث الفارغ - تسبب ارتدادات صامتة وأخطاء PermError قد يستغرق تشخيصها ساعات.
الحل ليس مولد SPF أفضل، بل تدقيق CLI في خمس دقائق: افحص السجلات المكررة، واحسب البحث المتداخل، وراجع الآليات، ثم انشر.
إذا فضلت تجاوز عملية التوليد تماما، يجمع TrekMail الإرسال الصادر في include: واحدة. سطر واحد في DNS، بلا حساب للبحث أو تشخيص PermError.
ابدأ تجربة مجانية لمدة 14 يوما - تتطلب بطاقة ائتمان ويمكن الإلغاء في أي وقت.
