يعمل إعداد SPF جيدا مع مرسل واحد. ثم تضيف Google Workspace وMailchimp وZendesk وواجهة تشغيلية، فيبدأ Microsoft بإرجاع البريد مع 550 5.7.515. لقد تجاوز السجل حد 10 استعلامات، وقد تفشل مصادقة الرسائل الصادرة من دون تنبيه واضح.
هذا هو الفخ. يضع البروتوكول سقفا صارما قد تبلغه الفرق عند إضافة خدمة الإرسال الثالثة أو الرابعة. ولا يعود حل إضافة include: أخرى صالحا. ابدأ بدليل سجل SPF للبريد لفهم الصياغة. أما هنا فنشرح بنية تتحمل عدة مرسلين وتغييرات المزودين وتقلل إعادة الكتابة المتكررة.
لماذا يتعطل SPF مع عدة مرسلين
يحدد RFC 7208 تقييم SPF عند 10 استعلامات DNS للسجل. وتحتسب آليات include وa وmx وexists وredirect بصورة تكرارية. إذا احتوى سجل المزود على ثلاث آليات أخرى، دخلت كلها في الميزانية. عند 11 يظهر PermError وقد ترفض الرسالة.
يبدأ السجل بآليتي include. يضيف التسويق HubSpot، والدعم Freshdesk، والهندسة SendGrid. تكون السلاسل أعمق من المتوقع، فتصل إلى 12 استعلاما وقد يعيد Google 550 5.7.26.
| الآلية | تستهلك استعلاما؟ | ملاحظة للمشغل |
|---|---|---|
include: | نعم، مع المتداخل | شائعة للمزودين لكن سلسلتها قد تتغير |
ip4: / ip6: | لا | مناسبة لمرسل ثابت تتحكم فيه |
mx | نعم | تستخدم أكثر من اللازم؛ استبدلها بـ ip4 حين يمكن |
a | نعم | غير فعالة في SPF؛ يفضل ip4 |
ptr | نعم | مهملة؛ لا تستخدمها |
redirect | نعم | تنقل التقييم إلى سجل نطاق آخر |
-all / ~all | لا | تنهي السياسة؛ أدرج واحدة دائما |
الحساب بسيط لكنه غير مرئي حتى يقع الخلل. لذلك يبدأ إعداد عدة مرسلين بالهندسة لا بالنسخ واللصق.
راجع سجل SPF قبل أن تضيف شيئا
احذف أولا ما لم يعد مستخدما. تحتفظ نطاقات كثيرة بآليات include لخدمات ألغيت منذ زمن، وكلها تهدر الميزانية. نظف ثم ابن.
افحص المنشور فعليا:
dig txt yourdomain.com +shortثم تتبع عمق كل include:
dig txt _spf.google.com +short
dig txt spf.protection.outlook.com +shortقارن بتقارير DMARC المجمعة. إذا لم تر حركة من عناوين مزود، فتأكد من توقف الخدمة قبل إزالة السجل.
ثلاثة تحسينات سريعة:
- استبدل
mxبعنوان IP الثابت عبرip4:إذا كنت تتحكم فيه، لتوفر استعلاما. - احذف آليات include للخدمات غير المستخدمة.
- ابحث عن سجلات SPF مكررة. وجود سجلي TXT يبدآن بـ
v=spf1على النطاق نفسه يسبب PermError.
قد يوفر هذا وحده 2-3 استعلامات. راجع دليل إعداد سجل SPF.
تقسيم النطاقات الفرعية: بنية SPF قابلة للتوسع
التقسيم إلى نطاقات فرعية طريقة موثوقة لإدارة عدة مرسلين ضمن حد 10. يقيم SPF نطاق Return-Path لا ترويسة From الظاهرة. انقل كل مسار غير مؤسسي إلى نطاق فرعي ليحصل على ميزانية مستقلة من 10 استعلامات.
إليك النمط:
النطاق الجذر: بريد الأشخاص فقط
أبق الجذر بسيطا ولا تضع فيه سوى مزود الصناديق الأساسي.
v=spf1 include:spf.trekmail.net -allآلية include واحدة واستعلام واحد، فلا تعدل أداة تسويق سجل بريد الإدارة نفسه.
نطاق التسويق الفرعي: الحملات والنشرات
; news.example.com
v=spf1 include:spf.hubspot.com include:servers.mcsv.net -allيستهلك HubSpot وMailchimp ميزانية news.example.com لا الجذر. ولا يلزم أن يوقف تقييده البريد المؤسسي مباشرة، مع بقاء إشارات السمعة الأوسع مؤثرة.
نطاق الدعم الفرعي: أنظمة التذاكر
; help.example.com
v=spf1 include:mail.zendesk.com -allالنطاق التشغيلي الفرعي: التنبيهات والإيصالات
; alerts.example.com
v=spf1 include:amazonses.com -allحين يرسل Zendesk باسم support@help.example.com، يفحص المستلم help.example.com ولا يستخدم سجل SPF للجذر. هذه هي الفكرة.
| الطريقة القديمة | الطريقة الجديدة |
|---|---|
| كل المرسلين في سجل جذر واحد | الجذر لمزود الصناديق الأساسي فقط |
| تغيير مزود قد يؤثر في كل البريد | المشكلة معزولة غالبا في النطاق الفرعي |
| ميزانية واحدة للجميع | لكل نطاق فرعي 10 استعلامات |
| إعادة كتابة SPF مع كل أداة | البنية تتحمل التغييرات بصورة أفضل |
تسطيح SPF: الحل الأخير
إذا وجب إرسال كل البريد من النطاق المجرد وتعذر استخدام النطاقات الفرعية، فقد يساعد التسطيح. يحول آليات المزودين إلى عناوين IP ضمن ip4: لا تستهلك استعلامات، لكنه يحتاج إلى صيانة.
يغير مزودو SaaS عناوينهم. إذا أضاف SendGrid نطاق IP غدا وبقي السجل على عناوين الأمس، فقد يفشل SPF. لا تسطح يدويا بلا متابعة متكررة. وعند الحاجة استخدم خدمة SPF ديناميكية موثوقة تراقب التغييرات وتحدث TXT بضوابط مناسبة.
التسطيح حل التفافي لا تصميما مثاليا. استخدم التقسيم متى أمكن.
تحقق من عمل إعداد SPF
بعد أي تغيير، افحص ما يعيده DNS العام مباشرة. لا تعتمد فقط على لوحات المسجل أو إشارات المزود الخضراء. يجب وجود سجل SPF صالح واحد لكل اسم مضيف.
# Check the root record
dig txt example.com +short
# Check a subdomain
dig txt news.example.com +short
# Verify DMARC while you're at it
dig txt _dmarc.example.com +shortتريد سجل TXT واحدا يبدأ بـ v=spf1 لكل مضيف، لا سجلين ولا سجلا قديما من ترحيل سابق.
أرسل رسالة اختبار إلى Gmail، وافتح قائمة النقاط الثلاث واختر "عرض النسخة الأصلية"، ثم ابحث عن:
SPF: PASS with IP [your sending IP]
DKIM: PASS
DMARC: PASSتتطلب FAIL أو SOFTFAIL تحقيقا قبل الإرسال بكميات كبيرة. وللمشكلات خارج SPF، يشرح دليل سمعة مرسل البريد الصورة الأوسع.
كيف يبسط TrekMail إعداد SPF عبر النطاقات
يتطلب نطاق واحد عملا، أما 50 نطاقا للعملاء مع مزودين وDNS مختلفين فتستهلك وقتا كبيرا. يبقي TrekMail أثره في SPF صغيرا ويمكن توقعه.
الآلية الأساسية هي include:spf.trekmail.net. في الإعداد الحالي تستهلك استعلاما واحدا بلا redirect متداخل. وقد يستهلك Microsoft 365 مقدار 2-3 عبر إحالاته، بينما قد يتغير Google Workspace. تحقق دائما من DNS.
يبقى إعداد المؤسس بسيطا بعد إضافة التسويق، وتقل أخطاء إدخال الفرق، وتحصل الوكالات على قالب قابل للتكرار. أضف TrekMail وقسم المزودين الآخرين وراقب العدد. ينخفض الخطر ولا يختفي. راجع استضافة البريد لعدة نطاقات.
يمكن لمدقق DNS في TrekMail إظهار تعارضات SPF ضمن الفحوص المدعومة قبل أن تظهر للمستخدمين. راجع سجلات DNS المطلوبة.
الخلاصة: صمم SPF مرة وأدر التغييرات
يبدأ SPF الجيد بالبنية. احذف الآليات القديمة، وقسم المرسلين إلى نطاقات فرعية لكل منها 10 استعلامات، وأبق الجذر مع مزود واحد وآلية include واحدة و-all واحدة. تحقق باستخدام dig لا اللوحات وحدها.
يوفر TrekMail لنطاق واحد أو مئة استضافة متعددة النطاقات بسعر ثابت، وآلية SPF مختصرة، وتخزينا مجمعا ومدقق DNS. وفقا للخطط الموصوفة، تشمل Nano عدد 10 نطاقات مع SMTP من اختيارك، بلا بطاقة ومجانا ضمن الشروط. تبدأ Starter من $3.50/شهريا مع SMTP مدار وتجربة 14 يوما تتطلب بطاقة. راجع الخطط الحالية على trekmail.net/pricing.
