Defaults.Exposed › Поправки › Guides

Outlook отхвърля вашия имейл: 550 5.7.515, 550 5.7.509 и compauth=fail — обяснено и поправено (2026)

Публикувано 2026-07-08

Данни към 2026-06-29 · методология v7. Обобщени данни от census за 261 милиона оценени домейна. Вижте как оценяваме.

Две различни системи на Microsoft отхвърлят поща. Потребителският Outlook.com отхвърля масовите изпращачи, неуспяващи при автентикацията (550 5.7.515, приложено от май 2025 г.); Exchange Online отхвърля поща, неуспяваща при вашата собствена DMARC политика за отхвърляне (550 5.7.509). От 10,205,070 домейна, упълномощаващи spf.protection.outlook.com, 85.0% имат строг SPF, но само 21.7% прилагат DMARC, според census на Defaults.Exposed за 261,086,232 домейна.

Повечето проблеми с „Outlook отхвърля имейла ми” изобщо не са отхвърляния — пощата безшумно попада в Нежелана поща с compauth=fail в заглавията. Това ръководство декодира кодовете на Microsoft, показва ви как да прочетете заглавието Authentication-Results и описва поправката в ред: потвърдете SPF, активирайте DKIM за вашия персонализиран домейн, публикувайте и приложете DMARC, тествайте отново.

Каква е всъщност вашата грешка от Microsoft?

Microsoft управлява две отделни повърхности за получаване и отхвърлят по различни причини. Намерете симптома си първо — грешна диагноза губи ден.

Точните формулировки на NDR се променят; проверете низовете, на които разчитате, спрямо реално отхвърляне, преди да им се доверите.

Какво означава 550 5.7.515?

Това е изискването на потребителския Outlook.com/Hotmail, а не грешка на наемателя на Microsoft 365. От май 2025 г., изпращачи на повече от 5 000 съобщения на ден до потребителски адреси на Outlook трябва да преминат SPF, да преминат DKIM и да публикуват DMARC запис (поне p=none), съответстващ с From домейна. При неизпълнение потребителският Outlook отхвърля с формулировка като:

550 5.7.515 Access denied, sending domain [yourdomain.com] does not meet the required authentication level.

Две неща, каквито това не е: не е мандат от 2026 г. (ако пощата ви е започнала да се отхвърля наскоро, обемът или DNS е сменен, а не правилото) и не касае настройките на наемателя M365 на получателя. Поправката е стълбата за автентикация по-долу — а еднократните кампании, надхвърлящи 5 000/ден, също се броят.

Какво означава 550 5.7.509?

Този идва от Exchange Online Protection при бизнес наематели и означава, че вашата собствена DMARC политика се спазва:

550 5.7.509: Access denied, sending domain [yourdomain.com] does not pass DMARC verification and has a DMARC policy of reject.

Прочетете внимателно — не Microsoft е трудният. Вашият домейн публикува p=reject, това съобщение не е преминало DMARC и получателят е направил точно това, което сте поискали. Ако отхвърлената поща е легитимна, някакъв изпращащ источник (инструмент за бюлетини, CRM, устройство за сканиране към имейл) не е автентикиран по съответстващ начин. Не отслабвайте политиката; дайте на този источник съответстващ SPF или DKIM — вижте поправяне на DMARC и от p=none до p=reject.

Защо Outlook изхвърля пощата ми с compauth=fail вместо да я отхвърля?

Повечето болки с доставимостта при Microsoft никога не произвеждат отхвърляне. Съобщението се приема, оценява и подава в Нежелана поща — единственото доказателство е заглавието Authentication-Results. В пощенската кутия на получателя (или собствената ви тестова пощенска кутия на outlook.com), отворете съобщението, изберете Преглед на изходния код на съобщението и намерете реда:

Authentication-Results: spf=pass ... dkim=fail ... dmarc=fail action=none ... compauth=fail reason=001

compauth е резултатът от съставната автентикация на Microsoft: дори когато домейн не публикува DMARC запис, Microsoft прилага имплицитни проверки, подобни на DMARC. Често наблюдавани стойности:

• compauth=fail reason=000 — съобщението не е преминало явна автентикация: DMARC политиката на вашия домейн е quarantine/reject и съобщението не я е изпълнило.
• compauth=fail reason=001 — съобщението не е преминало имплицитна автентикация: вашият домейн не публикува (или не достатъчно) auth записи и съобщението не е изглеждало, сякаш идва от вас. Класическата „сигнатура за никога не сме настройвали DKIM/DMARC”.
• compauth=fail reason=6xx — варианти на неуспех при имплицитна автентикация; 601 специално означава, че домейнът на изпращача е един от собствените приети домейни на вашата организация (вътрешно подправяне, self-to-self).

Поуката: при Microsoft, четете заглавието, не само NDR. Резултатите spf=, dkim= и dmarc= на същия ред ви казват точно кой компонент да поправите.

Как да поправите отхвърлянията и изхвърлянията на Outlook?

