Defaults.Exposed › الإصلاحات › SPF (إطار سياسة المُرسِل)

كيف تُصلح SPF (إطار سياسة المُرسِل)

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

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

ماذا قد يكلّفك هذا

يرسل محتال إلى عميلك فاتورة 'منك' تحمل تفاصيل حسابه المصرفي، فيدفع له العميل. لا تكتشف الأمر إلا بعد أسابيع حين يسأل العميل عن بضاعته — وأصبح الأمر الآن يمسّ سمعتك، وربما مسؤوليتك القانونية.
تقع عروض أسعارك وفواتيرك وردودك بهدوء في مجلدات البريد غير المرغوب فيه لدى عملائك لأن مزوّدي الخدمة الكبار لا يستطيعون التحقق من أنها صادرة منك فعلاً. تَبرُد الصفقات ولا تعرف السبب أبداً.
ينتحل محتال هوية صاحب العمل أو مسؤول الشؤون المالية ويرسل إلى الموظفين طلباً عاجلاً بالدفع أو ببطاقات هدايا — تبدو الرسالة فعلاً وكأنها صادرة من نطاقك، فيدفع أحدهم.
تتفحّص جهة تقنية أو أمنية لدى عميل محتمل أكبر نطاقَك، فترى غياب حماية المُرسِل، فإمّا تستبعدك أو تشترط عليك إصلاح الأمر قبل التوقيع — مما يكلّفك الصفقة أو أسابيع من التأخير.
تظن أنك محمي لأن سجل SPF موجود — لكنه مضبوط على 'الفشل الميّن' (soft fail) دون أي شيء يفرضه، أو أنه معطوب بصمت، فيمرّ البريد المنتحَل رغم ذلك.

لماذا يهمّ. تزييف عنوان المُرسِل في البريد الإلكتروني سهل للغاية ولا يكلّف المهاجم شيئاً. SPF هو أرخص وأسرع وسيلة لجعل انتحال نطاقك أصعب وللحفاظ على وصول بريدك المشروع بعيداً عن مجلد الرسائل غير المرغوب فيها. تقوم Google وYahoo الآن بشكل فعّال بحظر أو رفض البريد الصادر من نطاقات غير مُصادَق عليها، فلم يعد هذا اختيارياً — بل هو الحدّ الأدنى لمجرّد إيصال بريدك أصلاً.

الخلاصة المختصرة

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

SPF (إطار سياسة المُرسِل) هو الحلّ. إنه سطر نصّي واحد في إعدادات نطاقك يحدد خدمات البريد المسموح لها فعلاً بالإرسال باسمك. يتحقق مزوّدو البريد المستقبِلون — Gmail وOutlook والجميع — من هذه القائمة قبل أن يقرّروا ما إذا كانت الرسالة حقيقية. لا قائمة، أو قائمة ضعيفة، فلا يوجد لديهم ما يستندون إليه.

تتناول هذه الصفحة أمرين لا بد أن يكونا صحيحين معاً: هل يوجد سجل SPF أصلاً، وهل هو مضبوط بصرامة كافية ليؤدي عمله فعلاً.

ما قد يكلّفك هذا

هذه هي الطرق اليومية الواقعية التي يتحوّل بها غياب سجل SPF أو ضعفه إلى أموال وثقة تخرج من الباب. نحن لا نذكر أبداً نشاطاً تجارياً حقيقياً — هذه أنماط نراها عبر البيانات.

