حد استعلامات SPF: معالجة 10 استعلامات DNS

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

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

الخبر الجيد أن الحل غالبا بسيط: احذف الإدخالات غير المستخدمة، ولا تستخدم `mx` إلا عند الحاجة الفعلية إليه. افصل الرسائل التسويقية في نطاق فرعي، وحافظ على بساطة سياسة نطاقك الرئيسي.

ما حد استعلامات SPF؟

حد استعلامات SPF هو السقف الذي تحدده RFC لبنود SPF التي تستدعي DNS أثناء التقييم. يجب ألا تعالج خوادم الاستقبال أكثر من 10 من هذه البنود في مسار التقييم الكامل، بما فيه سلاسل `include` المتداخلة. إذا تجاوزت السياسة هذا السقف، فقد يعيد SPF النتيجة `permerror`، وتفقد الرسالة إشارة مهمة للتحقق من هوية المرسل.

تحدد RFC 7208 هذه القاعدة. وهدف السقف منع SPF من توليد حركة DNS مفرطة. فهو ليس خيارا ولا مجرد ممارسة مستحسنة، بل حد في البروتوكول.

ما يغفل عنه كثيرون أن حد استعلامات SPF تراكمي. لا تحصل على 10 استعلامات في السجل الرئيسي ثم 10 أخرى داخل كل include. هناك ميزانية واحدة لمسار التقييم كله.

آلية SPF	تكلفة الاستعلام	ملاحظة عملية
`include:`	1	شائعة، لكن بنود include المتداخلة تتراكم بسرعة
`a`	1	مناسبة لبعض الإعدادات الصغيرة، وغالبا غير ضرورية
`mx`	1+	غالبا ليست خيارا مناسبا لتفويض الإرسال الصادر
`ptr`	1+	تجنبها؛ توصي RFC 7208 بشدة بعدم استخدامها
`exists`	1	نادرة ويسهل إعدادها بطريقة خاطئة
`redirect=`	1	مفيدة في تصميمات معينة، لكنها تحتسب ضمن الحد
`ip4` / `ip6`	0	لا تستدعي DNS أثناء تقييم SPF
`all`	0	تحدد السياسة فقط، دون تكلفة استعلام

لماذا يتسبب حد استعلامات SPF في فشل سجلات تبدو سليمة؟

قد يؤثر حد استعلامات SPF في سجل يبدو سليما لأن SPF لا يهتم بمدى ترتيب سجل TXT الرئيسي. المهم هو عدد البنود المستدعية لـ DNS التي يعالجها خادم الاستقبال بعد تتبع include وredirect و`a` و`mx` عبر سلسلة التقييم.

مثال:

تنشر `v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:servers.mcsv.net -all` وتظن أنك استخدمت ثلاثة استعلامات. لكن الأمر ليس كذلك: تتفرع سجلات Google وMicrosoft إلى بنود استعلام إضافية. السجل الظاهر قصير، أما مسار التقييم الكامل فليس قصيرا بالضرورة.

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

وهناك مشكلة أخرى: الاستعلامات الخالية، أو void lookups. توصي RFC 7208 بأن تحدها التطبيقات باثنين. والاستعلام الخالي هو طلب DNS لا يعيد بيانات أو يعيد `NXDOMAIN`. قد لا يكون خطأ مطبعي واحد في include كافيا للتسبب بالفشل، لكن مرجعين غير صالحين قد يسببان المشكلة. وهكذا قد تظهر `permerror` أثناء فحص حد استعلامات SPF حتى وأنت دون 10.

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

كيف تحسب استهلاك حد استعلامات SPF؟

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

ابدأ بالسجل الرئيسي:

dig +short txt example.com

مثال على الناتج:

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

ثم افحص كل نطاق مشار إليه:

dig +short txt _spf.google.com

dig +short txt spf.protection.outlook.com

تابع التتبع إلى أن تصل إلى `ip4` أو `ip6` أو بنود تنهي تقييم السياسة فقط.

استخدم طريقة العد التالية:

احسب كل include وa وmx وptr وexists وredirect في مسار التقييم.
احسب أيضا البنود المتداخلة داخل السجلات المضمنة.
لا تحسب ip4 أو ip6 أو all.
حدد كل هدف include لا يعيد بيانات، فقد يسبب مشكلة في الاستعلامات الخالية.

إذا أردت فحصا سريعا لإعداد DNS أثناء إضافة نطاق في TrekMail، فابدأ بوثائق فحص حالة DNS وسجلات DNS المطلوبة.

أخطاء شائعة تتعلق بحد استعلامات SPF

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

أبرز هذه الأخطاء:

