Defaults.Exposed › Fikser › Guides
Outlook avviser e-posten din: 550 5.7.515, 550 5.7.509 og compauth=fail, forklart og fikset (2026)
Publisert 2026-07-08
Tall per 2026-06-29 · metodikk v7. Samlet sensusdata for 261 millioner graderte domener. Se hvordan vi graderer.
To forskjellige Microsoft-systemer avviser e-post. Forbruker-Outlook.com avviser høyvolum-avsendere som feiler autentisering (550 5.7.515, håndhevet siden mai 2025); Exchange Online avviser e-post som feiler din egen DMARC-avvisingspolicy (550 5.7.509). Av 10,205,070 domener som autoriserer spf.protection.outlook.com, har 85.0% streng SPF men bare 21.7% håndhever DMARC, ifølge Defaults.Exposed-sensus over 261,086,232 domener.
De fleste «Outlook avviser e-posten min»-problemer er ikke avvisninger i det hele tatt — det er e-post som stille havner i Søppel med compauth=fail i overskriftene. Denne veiledningen dekoder Microsoft-kodene, viser deg hvordan du leser Authentication-Results-overskriften, og går gjennom fiksen i rekkefølge: bekreft SPF, aktiver DKIM for det egendefinerte domenet, publiser og håndhev DMARC, test på nytt.
Hvilken Microsoft-feil har du egentlig?
Microsoft kjører to separate mottaksflater, og de avviser av forskjellige årsaker. Match symptomet ditt først — feil diagnose kaster bort en dag.
| Kode / signal | Hvor det kommer fra | Hva det betyr | Data per 2026-06-29 |
|---|---|---|---|
| 550 5.7.515 | Forbruker-Outlook.com / Hotmail / Live | Du sender >5 000 meldinger/dag til forbruker-Outlook og feiler autentiseringskravene (SPF + DKIM + DMARC), håndhevet siden mai 2025 | — |
| 550 5.7.509 | Exchange Online / EOP (bedriftsleietakere) | Mottaksserveren respekterte ditt eget domenes DMARC p=reject — e-posten din feilet DMARC | Bare 10.59% av alle 261,086,232 graderte domener håndhever DMARC |
| 550 5.7.511 | Exchange Online / EOP | Sendingsadressen eller -domenet ditt er på mottakerorganisasjonens eller Microsofts forbudt-avsender-liste | — |
| S3140 / S3150 | Forbruker-Outlook.com | Sending-IP-en din har dårlig omdømme — en blokkering, ikke en autentiseringsfeil | — |
compauth=fail (overskrifter) | Begge flater — det vanligste tilfellet | E-post ble godtatt men søppelkategorisert: Microsofts sammensatte autentisering feilet. Ingen avvisning, ingen NDR — bare søppelmappen | Av 10,205,070 M365-sendende domener håndhever bare 21.7% DMARC |
Eksakt NDR-ordlyd endres; bekreft strengene du siterer mot en live avvisning før du stoler på dem.
Hva betyr 550 5.7.515?
Det er forbruker-Outlook.com/Hotmail-kravet, ikke en Microsoft 365-leietakerfeil. Siden mai 2025 må avsendere av mer enn 5 000 meldinger per dag til forbruker-Outlook-adresser bestå SPF, bestå DKIM, og publisere en DMARC-post (minst p=none) justert med Fra-domenet. Feiler den grensen og forbruker-Outlook avviser med ordlyd som:
550 5.7.515 Access denied, sending domain [dittdomene.com] does not meet the required authentication level.
To ting dette ikke er: det er ikke et 2026-mandat (hvis e-posten nettopp begynte å bli avvist, endret volumet ditt eller DNS-en seg, ikke regelen), og det handler ikke om mottakerens M365-leietakerinnstillinger. Fiksen er autentiseringsstigen nedenfor — og tilfeldige kampanjedager som krysser 5 000/dag teller.
Hva betyr 550 5.7.509?
Denne kommer fra Exchange Online Protection på bedriftsleietakere, og betyr at din egen DMARC-policy respekteres:
550 5.7.509: Access denied, sending domain [dittdomene.com] does not pass DMARC verification and has a DMARC policy of reject.
Les det nøye — det er ikke Microsoft som er vanskelig. Domenet ditt publiserer p=reject, denne meldingen feilet DMARC, og mottakeren gjorde nøyaktig det du ba om. Hvis den avviste e-posten er legitim, er en sendingskilde (et nyhetsbrevverktøy, et CRM, en skann-til-e-post-enhet) ikke autentisert på en justert måte. Svekk ikke policyen; gi den kilden justert SPF eller DKIM — se fiks DMARC og fra p=none til p=reject.
Hvorfor søppelkategoriserer Outlook e-posten min med compauth=fail i stedet for å avvise den?
De fleste Microsoft-leveranseproblemene produserer aldri en avvisning. Meldingen godtas, scores, og arkiveres i Søppel — det eneste beviset er Authentication-Results-overskriften. I mottakerens postkasse (eller din egen outlook.com-testpostkasse), åpne meldingen, velg Vis meldingskilde, og finn linjen:
Authentication-Results: spf=pass ... dkim=fail ... dmarc=fail action=none ... compauth=fail reason=001
compauth er Microsofts sammensatte autentisering-dom: selv når et domene ikke publiserer noen DMARC-post, anvender Microsoft implisitte, DMARC-lignende sjekker. Vanlig observerte verdier:
compauth=fail reason=000— meldingen feilet eksplisitt autentisering: domenets DMARC-policy er karantene/avvisning og meldingen feilet den.compauth=fail reason=001— meldingen feilet implisitt autentisering: domenet publiserer ingen (eller ikke nok) auth-poster, og meldingen så ikke ut som om den kom fra deg. Den klassiske «vi satte aldri opp DKIM/DMARC»-signaturen.compauth=fail reason=6xx— implisitte-autentisering-feil-varianter;601betyr spesifikt at sendingsdomenet er ett av organisasjonens egne aksepterte domener (intra-org-forfalskning, selv-til-selv).
Lærdommen: på Microsoft, les overskriften, ikke bare NDR. spf=-, dkim=- og dmarc=-dommene på den samme linjen forteller deg nøyaktig hvilket ben som skal fikses.
Hvordan fikser du Outlook-avvisninger og søppelkategorisering?
- Kjør den gratis skanningen først. Den graderer SPF, DKIM og DMARC i én omgang og viser hvilket ben som feiler før du rører DNS.
- Bekreft SPF — vanligvis allerede i orden på Microsoft 365. Standardposten er
v=spf1 include:spf.protection.outlook.com -all, og M365-oppsett legger den der: 85.0% av de 10,205,070 domenene som autoriserer spf.protection.outlook.com slutter allerede i streng-all(data per 2026-06-29). Én sikkerhetsventil: mottakere evaluerer SPF mot Return-Path (RFC5321.MailFrom)-domenet, ikke Fra-overskriften — slik at et nyhetsbrevverktøy kan bestå SPF på sitt sprette-domene mens det ikke gjør noe for ditt. Det er grunnen til at trinn 3 og 4 betyr mer. - Aktiver DKIM for det egendefinerte domenet — to velger-CNAME-er. M365 signerer med en unjustert
onmicrosoft.com-standard til du slår på egendefinert-domene-signering: publiserselector1._domainkey- ogselector2._domainkey-CNAME-er som peker på leietakerens nøkler, og aktiver deretter signering i Defender-portalen. Fullstendig klikk-sti: sett opp DKIM på Microsoft 365. Hvis DKIM viser «pass» men DMARC feiler fortsatt, er du i standard-signatur-fellen. - Publiser DMARC, og håndhev det deretter. Start med
v=DMARC1; p=none; rua=mailto:...for å få rapporter, fiks alle legitime kilder det avslører, og skru deretter opp tilp=quarantineogp=reject— den trinnvise stien er i fiks DMARC. Dette er trinnet de fleste Microsoft-bedrifter hopper over: bare 21.7% av M365-sendende domener håndhever DMARC. - Test på nytt ved å lese overskriften. Send til en forbruker-outlook.com-postkasse, åpne meldingskilden, og bekreft
spf=pass,dkim=pass,dmarc=passogcompauth=pass. - Høyvolum-avsendere: møt forbruker-Outlook-grensen. Over 5 000/dag trenger du også en gyldig, overvåket Fra/svar-til, fungerende avmelding, og rene lister — autentisering rydder opp 5.7.515; klageraten holder deg unna S3140/S3150 IP-blokkeringer. Hvis du allerede er IP-blokkert, fjerner ikke fiksen av SPF/DKIM/DMARC blokkeringen: be om avlistning gjennom Microsofts senderstøtte, og behandle autentisering som grunnen til at du ikke vil være tilbake.
Hvorfor feiler så mange Microsoft 365-domener fortsatt?
Fordi standarden gjør det første trinnet for deg og ingen av de andre. Blant de 10,205,070 domenene som autoriserer spf.protection.outlook.com, bærer 85.0% streng SPF — posten M365 gir deg ved oppsett — men bare 21.7% håndhever DMARC, ifølge Defaults.Exposed-sensus over 261,086,232 domener. M365 gir deg streng SPF som standard, og deretter stopper de fleste leietakere der — nøyaktig populasjonen compauth var bygget for å fange (om enn fortsatt foran de 10.59% DMARC-håndhevelse over alle graderte domener). Full leverandørsammenligning: vår e-postleverandør SPF-ligatabell.
Ofte stilte spørsmål
Er 550 5.7.515 en Microsoft 365-feil? Nei. Den kommer fra forbruker-Outlook.com/Hotmail og retter seg mot avsendere av >5 000 meldinger/dag, håndhevet siden mai 2025. Exchange Online-avvisninger for bedrifter bruker forskjellige koder — oftest 550 5.7.509 (din DMARC-avvisningspolicy) eller 5.7.511 (forbudt avsender).
Vi fikk 550 5.7.509 men e-posten var legitim — bør vi droppe p=reject?
Nei — policyen din fanget en uautentisert kilde, som er den som virker. Finn kilden i overskriften eller DMARC-rapportene og gi den justert DKIM (eller justert SPF). Å svekke til p=none gjenåpner eksakt-domene-forfalskning for alle.
Betyr compauth=fail at noen forfalsker oss?
Ikke nødvendigvis. reason=001 betyr vanligvis at din egen e-post ikke kan bevise at den er din — ingen justert DKIM, ingen DMARC. Bare 21.7% av de 10,205,070 M365-sendende domenene håndhever DMARC (data per 2026-06-29), slik at Microsoft anvender implisitte sjekker på alle andre, og uautentisert legitim e-post feiler dem også.
Jeg sender færre enn 5 000 e-poster om dagen — kan jeg ignorere dette?
Du unngår 550 5.7.515, men ikke Søppel-mappen: compauth gjelder ved hvilket som helst volum. Gmail kjører det samme — se Gmail 550 5.7.26-veiledningen. Fiksene er gratis; barrieren er bevissthet, ikke kostnad.
Send eieren rapporten
Hvis du fikser e-post for noen andre — en klient, sjefen din, firmaet hvis fakturaer ble avvist — fullfør jobben med bevis. Kjør den gratis skanningen på nytt etter at DNS er avgjort og videresend den graderte rapporten. Den viser SPF, DKIM og DMARC som går grønt på et enkelt norsk en bedriftseier kan lese, og det er artefakten de trenger neste gang fornyelse av cyberforsikring eller et kund-sikkerhets-spørreskjema spør om e-posten er autentisert. Fikset er bra; beviselig fikset er det som betaler deg og dekker dem.
Sjekk domenet ditt gratis
Se hvilket ben Microsoft feiler deg på — SPF, DKIM, DMARC — privat og kun for eieren.
Sjekk domenet ditt → · Fiks DMARC → · DKIM består men DMARC feiler → · Hvordan vi graderer → · Kun aggregerte data. Data lagret og behandlet i EU.