سجلّ SPF لـ Google Workspace وSendGrid ومزوّدين آخرين: كيف تدمجهم بأمان

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

SPF في دقيقة

SPF (Sender Policy Framework، RFC 7208) سجلّ DNS من نوع TXT يسرد الخوادم المسموح لها بإرسال البريد باسم نطاقك. يفحص المستقبِلون عنوان IP المتصل مقابله. السجلّ البسيط يبدو هكذا:

v=spf1 ip4:203.0.113.10 include:_spf.google.com ~all

العنصر	المعنى	هل يُحتسب ضمن حدّ 10؟
v=spf1	وسم الإصدار، يجب أن يأتي أولًا	لا
ip4: / ip6:	يصرّح بعنوان IP أو نطاق CIDR	لا
a وmx	يصرّح بمضيفات A أو MX للنطاق	نعم
include:domain	يقبل أيضًا ما يقبله SPF لذلك النطاق	نعم (مع كل ما تحته من تداخل)
exists: وptr	آليات متقدمة / لا يُنصح بها	نعم
redirect=	يستخدم سجلّ نطاق آخر بدل هذا	نعم
~all	فشل ناعم لكل ما عداه	لا
-all	فشل صارم لكل ما عداه	لا

يحدّد المؤهِّل أمام العنصر النتيجة: + نجاح (الافتراضي)، - فشل، ~ فشل ناعم، ? محايد. تُقيَّم العناصر من اليسار إلى اليمين، ويُتجاهل كل ما بعد all.

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

يجوز للنطاق نشر سجلّ واحد فقط يبدأ بـ v=spf1. ينصّ RFC 7208 على أنه إن أعاد DNS أكثر من سجلّ فالنتيجة permerror ويفشل SPF لكل رسالة. يحدث هذا عادة حين يقول دليل إعداد مزوّد ثانٍ «أضف سجلّ TXT هذا» فتضيفه بجوار الموجود.

# WRONG: two SPF records
example.com. TXT "v=spf1 include:_spf.google.com ~all"
example.com. TXT "v=spf1 include:sendgrid.net ~all"

# RIGHT: one merged record
example.com. TXT "v=spf1 include:_spf.google.com include:sendgrid.net ~all"

قيم include الشائعة وتكلفتها الفعلية

قيم include هي التي يوثّقها المزوّدون اليوم؛ تحقّق دائمًا من صفحة مساعدة المزوّد لأنها قد تتغيّر. أما عمود التكلفة فهو ما قسناه بحلّ كل سجلّ وكل ما بداخله من تداخل في 2026-10-13 عبر DNS عام. تتحرّك هذه الأرقام حين يعيد مزوّد تنظيم سجلّه، فأعد القياس قبل الاعتماد عليها.

المزوّد	include	الاستعلامات التي يضيفها	ما بداخله
Google Workspace	include:_spf.google.com	1	نطاقات IP فقط (مسطَّحة)
Microsoft 365	include:spf.protection.outlook.com	1	نطاقات IP فقط
SendGrid	include:sendgrid.net	2	نطاقات IP + include:ab.sendgrid.net
Mailchimp / Mandrill	include:servers.mcsv.net	1	نطاقات IP فقط
Amazon SES	include:amazonses.com	1	نطاقات IP فقط
Mailgun	include:mailgun.org	5	includeان متداخلان، أحدهما يحوي اثنين آخرين
Postmark	include:spf.mtasv.net	1	نطاقات IP فقط
Brevo	include:spf.brevo.com	1	نطاقات IP فقط

أمران يلفتان النظر. أولًا، النصيحة القديمة «Google تكلّف أربعة استعلامات» لم تعد صحيحة: سجلّها قائمة مسطّحة من نطاقات IP. ثانيًا، قد يستهلك مزوّد واحد (Mailgun في هذه اللقطة) نصف ميزانيتك وحده، فيستحق فحص تكلفة كل include قبل إضافته.

