أمثلة سجل SPF جاهزة للنسخ لكل إعداد

غالبا ما يكون أي مثال لسجل SPF تجده عبر الإنترنت مبسطا أكثر من اللازم أو مثقلا بحالات نادرة. ما تحتاج إليه هو قوالب مناسبة للإنتاج لثلاثة إعدادات تغطي 95% من النطاقات. سجل TXT واحد يبدأ بـ v=spf1 وينتهي بـ -all. قد يؤدي الخطأ فيه إلى رفض مزودين مثل Google وMicrosoft رسائلك مع أخطاء SMTP غامضة مثل 550 5.7.26.

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

قوالب سجل SPF لكل إعداد إرسال

ينبغي أن يطابق المثال الجيد بنيتك الفعلية، لا إعدادا افتراضيا يضم ست أدوات SaaS. تغطي السيناريوهات الثلاثة نطاقات بمرسل واحد، وإعدادات هجينة، وبنى معقدة متعددة المرسلين. وكل قالب جاهز للنشر كسجل DNS TXT على النطاق الجذر.

السيناريو 1: مرسل واحد (مزود واحد يدير كل شيء)

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

TrekMail (باقة Starter أو Pro أو Agency):

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

Google Workspace:

v=spf1 include:_spf.google.com -all

Microsoft 365:

v=spf1 include:spf.protection.outlook.com -all

آلية include واحدة وآلية -all واحدة. هذا كل شيء. أنت تستخدم 1 من أصل 10 استعلامات DNS مسموحة.

السيناريو 2: مرسل هجين (صندوق وارد + خدمة معاملات)

تستخدم مزودا رئيسيا لصندوق الوارد وخدمة منفصلة للرسائل التسويقية أو رسائل المعاملات. وهذا شائع مع باقة Nano من TrekMail التي تستخدم SMTP خاصا بك، أو عند إضافة أداة مثل Amazon SES أو Mailchimp.

TrekMail Free + Amazon SES:

v=spf1 include:amazonses.com -all

Google Workspace + Mailchimp:

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

آليتا تضمين واستعلامان، إضافة إلى أي استعلامات متداخلة يشغلها المزودان. ويظل الإجمالي ضمن الحدود.

السيناريو 3: بنية متعددة المرسلين (مخاطر مرتفعة)

يغطي هذا المثال بريد الشركة وCRM والدعم ومنصة الموارد البشرية، وكلها مخولة على نطاق واحد. وهنا تظهر المشكلات عادة.

v=spf1 include:spf.trekmail.net include:hubspot.com include:mail.zendesk.com include:spf.bamboohr.com -all

توجد أربع آليات تضمين ظاهريا، لكن كل include قد يحتوي استعلامات متداخلة. ويمكن لـ HubSpot وحده أن يضيف 3-4 استعلامات. إذا تجاوزت السلسلة 10، يعيد المستلمون PermError ويعاملون الرسالة كأنها غير موثقة. إذا كانت بنيتك مماثلة، فاقرأ قسم حد الاستعلامات التالي.

كيف تعمل صياغة SPF: الأجزاء المهمة

SPF قائمة سماح تستند إلى DNS ومحددة في RFC 7208. وهي تخبر خوادم الاستقبال بعناوين IP المسموح لها بإرسال البريد لنطاقك. هذه هي المكونات التي تظهر في مثال حقيقي:

للاطلاع على خطوات الإعداد كاملة، بما فيها أدوات التحقق ومخاطر التسطيح، راجع دليل إعداد سجل SPF.

حد 10 استعلامات: موضع تعطل معظم سجلات SPF

تضع RFC 7208 حدا قدره 10 استعلامات DNS لكل تقييم SPF. يساعد ذلك على منع هجمات حجب الخدمة، لكنه يمثل أيضا قيدا مهما أمام الشركات النامية.

تستهلك كل آلية من هذه 1 استعلام: include وa وmx وredirect وexists وptr (مهملة، فلا تستخدمها).

أما هذه فلا تستهلك استعلامات: ip4 وip6 وall.

الاستعلامات تكرارية. عند إضافة include:bluehost.com تستهلك 1 استعلام. وإذا كان سجل Bluehost يتضمن include:spf.protection.outlook.com، يحتسب الاستعلام المتداخل من حدك أنت. وعند ربط 3-4 مزودين لديهم تضمينات متداخلة قد تتجاوز 10.

حد الاستعلامات الفارغة الذي غالبا ما يهمل

تضيف RFC 7208 §11.1 حدا ثانويا: لا يزيد عدد استعلامات DNS بلا نتائج، سواء NXDOMAIN أو استجابة فارغة، على 2. خطأ في include:spf.trekmaill.net بسبب حرف 'l' إضافي؟ هذا 1 استعلام فارغ. وخطآن يؤديان إلى فشل السجل كله.