إعادة توجيه الفاتورة. يرسل مجرم إلى أحد عملائك بريداً يبدو تماماً وكأنه صادر منك، مرفقاً به فاتورة تبدو حقيقية تحمل حسابه المصرفي. يدفعها عميلك. وأول ما تسمعه هو مطالبة تسأل عن مكان الطلب. والآن لديك عميل غاضب، ودفعة ذهبت إلى مجرم، ومحادثة صعبة حول من يتحمّل الخسارة.
احتيال المدير التنفيذي / الشؤون المالية. يرسل أحدهم بريداً إلى محاسبك ‘من’ المالك: “خدمة سريعة — هل يمكنك تمرير هذه الدفعة قبل نهاية اليوم؟” ولأن الرسالة تبدو فعلاً صادرة من نطاقك، فإنها لا تُثير شكوك أحد. وتخرج الأموال من الشركة.
ضريبة التسليم الصامتة. تبدأ عروض أسعارك وفواتيرك بالوقوع في مجلدات البريد غير المرغوب فيه لدى عملائك لأن Gmail وYahoo لا يستطيعان التحقق من أنها صادرة منك فعلاً. لا يصلك ارتداد، ولا تصلك رسالة خطأ — تخفت الصفقات فحسب. أنت تخسر أعمالاً ولا تستطيع حتى رؤية ذلك يحدث.
العقد المفقود. يُجري فريق المشتريات أو الأمن لدى عميل أكبر فحصاً أساسياً على نطاقك ضمن إجراءات التعاقد. يرون غياب مصادقة المُرسِل فيصنّفونك كخطر. في أفضل الأحوال، تهرع لإصلاحه تحت ضغط المواعيد؛ وفي أسوأها، يختارون منافساً اجتاز الفحص.
موجة تسميم العلامة التجارية. يُستخدم نطاقك في حملة تصيّد موجّهة للجمهور. الأشخاص الذين تضرّروا أصبحوا الآن لا يثقون بأي بريد يحمل اسمك — فحتى عروضك وتجديداتك الحقيقية تُتجاهل أو يُبلَّغ عنها.

الخيط الجامع لكل هذا: لا ينفق المهاجم شيئاً، ويتحمّل نشاطك التجاري التكلفة واللوم.

ما هو فعلاً

حين يصل بريد إلكتروني، يريد الخادم المستقبِل معرفة أمر واحد: هل هذا صادر فعلاً من الجهة التي يدّعي أنه صادر منها؟ يُجيب SPF عن جزء من هذا السؤال.

تنشر سطراً نصّياً قصيراً في إعدادات DNS لنطاقك — “سجل TXT” — يُسمّي خدمات البريد المسموح لها بالإرسال نيابة عنك. شيء من قبيل:

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

بعبارة بسيطة، يُقرأ هذا: “بريدنا الحقيقي يأتي من خوادم Google وخوادم SendGrid — ارفض أي شيء آخر يدّعي أنه منّا.”

الجزآن المهمّان لدرجتك:

هل السجل موجود؟ هذا هو الأهمّ (إذ يحمل أكبر وزن بين أي فحص بريد مفرد). غياب السجل يعني عدم وجود قائمة يتحقق منها المستقبِلون، فيكون باب الانتحال مفتوحاً على مصراعيه. وهناك أيضاً نمط فشل خفي هنا: إذا كان لنطاقك سجلّا SPF أو أكثر، فإن القواعد تقضي بأن جميعها باطلة — فلا يكون لديك SPF فعلياً على الإطلاق، رغم أنه يبدو موجوداً.
هل السياسة صارمة بما يكفي؟ قد يوجد السجل لكنه يبقى بلا أنياب. النهاية — آلية “all” — هي التعليمات الموجَّهة للمستقبِلين:
- -all (الفشل الصارم) — ارفض أي شيء غير مُدرَج في القائمة. الأقوى. الدرجة الكاملة.
- ~all (الفشل الميّن) + DMARC مضبوط على reject — الإعداد الحديث الموصى به. حماية مكافئة للفشل الصارم، دون مخاطرة ارتداد البريد المشروع المُعاد توجيهه. الدرجة الكاملة.
- ~all + DMARC مضبوط على quarantine — مقبول، أضعف قليلاً؛ انقل DMARC إلى reject للحصول على الحماية الكاملة.
- ~all وحده (دون فرض من DMARC) — ضعيف. يقول “على الأرجح مزيّف، سلّمه رغم ذلك”. لا يزال البريد المنتحَل يمرّ. هذا هو الفخّ الذي تقع فيه كثير من الأنشطة التجارية ظنّاً منها أنها محمية.
- ?all (محايد) — لا يوفّر أي حماية.
- +all — خطير بشكل فعّال: يُخبر العالم بأن أي شخص يمكنه الإرسال باسمك. لا تستخدم هذا أبداً.

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