🛠️مولّد سجل SPFسجل SPF بترتيب صحيح مع عدّ أدنى للاستعلامات (حد 10) وتقسيم النصوص الطويلةافتح الأداة →

مثال عملي: عدّ الاستعلامات لمجموعة نموذجية

شركة تستخدم Microsoft 365 لبريد الموظفين وMailchimp للنشرات وSendGrid لبريد التطبيق المعاملاتي وAmazon SES احتياطًا. السجلّ المدمج:

v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net include:sendgrid.net include:amazonses.com ~all

العنصر	الاستعلامات
include:spf.protection.outlook.com	1
include:servers.mcsv.net	1
include:sendgrid.net (+ ab.sendgrid.net)	2
include:amazonses.com	1
المجموع	5 من 10

خمسة استعلامات تترك مساحة لـ CRM ومكتب دعم. لو استبدلت الشركة نفسها SendGrid بـ Mailgun لقفز المجموع إلى 8، ولهذا يجب أن تعدّ قبل إضافة الخدمة التالية. وقد تقترب السجلّات الحقيقية من الحدّ: السجلّ العام لشركة كبيرة لاستضافة الشيفرة، حُلّ في اليوم نفسه، يستخدم 10 بالضبط.

انتبه لحدّ 10 استعلامات

ينصّ RFC 7208 في §4.6.4 على أنه يجب (MUST) أن تحدّ التنفيذات إجمالي العناصر التي تستعلم عن DNS بـ 10، وأن تجاوزه ينتج permerror. ويحدّ أيضًا تقييم mx بـ 10 سجلّات عنوان لكل اسم MX، ويقول إن على التنفيذات (SHOULD) أن تحدّ الاستعلامات الفارغة (التي لا تعيد شيئًا) باثنين. للبقاء دون الحدّ:

• عُدّ بأداة لا بالعين؛ فأداة الفحص تمشي على الشجرة كلها.
• أزل المزوّدين الذين لم تعد تستخدمهم. الـ includes القديمة أشيع أسباب التجاوز.
• استخدم نطاقات فرعية مخصّصة: أرسل الحملات من news.example.com وامنح ذلك النطاق الفرعي سجلّ SPF خاصًا وميزانية 10 استعلامات خاصة به.
• فضّل ip4/ip6 للبنية الثابتة التي تتحكم بها لأنها لا تكلّف استعلامات.
• احذر من التسطيح (flattening). نسخ نطاقات IP لمزوّد إلى سجلّك يزيل الاستعلامات لكنه يتقادم بصمت حين يغيّر المزوّد نطاقاته؛ أتمتْه أو تجنّبه.

اقرأ التفاصيل في دليل حدّ استعلامات SPF.

استراتيجية النطاقات الفرعية التي تُبقي كل ميزانية صغيرة

إن بدأ السجلّ المسطّح الواحد يزدحم فقسّم بحسب الغرض وامنح كل تدفق نطاقه الفرعي وسجلّه، مثل example.com لبريد الموظفين وnews.example.com للنشرات وapp.example.com للبريد المعاملاتي من منتجك. يحصل كل نطاق فرعي على ميزانية 10 استعلامات خاصة به، وسمعة أنظف (مشكلة في تدفق النشرات لم تعد تسحب بريد الموظفين معها)، وأثر تدقيق أسهل في تقارير DMARC. الثمن أن عنوان From الظاهر يجب أن يستخدم النطاق الفرعي المطابق لمطابقة DMARC، وأن لكل نطاق فرعي إعداد DKIM وDMARC خاصًا به.

خطوة بخطوة: ابنِ السجلّ المدمج وانشره

1. أحصِ كل مرسِل يستخدم نطاقك: صناديق الموظفين وأدوات التسويق وCRM والفوترة والدعم ونماذج الموقع والخوادم.
2. ابنِ السجلّ بالمولّد؛ يرتّب عناوين IP أولًا ثم a/mx ثم الـ includes، وينتهي بقاعدة all واحدة.
3. استبدل سجلّ SPF TXT الحالي في DNS؛ لا تضف سجلًّا ثانيًا.
4. انتظر انتشار DNS (غالبًا دقائق، حتى TTL سجلّك) وأعد تشغيل الفحص.
5. أرسل رسائل اختبار من كل منصّة وافحص Authentication-Results بحثًا عن spf=pass (انظر كيف تقرأ رؤوس البريد).

