Defaults.Exposed › Åtgärder › Guides

Outlook avvisar din e-post: 550 5.7.515, 550 5.7.509 och compauth=fail, förklarade och åtgärdade (2026)

Publicerad 2026-07-08

Siffror från 2026-06-29 · metodik v7. Aggregerade censusdata över 261 miljoner graderade domäner. Se hur vi graderar.

Två olika Microsoft-system avvisar e-post. Konsument-Outlook.com studsar volymhöga avsändare som misslyckas med autentisering (550 5.7.515, tillämpat sedan maj 2025); Exchange Online studsar e-post som misslyckas med din egna DMARC-avvisningspolicy (550 5.7.509). Av 10,205,070 domäner som auktoriserar spf.protection.outlook.com har 85.0% strikt SPF men bara 21.7% tillämpar DMARC, enligt Defaults.Exposed-censuset med 261,086,232 domäner.

De flesta “Outlook avvisar min e-post”-problem är inga avvisningar alls — de är e-post som tyst landar i Skräppost med compauth=fail i rubrikerna. Den här guiden avkodar Microsoft-koderna, visar hur du läser Authentication-Results-rubriken och går igenom fixen i ordning: bekräfta SPF, aktivera DKIM för din anpassade domän, publicera och tillämpa DMARC, testa igen.

Vilket Microsoft-fel har du egentligen?

Microsoft kör två separata mottagningsytor, och de avvisar av olika skäl. Matcha ditt symptom först — fel diagnos slösar en dag.

Exakt NDR-formulering ändras; verifiera strängarna du citerar mot en live studs innan du förlitar dig på dem.

Vad betyder 550 5.7.515?

Det är konsument-Outlook.com/Hotmail-kravet, inte ett Microsoft 365-klientfel. Sedan maj 2025 måste avsändare av mer än 5 000 meddelanden per dag till konsument-Outlook-adresser godkännas med SPF, godkännas med DKIM och publicera en DMARC-post (minst p=none) anpassad till From-domänen. Misslyckas med den ribban och konsument-Outlook avvisar med formulering som:

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

Två saker det inte är: det är inte ett 2026-mandat (om din e-post just börjat studsa, ändrades din volym eller DNS, inte regeln), och det handlar inte om mottagarens M365-klientinställningar. Fixen är autentiseringsstegen nedan — och enstaka kampanjdagar som passerar 5 000/dag räknas.

Vad betyder 550 5.7.509?

Den här kommer från Exchange Online Protection på affärsklienter, och den betyder att din egna DMARC-policy hedras:

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

Läs det noga — det är inte Microsoft som är svårt. Din domän publicerar p=reject, det här meddelandet misslyckades med DMARC, och mottagaren gjorde exakt vad du bad om. Om den studsade e-posten är legitim är någon sändande källa (ett nyhetsbrevverktyg, ett CRM, en scan-till-e-post-enhet) inte autentiserad på ett anpassat sätt. Försvaga inte policyn; ge den källan anpassad SPF eller DKIM — se åtgärda DMARC och från p=none till p=reject.

Varför sorterar Outlook min e-post i skräppost med compauth=fail istället för att studsa den?

De flesta Microsoft-leveransproblem producerar aldrig en studs. Meddelandet accepteras, poängsätts och arkiveras i Skräppost — det enda beviset är Authentication-Results-rubriken. I mottagarens postlåda (eller din egna outlook.com-testpostlåda), öppna meddelandet, välj Visa meddelandekälla och hitta raden:

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

compauth är Microsofts sammansatta autentiserings-dom: även när en domän inte publicerar någon DMARC-post tillämpar Microsoft implicita, DMARC-liknande kontroller. Vanliga värden:

• compauth=fail reason=000 — meddelandet misslyckades med explicit autentisering: din domäns DMARC-policy är quarantine/reject och meddelandet misslyckades med den.
• compauth=fail reason=001 — meddelandet misslyckades med implicit autentisering: din domän publicerar inga (eller inte tillräckliga) autentiseringsposter, och meddelandet såg inte ut att komma från dig. Den klassiska “vi konfigurerade aldrig DKIM/DMARC”-signaturen.
• compauth=fail reason=6xx — implicit-autentiseringsfel-varianter; 601 specifikt betyder att den sändande domänen är en av din organisations egna accepterade domäner (intra-org-spoofing, self-to-self).

Lärdomen: på Microsoft, läs rubriken, inte bara NDR:et. spf=-, dkim=- och dmarc=-domarna på samma rad talar om exakt vilket ben du ska åtgärda.

Hur åtgärdar du Outlook-avvisningar och skräppost-sortering?