1. Първо стартирайте безплатното сканиране. То оценява вашия SPF, DKIM и DMARC наведнъж и показва кой компонент не успява, преди да докоснете DNS.
2. Потвърдете SPF — обикновено вече е наред при Microsoft 365. Стандартният запис е 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), а не заглавието From — така инструментът за бюлетини може да премине SPF за неговия домейн за отвърнати писма, без да прави нищо за вашия. Затова стъпки 3 и 4 са по-важни.
3. Активирайте DKIM за вашия персонализиран домейн — два селектора CNAME. M365 подписва с неприлягащ стандарт onmicrosoft.com, докато не активирате подписването с персонализиран домейн: публикувайте CNAME на selector1._domainkey и selector2._domainkey, сочещи към ключовете на вашия наемател, след което активирайте подписването в портала на Defender. Пълен наръчник: настройване на DKIM за Microsoft 365. Ако DKIM показва „pass”, но DMARC все още не успява, попаднали сте в капана на стандартния подпис.
4. Публикувайте DMARC, след което го приложете. Започнете с v=DMARC1; p=none; rua=mailto:... за получаване на доклади, поправете всеки легитимен изпращач, разкрит от тях, след което постепенно преминете към p=quarantine и p=reject — поетапният път е в поправяне на DMARC. Това е стъпката, която повечето организации с Microsoft пропускат: само 21.7% от домейните, изпращащи чрез M365, прилагат DMARC.
5. Повторно тестване чрез четене на заглавието. Изпратете на потребителска пощенска кутия на outlook.com, отворете изходния код на съобщението и потвърдете spf=pass, dkim=pass, dmarc=pass и compauth=pass.
6. Масови изпращачи: изпълнете изискванията на потребителския Outlook. При над 5 000/ден имате нужда и от валиден, наблюдаван From/reply-to, работещо деабониране и чисти списъци — автентикацията изчиства 5.7.515; процентът на оплаквания ви предпазва от IP блокирания S3140/S3150. Ако вече сте блокирани по IP, поправянето на SPF/DKIM/DMARC не вдига блокирането: поискайте изключване от списъка чрез поддръжката за изпращачи на Microsoft и третирайте автентикацията като причина да не се върнете отново.

Защо толкова много домейни на Microsoft 365 все още не успяват?

Защото стандартното прави първата стъпка за вас и нито едно от останалите. Сред 10,205,070 домейна, упълномощаващи spf.protection.outlook.com, 85.0% носят строг SPF — записът, който M365 ви дава при настройката — но само 21.7% прилагат DMARC, според census на Defaults.Exposed за 261,086,232 домейна. M365 ви дава строг SPF по подразбиране, след което повечето наематели спират до там — точно популацията, за улавянето на която е изграден compauth (все пак по-напред от 10.59% прилагане на DMARC сред всички оценени домейни). Пълното сравнение на доставчиците: нашата таблица за SPF рейтинг на пощенски доставчици.

Често задавани въпроси

550 5.7.515 грешка ли е на Microsoft 365? Не. Идва от потребителския Outlook.com/Hotmail и се отнася за изпращачи на >5 000 съобщения/ден, прилагани от май 2025 г. Отхвърлянията на бизнес Exchange Online използват различни кодове — най-честото е 550 5.7.509 (вашата DMARC политика reject) или 5.7.511 (забранен изпращач).

Получихме 550 5.7.509, но пощата беше легитимна — трябва ли да изоставим p=reject? Не — вашата политика е уловила неавтентикиран источник, което означава, че работи. Намерете источника в заглавието или в докладите ви за DMARC и му дайте съответстващ DKIM (или съответстващ SPF). Отслабването към p=none отваря отново точното подправяне на домейна за всички.

compauth=fail означава ли, че някой ни подправя? Не непременно. reason=001 обикновено означава, че вашата собствена поща не може да докаже, че е ваша — без съответстващ DKIM, без DMARC. Само 21.7% от 10,205,070 домейна, изпращащи чрез M365, прилагат DMARC (данни към 2026-06-29), така че Microsoft прилага имплицитни проверки за всички останали, и неавтентикираната легитимна поща не ги преминава.

Изпращам по-малко от 5 000 имейла на ден — мога ли да пренебрегна това? Ще избегнете 550 5.7.515, но не и папката за Нежелана поща: compauth се прилага при всякакъв обем. Gmail играе по същия начин — вижте ръководството за Gmail 550 5.7.26. Поправките са безплатни; препятствието е осъзнаването, а не разходите.

Изпратете на собственика доклада

Ако поправяте имейл за някой друг — клиент, шеф, фирмата, чиито фактури се отхвърляха — завършете с доказателство. Пуснете отново безплатното сканиране след успокояването на DNS и препратете оценения доклад. Той показва SPF, DKIM и DMARC с показания зелени на разбираем език, четим от собственик на бизнес, и е артефактът, от който ще се нуждаят следващия път, когато подновяването на киберзастраховката или въпросник за сигурност от клиент попита дали имейлът им е автентикиран. Поправено е добре; доказуемо поправено е това, за което ви плащат и те са застраховани.

Проверете вашия домейн безплатно

Вижте кой компонент Microsoft не успява — SPF, DKIM, DMARC — поверително и само за собственика.

Проверете вашия домейн → · Поправяне на DMARC → · DKIM преминава, но DMARC не успява → · Как оценяваме → · Само обобщени данни. Данните се съхраняват и обработват в ЕС.