إذا كنت تدير خادم بريد خاصًا بك، فسيصلك عاجلًا أو آجلًا بريد مرتد من Outlook.com يحوّله إليك أحد المستخدمين، وينتهي بالعبارة 550 5.7.515 Access denied, sending domain [yourdomain] does not meet the required authentication level. بعدها يقترح أحدهم تعديل سجل SPF، ويريد آخر إضافة خادم ترحيل، وخلال ساعة يكون ثلاثة أشخاص يعدّلون DNS لنطاق تعتمد عليه كل صناديق البريد في الشركة.
تمهّل أولًا. في هذا المقال ما نفحصه، وبأي ترتيب، قبل أن نلمس أي سجل. الخبرة هنا من تشغيلنا للبريد الصادر الخاص بنطاق fanpino.com، ومن نشر لبريد جامعة يضم 10,000 صندوق، ومن حالة واحدة تبيّن فيها أن التشخيص البديهي كان خاطئًا.
ما الذي تطلبه Microsoft فعلًا
نشرت Microsoft قواعدها الخاصة بخدمات Outlook.com وHotmail وLive وMSN في تدوينة على مدونة Defender for Office 365 في أبريل 2025. النطاقات التي ترسل أكثر من 5,000 رسالة يوميًا إلى هذه العناوين الاستهلاكية يجب أن تنجح في SPF وفي DKIM، وأن يكون لديها سجل DMARC بسياسة p=none على الأقل، ينجح عبر نتيجة SPF أو DKIM متطابقة مع النطاق. ابتداءً من 5 مايو 2025 صارت الرسائل المخالفة تذهب إلى مجلد البريد غير الهام، ثم جاء الرفض الصريح برمز 5.7.515 لاحقًا، وهو الارتداد الذي يراه الناس الآن.
تفصيلان يوقعان من يستضيفون بريدهم بأنفسهم. الأول أن حد الـ 5,000 يُحسب لكل نطاق في حقل From، ومع ذلك يذكر كثير من المسؤولين على Microsoft Q&A أنهم تلقّوا الخطأ وهم يرسلون بضع عشرات من الرسائل يوميًا، فلا تفترض أنك مستثنى لأن حجمك صغير. والثاني أن «التطابق» (alignment) يعني أن النطاق الذي نجح في SPF أو DKIM يجب أن يطابق النطاق الظاهر في ترويسة From. نجاح SPF للنطاق bounces.some-relay.net لا يفيد شيئًا لرسالة عنوان مرسلها على yourdomain.com.
الخطوة 1: احصل على الترويسة الحقيقية لا على نص الارتداد
رسالة الارتداد تخبرك أن Outlook غير راضٍ، لكنها لا تخبرك أي فحص فشل. لذلك، قبل أي شيء آخر، أرسل رسالة واحدة من الخادم المعني إلى صندوق تملكه على Gmail أو Outlook.com، وافتح المصدر الأصلي للرسالة ("Show original" في Gmail، و"View message source" في Outlook.com)، وابحث عن سطر Authentication-Results. المطلوب أن ترى النتائج الثلاث:
spf=pass smtp.mailfrom=yourdomain.com
dkim=pass header.d=yourdomain.com
dmarc=pass (p=REJECT) header.from=yourdomain.comهذا الاختبار وحده حسم خلافًا حقيقيًا لدينا. أُبلغنا أن ردًا أُرسل من نطاقنا رفضه مستلم على Microsoft 365، وكان التشخيص الأول في النقاش واثقًا: سجل SPF ينقصه include لخادم ترحيل، وDKIM غير مُعدّ. قبل تغيير أي شيء أرسلنا رسالة اختبار إلى Gmail وقرأنا الترويسة، فكانت spf=pass وdkim=pass وdmarc=pass مع سياسة p=reject الخاصة بنا. وبحثنا عن رسالة الارتداد نفسها فلم نجدها، لا في صندوق الوارد ولا في سجل التسليم على خادم البريد. لم يكن هناك عطل أصلًا. لو «أصلحنا» SPF بإضافة خادم ترحيل لا نستخدمه، لكنا منحنا طرفًا ثالثًا صلاحية الإرسال باسمنا دون أن نصلح شيئًا.
الخطوة 2: طابِق SPF مع عنوان IP الذي يرسل فعلًا
إذا فشل SPF، فاستعلم عن السجل (dig +short TXT yourdomain.com) وقارنه بعنوان IP العام الذي يستخدمه خادمك فعلًا للاتصالات الصادرة. خذ هذا العنوان من الخادم نفسه، مثلًا عبر curl -4 ifconfig.me، لا من سجل MX ولا من لوحة تحكم. على خادم له عدة عناوين، أو خلف NAT، قد يختلف العنوانان.
سجلّنا من أقصر ما يمكن أن يكون عليه SPF: v=spf1 mx -all. خادم MX هو نفسه خادم الإرسال، فيغطيه mx، و-all يرفض كل ما سواه. إذا كنت ترسل أيضًا عبر أداة نشرات بريدية أو نظام CRM، فكل منها يحتاج include خاصًا به، وعليك أن تبقى تحت حد SPF البالغ 10 استعلامات DNS. إذا تجاوزته أعاد SPF النتيجة permerror، ويعدّها Outlook فشلًا.
الخطوة 3: DKIM، الفحص الذي يتعطل بصمت
الخوادم الحديثة مثل Stalwart تولّد مفاتيح DKIM تلقائيًا، وبعضها يدوّرها دوريًا، وهذا جيد إلى أن يتأخر جانب DNS عن اللحاق. اسم المحدِّد (selector) موجود في ترويسة DKIM-Signature لأي رسالة ترسلها (s=...). استعلم عن <selector>._domainkey.yourdomain.com وتأكد أن المفتاح العام المنشور هناك هو المفتاح الذي يوقّع به الخادم الآن. مفتاح قديم بعد التدوير يعطيك dkim=fail (bad signature) على كل رسالة، وإذا كان SPF سليمًا فقد لا تنتبه حتى يبدأ Outlook في رد الرسائل.
تحقق أيضًا من أن قيمة d= في التوقيع هي نطاقك، لا اسم مضيف الخادم ولا نطاق مزوّد الخدمة. توقيع صالح من النطاق الخطأ ينجح في DKIM لكنه يفشل في تطابق DMARC.
الخطوة 4: DMARC، ولماذا لا تكون p=none هي الهدف
الحد الأدنى لدى Microsoft هو p=none، وهذا يكفي لإيقاف ارتداد 5.7.515، لكنه لا يكفي لمنع غيرك من الإرسال باسم نطاقك. نحن ننشر v=DMARC1; p=reject; rua=mailto:postmaster@.... إذا كنت تبدأ من الصفر، فابدأ بـ p=none مع عنوان rua يعمل، واقرأ التقارير المجمّعة لأسبوعين أو ثلاثة لتكتشف المرسلين الذين نسيتهم (نظام الفوترة، نموذج الموقع القديم، الماسح الضوئي الذي يرسل ملفات PDF بالبريد)، ثم انتقل إلى quarantine وبعدها إلى reject.
عندما تنجح الفحوص الثلاثة ويستمر Outlook في الرفض
عندها لا تكون المشكلة في المصادقة، ولن يفيد تعديل DNS. اقرأ الرمز بعناية. الرمز 5.7.515 يخص المصادقة. أما الحظر بسبب سمعة عنوان IP فيبدو مختلفًا، بصيغة S3150 الخاصة بـ Outlook أو عبارة "banned sender"، ولدى Gmail نسخته الخاصة (550 5.7.28 ... unusual rate of unsolicited mail، وقد تلقيناها فعلًا من Gmail على عنوان IP البريدي لدينا في يونيو، بعد أن كانت سجلاتنا صحيحة بوقت طويل). مشكلات السمعة تُعالج عبر Microsoft SNDS ونموذج دعم المرسلين، أو عبر Google Postmaster Tools، وبتقليل البريد غير المرغوب فيه، لا بتعديل SPF.
قائمة فحص مختصرة
- اقرأ ترويسة
Authentication-Resultsلرسالة اختبار جديدة قبل أن تغيّر أي شيء. - SPF: يغطي عنوان IP الصادر الحقيقي، وينتهي بـ
-allأو~all، وأقل من 10 استعلامات. - DKIM: المحدِّد في DNS يطابق المفتاح الذي يوقّع به الخادم اليوم، و
d=هو نطاقك. - DMARC: على الأقل
p=noneمع تقارير، والاتجاه نحوreject. - كل شيء ينجح والبريد ما زال يرتد: المشكلة في السمعة أو المحتوى، راجع SNDS وPostmaster Tools.
إذا كنت ما زلت تختار خادم بريد، فقد قارنّا ثلاثة خيارات مستضافة ذاتيًا على نطاق حقيقي في Mailcow مقابل Stalwart مقابل Mailu. أما السؤال الأوسع حول جدوى استضافة البريد بنفسك أصلًا فتجده في لماذا ما زالت بعض المؤسسات تستضيف بريدها بنفسها في 2026، وإذا كنت تنتقل من خادم Exchange قديم فإن مقال انتهاء دعم Exchange 2019 يغطي جانب الترحيل.