1. Kör den kostnadsfria sökningen först. Den betygsätter din SPF, DKIM och DMARC i ett svep och visar vilket ben som misslyckas innan du rör DNS.
2. Bekräfta SPF — vanligtvis redan fine på Microsoft 365. Standardposten är v=spf1 include:spf.protection.outlook.com -all, och M365-konfigurationen lägger dit den: 85.0% av de 10,205,070 domänerna som auktoriserar spf.protection.outlook.com slutar redan med strikt -all (data per 2026-06-29). En varning: mottagare utvärderar SPF mot Return-Path (RFC5321.MailFrom)-domänen, inte From-rubriken — så ett nyhetsbrevverktyg kan godkännas med SPF på dess studs­domän utan att göra något för din. Det är därför steg 3 och 4 spelar större roll.
3. Aktivera DKIM för din anpassade domän — två selektor-CNAMEs. M365 signerar med en oanpassad onmicrosoft.com-standard tills du slår på anpassad domänsignering: publicera selector1._domainkey- och selector2._domainkey-CNAMEer som pekar på din klientorganisations nycklar, aktivera sedan signering i Defender-portalen. Fullständig klick-väg: konfigurera DKIM på Microsoft 365. Om DKIM visar “pass” men DMARC fortfarande misslyckas befinner du dig i standardsignatursfällan.
4. Publicera DMARC, tillämpa det sedan. Börja med v=DMARC1; p=none; rua=mailto:... för att få rapporter, åtgärda varje legitim källa det avslöjar, trappa sedan upp till p=quarantine och p=reject — den stegvisa vägen finns i åtgärda DMARC. Det här är steget de flesta Microsoft-installationer hoppar över: bara 21.7% av M365-sändande domäner tillämpar DMARC.
5. Testa igen genom att läsa rubriken. Skicka till en konsument-outlook.com-postlåda, öppna meddelandekällan och bekräfta spf=pass, dkim=pass, dmarc=pass och compauth=pass.
6. Volymhöga avsändare: uppfyll konsument-Outlook-ribban. Över 5 000/dag behöver du också en giltig, övervakad From/svara-till, fungerande avprenumeration och rena listor — autentisering rensar 5.7.515; klagomålsfrekvens håller dig borta från S3140/S3150 IP-block. Om du redan är IP-blockad, åtgärdar SPF/DKIM/DMARC inte blocket: begär avlistning via Microsofts avsändarstöd och behandla autentisering som anledningen till att du inte kommer tillbaka.

Varför misslyckas så många Microsoft 365-domäner fortfarande?

Eftersom standarden gör det första steget åt dig och ingen av resten. Bland de 10,205,070 domänerna som auktoriserar spf.protection.outlook.com bär 85.0% strikt SPF — posten M365 ger dig vid konfiguration — men bara 21.7% tillämpar DMARC, enligt Defaults.Exposed-censuset med 261,086,232 domäner. M365 ger dig strikt SPF som standard, sedan stannar de flesta klienter där — exakt den population compauth byggdes för att fånga (dock fortfarande steget före 10.59% DMARC-tillämpning bland alla graderade domäner). Fullständig leverantörsjämförelse: vår e-postleverantörs SPF-liga-tabell.

Vanliga frågor

Är 550 5.7.515 ett Microsoft 365-fel? Nej. Det kommer från konsument-Outlook.com/Hotmail och riktar sig till avsändare av >5 000 meddelanden/dag, tillämpat sedan maj 2025. Affärs-Exchange Online-avvisningar använder olika koder — vanligast 550 5.7.509 (din DMARC-avvisningspolicy) eller 5.7.511 (förbjuden avsändare).

Vi fick 550 5.7.509 men e-posten var legitim — ska vi sänka p=reject? Nej — din policy fångade en oautentiserad källa, vilket är den som fungerar. Hitta källan i rubriken eller dina DMARC-rapporter och ge den anpassad DKIM (eller anpassad SPF). Att försvaga till p=none öppnar exakt-domän-spoofing för alla igen.

Betyder compauth=fail att någon förfalskar oss? Inte nödvändigtvis. reason=001 betyder vanligtvis att din egna e-post inte kan bevisa att den är din — ingen anpassad DKIM, ingen DMARC. Bara 21.7% av de 10,205,070 M365-sändande domänerna tillämpar DMARC (data per 2026-06-29), så Microsoft tillämpar implicita kontroller på alla andra, och oautentiserad legitim e-post misslyckas med dem också.

Jag skickar färre än 5 000 e-postmeddelanden per dag — kan jag ignorera detta? Du undviker 550 5.7.515, men inte skräppostmappen: compauth gäller vid vilken volym som helst. Gmail kör samma spel — se Gmail 550 5.7.26-guiden. Fixarna är gratis; barriären är medvetenhet, inte kostnad.

Skicka ägaren rapporten

Om du åtgärdar e-post för någon annan — en kund, din chef, företaget vars fakturor studsade — avsluta jobbet med bevis. Kör om den kostnadsfria sökningen efter att DNS har stabiliserats och vidarebefordra den graderade rapporten. Den visar SPF, DKIM och DMARC som slår grönt på ett klarspråk som en företagsägare kan läsa, och det är artefakten de behöver nästa gång förnyelsen av cyberförsäkringen eller en kundssäkerhetsenkät frågar om deras e-post är autentiserad. Åtgärdat är bra; bevisligen åtgärdat är vad som ger dig betalt och dem täckta.

Kontrollera din domän kostnadsfritt

Se vilket ben Microsoft misslyckas dig på — SPF, DKIM, DMARC — privat och enbart för ägaren.

Kontrollera din domän → · Åtgärda DMARC → · DKIM godkänns men DMARC misslyckas → · Hur vi graderar → · Enbart aggregerade data. Data lagras och behandlas inom EU.