Defaults.Exposed › Remedieri › Guides

Outlook respinge e-mailul dvs.: 550 5.7.515, 550 5.7.509 și compauth=fail, explicate și remediate (2026)

Publicat 2026-07-08

Date din 2026-06-29 · metodologie v7. Date agregate din recensământul a 261 milioane de domenii clasificate. Consultați cum clasificăm.

Două sisteme Microsoft diferite resping e-mailul. Outlook.com de consum respinge expeditorii cu volum mare care eșuează autentificarea (550 5.7.515, aplicat din mai 2025); Exchange Online respinge e-mailul care eșuează propria dvs. politică DMARC de respingere (550 5.7.509). Din 10,205,070 domenii care autorizează spf.protection.outlook.com, 85.0% au SPF strict dar doar 21.7% aplică DMARC, conform recensământului Defaults.Exposed al 261,086,232 de domenii.

Cele mai multe probleme „Outlook respinge e-mailul meu” nu sunt respingeri deloc — sunt e-mail care aterizează silențios în Junk cu compauth=fail în antete. Acest ghid decodifică codurile Microsoft, vă arată cum să citiți antetul Authentication-Results și parcurge remedierea în ordine: confirmați SPF, activați DKIM pentru domeniul personalizat, publicați și aplicați DMARC, re-testați.

Ce eroare Microsoft aveți de fapt?

Microsoft rulează două suprafețe de primire separate și resping din motive diferite. Potriviți mai întâi simptomul — diagnosticul greșit irosește o zi.

Formularea exactă a NDR se schimbă; verificați șirurile pe care le citați față de un bounce live înainte de a vă baza pe ele.

Ce înseamnă 550 5.7.515?

Este cerința consumer Outlook.com/Hotmail, nu o eroare de chiriaș Microsoft 365. Din mai 2025, expeditorii de mai mult de 5.000 de mesaje pe zi la adresele consumer Outlook trebuie să treacă SPF, să treacă DKIM și să publice un record DMARC (cel puțin p=none) aliniat cu domeniul From. Eșuați acea bară și Outlook de consum respinge cu formularea:

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

Două lucruri care nu este: nu este un mandat din 2026 (dacă e-mailul tocmai a început să bounced-uiască, volumul dvs. sau DNS-ul s-a schimbat, nu regula), și nu este despre setările chiriașului M365 al destinatarului. Remedierea este scara de autentificare de mai jos — iar zilele de campanie ocazionale care depășesc 5.000/zi contează.

Ce înseamnă 550 5.7.509?

Acesta vine de la Exchange Online Protection pe chiriașii de afaceri și înseamnă că propria dvs. politică DMARC este onorată:

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

Citiți asta cu atenție — nu este Microsoft care face dificultăți. Domeniul dvs. publică p=reject, acest mesaj a eșuat DMARC și receptorul a făcut exact ce ați cerut. Dacă e-mailul respins este legitim, o sursă de trimitere (un instrument de newsletter, un CRM, un dispozitiv scan-to-email) nu este autentificată într-un mod aliniat. Nu slăbiți politica; dați acelei surse SPF sau DKIM aliniat — consultați corectați DMARC și de la p=none la p=reject.

De ce Outlook trimite e-mailul meu în Junk cu compauth=fail în loc să-l bounce-uiască?

Cele mai multe dureri de livrare Microsoft nu produc niciodată un bounce. Mesajul este acceptat, scored și depus în Junk — singura dovadă este antetul Authentication-Results. În căsuța poștală a destinatarului (sau propria dvs. căsuță poștală de test outlook.com), deschideți mesajul, alegeți View message source și găsiți linia:

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

compauth este verdictul autentificării compuse Microsoft: chiar și când un domeniu nu publică niciun record DMARC, Microsoft aplică verificări implicite asemănătoare DMARC. Valori frecvente:

• compauth=fail reason=000 — mesajul a eșuat autentificarea explicită: politica DMARC a domeniului dvs. este quarantine/reject și mesajul a eșuat-o.
• compauth=fail reason=001 — mesajul a eșuat autentificarea implicită: domeniul dvs. nu publică (sau nu publică suficiente) înregistrări auth și mesajul nu părea să vină de la dvs. Semnătura clasică „nu am configurat niciodată DKIM/DMARC”.
• compauth=fail reason=6xx — variante de eșec de autentificare implicită; 601 înseamnă specific că domeniul de trimitere este unul dintre propriile domenii acceptate ale organizației (spoofing intra-org, self-to-self).

Lecția: pe Microsoft, citiți antetul, nu doar NDR-ul. Verdictele spf=, dkim= și dmarc= pe aceeași linie vă spun exact ce picior să reparați.

Cum reparați respingerile și trimiterea în Junk Outlook?

