Defaults.Exposed › Oplossingen › Guides
Outlook weigert uw e-mail: 550 5.7.515, 550 5.7.509 en compauth=fail, uitgelegd en opgelost (2026)
Gepubliceerd 2026-07-08
Cijfers per 2026-06-29 · methodologie v7. Geaggregeerde censusgegevens over 261 miljoen beoordeelde domeinen. Zie hoe wij beoordelen.
Twee verschillende Microsoft-systemen weigeren mail. Consumenten-Outlook.com bounce’t grootvolume-afzenders die de authenticatie niet doorstaan (550 5.7.515, gehandhaafd sinds mei 2025); Exchange Online bounce’t mail die het eigen DMARC-reject-beleid niet doorstaat (550 5.7.509). Van 10.205.070 domeinen die spf.protection.outlook.com autoriseren, heeft 85,0% strikte SPF maar handhaaft slechts 21,7% DMARC, volgens de Defaults.Exposed-census van 261.086.232 domeinen.
De meeste “Outlook weigert mijn e-mail”-problemen zijn helemaal geen weigeringen — het is mail die stilletjes in Ongewenste e-mail belandt met compauth=fail in de headers. Deze gids ontcijfert de Microsoft-codes, laat zien hoe u de Authentication-Results-header leest, en doorloopt de oplossing in volgorde: bevestig SPF, schakel DKIM voor uw aangepaste domein in, publiceer en handhaaf DMARC, test opnieuw.
Welke Microsoft-fout hebt u eigenlijk?
Microsoft draait twee afzonderlijke ontvangstsystemen, en ze weigeren om verschillende redenen. Vergelijk eerst uw symptoom — de verkeerde diagnose kost een dag.
| Code / signaal | Waar het vandaan komt | Wat het betekent | Gegevens per 2026-06-29 |
|---|---|---|---|
| 550 5.7.515 | Consumenten Outlook.com / Hotmail / Live | U verstuurt >5.000 berichten/dag naar consumenten-Outlook en voldoet niet aan de authenticatievereisten (SPF + DKIM + DMARC), gehandhaafd sinds mei 2025 | — |
| 550 5.7.509 | Exchange Online / EOP (zakelijke tenants) | De ontvangende server respecteerde het DMARC-beleid van uw eigen domein p=reject — uw mail faalde DMARC | Slechts 10,59% van alle 261.086.232 beoordeelde domeinen handhaaft DMARC |
| 550 5.7.511 | Exchange Online / EOP | Uw verzendadres of -domein staat op de verboden-afzenderlijst van de ontvangende organisatie of van Microsoft | — |
| S3140 / S3150 | Consumenten-Outlook.com | Uw verzend-IP heeft een slechte reputatie — een blokkade, geen authenticatiefout | — |
compauth=fail (headers) | Beide systemen — het meest voorkomende geval | Mail werd geaccepteerd maar naar Ongewenste e-mail verplaatst: Microsoft’s samengestelde authenticatie faalde. Geen bounce, geen NDR — alleen de spammap | Van 10.205.070 M365-verzenddomeinen handhaaft slechts 21,7% DMARC |
De exacte NDR-bewoording verandert; controleer citeerde teksten tegen een echte bounce voordat u erop vertrouwt.
Wat betekent 550 5.7.515?
Het is de vereiste van consumenten-Outlook.com/Hotmail, geen fout van een Microsoft 365-tenant. Sinds mei 2025 moeten afzenders van meer dan 5.000 berichten per dag naar consumenten-Outlook-adressen SPF doorstaan, DKIM doorstaan, en een DMARC-record publiceren (minimaal p=none) dat aligneert met het From-domein. Voldoet u niet aan die lat, dan weigert consumenten-Outlook met een tekst zoals:
550 5.7.515 Access denied, sending domain [yourdomain.com] does not meet the required authentication level.
Twee dingen die dit niet is: het is geen mandaat van 2026 (als uw mail net begon te bouncen, veranderde uw volume of uw DNS, niet de regel), en het gaat niet over de M365-tenantinstellingen van de ontvanger. De oplossing is de authenticatieladder hieronder — en incidentele campagnedagen die 5.000/dag overschrijden, tellen ook mee.
Wat betekent 550 5.7.509?
Deze komt van Exchange Online Protection op zakelijke tenants, en betekent dat uw eigen DMARC-beleid wordt gerespecteerd:
550 5.7.509: Access denied, sending domain [yourdomain.com] does not pass DMARC verification and has a DMARC policy of reject.
Lees dat zorgvuldig — het is Microsoft niet die moeilijk doet. Uw domein publiceert p=reject, dit bericht faalde DMARC, en de ontvanger deed precies wat u vroeg. Als de gebouncete mail legitiem is, is een verzendbron (een nieuwsbrieftool, een CRM, een scan-naar-e-mailapparaat) niet op een gealigneerde manier geauthenticeerd. Verzwak het beleid niet; geef die bron gealigneerde SPF of DKIM — zie repareer DMARC en van p=none naar p=reject.
Waarom plaatst Outlook mijn mail met compauth=fail in Ongewenste e-mail in plaats van te bouncen?
De meeste Microsoft-aflevermiserie levert nooit een bounce op. Het bericht wordt geaccepteerd, beoordeeld en in Ongewenste e-mail geplaatst — het enige bewijs is de Authentication-Results-header. Open in het postvak van de ontvanger (of uw eigen testpostvak op outlook.com) het bericht, kies Berichtbron weergeven, en zoek de regel:
Authentication-Results: spf=pass ... dkim=fail ... dmarc=fail action=none ... compauth=fail reason=001
compauth is Microsoft’s oordeel over samengestelde authenticatie: zelfs als een domein geen DMARC-record publiceert, past Microsoft impliciete, DMARC-achtige controles toe. Vaak gezien waarden:
compauth=fail reason=000— het bericht faalde expliciete authenticatie: het DMARC-beleid van uw domein is quarantine/reject en het bericht faalde daaraan.compauth=fail reason=001— het bericht faalde impliciete authenticatie: uw domein publiceert geen (of onvoldoende) authenticatierecords, en het bericht leek niet van u te komen. De klassieke “we hebben nooit DKIM/DMARC ingesteld”-handtekening.compauth=fail reason=6xx— varianten van impliciete-authenticatiefouten;601betekent specifiek dat het verzenddomein een van de eigen geaccepteerde domeinen van uw organisatie is (spoofing binnen de organisatie, van uzelf naar uzelf).
De les: lees bij Microsoft de header, niet alleen de NDR. De oordelen spf=, dkim= en dmarc= op diezelfde regel vertellen u precies welk onderdeel u moet repareren.
Hoe lost u Outlook-weigeringen en het naar Ongewenste e-mail verplaatsen op?
- Voer eerst de gratis scan uit. Die beoordeelt uw SPF, DKIM en DMARC in één keer en laat zien welk onderdeel faalt voordat u aan DNS komt.
- Bevestig SPF — meestal al in orde bij Microsoft 365. Het standaardrecord is
v=spf1 include:spf.protection.outlook.com -all, en de M365-installatie plaatst het daar: 85,0% van de 10.205.070 domeinen die spf.protection.outlook.com autoriseren, eindigen al met een strikte-all(gegevens per 2026-06-29). Eén waarschuwing: ontvangers evalueren SPF tegen het Return-Path-domein (RFC5321.MailFrom), niet de From-header — dus een nieuwsbrieftool kan slagen voor SPF op zijn bounce-domein terwijl het niets doet voor het uwe. Daarom zijn stappen 3 en 4 belangrijker. - Schakel DKIM voor uw aangepaste domein in — twee selector-CNAME’s. M365 ondertekent met een niet-gealigneerde
onmicrosoft.com-standaard totdat u ondertekening voor het aangepaste domein inschakelt: publiceer de CNAME’sselector1._domainkeyenselector2._domainkeydie verwijzen naar de sleutels van uw tenant, en schakel vervolgens ondertekening in het Defender-portaal in. Volledig klikpad: DKIM instellen op Microsoft 365. Toont DKIM “geslaagd” maar faalt DMARC nog steeds, dan zit u in de standaardhandtekeningval. - Publiceer DMARC en handhaaf het vervolgens. Begin met
v=DMARC1; p=none; rua=mailto:...om rapporten te ontvangen, repareer elke legitieme bron die het onthult, schroef dan op naarp=quarantineenp=reject— het gefaseerde pad staat in repareer DMARC. Dit is de stap die de meeste Microsoft-shops overslaan: slechts 21,7% van de M365-verzenddomeinen handhaaft DMARC. - Test opnieuw door de header te lezen. Stuur naar een consumenten-outlook.com-postvak, open de berichtbron, en bevestig
spf=pass,dkim=pass,dmarc=passencompauth=pass. - Grootvolume-afzenders: voldoe aan de consumenten-Outlook-lat. Boven 5.000/dag hebt u ook een geldig, gemonitord From-/reply-to-adres, een werkende afmeldoptie en schone lijsten nodig — authenticatie ruimt 5.7.515 op; het klachtpercentage houdt u buiten IP-blokkades van S3140/S3150. Bent u al IP-geblokkeerd, dan heft het repareren van SPF/DKIM/DMARC de blokkade niet op: vraag verwijdering van de lijst aan via Microsoft’s afzenderondersteuning, en beschouw authenticatie als de reden dat u niet terugkomt.
Waarom falen zoveel Microsoft 365-domeinen nog steeds?
Omdat de standaardinstelling de eerste stap voor u doet en niets van de rest. Onder de 10.205.070 domeinen die spf.protection.outlook.com autoriseren, draagt 85,0% strikte SPF — het record dat M365 u bij de installatie geeft — maar handhaaft slechts 21,7% DMARC, volgens de Defaults.Exposed-census van 261.086.232 domeinen. M365 geeft u standaard strikte SPF, en dan stoppen de meeste tenants daar — precies de populatie waarvoor compauth is gebouwd (al blijft dit nog voor op de 10,59% DMARC-handhaving over alle beoordeelde domeinen). Volledige providervergelijking: onze ranglijst van e-mailprovider-SPF-sterkte.
Veelgestelde vragen
Is 550 5.7.515 een Microsoft 365-fout? Nee. Het komt van consumenten-Outlook.com/Hotmail en richt zich op afzenders van >5.000 berichten/dag, gehandhaafd sinds mei 2025. Zakelijke Exchange Online-weigeringen gebruiken andere codes — meestal 550 5.7.509 (uw DMARC-reject-beleid) of 5.7.511 (verboden afzender).
We kregen 550 5.7.509 maar de mail was legitiem — moeten we p=reject laten vallen?
Nee — uw beleid ving een niet-geauthenticeerde bron, en dat is het beleid dat werkt. Zoek de bron in de header of uw DMARC-rapporten en geef die gealigneerde DKIM (of gealigneerde SPF). Verzwakken naar p=none heropent exact-domeinspoofing voor iedereen.
Betekent compauth=fail dat iemand ons spooft?
Niet noodzakelijk. reason=001 betekent meestal dat uw eigen mail niet kan bewijzen dat hij van u is — geen gealigneerde DKIM, geen DMARC. Slechts 21,7% van de 10.205.070 M365-verzenddomeinen handhaaft DMARC (gegevens per 2026-06-29), dus past Microsoft impliciete controles toe op iedereen daarbuiten, en niet-geauthenticeerde legitieme mail faalt daar ook aan.
Ik verstuur minder dan 5.000 e-mails per dag — kan ik dit negeren?
U ontwijkt 550 5.7.515, maar niet de map Ongewenste e-mail: compauth geldt bij elk volume. Gmail speelt dezelfde kaart — zie de gids Gmail 550 5.7.26. De oplossingen zijn gratis; de barrière is bewustzijn, geen kosten.
Stuur de eigenaar het rapport
Repareert u e-mail voor iemand anders — een klant, uw baas, het bedrijf wiens facturen bounceten — rond de klus dan af met bewijs. Voer de gratis scan opnieuw uit zodra DNS is bijgetrokken en stuur het beoordeelde rapport door. Het laat in gewone taal zien dat SPF, DKIM en DMARC groen worden, leesbaar voor een bedrijfseigenaar, en het is het bewijsstuk dat ze nodig hebben de volgende keer dat de cyberverzekeringsverlenging of een beveiligingsvragenlijst van een klant vraagt of hun e-mail is geauthenticeerd. Opgelost is goed; aantoonbaar opgelost is wat u betaald krijgt en hen gedekt houdt.
Controleer uw domein gratis
Zie op welk onderdeel Microsoft u laat falen — SPF, DKIM, DMARC — privé en alleen voor de eigenaar.
Controleer uw domein → · Repareer DMARC → · DKIM slaagt maar DMARC faalt → · Hoe wij beoordelen → · Uitsluitend geaggregeerde gegevens. Gegevens opgeslagen en verwerkt in de EU.