تسطيح SPF: إصلاح حد الاستعلامات العشرة

شرح حد الاستعلامات العشرة

يفشل SPF (إطار سياسة المُرسِل) بالخطأ permerror عندما يضطر خادم البريد المستلِم إلى إجراء أكثر من 10 استعلامات DNS لحلّ سجل SPF الخاص بك. ويحدث ذلك بسبب عبارات include المتداخلة: فإذا كان سجلك يضمّن مزوّدًا، وكان ذلك المزوّد يضمّن خدمة أخرى، فإن كل خطوة تُحتسب ضمن الحد. ولإصلاح ذلك، يجب استخدام تسطيح SPF الذي يستبدل هذه الاستعلامات التعاودية بقائمة ثابتة من عناوين IP.

بصفتي مهندسًا يدير قابلية التسليم، رأيت هذه المشكلة تظهر في أغلب الأحيان أثناء «تشعّب الموردين». تبدأ شركة بمزوّد معاملاتي واحد، ثم تضيف أداة تسويق، ثم نظام CRM، وفجأة يصبح سجل SPF لديها بيتًا من ورق. وعند تشغيل الاستعلام الحادي عشر، يتوقف الخادم المستلِم عن البحث ويعيد خطأً دائمًا. وهذا يعني أن رسالتك لا تُصنَّف بريدًا مزعجًا فحسب، بل قد تُرفض بالكامل لأن فحص المصادقة فشل من أساسه.

كيف يعمل حد الاستعلامات

وفقًا لـ RFC 7208، يوجد الحد لمنع هجمات حجب الخدمة (DoS) على بنية DNS التحتية. فبدون حد، يمكن لجهة خبيثة إنشاء مرجع دائري أو سلسلة ضخمة من include تُجبر الخادم المستلِم على إجراء مئات الاستعلامات لرسالة واحدة.

ما الذي يُحتسب استعلامًا؟

ليست كل آلية في سجل SPF لديك مجانية. تُطلق الآليات التالية استعلام DNS:

• include: المتسبب الأكثر شيوعًا. يخبر الخادم بالذهاب لفحص سجل SPF الخاص بنطاق آخر.
• a: يستعلم عن سجل A للنطاق.
• mx: يستعلم عن سجلات MX للنطاق.
• ptr: يستعلم عن DNS العكسي (رغم أنه مهجور وينبغي تجنبه).
• exists: يستعلم عن نطاق محدد لمعرفة ما إذا كان موجودًا.

آليات مثل ip4 وip6 مجانية لأن عنوان IP مذكور صراحةً في السجل.

تشريح سلسلة الاستعلامات

لنفترض سجل SPF افتراضيًا كهذا:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendhq.cc ~all

في الظاهر، هذه 3 استعلامات. لكن إذا كان _spf.google.com يحتوي على ثلاث عبارات include أخرى، وكان spf.protection.outlook.com يحتوي على أربع، فقد بلغت 10 استعلامات بالفعل. وإذا كان سجل SendHQ يتضمن include أيضًا، فقد بلغت الحد. هذه هي «سلسلة include».

التعرّف على permerror

إذا لم تكن متأكدًا من أنك بلغت الحد، فيمكنك استخدام أداة فحص DNS للبريد من SendHQ للتحقق من سجلاتك. وفي سجل خام أو أداة لتحليل الترويسات، سترى نتيجة كهذه:

spf=permerror (too many DNS lookups)

وهذا يختلف عن softfail (‎~all‎) أو fail (‎-all‎). فالخطأ permerror يعني أنه تعذّر إكمال فحص SPF. وعندما يحدث ذلك، لا يستطيع المستلِم التحقق مما إذا كان المُرسِل مخوَّلًا، وغالبًا ما يؤدي ذلك إلى إسقاط الرسالة أو وسمها بواسطة مرشحات صارمة.

ما هو تسطيح SPF؟

تسطيح SPF هو عملية حلّ جميع آليات include وa وmx إلى قائمة مسطّحة من عناوين ip4 وip6.

مثال: قبل وبعد

قبل (تعاودي):

v=spf1 include:_spf.example.com include:_spf.vendor.com ~all

