إعداد سجل SPF: دليل الخطوات والتحقق

يساعد إعداد سجل SPF الصحيح خادم البريد المستقبِل على تحديد ما إذا كان الخادم المرسِل مخولًا بالإرسال باسم نطاقك. SPF واحد من عدة فحوص، وليس بالضرورة أولها. قد تؤدي أخطاء الإعداد إلى رفض الرسالة، لكن رمز SMTP مثل 550 5.7.26 لا يثبت وحده أن SPF هو السبب. منذ فبراير 2024 تُطبَّق متطلبات المصادقة لدى Google وYahoo، وتختلف تفاصيلها بحسب حجم الإرسال ونوع الرسائل وغير ذلك.

من المشكلات الشائعة تكرار السجلات، وتجاوز حد 10 عناصر تستلزم استعلامات DNS، واختيار مُحدِّد ختامي غير مناسب. يمكن أن تؤثر هذه الأخطاء في المصادقة والتسليم وتبقى أيامًا من دون اكتشاف، ولا توضح رسائل الارتداد السبب دائمًا.

يغطي هذا الدليل بنية سجل SPF، وأمثلة إعداد TrekMail مع Managed SMTP أو BYO، ونشر السجل في DNS، والتحقق عبر سطر الأوامر. إذا لم تُعِد بريد نطاقك بعد، ابدأ بدليل إعداد البريد الإلكتروني على نطاقك، ثم عُد لإضافة طبقة المصادقة.

ما وظيفة SPF؟

ينشر SPF، أو Sender Policy Framework، سياسة في سجل DNS من نوع TXT تحدد الخوادم المسموح لها بالإرسال باستخدام هوية نطاق معين. يقارن الخادم المستقبِل عنوان IP المرسِل بهذه السياسة. تتحدد النتيجة وفق الآليات والمُحدِّدات المطابقة، ثم يقرر المستقبِل كيفية معالجة الرسالة وفق سياسته. يعرّف RFC 7208 فحص SPF لهوية MAIL FROM، أي مرسِل المغلف، ولـ HELO عند انطباقه، وليس لترويسة From التي يراها المستلِم.

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

قاعدة السجل الواحد

يجب نشر سجل SPF واحد فقط لكل هوية نطاق يُجري SPF تقييمها. وجود سجلَي TXT منفصلين يبدأ كل منهما بـ v=spf1 يؤدي إلى PermError. أما المقاطع النصية المتعددة بين علامتَي اقتباس داخل السجل نفسه فتُضم إلى قيمة واحدة ولا تُعد سجلات مكررة. يقرر المستقبِلون كيفية المعالجة وفق سياساتهم. قد يحدث هذا الخطأ عند الانتقال بين المزودين أو إضافة أداة تسويق من دون دمج الإعدادات.

خطأ: سجلان منفصلان	صحيح: سجل واحد مدمج
`v=spf1 include:spf.trekmail.net -all` `v=spf1 include:_spf.google.com -all`	`v=spf1 include:spf.trekmail.net include:_spf.google.com -all`

عدّل سجل SPF الموجود وادمج فيه الآليات المطلوبة. لا تحذفه أولًا ثم تنشئ سجلًا جديدًا، حتى لا تترك فترة بلا سياسة SPF. أثناء الانتقال، تأكد من إدراج المرسِلين القدامى والجدد الذين تحتاج إليهم خلال المرحلة الانتقالية.

الخطوة 1: احصر جميع الخدمات التي ترسل باستخدام نطاقك

قبل تعديل DNS، أعد قائمة بكل خدمة ترسل باسم @yourdomain.com وافحص مرسِل المغلف الفعلي. إذا نسيت خدمة، فقد تحصل رسائلها على نتيجة SPF fail بعد نشر سجل ينتهي بـ -all. أما رفض الرسالة فعليًا فيعتمد على المستقبِل. المقارنة بين خمس دقائق للحصر وساعات لاستكشاف الأخطاء توضيحية وليست ضمانًا للمدة؛ فحجم المراجعة يتوقف على بيئتك.