الخطأ	أثره	التصرف الأفضل
الإبقاء على مزودين قدامى	يهدر ميزانية الاستعلامات ويوسع نطاق المخاطر	احذف كل مزود لم تعد ترسل عبره
استخدام `mx` لتفويض الإرسال الصادر	خوادم MX المستقبلة ليست غالبا خوادم الإرسال	فوض المرسل الفعلي صراحة
استخدام `ptr`	بطيئة وغير موصى بها وقابلة للفشل	احذفها
إرسال كل شيء من نطاق واحد	تتنافس الرسائل التسويقية ورسائل المعاملات على ميزانية SPF واحدة	افصل تدفقات البريد بين نطاقات فرعية
التسطيح اليدوي	قد يفشل عندما يغير المزودون عناوين IP	أتمت التحديثات أو تجنب التسطيح

هنا يختلط التعقيد الظاهر بالتعقيد الفعلي. فقد يستهلك include واحد لمزود عدة بنود استعلام بعد توسيعه. لذلك لا تناسب فكرة «إضافة مرسل آخر فقط» التعامل مع حد استعلامات SPF.

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

كيف تعالج حد استعلامات SPF مع تقليل مخاطر تعطل البريد؟

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

1. احذف العناصر الزائدة.

احذف المزودين الذين لا تستخدمهم و`ptr`. واستبدل `mx` بالتفويض الذي يحتاج إليه المرسل الفعلي. قد تعود سياسات SPF كثيرة إلى ما دون حد استعلامات SPF بعد جولة تنظيف واحدة.

2. افصل حركة البريد حسب النطاق الفرعي.

غالبا ما يكون ذلك خيارا مناسبا للفرق التي تنمو.

; Primary company mail
example.com.              TXT  "v=spf1 include:spf.trekmail.net -all"

; Marketing mail
marketing.example.com.    TXT  "v=spf1 include:servers.mcsv.net include:hubspotemail.net -all"

; Transactional app mail
notify.example.com.       TXT  "v=spf1 include:amazonses.com -all"

لكل نطاق فرعي ميزانية SPF مستقلة. وقد يساعد ذلك على تقليل تعقيد النطاق الرئيسي وتسهيل إدارة حد استعلامات SPF.

3. استخدم التسطيح كحل أخير فقط.

يستبدل التسطيح بنود include بنطاقات IP صريحة:

; Before
v=spf1 include:vendor-a.example include:vendor-b.example -all

; After
v=spf1 ip4:192.0.2.10 ip4:192.0.2.11 ip4:198.51.100.0/24 -all

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

النهج القديم والجديد: إدارة حد استعلامات SPF مع TrekMail

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

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

النهج الجديد: تبسيط استضافة صناديق البريد، وعزل المرسلين بكميات كبيرة في نطاقات فرعية، ومنح النطاق الرئيسي سياسة SPF قصيرة مع هامش كاف.

يمكن أن يساعد TrekMail في هذا الإعداد. عند استخدام الإرسال المدار من TrekMail ضمن الخطط المدفوعة، توصي تعليمات DNS بإضافة `include:spf.trekmail.net` إلى سجل SPF. يحتسب هذا البند نفسه كاستعلام واحد، وينبغي فحص أي مراجع متداخلة أيضا. السعر الابتدائي المذكور هو $3.50 شهريا، وتشمل الميزات المعلنة النطاقات المخصصة وصناديق IMAP وcatch-all وإعادة توجيه صناديق البريد وأداة ترحيل مدمجة والوصول إلى API. تذكر الخطط المدفوعة تجربة مجانية لمدة 14 يوما تتطلب بطاقة ائتمان. وتعرض Nano كخطة مجانية دون فترة تجربة، مع BYO SMTP. تحقق من الأسعار والشروط الحالية.

في خطة Nano يمكنك استخدام TrekMail لطبقة صناديق البريد، مع الإرسال عبر SES أو Mailgun أو خادم ترحيل آخر. نظم النطاقات الفرعية بعناية لتجنب وصول سياسة النطاق الرئيسي إلى حد استعلامات SPF. تغطي وثائق SMTP المخصص (BYO) وSMTP المدار من TrekMail وبدء الترحيل من لوحة التحكم الجوانب التشغيلية.

إذا كنت تجمع نطاقاتك، فقد يفيدك أيضا استضافة البريد لعدة نطاقات وإعداد البريد على نطاقي.

الخلاصة: كيف تبقى دون حد استعلامات SPF؟

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

هذه هي الفكرة الأساسية. حد استعلامات SPF ليس حالة نظرية هامشية في RFC، بل قيد تشغيلي واضح تظهر آثاره مع تراكم الخدمات. اجعل السجل قصيرا والمسؤولية عن DNS واضحة. لا تدع خمسة مزودين يتشاركون مسار تحقق واحدا محدود الميزانية دون مراجعة، إلا إذا كنت تفضل فحص ترويسات البريد عند الساعة 2 فجرا.

لإعداد أبسط، يقدم TrekMail استضافة بريد لعدة نطاقات بسعر ثابت دون رسوم لكل مستخدم، مع مساحة تخزين مشتركة وترحيل IMAP مدمج وخيار BYO SMTP أو SMTP المدار من TrekMail. قد يختلف التوفر والشروط حسب الخطة. راجع أسعار TrekMail أو انتقل مباشرة إلى TrekMail.