كيف يبدو “الجيد”: سجل SPF واحد بالضبط، يُدرِج كل خدمة ترسل بريداً مشروعاً باسمك، ينتهي بـ -all (أو ~all مقترناً بـ DMARC على p=reject)، ويبقى بأريحية تحت حدّ الـ 10 عمليات بحث.

كيفية الإصلاح (مجاناً، ~10 دقائق)

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

الخطوة 1 — أدرِج كل خدمة ترسل بريداً باسمك. هذا هو الجزء الذي يُخطئ فيه الناس. اكتبها جميعاً: مزوّد صندوق بريدك (Google Workspace، Microsoft 365، إلخ)، بالإضافة إلى أي أداة نشرة بريدية، ونظام إدارة علاقات العملاء، ومكتب المساعدة، ومنصة التجارة الإلكترونية، وتطبيق الفوترة/المحاسبة، ونظام الحجوزات. إذا كانت خدمة ما ترسل بريداً يحمل اسمك ونسيتها، فسيحجب SPF بريدها عند تشديد السياسة.

الخطوة 2 — انشر سجل TXT واحداً عند نطاقك الجذري. ادمج أسطر “include” لجميع مُرسِليك في سجل واحد. حسب المنصة الشائعة:

Google Workspace: include:_spf.google.com
Microsoft 365: include:spf.protection.outlook.com
SendGrid: include:sendgrid.net
Mailchimp: include:servers.mcsv.net
Zoho: include:zoho.eu (أو النطاق المناسب لمنطقتك)

يبدو السجل المدموج هكذا:

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

أين تضيفه، حسب المزوّد:

Cloudflare: DNS ← Records ← Add record ← النوع TXT، الاسم @، المحتوى = القيمة أعلاه.
Microsoft 365 / لوحة إدارة Google: يقدّمان لك سلسلة الـ include الدقيقة المطلوب استخدامها في معالج الإعداد لديهما؛ انسخها إلى سجل TXT لدى مضيف DNS الخاص بك.
GoDaddy / Blacknight / معظم المضيفين: إدارة DNS ← Add ← TXT، المضيف/الاسم @، القيمة = السجل.

الخطوة 3 — ابدأ آمناً، ثم افرِض. بينما تتأكد من اكتمال قائمة مُرسِليك، انشر بـ ~all (الفشل الميّن) حتى لا يُحجب أي بريد مشروع بالخطأ. وبمجرد تأكدك من أن كل بريدك الحقيقي لا يزال يتدفّق، شدّد إلى -all (الفشل الصارم) — أو، الأفضل، أبقِ ~all وأضف سياسة DMARC قيمتها p=reject، وهو الاقتران الحديث الموصى به.

الخطوة 4 — تأكد من وجود سجل واحد فقط بالضبط. إذا كان هناك سجل SPF قديم موجود بالفعل، فحرّر ذلك السجل بدلاً من إضافة ثانٍ. سجلّا v=spf1 يلغيان بعضهما البعض ويتركانك بلا حماية.

الخطوة 5 — راقِب عدد عمليات البحث. إذا كان لديك العديد من المُرسِلين، فقد تتجاوز حدّ الـ 10 عمليات بحث. إذا حدث ذلك، فقم بالتوحيد — يقدّم بعض المزوّدين “تسطيح SPF” (SPF flattening)، أو احذف المُرسِلين الذين لم تعد تستخدمهم.

الخطوة 6 — أعِد فحص نطاقك للتأكد من أنه يجتاز الفحص الآن، بوجود السجل وصرامة السياسة.

الأخطاء الشائعة

سجلَّا SPF. أكثر أنماط الفشل الصامت شيوعاً. إضافة سجل جديد بدلاً من تحرير السجل الموجود تُبطل كليهما. لا بد من وجود سجل واحد بالضبط.
التوقف عند ~all وافتراض أنك انتهيت. الفشل الميّن دون DMARC خلفه هو المنطقة الوسطى الضعيفة — يبدو مُعدّاً لكنه بالكاد يحميك. إمّا أن تنتقل إلى -all، أو أن تقرن ~all بـ DMARC على p=reject.
نسيان مُرسِل. التشديد إلى -all قبل إدراج تطبيق الفوترة أو نظام إدارة علاقات العملاء أو أداة النشرة البريدية سيبدأ بحجب بريدك المشروع. أدرِج كل شيء أولاً.
تجاوز حدّ الـ 10 عمليات بحث. كل include: قد يتسلسل إلى مزيد من عمليات البحث. أكثِر منها فيُعامَل السجل كأنه معطوب. أبقِه خفيفاً.
استخدام +all. هذا يُصرّح صراحةً للإنترنت بأكمله بالإرسال باسمك. إنه أسوأ من عدم وجود سجل أصلاً. لا تنشره أبداً.