تشمل الخدمات التي ينبغي مراجعتها:

بريد العمل: TrekMail وGoogle Workspace وMicrosoft 365
الرسائل المرتبطة بالمعاملات: Amazon SES وSendGrid وMailgun وPostmark
التسويق: Mailchimp وHubSpot وKlaviyo وBrevo
أدوات SaaS: Zendesk وFreshdesk وShopify وIntercom

تستخدم بعض الخدمات نطاق return-path خاصًا بها، مثل bounce.mailchimp.com. عندئذ يُفحص SPF لذلك النطاق، ولا يلزم تلقائيًا إدراج الخدمة في سجل نطاقك. لكن قد يتغير ذلك إذا ضُبطت الخدمة لاستخدام نطاقك من أجل محاذاة DMARC. راجع وثائق المزود وهوية مرسِل المغلف الفعلية قبل استبعاد أي خدمة.

الخطوة 2: أنشئ قيمة سجل SPF

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

العنصر	مثال	الوظيفة
الإصدار	`v=spf1`	إلزامي. يبدأ به كل سجل SPF.
include	`include:domain.com`	يقيّم سياسة SPF الخاصة بالمزود عبر DNS، ويُحتسب ضمن حد 10 عناصر تستلزم استعلامات DNS.
ip4	`ip4:203.0.113.0/24`	يسمح مباشرة بعنوان IPv4 أو نطاق CIDR، من دون استعلام DNS.
ip6	`ip6:2001:db8::/32`	يؤدي الوظيفة نفسها لعناوين IPv6.
-all	`-all`	يعيد fail للمرسِلين غير المطابقين. يقرر المستقبِل الإجراء النهائي. يُنظر فيه بعد التأكد من جميع المرسِلين الشرعيين.
~all	`~all`	يعيد softfail للمرسِلين غير المدرجين. لا يضمن التسليم، ويمكن استخدامه في انتقال مدروس.

الخطوة 3: إعداد SPF بحسب مزود الخدمة

اختر السيناريو الموافق لبنيتك. السجلات التالية أمثلة، وليست قيمًا جاهزة لكل حساب. تحقق من تعليمات المزود الحالية وإعدادات حسابك قبل النشر. إذا استخدمت عدة مزودين، فادمج آليات include في سجل واحد.

السيناريو A: TrekMail Managed SMTP في خطتَي Starter وAgency

إذا كان Managed SMTP متاحًا ومفعّلًا في خطتك الحالية، وكان TrekMail جهة الإرسال الوحيدة، فقد يكون المثال التالي أساسًا مناسبًا. راجع تعليمات DNS الحالية في حسابك:

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

يدير TrekMail عناوين IP المرتبطة بهذا المسار. أدرج أيضًا أي خدمات أخرى مخولة بالإرسال.

السيناريو B: TrekMail BYO SMTP مع إعداد إرسال خاص بك

إذا استخدمت TrekMail لصندوق الوارد وربطت مزود SMTP خاصًا للإرسال، فاتبع تعليمات ذلك المزود الخاصة بهوية مرسِل المغلف المستخدمة. تعتمد مرحلة التسليم النهائية على عناوين IP التابعة له. قد لا تناسب الأمثلة التالية كل حساب أو إعداد return-path.

# Amazon SES
v=spf1 include:amazonses.com -all

# SendGrid
v=spf1 include:sendgrid.net -all

السيناريو C: Google Workspace

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

السيناريو D: Microsoft 365

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

السيناريو E: إعداد مختلط، TrekMail مع منصة تسويق

هل تستخدم TrekMail لبريد الفريق وHubSpot للحملات؟ ادمج العناصر المطلوبة في سجل واحد. يتضمن المثال التالي قيمة HubSpot توضيحية مرتبطة بحساب:

