انتقل إلى المحتوى الرئيسي
MailLand

دليل: المصادقة

كيف تُعد SPF

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

آخر مراجعة: 4 نوفمبر 2026

ما الذي يتحقق منه SPF

إطار سياسة المرسل SPF (المعيار RFC 7208) سجل TXT على نطاقك يذكر الخوادم المسموح لها بإرسال البريد باسمه. عند وصول رسالة، يقرأ الخادم المستقبِل سجل نطاق مرسل المغلف (أمر MAIL FROM في SMTP، ويسمى أيضًا Return-Path) ويقارنه بعنوان IP الذي اتصل به.

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

سجل واحد لكل المرسلين

لا يجوز للنطاق أن ينشر أكثر من سجل SPF واحد. فوجود سجلين يبدأ كل منهما بـ v=spf1 يُفشل التحقق بخطأ دائم، لذا عند إضافة خدمة جديدة أضف include الخاص بها إلى السجل الموجود بدل إنشاء سجل ثانٍ.

يبدأ السجل بـ v=spf1، ويذكر الآليات، وينتهي عادة بآلية all التي تحدد ما يُفعل بكل المرسلين الآخرين. المثال أدناه توضيحي فقط: يحتفظ بمزود قائم (استبدل _spf.example.com بقيمة include الخاصة بمزودك) ويضيف Mail.Land.

  • تضيف include:domain الخوادم التي يأذن بها نطاق آخر، وهي الطريقة المعتادة لإضافة خدمة بريد.
  • تذكر ip4: وip6: عناوينك أو نطاقاتك مباشرة.
  • تأذن a وmx للمضيفين الواردين في سجلات A أو MX لنطاقك.
  • تَسِم ~all (soft fail) المرسلين الآخرين بأنهم مشبوهون، وتقول -all (fail) إنهم غير مسموح لهم. لا تُنهِ السجل أبدًا بـ +all التي تسمح لأي أحد بالإرسال.
TXT @
v=spf1 include:_spf.example.com include:spf.mlnd.net ~all

ابقَ ضمن حد الاستعلامات

تُحتسب كل من آليات include وa وmx وptr وexists والمعدِّل redirect ضمن حد قدره 10 مصطلحات تتطلب استعلام DNS في كل تقييم، وتُحتسب كذلك المصطلحات الموجودة داخل السجل المضمَّن. وما زاد على هذا الحد يعطي خطأ دائمًا ويعامل المستقبِلون السجل على أنه معطل.

احذف الخدمات التي لم تعد تستخدمها، وفضّل نطاقات ip4 أو ip6 لخوادمك، وتجنب آلية ptr التي يطلب المعيار عدم استخدامها.

تحقق من النتيجة

بعد النشر أرسل رسالة إلى صندوق بريد تملكه واقرأ ترويسة Authentication-Results، فهي تعرض spf=pass أو fail أو softfail أو neutral أو none أو permerror أو temperror، والنطاق الذي جرى التحقق منه.

كثيرًا ما تُفشل إعادة التوجيه SPF لأن الخادم الذي يعيد التوجيه ليس في سجلك. هذا متوقع، أما DKIM فيصمد عادة أمام إعادة التوجيه التي لا تغيّر المحتوى الموقَّع، وهذا من أسباب نشر الاثنين معًا.

ما يطلبه مزودو صناديق البريد

تطلب Google من كل مرسل إعداد SPF أو DKIM، ومن الذين يرسلون قرابة 5,000 رسالة أو أكثر يوميًا إلى حسابات Gmail الشخصية إعداد SPF وDKIM وDMARC. وتطلب Yahoo من المرسلين بالجملة تطبيق SPF وDKIM معًا. نشر الاثنين هو الخيار الآمن لأي نطاق يرسل البريد.

كيف تتعامل Mail.Land مع SPF

أضف include:spf.mlnd.net إلى سجل SPF الوحيد لنطاق الإرسال، قبل آلية all. يجب التحقق من SPF وDKIM وDMARC جميعًا قبل أن يتمكن النطاق من الإرسال.

تحصل النطاقات الجديدة أيضًا على Return-Path خاص: سجل CNAME من bounce.yourdomain إلى bounce.mlnd.net. وبعد التحقق من هذا السجل يصبح نطاق المغلف نطاقًا فرعيًا تملكه ويتحاذى SPF مع نطاق From لديك بالمحاذاة relaxed، وهي القيمة الافتراضية في DMARC، وإلى أن يحدث ذلك تستخدم Mail.Land مسار Return-Path الافتراضي الخاص بها. أبقِ السجل في DNS فقط (من دون وكيل)، وإلا فلن تراه خوادم البريد.

إعداد DNS في توثيق Mail.Land

المصادر

  1. RFC 7208، Sender Policy Framework (SPF) (تاريخ الاطلاع 4 نوفمبر 2026)
  2. Google، إرشادات مرسلي البريد الإلكتروني (تاريخ الاطلاع 4 نوفمبر 2026)
  3. Yahoo، أفضل الممارسات للمرسلين (تاريخ الاطلاع 4 نوفمبر 2026)

ضعه موضع التطبيق

أضف نطاقك إلى Mail.Land، وستعرض لوحة التحكم بالضبط سجلات SPF وDKIM وDMARC التي عليك نشرها.

ابدأ مجاناً