Eisen van Outlook voor afzenders sinds mei 2025 en de weigering 550 5.7.515

De bounce 550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level betekent dat Outlook.com uw bericht heeft geweigerd, omdat uw domein niet slaagde voor de SPF-, DKIM- en DMARC-controles die Microsoft van afzenders met grote volumes eist. De oplossing zit in uw DNS en in de configuratie van de systemen die uw e-mail versturen, niet in de inhoud van het bericht.

Microsoft kondigde de regels in april 2025 aan op zijn Microsoft Defender for Office 365-blog, met handhaving vanaf 5 mei 2025. Ze gelden voor Outlook.com, de consumentendienst van Microsoft, met adressen op outlook.com, hotmail.com en live.com.

De eisen volgen grotendeels wat Gmail en Yahoo in 2024 invoerden. Een domein dat voor de ene provider correct is ingericht, is dus meestal al een heel eind op weg voor de andere.

Wat Microsoft eist

Volgens de aankondiging moeten domeinen die meer dan 5.000 e-mails per dag naar Outlook.com sturen aan 3 voorwaarden voldoen:

• SPF moet slagen voor het verzendende domein, met een DNS-record dat de toegestane IP-adressen en hosts nauwkeurig opsomt.
• DKIM moet slagen, om de integriteit en echtheid van het bericht te bevestigen.
• DMARC moet gepubliceerd zijn met minstens p=none, en moet aligned zijn met SPF of DKIM (volgens Microsoft bij voorkeur met beide).

Microsoft noemt ook goede e-mailpraktijken voor grote afzenders en behoudt zich het recht voor afzenders die ze negeren te filteren of te blokkeren:

• Een geldig From- of Reply-To-adres dat het echte verzendende domein weerspiegelt en antwoorden kan ontvangen.
• Een duidelijke, werkende afmeldoptie voor marketing- en bulkmail.
• Regelmatig ongeldige adressen verwijderen en bounces afhandelen.
• Juiste onderwerpregels, geen misleidende headers en ontvangers die ermee instemden uw berichten te ontvangen.

Map Ongewenste e-mail of weigering

Volgens de oorspronkelijke aankondiging zou mail die niet voldoet eerst naar de map Ongewenste e-mail gaan. Microsoft werkte het bericht op 29 april 2025 bij: berichten die niet aan de authenticatie-eisen voldoen, worden geweigerd met de fout 550 5.7.515, vanaf 5 mei 2025, zoals oorspronkelijk gepland (bron).

In de praktijk is dat nuttig: een weigering verschijnt in uw verzendlogs en bouncerapporten, terwijl een stille verplaatsing naar Ongewenste e-mail lang onopgemerkt kan blijven.

Waarom een legitiem domein 5.7.515 krijgt

De gebruikelijke oorzaken zijn hiaten in de configuratie, niets kwaadaardigs:

Een verzendtool zonder DKIM voor uw domein. Nieuwsbriefplatforms, CRM's en facturatietools ondertekenen vaak met hun eigen domein, tenzij u hun DKIM-records aan het uwe toevoegt.

SPF dat slaagt voor de leverancier, niet voor u. Veel diensten gebruiken hun eigen return path, zodat SPF slaagt voor bounce.vendor.net. Zonder gealigneerde DKIM faalt DMARC.

Geen DMARC-record. Microsoft eist minstens p=none. Een ontbrekend _dmarc-record volstaat om te falen.

SPF boven de limiet voor lookups. SPF staat maximaal 10 DNS-lookups toe (RFC 7208, sectie 4.6.4). Voeg één dienst te veel toe en SPF geeft bij elk bericht een fout.

Een recente DNS-wijziging. Een migratie naar een nieuwe DNS-provider of mailhost waarbij een DKIM-selector of de SPF-include voor één dienst is weggevallen.

Zo vindt u de oorzaak

Begin met uw DNS:

dig +short TXT yourcompany.com | grep spf1
dig +short TXT _dmarc.yourcompany.com
dig +short TXT selector1._domainkey.yourcompany.com

Zoek vervolgens uit welk systeem het geweigerde bericht verstuurde. De bounce bevat meestal de oorspronkelijke headers. Stuur daarna vanuit datzelfde systeem een test naar een Outlook.com-adres dat u beheert en bekijk de header Authentication-Results. Microsoft legt in zijn documentatie over berichtheaders uit hoe u die leest. U zoekt naar:

spf=pass smtp.mailfrom=yourcompany.com
dkim=pass header.d=yourcompany.com
dmarc=pass header.from=yourcompany.com

Toont smtp.mailfrom of header.d het domein van de leverancier in plaats van het uwe, dan ligt het probleem bij de alignment. Staat er dkim=none, dan ondertekent het systeem helemaal niet.

Zo lost u het op

1. Publiceer een DMARC-record als u er geen hebt: v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com.
2. Stel in elke verzendtool DKIM in met uw eigen domein (de tool geeft u CNAME- of TXT-records om toe te voegen).
3. Ondersteunt de tool een eigen return path, laat dat dan naar een subdomein van u wijzen, zodat ook SPF aligned is.
4. Voeg SPF samen in één record, verwijder diensten die u niet meer gebruikt en blijf onder 10 lookups.
5. Stuur opnieuw een test naar Outlook.com en bevestig dat alle 3 controles slagen.
6. Zodra de DMARC-rapporten tonen dat alle legitieme mail slaagt, gaat u richting p=quarantine en later p=reject.

Microsoft verwijst afzenders voor verdere hulp naar zijn Outlook sender support portal. Onze gids over SPF, DKIM en DMARC legt elk record uitgebreider uit.

Korte checklist

• SPF slaagt, één record, onder 10 lookups.
• DKIM-ondertekening met uw domein in elk systeem dat mail verstuurt.
• DMARC gepubliceerd, minstens p=none, aligned met SPF of DKIM.
• Bouncelogs gecontroleerd op 5.7.515 na elke wijziging van DNS of provider.
• Een werkende afmeldoptie en opgeschoonde lijsten voor marketingmail.

De rol van Datahorses

Datahorses bewaakt elke dag van buitenaf de DNS-records die met uw e-mail te maken hebben, zodat een verwijderde DKIM-selector, een kapot SPF-record of een afgezwakt DMARC-beleid wordt opgemerkt voordat er bounces van komen. Een specialist beoordeelt elke wijziging en stuurt uw ontwikkelaar de exacte records om te herstellen. Bekijk wat wij bewaken, hoe we een bevinding afhandelen of het voorbeelddashboard.