v=spf1 include:spf.trekmail.net include:456789.spf05.hubspotemail.net -all

قيمة include في HubSpot خاصة ببوابتك. احصل على قيمتك من شاشة إعدادات DNS في HubSpot، ولا تنسخ قيمة دليل عام كما هي.

الخطوة 4: انشر السجل في DNS

انشر سياسة SPF كسجل TXT لدى مزود DNS لنطاقك. سجّل الدخول إلى Cloudflare أو Namecheap أو GoDaddy أو Route 53، أو إلى الخدمة التي تدير DNS بالفعل. إذا كان سجل SPF موجودًا، فعدّله بدل إنشاء سجل ثانٍ.

النوع: TXT
المضيف/الاسم: @، أو اتركه فارغًا بحسب المزود والنطاق المقصود
القيمة: سلسلة SPF الكاملة، مثل v=spf1 include:spf.trekmail.net -all
TTL: 3600 ثانية (1 ساعة)

بعد مراجعة مفوّضة للمرسِلين القدامى والجدد، استبدل محتوى السجل الموجود بالقيمة المدمجة. لا تضف سجل SPF ثانيًا، ولا تحذف سجلات TXT الأخرى المستخدمة للتحقق من النطاق. بعد الحفظ، تأكد من وجود سجل واحد لاسم النطاق الصحيح. قد تبقى القيم القديمة المخزنة مؤقتًا سارية حتى تنتهي مدة TTL السابقة.

الخطوة 5: تحقق من سجل SPF

تحقق من قيمة DNS عبر سطر الأوامر بعد النشر. يساعد ذلك على مقارنة نتائج أدوات الويب، لكنه لا يتجاوز كل التخزين المؤقت؛ فقد تستخدم هذه الأوامر محلّل DNS يخزن النتائج. وهي لا تُظهر بالضرورة ما يراه كل مستقبِل في اللحظة نفسها.

# Mac, Linux, or Windows PowerShell
nslookup -q=txt yourdomain.com

# Linux/Mac alternative
dig txt yourdomain.com +short

راجع هذه النقاط الثلاث:

وجود سجل SPF واحد فقط يبدأ بـ v=spf1
وجود جميع آليات include المطلوبة
انتهاء السجل بالمُحدِّد المقصود، -all أو ~all

إذا وجدت سجلين منفصلين يبدأان بـ v=spf1، فادمج المرسِلين المخوّلين في سجل واحد، ثم احذف السجل المكرر الزائد فقط. لا تثبت أسطر العرض المتعددة أو المقاطع المقتبسة وحدها وجود تكرار. افحص أيضًا تقييم SPF المتداخل ومصادقة رسائل فعلية ومحاذاة DMARC.

معالجة أخطاء SPF الشائعة

تندرج كثير من مشكلات SPF ضمن الفئات الثلاث التالية. استخدم رسالة الخطأ الكاملة ونتائج المصادقة وفحص DNS لتحديد السبب، بدل الاكتفاء برمز SMTP.

1. حد 10 عناصر تستلزم استعلامات DNS، PermError

يسمح SPF أثناء التقييم بـ 10 عناصر كحد أقصى تستلزم استعلامات DNS. تشمل هذه العناصر include وa وmx وptr وexists وredirect. تُحتسب أيضًا العناصر في التقييمات المتداخلة؛ فالحد ليس مجرد عدد حزم DNS. يؤدي تجاوز 10 عناصر إلى PermError، وقد يرفض المستقبِل الرسائل بناءً عليه.

العَرَض: تُظهر أداة التحقق PermError أو "too many DNS lookups".

الحل: فكّر في نقل خدمات مثل Mailchimp أو Zendesk إلى نطاق فرعي مثل support.yourdomain.com. لهذا النطاق ميزانية مستقلة من 10 عناصر تستلزم استعلامات DNS. يجب حينئذ ضبط هوية MAIL FROM أو return-path الفعلية لاستخدام هذا النطاق الفرعي، مع مراجعة محاذاة DMARC. إضافة سجل TXT منفصل وحدها لا تنقل تقييم SPF إلى النطاق الفرعي.