حل حد الاستعلامات من دون تسطيح

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

استخدم النطاقات الفرعية لفصل المرسلين

لا تضع كل الأدوات على النطاق الجذر. يحصل كل نطاق فرعي على حد جديد قدره 10 استعلامات.

• بريد الشركة: @company.com، المزود الرئيسي فقط (TrekMail أو Google، إلخ)
• التسويق: @news.company.com، Mailchimp وHubSpot
• الدعم: @support.company.com، Zendesk وFreshdesk

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

استبدل استعلامات DNS بآليات IP

إذا كان لديك خادم بريد بعنوان ثابت، فأدرج عنوان IP مباشرة بدلا من آلية a.

يستهلك 1 استعلام:

v=spf1 a:mail.company.com -all

يستهلك 0 استعلامات:

v=spf1 ip4:192.0.2.55 -all

كل ip4 أو ip6 تستخدمه بديلا يحرر استعلاما لأدوات SaaS التي تتطلب include.

أخطاء SPF الحرجة التي تضر بوصول البريد

الخطأ 1: سجلان SPF على النطاق نفسه

هذا أكثر أخطاء الأمثلة شيوعا. لا يمكنك نشر سجلي TXT يبدأان بـ v=spf1 على النطاق نفسه. سيفشل كلاهما مع PermError.

خطأ:

TXT: v=spf1 include:_spf.google.com -all
TXT: v=spf1 include:spf.trekmail.net -all

صحيح:

TXT: v=spf1 include:_spf.google.com include:spf.trekmail.net -all

ادمجهما دائما في سجل واحد. لشرح أعمق ومثال كامل، راجع سجل SPF للبريد. ويغطي دليل إعداد سجل SPF العملية كاملة من البداية.

الخطأ 2: استخدام +all

لا تستخدم +all. فهي تسمح بكل شيء وتخبر كل خادم بأن أي شخص يستطيع الإرسال باسم نطاقك. استخدم -all (HardFail) دائما.

الخطأ 3: الاعتماد على SPF وحده للبريد المعاد توجيهه

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

لهذا يوجد DKIM، فهو يوقع محتوى الرسالة ويمكن أن يبقى سليما عند التوجيه. إذا كنت تعتمد على قوائم بريدية أو إعادة توجيه البريد، فلا يكفي SPF وحده. تحتاج إلى DKIM، ويفضل سياسة DMARC تقبل أيا منهما. ويكمل Sender Rewriting Scheme (SRS) العملية بإعادة كتابة مرسل المغلف كي ينجح SPF عند النقلة التالية.

كيف تبسط TrekMail إدارة SPF

إدارة سجلات DNS لنطاق واحد مرهقة. وعبر 50 أو 100 نطاق لعملاء يمكن أن تتراكم الأخطاء.

يعتمد نهج TrekMail على باقتك:

• Free ($0/mo، لا تتطلب بطاقة): تستخدم SMTP خاصا بك وتضيف سجل SPF لمزودك. تحكم كامل وتكلفة صفرية.
• Starter ($3.50/mo) وPro ($10/mo): SMTP مدار. أضف include:spf.trekmail.net لندير بنية IP الأساسية. وعند تبديل الخوادم يبقى DNS بلا تغيير.
• Agency (.25/mo): خدمة SMTP المدارة نفسها، لكنها مخصصة لإدارة نطاقات متعددة. طبق قالب SPF موحدا على نطاقات العملاء. نبقي الأثر صغيرا بتضمين واحد، ونترك مساحة لاستعلامات أدواتهم الأخرى.

تتضمن كل الباقات المدفوعة تجربة مجانية لمدة 14 يوما تتطلب بطاقة. يرشدك معالج SPF/DKIM/DMARC المدمج خلال إعداد DNS وينبه إلى الأخطاء قبل الإنتاج.

قائمة مراجعة SPF

تتبع أمثلة هذا الدليل المبادئ نفسها. ولا يكون سجل SPF الجيد معقدا إذا تجنبت التعقيد غير الضروري. هذا تسلسل التدقيق:

1. احسب الاستعلامات. نفذ dig TXT yourdomain.com أو استخدم أداة تحقق SPF. إذا تجاوزت 10، فالسجل يفشل بالفعل.
2. ادمج السجلات المكررة. نطاق واحد وسجل v=spf1 واحد.
3. افصل المرسلين كثيفي الاستخدام. انقل أدوات التسويق والدعم إلى نطاقات فرعية.
4. استبدل آليات a بآليات ip4 عندما تكون الخوادم ثابتة.
5. اختم بـ -all. بلا استثناءات.

إذا فضلت تجنب تحرير DNS بالكامل، تمنحك باقة TrekMail المجانية منظومة بريد عاملة من دون تكلفة مسبقة. وتتولى الباقات المدفوعة إدارة بنية SPF.