(افترض أن _spf.example.com يُحلّ إلى 1.2.3.4 وأن _spf.vendor.com يُحلّ إلى 5.6.7.8)

بعد (مسطّح):

v=spf1 ip4:1.2.3.4 ip4:5.6.7.8 ~all

بتحويل السجل إلى قائمة من عناوين IP، ينخفض عدد الاستعلامات من 2 (أو أكثر) إلى 0. ويرى الخادم المستلِم عناوين IP فورًا ويتحقق من المُرسِل دون استعلامات DNS إضافية.

مفاضلات التسطيح

التسطيح إصلاح قوي، لكنه يُدخل عبئًا كبيرًا في الصيانة.

1. مشكلة عناوين IP القديمة

عندما تستخدم عبارة include، فإنك تفوّض إدارة عناوين IP إلى المزوّد. وإذا أضافت Amazon SES أو SendGrid نطاق IP جديدًا إلى بنيتها التحتية، فإنها تحدّث سجل SPF الخاص بها وتستمر رسائلك في التدفق.

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

2. حدود طول السجل

لسجلات DNS حد أقصى للطول. فالسلسلة النصية الواحدة في سجل TXT محدودة بـ 255 حرفًا. ورغم إمكانية ضمّ عدة سلاسل، فإن بعض محلّلات DNS الأقدم تعاني مع السجلات الطويلة جدًا. وإذا سطّحت مزوّدين كثيرين جدًا، فقد يصبح سجل SPF أكبر من أن يُعالَج بشكل صحيح.

كيف تصلح سلاسل include

إذا كنت تبلغ حد الاستعلامات العشرة، فاتبع هذا التسلسل من الحلول، منتقلًا من الأكثر أمانًا إلى الأكثر جرأة.

الخطوة 1: دقّق ونقِّح

افحص سجلك بحثًا عن المزوّدين القدامى. ما زالت فرق كثيرة تحتفظ بعبارات include لخدمات توقفت عن استخدامها منذ ثلاث سنوات. أزل أي مزوّد لم يعد يرسل البريد نيابةً عنك.

الخطوة 2: استخدم نطاقات فرعية لأنواع الحركة المختلفة

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

• النطاق الجذري (example.com): البريد المؤسسي (Google Workspace/Outlook).
• النطاق الفرعي المعاملاتي (mail.example.com): SendHQ أو Amazon SES.
• النطاق الفرعي التسويقي (news.example.com): Mailchimp أو Klaviyo.

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

الخطوة 3: التسطيح الديناميكي لـ SPF

التسطيح الديناميكي خدمة تراقب سلاسل include لمزوّديك في الوقت الفعلي وتحدّث سجل DNS الخاص بك تلقائيًا بعناوين IP الحالية. وهذا يحلّ مشكلة «عناوين IP القديمة» بأتمتة عملية التحديث عبر API.

SPF في سياق التسليم الحديث

من المهم أن تفهم أن SPF ليس سوى جزء واحد من أحجية المصادقة. ولضمان قبول الخادم المستلِم لبريدك، يجب أن تنسّق SPF مع DKIM وDMARC. ويمكنك الاطلاع على تفصيل مفصّل لهذه العلاقات في دليل SendHQ عن DKIM وSPF وDMARC.

القبول مقابل التسليم مقابل الوصول

بصفتي مهندسًا، أميّز بين هذه المراحل الثلاث:

1. القبول: يقبل الخادم المستلِم الاتصال والرسالة. وقد يجعل الخطأ permerror في SPF الخادم يرفض الرسالة على مستوى SMTP، أي أنها لا تُقبل أصلًا.
2. التسليم: تُقبل الرسالة وتُنقل إلى صندوق بريد المستخدم (أو إلى مجلد).
3. الوصول إلى صندوق الوارد: تصل الرسالة إلى صندوق الوارد الرئيسي بدلًا من مجلد البريد المزعج.

يعالج تسطيح SPF مشكلة القبول. ولا يضمن الوصول إلى صندوق الوارد. فالوصول تحدده سمعة المُرسِل والمحتوى ومقاييس التفاعل.

اعتبارات خاصة بوكلاء الذكاء الاصطناعي

