إنشاء سجل SPF: تنظيم المرسلين وإدارة استعلامات DNS

إذا كنت تريد إنشاء سجل SPF لنطاق، فالهدف بسيط: السماح للجهات الصحيحة بإرسال البريد، من دون بناء إعدادات DNS معقدة تتعطل بعد بضعة أشهر. تبدأ مشكلات كثيرة بالطريقة نفسها. تضيف مزودا، ثم مزودا آخر. وبعد ذلك يظهر الخطأ 550 5.7.515 لدى Microsoft والخطأ 550 5.7.26 لدى Google، فتجد نفسك تبحث في سجلات TXT الساعة 11 مساء.

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

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

لماذا تواجه سجلات SPF مشكلات متكررة؟

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

توضح RFC 7208 القاعدة بوضوح. تشمل العناصر التي تستدعي استعلامات DNS كلا من include وa وmx وptr وexists وredirect. يجب على الجهات المستقبلة وضع حد قدره 10 للعناصر من هذه الأنواع التي يجري تقييمها، بما فيها التقييمات المتداخلة. لا يتعلق الحد بإجمالي حزم DNS. وتجاوزه ينتج خطأ دائما، لا مجرد تحذير. وتنص الوثيقة نفسها على أن وجود عدة سجلات SPF للنطاق الواحد يسبب PermError. أما سجلات TXT الأخرى غير المرتبطة بـ SPF فيجوز أن توجد إلى جانب سجل SPF الوحيد.

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

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

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

القيد الحقيقي: ميزانية 10 عناصر تعتمد على DNS

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

العناصر التي تحتسب ضمن الميزانية:

• include
• a
• mx
• ptr (تجنب استخدامه)
• exists
• redirect

العناصر التي لا تحتسب ضمن الميزانية:

• ip4
• ip6
• all

انتبه أيضا إلى استعلامات DNS التي لا تعيد نتيجة صالحة، والمعروفة باسم void lookups. توصي RFC 7208 بقصرها على استعلامين. وقد يستهلك خطأ كتابي في هدف include جزءا من هذا الهامش. تجاوز الحد الموصى به، وليس مجرد الوصول إليه، قد ينهي تقييم SPF بخطأ PermError آخر.

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

إنشاء سجل SPF بفصل مسارات الإرسال

من الطرق المتينة لإعداد SPF فصل مراسلات الموظفين عن البريد الجماعي وبريد التطبيقات. ضع مزود صناديق البريد الأساسي على النطاق الرئيسي، واجعل خدمات التسويق والدعم والتطبيقات تستخدم نطاقات فرعية مناسبة فعليا في MAIL FROM أو return-path. عندها يحصل كل مسار على ميزانية SPF مستقلة، ويقل احتمال أن يؤثر خلل لدى مزود في بقية المسارات. تغيير عنوان From الظاهر وحده لا يحقق هذا الفصل.

التصميم المقترح:

1. النطاق الرئيسي @ لمراسلات الموظفين المعتادة.
2. نطاقات فرعية للنشرات والدعم والتنبيهات المتعلقة بالمعاملات وغيرها من مسارات الإرسال المتخصصة.
3. سجل SPF واحد لكل اسم مضيف، من دون سجلات SPF مكررة أو قديمة متروكة. يمكن إبقاء سجلات TXT الأخرى.

مثال لسجل النطاق الرئيسي عند استخدام الإرسال المدار من TrekMail:

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

هذا سجل واضح: include واحد وسياسة محددة يسهل تدقيقها. لكن يجب مع ذلك فحص تكلفة التقييم المتداخل والتأكد من شمول كل المرسلين المصرح لهم.

مثال لنطاق فرعي للتسويق:

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

يستخدم Mailchimp وHubSpot هنا ميزانية marketing.example.com بدلا من النطاق الرئيسي، بشرط أن يكون ذلك نطاق الإرسال الفعلي الذي يفحصه SPF. وقد يقل بذلك تأثير توسع بنيتهما لاحقا في صناديق الموظفين على example.com. هذا مثال توضيحي، وليس وصفة عامة: اتبع أحدث تعليمات كل مزود الرسمية للمصادقة وإعداد MAIL FROM مخصص. وتظل DMARC بحاجة إلى SPF أو DKIM متوافق مع النطاق؛ فالمواءمة الصارمة والمرنة تتعاملان مع النطاقات الفرعية بشكل مختلف.

يمكن أن ينسجم TrekMail مع هذا التصميم. توضح وثائق إعداد النطاق استخدام include:spf.trekmail.net كمرجع أساسي للإرسال المدار. وقد يساعد فاحص DNS في اكتشاف التعارضات، لكنه لا يغني عن التحقق الكامل من المصادقة. إذا كنت لا تزال تضيف الصناديق وتضبط DNS، فراجع إضافة نطاق إلى TrekMail والتحقق من حالة DNS.