2. صناديق Microsoft الشخصية، 550 5.7.515

لا يثبت الرمز 550 5.7.515 أن SPF صحيح أو أن سمعة IP هي السبب. اقرأ استجابة Microsoft كاملة. للمرسِلين بكميات كبيرة إلى صناديق Outlook.com الشخصية، يجب أن ينجح SPF وDKIM معًا، وأن ينجح DMARC بمحاذاة فحص ناجح واحد على الأقل. يختلف ذلك عن قاعدة DMARC العامة التي يكفي فيها نجاح SPF أو DKIM مع المحاذاة. حتى نجاح المصادقة لا يضمن الوصول إلى صندوق الوارد؛ فقد تؤثر السمعة والمرشحات الأخرى. راجع أساسيات أمان بريد الأعمال لإعداد DKIM وDMARC.

3. الفرق بين SoftFail مع ~all وHardFail مع -all

المُحدِّد	ما يبلغه للمستقبِل	متى يُستخدم؟
`~all` (SoftFail)	يعيد softfail للمرسِل غير المطابق، ويترك قرار التسليم للمستقبِل.	أثناء انتقال مدروس ومراجعة المرسِلين، مثل فترة من 2 إلى 4 أسابيع إذا ناسبت بيئتك.
`-all` (HardFail)	يعيد fail للمرسِل غير المطابق، ولا يضمن الرفض التلقائي.	بعد تأكيد جميع المرسِلين الشرعيين والتأكد من ملاءمة السياسة للتشغيل.

يعيد ~all نتيجة SoftFail، بينما يعيد ?all نتيجة Neutral، وهي ليست نتيجة SPF fail سلبية، بل تعني أن السياسة لا تحكم على صلاحية المرسِل. لكن SPF وحده لا يمنع انتحال عنوان المرسِل الظاهر. بعد التحقق من جميع جهات الإرسال، يمكنك النظر في استخدام -all إلى جانب DKIM وDMARC.

إعداد SPF باستخدام TrekMail

تستهلك إدارة DNS وتحليل أخطاء SMTP وقتًا. إذا كان معالج إعداد SPF وDKIM وDMARC متاحًا في حسابك الحالي، فقد يساعدك على اختيار الإعداد المناسب لـ Managed SMTP أو BYO. يقارن فحص DNS السجلات بالقيم المتوقعة؛ ولا يثبت صحة توقيع رسالة أو محاذاة DMARC أو وصولها إلى صندوق الوارد. طابق القيم وافحص رسائل فعلية من بيئة الإرسال.

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

يذكر العرض التاريخي Starter من $3.50 شهريًا مع Managed SMTP، وNano كخيار استقبال مجاني من دون بطاقة ائتمان أو انتهاء فترة تجريبية، وتجربة مجانية لمدة 14 يومًا للخطط المدفوعة تتطلب بطاقة ائتمان. تحقق قبل التسجيل من الأسعار والتوافر والصلاحيات والحدود والشروط الحالية. في نموذج Nano الموصوف فقط، تحتاج جميع الرسائل الصادرة، بما فيها الردود، إلى SMTP خارجي خاص بك؛ أما الإرسال المُدار في الخطط المدفوعة فيعتمد على الصلاحيات والإعداد الفعليين. تعرّف على TrekMail.

قائمة التحقق الكاملة لإعداد SPF

راجع الخطوات السبع التالية قبل الانتهاء. قد يكتمل الإعداد البسيط خلال 15 دقيقة، لكن تعدد خدمات الإرسال ووجود نتائج DNS مخزنة مؤقتًا قد يستلزمان وقتًا إضافيًا للتحقق.