مع صعود وكلاء الذكاء الاصطناعي الذين يرسلون الرسائل عبر واجهات API، يزداد خطر مشكلات SPF لأن الوكلاء قد يُطلقون أحجامًا كبيرة من الرسائل عبر نطاقات متعددة. وعند بناء سير عمل الوكلاء، تعامل مع إرسال البريد كأثر جانبي خارجي.

عدم التكرار والموافقة

لا ينبغي أن ترسل الوكلاء رسائل في حلقة دون آلية أمان. استخدم مفتاح عدم التكرار (idempotency key) لضمان ألا يرسل منطق إعادة المحاولة في وكيلك الرسالة المعاملاتية نفسها عشر مرات إلى العميل. وفضلًا عن ذلك، ولرسائل الأهمية العالية، طبّق خطوة موافقة يشارك فيها إنسان قبل استدعاء API.

تحليل تكلفة مزوّدي الإرسال

عند اختيار مزوّد لتضمينه في سجل SPF لديك، ضع في اعتبارك تكلفة الحجم الذي ترسله. بالاستناد إلى أسعار سبتمبر 2026:

• Amazon SES: تكلّف 0.10 USD لكل 1,000 رسالة بنموذج a la carte (أسعار Amazon SES). ولـ 50,000 رسالة، يبلغ ذلك نحو 5 USD تقريبًا. وتشمل الباقات المتدرجة الجديدة التي أُطلقت في 21 يوليو 2026 باقة Essentials (0.16 USD لكل 1,000)، وPro (0.22 USD لكل 1,000 مع 105 USD/شهر/منطقة)، وEnterprise (0.23 USD لكل 1,000 مع 500 USD/شهر).
• Postmark: 15 USD شهريًا لـ 10,000 رسالة، مع رسوم تجاوز بين 1.80 و1.20 USD لكل 1,000 (أسعار Postmark). وتكلّف 50,000 رسالة على باقات Postmark نحو 66 USD.
• Resend: الباقة المجانية 3,000 رسالة شهريًا (بحد أقصى 100/يوم). وباقة Pro بـ 20 USD شهريًا لـ 50,000 رسالة، مع رسوم تجاوز قدرها 0.90 USD لكل 1,000 (أسعار Resend).
• Mailgun: 15 USD شهريًا لـ 10,000 رسالة، مع رسوم تجاوز من 1.80 إلى 1.10 USD لكل 1,000 (أسعار Mailgun).
• SendGrid: الباقة المجانية أصبحت الآن فترة تجريبية مدتها 60 يومًا، وتبدأ Essentials من 19.95 USD شهريًا (أسعار SendGrid).

قائمة التحقق لاستكشاف أخطاء SPF

إذا كنت تشتبه في مشكلة حد الاستعلامات، فمرّ على قائمة التحقق هذه:

• شغّل فحص DNS على النطاق الجذر وكل النطاقات الفرعية المرسِلة.
• احسب العدد الإجمالي لآليات include وa وmx وexists.
• تتبّع سلاسل include لكل مزوّد لمعرفة ما إذا كانت لها استعلامات متداخلة.
• حدّد المزوّدين غير المستخدمين وأزلهم.
• قيّم ما إذا كان يمكن نقل حركة المرور إلى نطاق فرعي مخصص (مثل notifications.example.com).
• إذا ظل الحد متجاوزًا، فنفّذ تسطيح SPF ديناميكيًا.
• تحقق من أن السجل النهائي لا يتجاوز حد 255 حرفًا لكل سلسلة.

جدول ملخص: آليات SPF

الآلية | استعلام DNS؟ | المخاطرة | التوصية

ip4 / ip6 | لا | منخفضة | استخدمها لعناوين IP الثابتة

include | نعم | عالية | استخدمها باقتصاد، وراقب السلاسل

a | نعم | متوسطة | تجنّبها إن أمكن، واستخدم ip4

mx | نعم | متوسطة | تجنّبها إن أمكن

ptr | نعم | عالية | لا تستخدمها (مهجورة)

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

للحصول على مجموعة كاملة من الأدوات لإدارة مصادقة نطاقك، زُر https://sendhq.cc.