التحقق من سجل SPF لنطاق

ما هو سجل SPF، ولماذا يحمي نطاقك من الانتحال، وكيف يبدو السجل الصحيح والخاطئ (مع مثال ‎~all‎ مقابل ‎-all‎)، وكيف تصلحه خطوة بخطوة. مع فحص مجاني وفوري لأي نطاق.

أداة مجانية · دون تسجيل

افحص سجل SPF لنطاقك الآن

أدخل نطاقك، وتفحص أداتنا لتحليل مصادقة البريد في ثوانٍ سجل SPF إلى جانب DKIM وDMARC وMX: هل هو موجود، وهل هو صالح، وهل تحمي سياسته من الانتحال. التحليل فوري ولا نخزّن نطاقك.

ما هو سجل SPF؟

SPF (إطار سياسة المُرسِل، المعرّف في RFC 7208) هو سجل TXT تنشره في DNS نطاقك لتعلن عن خوادم البريد المصرّح لها بإرسال الرسائل باسمه. عندما يتلقى خادم مستقبِل رسالة تدّعي أنها من نطاقك، يستعلم سجل SPF ويتحقق مما إذا كان عنوان IP الذي أرسلها ضمن قائمة المُرسِلين المصرّح لهم. يبدأ سجل SPF دائمًا بـ v=spf1 وينتهي بآلية all تحدّد ما يجب فعله مع المُرسِلين غير المدرَجين.

لماذا يهم: يوقف انتحال نطاقك

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

كيف يبدو سجل SPF صحيح وآخر خاطئ

يسرد السجل الصحيح جميع خدمات الإرسال لديك وينتهي بسياسة صارمة:

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

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

أخطاء شائعة تُبطل سجل SPF لديك

إلى جانب +all ونشر سجلَّين، فإن أكثر الأخطاء شيوعًا هو تجاوز حدّ الـ 10 استعلامات DNS: كل include أو a أو mx أو redirect يُحتسب، وبتجاوز العشرة يُرجع SPF خطأ PermError ويتوقف عن التحقق. ادمج عناصر include غير الضرورية. تذكّر أيضًا أن SPF وحده لا يحمي العنوان الظاهر (حقل "من:" الذي يراه المستلِم): فهو يتحقق من نطاق المغلّف (Return-Path). لذلك يجب أن يقترن SPF دائمًا بـ DMARC الذي يوائم ويحمي المُرسِل الظاهر.

كيف تُعِدّ أو تُصلح سجل SPF خطوة بخطوة

1. احصر كل خدمة تُرسل البريد باسم نطاقك: مزوّد صناديق البريد (Google Workspace وMicrosoft 365)، ومنصة التسويق، ونظام CRM، والفوترة، وغيرها.
2. أنشئ سجل TXT واحدًا فقط على النطاق الجذر يشملها جميعًا، مثل v=spf1 include:_spf.google.com include:sendgrid.net ~all.
3. انشره في DNS وانتظر الانتشار (من دقائق إلى بضع ساعات).
4. تحقّق من أنه يُحَلّ، ولا يتجاوز 10 استعلامات، ولا توجد سجلات مكررة.
5. عندما تتأكد من عدم نقص أي مُرسِل، شدّد السياسة من ~all إلى -all.
يمكنك التحقق من كل خطوة عبر أداتنا المجانية.

أسئلة شائعة حول SPF

كيف أتحقق من سجل SPF لنطاقي؟

أدخل نطاقك في أداتنا المجانية: نستعلم DNS العام ونخبرك فورًا بما إذا كان هناك سجل SPF، وما إذا كان صالحًا، وما إذا كانت سياسته تحمي من الانتحال، إلى جانب DKIM وDMARC وMX.

ما الفرق بين ‎~all‎ و‎-all‎ في SPF؟

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

هل يكفي SPF لحمايتي من الانتحال؟

لا. يتحقق SPF من نطاق المغلّف التقني، لكنه لا يتحقق من العنوان الظاهر الذي يراه المستلِم. للحماية الفعلية عليك دمجه مع DKIM، وقبل كل شيء مع DMARC الذي يوائم ويحمي المُرسِل الظاهر لرسائلك.

لماذا يُرجع SPF لدي خطأ PermError؟

السبب الأكثر شيوعًا هو تجاوز حدّ الـ 10 استعلامات DNS (كل include أو a أو mx أو redirect يُحتسب) أو نشر سجلَّي SPF على النطاق نفسه. ادمج عناصر include غير الضرورية واحتفظ بسجل TXT واحد يبدأ بـ v=spf1.

المصادر والمراجع

آخر تحديث: يوليو 2026 · محتوى معلوماتي؛ لا يُعد استشارة.

واصل التعلّم

راقب مصادقة بريدك باستمرار

سجّل مجانًا في OCIRIA Security واحصل على تنبيهات عندما يتغيّر SPF أو DKIM أو DMARC أو يتوقّف عن حماية نطاقك.

سجّل مجانًا تحدّث معنا