1. Rulați scanarea gratuită mai întâi. Clasifică SPF, DKIM și DMARC într-o singură trecere și arată ce picior eșuează înainte de a atinge DNS-ul.
2. Confirmați SPF — de obicei deja în regulă pe Microsoft 365. Înregistrarea standard este v=spf1 include:spf.protection.outlook.com -all, iar configurarea M365 o pune acolo: 85.0% din cele 10,205,070 domenii care autorizează spf.protection.outlook.com se termină deja în strict -all (date din 2026-06-29). O gardă: receptorii evaluează SPF față de domeniul Return-Path (RFC5321.MailFrom), nu antetul From — deci un instrument de newsletter poate trece SPF pe propriul domeniu de bounce fără a face nimic pentru al dvs. De aceea contează mai mult pașii 3 și 4.
3. Activați DKIM pentru domeniul personalizat — două CNAMEs de selector. M365 semnează cu un implicit onmicrosoft.com nealiniat până activați semnarea cu domeniu personalizat: publicați CNAMEs-urile selector1._domainkey și selector2._domainkey pointing la cheile chiriașului dvs., apoi activați semnarea în portalul Defender. Calea completă de clicuri: configurați DKIM pe Microsoft 365. Dacă DKIM arată „pass” dar DMARC tot eșuează, vă aflați în capcana semnăturii implicite.
4. Publicați DMARC, apoi aplicați-l. Începeți cu v=DMARC1; p=none; rua=mailto:... pentru a obține rapoarte, reparați fiecare sursă legitimă pe care o dezvăluie, apoi ajustați la p=quarantine și p=reject — calea etapizată este în corectați DMARC. Acesta este pasul pe care cele mai multe magazine Microsoft îl sar: doar 21.7% din domeniile care trimit prin M365 aplică DMARC.
5. Re-testați citind antetul. Trimiteți la o căsuță poștală consumer outlook.com, deschideți sursa mesajului și confirmați spf=pass, dkim=pass, dmarc=pass și compauth=pass.
6. Expeditori de volum mare: îndepliniți bara Outlook de consum. Peste 5.000/zi aveți nevoie și de un From/reply-to valid și monitorizat, dezabonare funcțională și liste curate — autentificarea elimină 5.7.515; rata de reclamații vă ține în afara blocajelor de IP S3140/S3150. Dacă sunteți deja blocat pe IP, repararea SPF/DKIM/DMARC nu ridică blocajul: solicitați dezlistarea prin suportul pentru expeditori Microsoft și tratați autentificarea ca motivul pentru care nu veți reveni.

De ce atât de multe domenii Microsoft 365 tot eșuează?

Deoarece valoarea implicită face primul pas pentru dvs. și niciunul dintre restul. Dintre cele 10,205,070 domenii care autorizează spf.protection.outlook.com, 85.0% poartă SPF strict — înregistrarea pe care M365 vi-o dă la configurare — dar doar 21.7% aplică DMARC, conform recensământului Defaults.Exposed al 261,086,232 de domenii. M365 vă oferă SPF strict implicit, apoi cei mai mulți chiriași se opresc acolo — exact populația pe care compauth a fost construit să o prindă (deși totuși în față față de cei 10.59% aplicare DMARC din toate domeniile clasificate). Comparație completă a furnizorilor: tabelul de clasament SPF al furnizorilor de e-mail.

Întrebări frecvente

Este 550 5.7.515 o eroare Microsoft 365? Nu. Vine de la consumer Outlook.com/Hotmail și vizează expeditorii de >5.000 mesaje/zi, aplicat din mai 2025. Respingerile Exchange Online de afaceri folosesc coduri diferite — cel mai frecvent 550 5.7.509 (politica dvs. DMARC de respingere) sau 5.7.511 (expeditor interzis).

Am primit 550 5.7.509 dar e-mailul era legitim — ar trebui să renunțăm la p=reject? Nu — politica dvs. a prins o sursă neautentificată, ceea ce înseamnă că funcționează. Găsiți sursa în antet sau rapoartele DMARC și dați-i DKIM aliniat (sau SPF aliniat). Slăbirea la p=none redeschide falsificarea domeniului exact pentru toată lumea.

compauth=fail înseamnă că cineva ne falsifică? Nu neapărat. reason=001 înseamnă de obicei că propriul e-mail nu poate dovedi că este al dvs. — niciun DKIM aliniat, niciun DMARC. Doar 21.7% din cele 10,205,070 domenii care trimit prin M365 aplică DMARC (date din 2026-06-29), deci Microsoft aplică verificări implicite tuturor celorlalți, iar e-mailul legitim neautentificat le eșuează și pe ele.

Trimit mai puțin de 5.000 de e-mailuri pe zi — pot ignora asta? Veți evita 550 5.7.515, dar nu folderul Junk: compauth se aplică la orice volum. Gmail joacă aceeași carte — consultați ghidul Gmail 550 5.7.26. Remedierile sunt gratuite; bariera este conștientizarea, nu costul.

Trimiteți proprietarului raportul

Dacă reparați e-mailul pentru altcineva — un client, șeful dvs., firma ale cărei facturi erau respinse — terminați treaba cu dovadă. Re-rulați scanarea gratuită după ce DNS-ul se stabilizează și trimiteți raportul clasificat. Arată SPF, DKIM și DMARC devenind verzi în limbaj simplu pe care îl poate citi un proprietar de afaceri, și este artefactul de care vor avea nevoie data viitoare când reînnoirea asigurării cibernetice sau un chestionar de securitate al clienților întreabă dacă e-mailul lor este autentificat. Remediat este bine; dovedit remediat este ceea ce vă face plătit și îi protejează pe ei.

Verificați gratuit domeniul

Vedeți pe ce picior vă eșuează Microsoft — SPF, DKIM, DMARC — privat și numai pentru proprietar.

Verificați domeniul → · Corectați DMARC → · DKIM trece dar DMARC eșuează → · Cum clasificăm → · Doar date agregate. Date stocate și procesate în UE.