أين يندرج هذا

SPF هو الأساس، لكنه واحد من ثلاث طبقات. DKIM يضيف توقيعاً تشفيرياً يثبت أن الرسالة لم تُعبَث بها، وDMARC هو التعليمة التي تربط SPF وDKIM معاً وتُخبر المستقبِلين بما يجب فعله فعلاً بالبريد الذي يفشل — بما في ذلك حظر انتحال اسم المُرسِل الظاهر الذي يراه عملاؤك. اضبط SPF أولاً بشكل صحيح (فهو الفوز الأسرع ويحمل الوزن الأكبر)، ثم أضف DKIM وDMARC لإغلاق الباب بالكامل. الإصلاحات الثلاثة جميعها مجانية.

أعدّه على مُضيفك

خطوة بخطوة لدى المزوّدين الشائعين:

الأسئلة الشائعة

لستُ شخصاً تقنياً — هل يمكنني التعامل مع هذا بنفسي؟

لستَ بحاجة لفهم التفاصيل. التغيير عبارة عن سطر أو سطرين يُضافان إلى إعدادات نطاقك، يتولّاه من يدير موقعك الإلكتروني أو مزوّد خدمتك التقنية. سلّمهم قسم 'كيفية الإصلاح' أدناه — يستغرق الأمر عادة بضع دقائق، وهو مجاني. نحن نتقاضى رسوماً فقط مقابل مراقبة بقائه صحيحاً بمرور الوقت.

لدينا بالفعل سجل SPF — أليس هذا يعني أننا محميون؟

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

هل سيُعطّل إصلاح هذا بريدي الخاص بالخطأ؟

قد يحدث ذلك إذا أغفل السجل مُرسِلاً مشروعاً — مثل تطبيق الفوترة أو أداة النشرة البريدية التي ترسل البريد باسمك. ولهذا السبب بالضبط، فإن النهج الآمن هو إدراج كل خدمة ترسل بريداً باسمك أولاً، ثم النشر بـ '~all' الميّن بينما تتأكد من عدم إغفال أي شيء، ثم التشديد إلى الفشل الصارم. بهذا الترتيب لن يتعطّل شيء.

ما الفرق بين '~all' و'-all'، وأيّهما ينبغي أن نستخدم؟

'-all' (الفشل الصارم) يُخبر المستقبِلين برفض أي شيء غير مُدرَج في قائمتك — وهو الإعداد الأقوى. أمّا '~all' (الفشل الميّن) فيقول 'على الأرجح غير مشروع، لكن اقبله رغم ذلك'. التوصية الحديثة الأفضل هي '~all' مقترناً بسياسة DMARC قيمتها 'reject' — هذا الاقتران يمنحك الحماية نفسها التي يمنحها '-all' دون مخاطرة ارتداد البريد المُعاد توجيهه. أمّا '~all' وحده، دون DMARC يفرضه، فهو الإعداد الضعيف الذي ينبغي تجنّبه.

هل سيوقف SPF كل انتحال البريد بمفرده؟

لا — إنه الطبقة الأولى الأساسية، وليس الحلّ الكامل. يحدد SPF أيّ الخوادم يمكنها الإرسال نيابة عنك، لكنه لا يُخبر المستقبِلين بما يجب فعله عند فشل الرسالة، ولا يغطّي اسم المُرسِل الظاهر الذي يراه المستخدم. لإحكام إغلاق باب الانتحال بالكامل تحتاج أيضاً إلى DKIM وDMARC. SPF هو الخطوة الأولى الأسرع والأعلى أثراً، فابدأ هنا، ثم أضف الاثنين الآخرين.

كم يستغرق سريان المفعول، وهل قد يكلّف شيئاً؟

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