خطوة بخطوة: كتابة قيم SPF دون تخمين

لإنشاء سجلات يسهل صيانتها، احصر جميع المرسلين أولا، وحدد نطاق الإرسال الصحيح لكل منهم، ثم ابن سجل TXT. لا تبدأ بتعديل DNS، بل بتحديد المسؤولية عن كل مسار إرسال. بذلك تمنع تراكم include عشوائيا على النطاق الرئيسي.

اتبع الخطوات التالية:

1. أدرج كل خدمة ترسل البريد باسم نطاقك.
2. صنف كل مرسل ضمن مراسلات الشركة أو المعاملات أو الدعم أو التسويق.
3. حدد اسم المضيف الذي سيستخدمه كل مرسل فعليا في MAIL FROM.
4. استخدم أبسط سياسة SPF صالحة تشمل كل المرسلين المصرح لهم لهذا المضيف.
5. انشر سجل SPF من نوع TXT واحدا لكل اسم مضيف، مع السماح بوجود سجلات TXT الأخرى.

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

مثال SMTP المدار من TrekMail:

Type: TXT
Host: @
Value: v=spf1 include:spf.trekmail.net -all
TTL: 3600

مثال توضيحي للجمع بين TrekMail وSMTP خارجي في خطة Nano أو إعداد مختلط:

Type: TXT
Host: @
Value: v=spf1 include:spf.trekmail.net include:amazonses.com -all
TTL: 3600

لا تطبق هذا المثال المركب تلقائيا. اسمح فقط لمزود SMTP الفعلي على نطاق مرسل الظرف الفعلي في MAIL FROM، واتبع تعليماته لإعداد MAIL FROM مخصص. بحسب نموذج المنتج الذي يصفه المصدر، تحتاج Nano إلى مزود SMTP تختاره للبريد الصادر؛ ولا يعني ذلك ضرورة السماح لكل من TrekMail وSES. يذكر المصدر خططا مدفوعة تبدأ من $3.50 شهريا وتشمل SMTP المدار، ويقدم Nano كخطة تبقى مجانية، ويذكر تجربة مجانية للخطط المدفوعة مدتها 14 يوما وتتطلب بطاقة ائتمان. تحقق من العرض والشروط الحالية قبل الاختيار. ولتفاصيل الإعداد، راجع SMTP خارجي من اختيارك (BYO) وSMTP المدار من TrekMail.

نشر السجل والتحقق منه

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

على Mac أو Linux:

dig txt example.com +short

على Windows:

nslookup -type=txt example.com

ينبغي أن ترى قيمة SPF واحدة تبدأ بـ v=spf1، لا قيما مكررة ولا سجلا قديما نسيته منذ انتقال قبل ثلاث سنوات. ويمكن وجود سجلات TXT أخرى لا تتعلق بـ SPF.

فحوص سريعة:

• يبدأ السجل بـ v=spf1
• ينتهي بـ -all بعد حصر جميع المرسلين المصرح لهم واختبارهم
• يشمل المرسلين الذين تستخدمهم فعليا فقط
• يوجد سجل SPF واحد لكل اسم مضيف، لا عدة سجلات

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

أخطاء SPF الشائعة ومسار إصلاحها

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

قاعدتان عمليتان توفران كثيرا من المتاعب:

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

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

متى يمكن أن يسهل TrekMail الإدارة؟

قد يساعد TrekMail عندما تريد إعداد SPF بصورة متسقة لعدة نطاقات. المزايا التي يصفها المصدر تشغيلية: include مركزي للإرسال المدار، ومساحة تخزين مشتركة، وعدم احتساب الرسوم لكل مستخدم، وترحيل IMAP مدمج، والاختيار بين SMTP خارجي وSMTP مدار بحسب الخطة ونموذج الإرسال. تحقق من الإمكانات والشروط الحالية؛ وجود include واحد لا يضمن تكلفة منخفضة للتقييم المتداخل.

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

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

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

الخلاصة: أنشئ بنية SPF تقلل عبء الصيانة

لإنشاء إعداد SPF قابل للاستمرار، فكر في البنية لا في قائمة سماح ضخمة على النطاق الرئيسي. النطاق الرئيسي لمراسلات الموظفين، ونطاقات MAIL FROM فرعية فعلية للمرسلين المتخصصين، وأقل عدد لازم من include. استخدم -all صراحة بعد التحقق من كل مسارات الإرسال المشروعة، وافحص DNS بعد النشر مع مراعاة التخزين المؤقت ومدة TTL ومواءمة DMARC.

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