🛡️فاحص SPF وDKIM وDMARCSPF تكراري مع حد الـ 10 استعلامات ومفاتيح DKIM وسياسة DMARCافتح الأداة →

فحص سريع بسطر الأوامر لما يراه العالم:

dig +short TXT example.com | grep -i "v=spf1"
# exactly one line expected; two lines = permerror

من ~all إلى -all: طرح آمن

يخبر ~all (فشل ناعم) المستقبِلين أن البريد من مصادر غير مدرجة مشبوه لكن قد يُسلَّم. ويطلب -all (فشل صارم) رفضه. ابدأ بـ ~all بينما تكتشف المرسِلين المنسيين. ادمج ذلك مع تقارير DMARC المجمّعة لترى كل مصدر يرسل باسم نطاقك، وبعدها فقط انتقل إلى -all. لا تنشر +all أبدًا؛ فهو يصرّح للإنترنت كله. وتذكّر أن SPF في قواعد Gmail وYahoo للمرسِلين بالجملة نصف الحكاية فقط: DKIM ومطابقة DMARC مهمّان أيضًا (انظر قائمة المتطلبات).

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

العَرَض	السبب المحتمل	الحل
permerror	سجلّان SPF، أو أكثر من 10 استعلامات، أو خطأ صياغة	ادمج في سجلّ واحد، وقلّل الاستعلامات، وتحقّق من الصياغة
softfail من مرسِل مشروع	المزوّد غير مضمَّن	أضف include المزوّد
SPF ينجح لكن DMARC يفشل	المزوّد يستخدم نطاق ظرف خاصًا به (لا مطابقة)	اضبط return-path مخصّصًا أو اعتمد على DKIM مطابق
none	لا سجلّ على نطاق الظرف	انشر سجلًّا على النطاق الدقيق المستخدم في MAIL FROM
يعمل مع بعض المستقبِلين ويفشل مع آخرين	السجلّ أطول من أن تتسع له استجابة DNS واحدة، أو الاستعلامات قرب الحدّ	اختصر، ووزّع المصادر على نطاقات فرعية

أسئلة شائعة

هل يمكن أن يكون لدي سجلّان SPF على نطاق واحد؟

لا. سجلّان v=spf1 على الاسم نفسه يسبّبان permerror. ادمج كل المرسِلين المصرَّح لهم في سجلّ واحد.

كيف أضيف SendGrid إلى سجلّ SPF موجود لـ Google Workspace؟

عدّل السجلّ الحالي وأضف include:sendgrid.net قبل عنصر all الأخير ليصبح v=spf1 include:_spf.google.com include:sendgrid.net ~all.

كم include يمكن أن يحوي سجلّ SPF؟

الحدّ هو 10 عناصر تستعلم عن DNS في المجموع بما فيها المتداخلة، وليس عددًا ثابتًا من الـ includes. بعض المزوّدين يكلّف عدة استعلامات لكل منهم.

هل أستخدم ~all أم -all؟

ابدأ بـ ~all أثناء تدقيق مرسِليك وانتقل إلى -all حين تتأكد أن كل مصدر مشروع مدرج. اقرنه بمراقبة DMARC.

هل ترث النطاقات الفرعية سجلّ SPF؟

لا. يُقيَّم SPF للنطاق الدقيق في مرسِل الظرف، فيحتاج كل نطاق فرعي مُرسِل إلى سجلّه الخاص.

المراجع ومزيد من القراءة

1. RFC 7208 — Sender Policy Framework (SPF)
2. Google Workspace — Set up SPF
3. Twilio SendGrid — Domain authentication
4. Google — Email sender guidelines