Defaults.Exposed › Rettelser › Guides
Outlook afviser din e-mail: 550 5.7.515, 550 5.7.509 og compauth=fail — forklaret og løst (2026)
Udgivet 2026-07-08
Tal fra 2026-06-29 · metodologi v7. Aggregerede censusdata på tværs af 261 millioner graderede domæner. Se hvordan vi graderer.
To forskellige Microsoft-systemer afviser mail. Forbruger-Outlook.com returnerer store afsendere, der fejler godkendelse (550 5.7.515, håndhævet siden maj 2025); Exchange Online returnerer mail, der fejler din egen DMARC reject-politik (550 5.7.509). Af 10,205,070 domæner, der godkender spf.protection.outlook.com, har 85.0% strict SPF, men kun 21.7% håndhæver DMARC, ifølge Defaults.Exposed-census over 261,086,232 domæner.
De fleste “Outlook afviser min e-mail”-problemer er slet ikke afvisninger — det er mail, der lydløst lander i Uønsket med compauth=fail i headerene. Denne vejledning dekoder Microsoft-koderne, viser dig, hvordan du læser Authentication-Results-headeren, og gennemgår løsningen i rækkefølge: bekræft SPF, aktivér DKIM for dit eget domæne, udgiv og håndhæv DMARC, gentest.
Hvilken Microsoft-fejl har du egentlig?
Microsoft kører to separate modtagelsesflader, og de afviser af forskellige årsager. Match dit symptom først — den forkerte diagnose spilder en dag.
| Kode / signal | Hvorfra det kommer | Hvad det betyder | Data pr. 2026-06-29 |
|---|---|---|---|
| 550 5.7.515 | Forbruger-Outlook.com / Hotmail / Live | Du sender >5.000 beskeder/dag til forbruger-Outlook og fejler godkendelseskravene (SPF + DKIM + DMARC), håndhævet siden maj 2025 | — |
| 550 5.7.509 | Exchange Online / EOP (erhvervs-lejere) | Den modtagende server håndhævede dit eget domænes DMARC p=reject — din mail fejlede DMARC | Kun 10.59% af alle 261,086,232 graderede domæner håndhæver DMARC |
| 550 5.7.511 | Exchange Online / EOP | Din afsenderadresse eller dit domæne er på modtagerorganisationens eller Microsofts forbudte-afsender-liste | — |
| S3140 / S3150 | Forbruger-Outlook.com | Dit afsender-IP har dårligt omdømme — en blokade, ikke en godkendelsesfejl | — |
compauth=fail (headers) | Begge flader — det mest almindelige tilfælde | Mail blev accepteret men sorteret i Uønsket: Microsofts composite authentication fejlede. Ingen returneringsbesked, ingen NDR — kun spammappen | Af 10,205,070 M365-afsendende domæner håndhæver kun 21.7% DMARC |
Præcis NDR-ordlyd ændres; verificér de strenge, du citerer, mod en live returneringsbesked inden du stoler på dem.
Hvad betyder 550 5.7.515?
Det er forbruger-Outlook.com/Hotmail-kravet, ikke en Microsoft 365-lejerfejl. Siden maj 2025 skal afsendere af mere end 5.000 beskeder om dagen til forbruger-Outlook-adresser bestå SPF, bestå DKIM og udgive en DMARC-post (mindst p=none) justeret med Fra-domænet. Fejler den bar, afviser forbruger-Outlook med ordlyd som:
550 5.7.515 Access denied, sending domain [ditdomæne.com] does not meet the required authentication level.
To ting dette ikke er: det er ikke et 2026-mandat (begyndte din mail just at returnere, ændrede dit volumen eller din DNS sig, ikke reglen), og det handler ikke om modtagerens M365-lejerindstillinger. Løsningen er godkendelsesrapporten nedenfor — og lejlighedsvise kampagnedage, der krydser 5.000/dag, tæller.
Hvad betyder 550 5.7.509?
Denne kommer fra Exchange Online Protection hos erhvervs-lejere, og den betyder, at din egen DMARC-politik håndhæves:
550 5.7.509: Access denied, sending domain [ditdomæne.com] does not pass DMARC verification and has a DMARC policy of reject.
Læs det omhyggeligt — det er ikke Microsoft, der er besværlig. Dit domæne udgiver p=reject, denne besked fejlede DMARC, og modtageren gjorde præcis, hvad du bad om. Er den returnerede mail legitim, er en afsenderkilde (et nyhedsbrevværktøj, et CRM, en scan-til-e-mail-enhed) ikke godkendt på en justeret måde. Svæk ikke politikken; giv den kilde justeret SPF eller DKIM — se ret DMARC og fra p=none til p=reject.
Hvorfor sorterer Outlook min mail i Uønsket med compauth=fail i stedet for at returnere den?
Det meste Microsoft-leveringspine producerer aldrig en returneringsbesked. Beskeden accepteres, scores og arkiveres i Uønsket — det eneste bevis er Authentication-Results-headeren. I modtagerens postkasse (eller din egen outlook.com-testpostkasse), åbn beskeden, vælg Vis beskedkilde, og find linjen:
Authentication-Results: spf=pass ... dkim=fail ... dmarc=fail action=none ... compauth=fail reason=001
compauth er Microsofts composite authentication-dom: selv når et domæne ikke udgiver en DMARC-post, anvender Microsoft implicitte, DMARC-lignende kontroller. Almindeligt sete værdier:
compauth=fail reason=000— beskeden fejlede eksplicit godkendelse: dit domænes DMARC-politik er quarantine/reject, og beskeden fejlede den.compauth=fail reason=001— beskeden fejlede implicit godkendelse: dit domæne udgiver ingen (eller ikke nok) godkendelses-poster, og beskeden lignede ikke noget, der kom fra dig. Det klassiske “vi har aldrig sat DKIM/DMARC op”-tegn.compauth=fail reason=6xx— implicit-godkendelse-fejlvarianter;601specifikt betyder, at afsenderdomænet er et af din organisations egne accepterede domæner (intra-org spoofing, selv-til-selv).
Læren: på Microsoft, læs headeren, ikke kun NDR’en. spf=-, dkim=- og dmarc=-dommene på den samme linje fortæller dig præcist, hvilket ben der skal løses.
Hvordan løser du Outlook-afvisninger og sortering i Uønsket?
- Kør den gratis scanning først. Den graderer din SPF, DKIM og DMARC i ét overblik og viser, hvilket ben der fejler, inden du rører DNS.
- Bekræft SPF — typisk allerede fin med Microsoft 365. Standardposten er
v=spf1 include:spf.protection.outlook.com -all, og M365-opsætning placerer den der: 85.0% af de 10,205,070 domæner, der godkender spf.protection.outlook.com, slutter allerede på strict-all(data pr. 2026-06-29). Én sikkerhedsforanstaltning: modtagere evaluerer SPF mod Return-Path (RFC5321.MailFrom)-domænet, ikke Fra-headeren — så et nyhedsbrevværktøj kan bestå SPF på sit bounce-domæne, mens det intet gør for dit. Det er grunden til, at trin 3 og 4 er vigtigere. - Aktivér DKIM for dit eget domæne — to selektor-CNAMEs. M365 signerer med et ujusteret
onmicrosoft.com-standard, indtil du slår signering med dit eget domæne til: udgivselector1._domainkey- ogselector2._domainkey-CNAMEs, der peger på din lejers nøgler, og aktivér derefter signering i Defender-portalen. Fuld klip-sti: opsæt DKIM på Microsoft 365. Viser DKIM “pass”, men DMARC fejler stadig, befinder du dig i standardsignatur-fælden. - Udgiv DMARC, og håndhæv den derefter. Start med
v=DMARC1; p=none; rua=mailto:...for at få rapporter, løs alle legitime kilder, de afslører, og stram derefter tilp=quarantineogp=reject— den trinvise vej er i ret DMARC. Dette er det trin, de fleste Microsoft-virksomheder springer over: kun 21.7% af M365-afsendende domæner håndhæver DMARC. - Gentest ved at læse headeren. Send til en forbruger-outlook.com-postkasse, åbn beskedkilden, og bekræft
spf=pass,dkim=pass,dmarc=passogcompauth=pass. - Store afsendere: opfyld forbruger-Outlook-niveauet. Over 5.000/dag skal du desuden have en gyldig, overvåget Fra/svar-til, fungerende afmelding og rene lister — godkendelse fjerner 5.7.515; klagerate holder dig ude af S3140/S3150 IP-blokader. Er du allerede IP-blokeret, fjerner løsning af SPF/DKIM/DMARC ikke blokaden: anmod om fjernelse fra listen via Microsofts afsendersupport, og behandl godkendelse som grunden til, at du ikke vender tilbage.
Hvorfor fejler så mange Microsoft 365-domæner stadig?
Fordi standarden gør det første trin for dig og ingen af resten. Blandt de 10,205,070 domæner, der godkender spf.protection.outlook.com, har 85.0% strict SPF — den post, M365 overrækker dig ved opsætning — men kun 21.7% håndhæver DMARC, ifølge Defaults.Exposed-census over 261,086,232 domæner. M365 giver dig strict SPF som standard, og derefter stopper de fleste lejere der — præcis den population, compauth er bygget til at fange (om end stadig foran de 10.59% DMARC-håndhævelse på tværs af alle graderede domæner). Fuld udbyder-sammenligning: vores e-mailudbyder SPF-rangliste.
Ofte stillede spørgsmål
Er 550 5.7.515 en Microsoft 365-fejl? Nej. Den kommer fra forbruger-Outlook.com/Hotmail og er rettet mod afsendere af >5.000 beskeder/dag, håndhævet siden maj 2025. Erhvervs-Exchange Online-afvisninger bruger andre koder — oftest 550 5.7.509 (din DMARC reject-politik) eller 5.7.511 (forbudt afsender).
Vi fik 550 5.7.509, men mailen var legitim — bør vi droppe p=reject?
Nej — din politik fangede en ugodkendt kilde, hvilket er den, der virker. Find kilden i headeren eller dine DMARC-rapporter og giv den justeret DKIM (eller justeret SPF). At svække til p=none genåbner eksakt-domæne-spoofing for alle.
Betyder compauth=fail, at nogen spoofer os?
Ikke nødvendigvis. reason=001 betyder typisk, at din egen mail ikke kan bevise, at den er din — ingen justeret DKIM, ingen DMARC. Kun 21.7% af de 10,205,070 M365-afsendende domæner håndhæver DMARC (data pr. 2026-06-29), så Microsoft anvender implicitte kontroller over for alle andre, og ugodkendt legitim mail fejler dem også.
Jeg sender færre end 5.000 e-mails om dagen — kan jeg ignorere dette?
Du undgår 550 5.7.515, men ikke Uønsket-mappen: compauth gælder ved ethvert volumen. Gmail kører det samme spil — se Gmail 550 5.7.26-guiden. Løsningerne er gratis; barrieren er bevidsthed, ikke pris.
Send ejeren rapporten
Løser du e-mail for nogen anden — en klient, din chef, firmaet, hvis fakturaer returnerede — afslut jobbet med bevis. Kør den gratis scanning igen, efter DNS er stabiliseret, og videresend den graderede rapport. Den viser SPF, DKIM og DMARC gå grøn på et klart sprog, virksomhedsejeren kan læse, og det er artefaktet, de har brug for næste gang fornyelsen af cyberforsikring eller et kundesikkerhedsspørgeskema spørger, om deres e-mail er godkendt. Løst er godt; bevisligt løst er det, der får dig betalt og dem dækket.
Kontrollér dit domæne gratis
Se, hvilket ben Microsoft fejler dig på — SPF, DKIM, DMARC — privat og kun for ejeren.
Kontrollér dit domæne → · Ret DMARC → · DKIM godkendes men DMARC fejler → · Sådan graderer vi → · Kun aggregerede data. Data opbevares og behandles i EU.