Defaults.Exposed › رفع اشکالها › Guides
Outlook ایمیل شما را رد میکند: 550 5.7.515، 550 5.7.509 و compauth=fail، توضیح و رفع (۲۰۲۶)
منتشرشده 2026-07-08
ارقام تا 2026-06-29 · روششناسی v7. دادههای آماری کل در 261 میلیون دامنه درجهبندیشده. ببینید چگونه درجهبندی میکنیم.
دو سیستم مختلف مایکروسافت ایمیل را رد میکنند. Outlook.com عمومی فرستندگان پرحجمی را که احراز هویت شکست میخورد bounce میکند (550 5.7.515، اعمال شده از می ۲۰۲۵)؛ Exchange Online ایمیلی را که سیاست رد DMARC خودتان شکست میخورد bounce میکند (550 5.7.509). از 10,205,070 دامنه مجاز کننده spf.protection.outlook.com، 85.0٪ SPF سختگیرانه دارند اما تنها 21.7٪ DMARC را اعمال میکنند، طبق سرشماری Defaults.Exposed از 261,086,232 دامنه.
اکثر مشکلات “Outlook ایمیلم را رد میکند” اصلاً رد نیستند — ایمیل بدون صدا در Junk فرود میآید با compauth=fail در headerها. این راهنما کدهای مایکروسافت را رمزگشایی میکند، نحوه خواندن header Authentication-Results را نشان میدهد، و رفع را به ترتیب راهنمایی میکند: تأیید SPF، فعال کردن DKIM برای دامنه سفارشی، انتشار و اعمال DMARC، آزمایش مجدد.
کدام خطای مایکروسافت واقعاً دارید؟
مایکروسافت دو سطح دریافت جداگانه اجرا میکند و به دلایل مختلف رد میکنند. ابتدا علامت خود را تطبیق دهید — تشخیص غلط یک روز هدر میدهد.
| کد / علامت | از کجا میآید | چه معنایی دارد | دادهها تا 2026-06-29 |
|---|---|---|---|
| 550 5.7.515 | Outlook.com عمومی / Hotmail / Live | بیش از ۵٬۰۰۰ پیام/روز به Outlook عمومی ارسال میکنید و الزامات احراز هویت (SPF + DKIM + DMARC) را تأمین نمیکنید، اعمال شده از می ۲۰۲۵ | — |
| 550 5.7.509 | Exchange Online / EOP (tenantهای تجاری) | سرور دریافتکننده DMARC p=reject دامنه خودتان را اعمال کرد — ایمیلتان DMARC شکست خورد | تنها 10.59٪ از تمام 261,086,232 دامنه درجهبندیشده DMARC اعمال میکنند |
| 550 5.7.511 | Exchange Online / EOP | آدرس یا دامنه فرستنده شما در لیست فرستندگان ممنوع سازمان گیرنده یا مایکروسافت است | — |
| S3140 / S3150 | Outlook.com عمومی | IP فرستنده شما اعتبار ضعیفی دارد — یک block، نه شکست احراز هویت | — |
compauth=fail (headerها) | هر دو سطح — رایجترین حالت | ایمیل پذیرفته شد اما به Junk رفت: احراز هویت ترکیبی مایکروسافت شکست خورد. هیچ bounce، هیچ NDR — فقط پوشه اسپم | از 10,205,070 دامنه ارسال M365، تنها 21.7٪ DMARC اعمال میکنند |
متن دقیق NDR تغییر میکند؛ رشتههایی که نقل میکنید را قبل از تکیه بر آنها در برابر یک bounce زنده تأیید کنید.
550 5.7.515 چه معنایی دارد؟
این الزام Outlook.com/عمومی Hotmail است، نه خطای tenant مایکروسافت ۳۶۵. از می ۲۰۲۵، فرستندگان بیش از ۵٬۰۰۰ پیام در روز به آدرسهای Outlook عمومی باید SPF pass کنند، DKIM pass کنند، و یک رکورد DMARC (حداقل p=none) همراستا با دامنه From منتشر کنند. این معیار را تأمین نکنید و Outlook عمومی با پیامی شبیه این رد میکند:
550 5.7.515 Access denied, sending domain [yourdomain.com] does not meet the required authentication level.
دو چیزی که این نیست: یک الزام ۲۰۲۶ نیست (اگر ایمیلتان تازه bounce شده، حجمتان یا DNS تغییر کرده، نه قانون)، و مربوط به تنظیمات tenant M365 گیرنده نیست. رفع، نردبان احراز هویت پایین است — و روزهای کمپین گاهگاهی که از ۵٬۰۰۰ در روز عبور میکنند حساب میشوند.
550 5.7.509 چه معنایی دارد؟
این از Exchange Online Protection روی tenantهای تجاری میآید، و به این معنا است که سیاست DMARC خودتان اعمال میشود:
550 5.7.509: Access denied, sending domain [yourdomain.com] does not pass DMARC verification and has a DMARC policy of reject.
آن را دقیق بخوانید — مایکروسافت مشکلساز نیست. دامنه شما p=reject منتشر میکند، این پیام DMARC شکست خورد، و گیرنده دقیقاً کاری کرد که خواستید. اگر ایمیل bounce شده قانونی است، یک منبع ارسال (ابزار خبرنامه، CRM، دستگاه scan-to-email) به شیوهای همراستا احراز هویت نشده. سیاست را تضعیف نکنید؛ به آن منبع SPF همراستا یا DKIM بدهید — ببینید رفع DMARC و از p=none به p=reject.
چرا Outlook ایمیلم را با compauth=fail به Junk میفرستد به جای bounce کردن؟
اکثر دردهای تحویل مایکروسافت هرگز bounce تولید نمیکند. پیام پذیرفته، امتیازبندی شده و در Junk ثبت میشود — تنها مدرک header Authentication-Results است. در صندوق پستی گیرنده (یا صندوق پستی آزمایشی outlook.com خودتان)، پیام را باز کنید، View message source را انتخاب کنید، و این خط را پیدا کنید:
Authentication-Results: spf=pass ... dkim=fail ... dmarc=fail action=none ... compauth=fail reason=001
compauth حکم احراز هویت ترکیبی مایکروسافت است: حتی وقتی دامنهای هیچ رکورد DMARC ندارد، مایکروسافت بررسیهای ضمنی مشابه DMARC اعمال میکند. مقادیر رایج دیده شده:
compauth=fail reason=000— پیام احراز هویت صریح شکست خورد: سیاست DMARC دامنه شما quarantine/reject است و پیام شکست خورد.compauth=fail reason=001— پیام احراز هویت ضمنی شکست خورد: دامنه شما رکورد احراز هویت (کافی) ندارد، و پیام به نظر نرسید از شما باشد. امضای کلاسیک “هرگز DKIM/DMARC تنظیم نکردیم”.compauth=fail reason=6xx— انواع شکست احراز هویت ضمنی؛601مشخصاً به این معنا است که دامنه ارسال یکی از دامنههای پذیرفته شده خود سازمان است (جعل هویت intra-org، self-to-self).
درس: در مایکروسافت، header را بخوانید، نه فقط NDR. حکمهای spf=، dkim= و dmarc= در همان خط دقیقاً به شما میگویند کدام بخش را رفع کنید.
چطور رد شدنها و رفتن به Junk Outlook را رفع کنم؟
- ابتدا اسکن رایگان را اجرا کنید. SPF، DKIM و DMARC را در یک بار درجهبندی میکند و قبل از دست زدن به DNS نشان میدهد کدام بخش شکست میخورد.
- SPF را تأیید کنید — معمولاً در مایکروسافت ۳۶۵ از قبل خوب است. رکورد استاندارد
v=spf1 include:spf.protection.outlook.com -allاست، و تنظیم M365 آن را قرار میدهد: 85.0٪ از 10,205,070 دامنه مجاز کننده spf.protection.outlook.com قبلاً با-allسختگیرانه پایان مییابند (دادهها تا 2026-06-29). یک نکته محافظتی: گیرندگان SPF را در برابر دامنه Return-Path (RFC5321.MailFrom) ارزیابی میکنند، نه header From — بنابراین یک ابزار خبرنامه میتواند SPF را در دامنه bounce خودش pass کند در حالی که هیچ کاری برای شما نمیکند. این دلیلی است که مراحل ۳ و ۴ بیشتر اهمیت دارند. - DKIM را برای دامنه سفارشی فعال کنید — دو CNAME برای selector. M365 با یک
onmicrosoft.comپیشفرض غیر همراستا امضا میکند تا امضای دامنه سفارشی را روشن کنید: CNAMEهایselector1._domainkeyوselector2._domainkeyرا که به کلیدهای tenant شما اشاره میکنند منتشر کنید، سپس امضا را در پورتال Defender فعال کنید. مسیر کامل کلیک: تنظیم DKIM روی مایکروسافت ۳۶۵. اگر DKIM “pass” نشان میدهد اما DMARC هنوز شکست میخورد، در تله امضای پیشفرض هستید. - DMARC را منتشر کرده، سپس آن را اعمال کنید. با
v=DMARC1; p=none; rua=mailto:...برای دریافت گزارش شروع کنید، هر منبع قانونی که نشان میدهد را رفع کنید، سپس بهp=quarantineوp=rejectبروید — مسیر مرحلهای در رفع DMARC است. این گامی است که اکثر سازمانهای مایکروسافتی از آن میگذرند: تنها 21.7٪ از دامنههای ارسال M365 DMARC را اعمال میکنند. - با خواندن header مجدداً آزمایش کنید. به یک صندوق پستی outlook.com عمومی ارسال کنید، source پیام را باز کنید، و
spf=pass،dkim=pass،dmarc=passوcompauth=passرا تأیید کنید. - فرستندگان پرحجم: معیار Outlook عمومی را تأمین کنید. بیش از ۵٬۰۰۰ در روز به یک From/reply-to معتبر و نظارت شده، unsubscribe کاری، و لیستهای تمیز هم نیاز دارید — احراز هویت 5.7.515 را پاک میکند؛ نرخ شکایت شما را از IP blockهای S3140/S3150 دور نگه میدارد. اگر قبلاً IP block شدهاید، رفع SPF/DKIM/DMARC block را برنمیدارد: از طریق پشتیبانی فرستندگان مایکروسافت درخواست delisting کنید، و احراز هویت را به عنوان دلیلی که دوباره نخواهید آمد در نظر بگیرید.
چرا بسیاری از دامنههای مایکروسافت ۳۶۵ هنوز شکست میخورند؟
چون پیشفرض اول قدم را برایتان انجام میدهد و هیچکدام از بقیه را. در 10,205,070 دامنهای که spf.protection.outlook.com را مجاز میکنند، 85.0٪ SPF سختگیرانه دارند — رکوردی که M365 در راهاندازی میدهد — اما تنها 21.7٪ DMARC را اعمال میکنند، طبق سرشماری Defaults.Exposed از 261,086,232 دامنه. M365 SPF سختگیرانه را به طور پیشفرض میدهد، سپس اکثر tenantها آنجا متوقف میشوند — دقیقاً جمعیتی که compauth برای گرفتار کردنشان ساخته شده (هرچند هنوز جلوتر از 10.59٪ اعمال DMARC در تمام دامنههای درجهبندیشده). مقایسه کامل ارائهدهنده: جدول لیگ SPF ارائهدهنده ایمیل.
پرسشهای متداول
آیا 550 5.7.515 یک خطای مایکروسافت ۳۶۵ است؟ خیر. از Outlook.com عمومی/Hotmail میآید و فرستندگان بیش از ۵٬۰۰۰ پیام/روز را هدف میگیرد، اعمال شده از می ۲۰۲۵. رد شدنهای Exchange Online تجاری از کدهای مختلف استفاده میکنند — رایجترین 550 5.7.509 (سیاست رد DMARC شما) یا 5.7.511 (فرستنده ممنوع).
550 5.7.509 گرفتیم اما ایمیل قانونی بود — آیا باید p=reject را کنار بگذاریم؟
خیر — سیاستتان یک منبع بدون احراز هویت را گرفت، که یعنی کار میکند. منبع را در header یا گزارشهای DMARC پیدا کنید و DKIM همراستا (یا SPF همراستا) به آن بدهید. تضعیف به p=none جعل هویت دامنه دقیق را برای همه دوباره باز میکند.
آیا compauth=fail یعنی کسی هویت ما را جعل میکند؟
لزوماً نه. reason=001 معمولاً به این معنا است که ایمیل قانونی خودتان نمیتواند ثابت کند از شماست — بدون DKIM همراستا، بدون DMARC. تنها 21.7٪ از 10,205,070 دامنه ارسال M365 DMARC را اعمال میکنند (دادهها تا 2026-06-29)، بنابراین مایکروسافت بررسیهای ضمنی را برای بقیه اعمال میکند، و ایمیل قانونی بدون احراز هویت هم در آنها شکست میخورد.
کمتر از ۵٬۰۰۰ ایمیل در روز ارسال میکنم — میتوانم این را نادیده بگیرم؟
از 550 5.7.515 جان سالم به در میبرید، اما نه از پوشه Junk: compauth در هر حجمی اعمال میشود. Gmail همین کار را میکند — ببینید راهنمای Gmail 550 5.7.26. رفعها رایگان هستند؛ مانع آگاهی است، نه هزینه.
گزارش را به صاحب سایت بفرستید
اگر ایمیل را برای شخص دیگری رفع میکنید — یک مشتری، رئیستان، شرکتی که فاکتورهایش bounce میشد — کار را با مدرک تمام کنید. بعد از یکپارچه شدن DNS اسکن رایگان را دوباره اجرا کنید و گزارش درجهبندیشده را ارسال کنید. SPF، DKIM و DMARC را به زبان سادهای که صاحب کسبوکار بتواند بخواند سبز نشان میدهد، و این مدرکی است که دفعه بعد که تمدید بیمه سایبری یا پرسشنامه امنیتی مشتری میپرسد آیا ایمیلشان احراز هویت شده نیاز خواهند داشت. رفع خوب است؛ اثبات رفع چیزی است که شما را میپردازد و آنها را تحت پوشش نگه میدارد.
دامنهتان را رایگان بررسی کنید
ببینید Outlook کدام بخش را شکست میزند — SPF، DKIM، DMARC — به صورت خصوصی و فقط برای صاحب.
دامنهتان را بررسی کنید ← · رفع DMARC ← · DKIM pass اما DMARC شکست ← · چگونه درجهبندی میکنیم ← · فقط دادههای جمعی. دادهها در اتحادیه اروپا ذخیره و پردازش میشوند.