Microsoft 550 5.7.1: Bericht bevat geen SPF/DKIM/DMARC-authenticatierecords (AS9031519)

Sinds 5 november 2026 melden e-mailbeheerders en gebruikers dat sommige berichten naar Microsoft-mailboxen worden geweigerd vanwege een fout in verband met authenticatie, waaronder e-mails van afzenders met een laag verzendvolume. Sommige beheerders brengen deze fouten in verband met ontbrekende DMARC-records, maar uit de meldingen blijkt niet dat er sprake is van een algemeen nieuw beleid van Microsoft. 

Opmerking: Het gemelde gedrag heeft betrekking op de e-maildiensten voor consumenten van Microsoft; er is nog geen algemene wijziging doorgevoerd voor zakelijke ontvangers van Microsoft 365.

De specifieke afwijzing luidt als volgt:

550 5.7.1 Bericht geweigerd: het bericht bevat geen SPF/DKIM/DMARC-authenticatierecords (AS9031519)

Als je dit afwijzingsbericht hebt ontvangen, moet je allereerst controleren of het domein in je zichtbare ‘Van’-adres een geldig DMARC-record heeft.

In deze handleiding wordt uitgelegd wat de foutmelding betekent, hoe je deze kunt onderzoeken en wat je moet doen als DMARC al voor je domein is geconfigureerd.

Hoe de Microsoft 550 5.7.1 DMARC-fout te verhelpen

Als u de foutmelding AS9031519 krijgt, volg dan deze stappen voor probleemoplossing voordat u wijzigingen aanbrengt in uw huidige configuratie voor e-mailverificatie.

1. Controleer het DMARC-record van je domein

Controleer eerst het domein in het zichtbare ‘Van’-adres van de geweigerde e-mail. Dit is het domein dat ontvangers zien wanneer ze je bericht ontvangen.

Gebruik de PowerDMARC DMARC-checker om het DMARC-record op te zoeken en te controleren of het record bestaat, een geldige syntaxis heeft en een effectief beleid specificeert.

Als er geen geldig DMARC-record wordt gevonden, moet u er wellicht een aanmaken.

Houd er rekening mee dat het feit dat een TXT-record begint met v=DMARC1, niet automatisch betekent dat uw DMARC-configuratie geldig is. Het record moet ook een geldig beleid en een geldige syntaxis bevatten.

2. Publiceer een DMARC-record als er nog geen is

Als uw domein nog geen DMARC-beleid heeft, kunt u er een aanmaken met behulp van de DMARC-recordgenerator.

Als je alleen wilt monitoren, gebruik dan een record dat er ongeveer zo uitziet:

Host/Naam: _dmarc
Type: TXT
Waarde: v=DMARC1; p=none; rua=mailto:[email protected]

Dit is wat elk onderdeel betekent:

• v=DMARC1 geeft aan dat het record een DMARC-beleid is.
• p=none geeft ontvangende servers de instructie om geen DMARC-quarantaine- of afwijzingsbeleid toe te passen op berichten die niet aan de DMARC-vereisten voldoen.
• rua geeft het e-mailadres aan waarop de samengevoegde DMARC-rapporten worden ontvangen.

Belangrijke overwegingen met betrekking tot DNS:

• Vervang example.com en [email protected] door uw eigen domein en rapportageadres. De rapportage-e-mailbox moet bestaan; anders dient u het adres en de installatie-instructies te gebruiken die door uw DMARC-monitoringservice zijn verstrekt.
• Publiceer het record bij _dmarc voor het betreffende domein. Sommige DNS-providers voegen automatisch je domeinnaam toe, dus controleer de interface voordat je de hostnaam invoert.
• Als er al een DMARC-record bestaat, overschrijf dit dan niet en publiceer geen duplicaat. Een domein moet één geldig DMARC-beleidsrecord hebben onder de betreffende DNS-naam.

Controleer na publicatie het openbare DNS-resultaat met behulp van een DMARC-checker, nadat de DNS-caches zijn vernieuwd. Stuur vervolgens een nieuwe test-e-mail naar de betreffende Microsoft-ontvanger. Eerder geweigerde berichten moeten mogelijk opnieuw worden verzonden.

Opmerking: Het publiceren van DMARC kan het probleem van ontbrekende records, dat in sommige gemelde gevallen is vastgesteld, verhelpen, maar het garandeert geen bezorging en lost niet alle mogelijke oorzaken van deze afwijzing op.

3. Controleer de SPF- en DKIM-authenticatie en of deze op elkaar zijn afgestemd

Het publiceren van DMARC is slechts een onderdeel van e-mailverificatie. U moet er ook voor zorgen dat uw legitieme verzendservices berichten correct verifiëren.

Volgens de door Microsoft gepubliceerde vereisten voor verzenders met een hoog verzendvolume moeten zowel SPF als DKIM de controle doorstaan. Om DMARC te laten slagen, moet ten minste één van deze mechanismen ook overeenkomen met het domein in het zichtbare „Van”-adres.

Controleer het volgende:

• SPF: Controleer of het verzendende IP-adres is geautoriseerd door het SPF-record voor het domein van de envelopafzender. Voor DMARC-afstemming moet dit domein overeenkomen met het zichtbare „Van”-domein.
• DKIM: Zorg ervoor dat uitgaande berichten worden ondertekend met een geldige DKIM-handtekening. Het ondertekenende domein (d=) moet overeenkomen met het zichtbare ‘Van’-domein, wil DKIM bijdragen aan een DMARC-pass.
• Microsoft 365 DKIM: Als u Microsoft 365 met een eigen domein gebruikt, schakel dan DKIM-ondertekening voor dat domein in in plaats van uitsluitend te vertrouwen op het standaardondertekeningsdomein van Microsoft.
• Externe afzenders: Controleer alle diensten die namens u e-mails versturen, waaronder marketingplatforms, CRM-systemen, aanbieders van transactionele e-mails en andere externe applicaties.

Houd er rekening mee dat het publiceren van SPF- en DKIM-records op zich nog geen bewijs is dat uw berichten de authenticatie doorstaan. U moet de daadwerkelijke authenticatieresultaten van de berichten die via elke dienst worden verzonden, controleren.

4. Houd DMARC-rapporten in de gaten op authenticatiefouten

Nadat u uw DMARC-record hebt gepubliceerd of gevalideerd, kunt u de geaggregeerde rapporten in de gaten houden om inzicht te krijgen in de manier waarop verschillende afzenders uw e-mails verifiëren.

Deze rapporten helpen je bij het vaststellen van:

• Legitieme afzenders die de SPF- en DKIM-controles doorstaan of niet doorstaan.
• Problemen met de configuratie die van invloed zijn op de DMARC-authenticatie.
• Ongeautoriseerde bronnen die proberen e-mails te versturen via uw domein.
• Verificatieproblemen die de bezorging van e-mails kunnen beïnvloeden.

Een DMARC-monitoringplatform zoals PowerDMARC kan deze rapporten samenvoegen tot een overzichtelijk dashboard, waardoor het eenvoudiger wordt om authenticatiefouten bij meerdere domeinen en verzendservices te onderzoeken.

Een toezichtsbeleid is niet hetzelfde als bescherming

Voor afzenders die te maken hebben met de gemelde afwijzing door Microsoft: publiceer een DMARC-record met p=none kan helpen om het acute probleem op te lossen. Maar als u dat als het einde van het proces beschouwt, blijven er belangrijke hiaten in de beveiliging van uw domein bestaan.

A p=none beleid geeft ontvangende mailservers de opdracht om DMARC-resultaten te controleren zonder handhavingsmaatregelen te nemen tegen berichten die niet voldoen. Het stelt een DMARC-beleid vast, maar het voorkomt niet dat niet-geverifieerde berichten de ontvangers bereiken. En tenzij het record een correct geconfigureerde rua rapportageadres bevat, hebt u wellicht weinig inzicht in hoe uw domein wordt gebruikt.

Die inzichtelijkheid is van groot belang. Zonder de DMARC-rapporten te bekijken, kunt u niet op betrouwbare wijze alle diensten identificeren die namens u berichten versturen, authenticatie- en afstemmingsfouten opsporen of legitiem verkeer onderscheiden van mogelijk domeinmisbruik.

Dit is wat organisaties over het hoofd dreigen te zien wanneer ze stoppen bij p=none:

• Onbekende afzenders: Het is mogelijk dat u niet weet welke platforms, applicaties of diensten van derden uw domein gebruiken om e-mail te verzenden.
• Aanhoudende blootstelling aan spoofing: Een beleid dat uitsluitend op monitoring is gericht, schrijft ontvangers niet voor om berichten die niet aan de DMARC-vereisten voldoen in quarantaine te plaatsen of te weigeren.
• Tekortkomingen in de authenticatie: Het hebben van SPF- en DKIM-records betekent niet automatisch dat DMARC wordt goedgekeurd. Ten minste één mechanisme moet worden goedgekeurd en overeenkomen met het domein dat zichtbaar is in het 'Van'-adres.
• Geen vooruitgang op het gebied van handhaving: Zonder rapporten te beoordelen en legitieme problemen met de afzenderbron op te lossen, is er geen duidelijke basis om over te stappen op een strenger DMARC-beleid.

De praktische aanpak is om het volgende te gebruiken: p=none als controlefase. Bekijk de resultaten, autoriseer legitieme verzendbronnen, los afstemmingsproblemen op en ga vervolgens verder met p=quarantaine of p=reject.

Het doel mag niet louter zijn om een rapport te publiceren dat voldoet aan een gerapporteerde bezorgingscontrole. Het moet zijn om elke dienst die e-mail verstuurt onder de naam van uw domein te begrijpen, te beheren en te beschermen.

Wat als je domein al een DMARC-record heeft?

Het ontbreken van een DMARC-record is niet de oorzaak van elke gemelde afwijzing met AS9031519. In discussies op Microsoft Q&A worden meldingen gedaan van sporadische storingen, waaronder gevallen waarin afzenders beweren dat SPF, DKIM en DMARC al correct zijn geconfigureerd.

Als je domein al DMARC heeft, ga dan na waarom de e-mail volledig is geweigerd, in plaats van nog een record aan te maken of je bestaande beleid te wijzigen.

Controleer het volgende:

1. Bekijk het volledige bounce-bericht: zoek naar de volledige diagnose, inclusief AS9031519, de ontvangende host en de tijdstempel.
2. Controleer het openbare DNS-record: Controleer of het DMARC-record geldig is en onder de juiste DNS-naam is gepubliceerd. Controleer ook of er geen dubbele records of syntaxfouten zijn.
3. Stel de afzender vast: ga na of de geweigerde e-mail afkomstig is van Microsoft 365, Google Workspace, een marketingplatform, een CRM-systeem of een andere dienst.
4. Controleer de daadwerkelijke authenticatieresultaten: bekijk de SPF-, DKIM- en DMARC-resultaten voor berichten die via de betreffende dienst zijn verzonden. Controleer of ten minste één goedgekeurd authenticatiemechanisme overeenkomt met het zichtbare ‘Van’-domein.
5. Vergelijk geslaagde en afgewezen pogingen zorgvuldig: een succesvol afgeleverd vergelijkingsbericht kan helpen bij het onderzoeken van je configuratie, maar aan de hand van de headers ervan kan niet worden vastgesteld wat er met een afzonderlijk afgewezen bericht is gebeurd.

Mocht het probleem aanhouden, neem dan contact op met uw e-mailprovider of de Microsoft-ondersteuning voor afzenders. Voeg de volledige diagnose, de UTC-tijdstempel, de ontvangende host en relevante verzendlogboeken toe. Verberg gevoelige informatie voordat u de logboeken openbaar maakt.

Uit sporadische meldingen van afwijzingen blijkt dat het probleem mogelijk verder gaat dan alleen ontbrekende DMARC-records. Ga er niet zomaar vanuit dat elk geval dezelfde onderliggende oorzaak heeft.

Waarom wijst Microsoft sommige e-mails zonder DMARC af?

De rapporten van november 2026 hebben de aandacht gevestigd op een mogelijke wijziging in de manier waarop de e-mailinfrastructuur voor consumenten van Microsoft authenticatiegegevens beoordeelt.

Om het verschil te begrijpen, is het belangrijk om het onlangs gemelde gedrag van AS9031519 los te zien van de eerder door Microsoft gepubliceerde vereisten voor afzenders met een hoog verzendvolume.

De door Microsoft gepubliceerde vereisten voor de authenticatie van e-mail met een hoog verzendvolume

Op 2 april 2025 kondigde Microsoft strengere vereisten voor e-mailverificatie voor verzenders met een hoog verzendvolume die gebruikmaken van zijn e-maildiensten voor consumenten.

De vereisten zijn op 5 mei 2025 van kracht geworden en gelden voor domeinen die meer dan 5.000 e-mails per dag versturen naar Outlook.com, Hotmail, Live.com en aanverwante consumentenadressen. In de ondersteuningsdocumentatie van Microsoft wordt de drempel omschreven als 5.000 of meer berichten waarbij hetzelfde domein in het zichtbare ‘Van’-adres wordt gebruikt.

Volgens deze gepubliceerde vereisten moeten verzenders van grote hoeveelheden:

• Publiceer geldige SPF- en DKIM-records, waarbij beide authenticatiecontroles worden doorstaan.
• Publiceer een geldig DMARC-record, waarbij in eerste instantie een p=none beleid.
• Zorg ervoor dat ten minste één verificatiemechanisme (SPF of DKIM) overeenkomt met het zichtbare „From“-domein, zodat DMARC wordt goedgekeurd.

Afzenders die niet aan deze vereisten voldoen, kunnen een afzonderlijke afwijzing ontvangen:

550 5.7.515 Toegang geweigerd; het verzendende domein voldoet niet aan het vereiste authenticatieniveau.

Dit verschilt van AS9031519. Het eerste heeft betrekking op de door Microsoft gepubliceerde vereisten voor afzenders met een hoog verzendvolume, terwijl het tweede de afwijzing in verband met authenticatie betreft die in november 2026 door operators is gemeld.

Wat kunnen we uit de rapporten van november 2026 opmaken?

In de recentere rapporten wordt melding gemaakt van afwijzingen die betrekking hebben op bepaalde afzenders die buiten de eerder gepubliceerde drempel voor grote volumes vallen.

Onderzoekers op het gebied van e-mailbezorging hebben de AS9031519-diagnose op 6 november 2026 vastgelegd in hun eigen observaties van uitgaande e-mail. Onder de onderzochte gevallen bevonden zich domeinen zonder DMARC-records, zelfs wanneer SPF en DKIM al waren geconfigureerd. Er werd ook gemeld dat de afwijzing met tussenpozen plaatsvond, waarbij sommige berichten van hetzelfde domein wel werden geaccepteerd.

Ook individuele gebruikers en e-mailbeheerders hebben het probleem gemeld in discussies op Microsoft Q&A. Het gaat onder meer om gevallen waarbij afzenders van Microsoft 365 e-mails sturen naar ontvangers met een Outlook.com- of Hotmail-adres, evenals meldingen dat berichten af en toe worden geweigerd.

Uit de beschikbare rapporten blijkt dat:

• Sommige afzenders met een laag verzendvolume hebben te maken gehad met afwijzingen.
• In verschillende onderzochte gevallen zijn ontbrekende DMARC-records vastgesteld.
• Voor sommige getroffen domeinen waren SPF en DKIM al geconfigureerd.
• Het publiceren van een geldig DMARC-record zou in sommige gevallen het probleem hebben opgelost.
• Niet elk bericht wordt afgewezen, en er zijn ook meldingen geweest van incidentele storingen.

Microsoft heeft nog niet publiekelijk bevestigd dat de DMARC-vereisten algemeen worden uitgebreid naar alle afzenders. De rapporten van november moeten daarom worden beschouwd als waargenomen gedrag, en niet als bewijs van een nieuw aangekondigd beleid dat van toepassing is op elke afzender met een laag verzendvolume.

Voor organisaties is de praktische aanpak om hun authenticatieconfiguratie te controleren, de volledige afwijzing te onderzoeken en de verdere ontwikkelingen in de gaten te houden, in plaats van ervan uit te gaan dat elke afwijzing dezelfde oorzaak heeft.

Wat houdt foutmelding 550 5.7.1 eigenlijk in?

De SMTP-statuscode 550 5.7.1 is een algemene afwijzingscode die aangeeft dat een bericht is geweigerd vanwege een probleem met betrekking tot autorisatie of beleid. Dit kan verschillende oorzaken hebben, waaronder onvolledige SPF-records, onjuiste configuraties van de connector of beveiligingsbeleidsregels van de ontvangende server.

In dit specifieke geval duidt het diagnostische bericht op een afwijzing in verband met authenticatie:

Het bericht bevat geen SPF/DKIM/DMARC-authenticatierecords (AS9031519)

Deze foutmelding is specifieker dan de algemene SMTP-statuscode. Ze wijst op een authenticatieprobleem dat is gemeld door de e-mailinfrastructuur voor consumenten van Microsoft, hoewel uit de beschikbare rapporten niet blijkt dat een ontbrekend DMARC-record de oorzaak is van elk geval.

Dit onderscheid is belangrijk omdat het oplossen van problemen met het verkeerde authenticatiemechanisme tijd kan kosten en ervoor kan zorgen dat het onderliggende leveringsprobleem onopgelost blijft.

Veelgestelde Vragen

1. Is p=none voldoende, of moet ik p=reject instellen?

Een ‘p=none’-beleid is een acceptabel uitgangspunt wanneer DMARC voor het eerst wordt geïmplementeerd. Als je echter alleen bij een beleid blijft dat uitsluitend op monitoring is gericht, blijft je domein kwetsbaar voor spoofing en identiteitsfraude. Het afdwingen van DMARC is de enige manier om te voorkomen dat aanvallers e-mails versturen vanuit je eigen domein. 

Zorg ervoor dat u uw beleid aanpast naar p=quarantine en uiteindelijk naar p=reject zodra u al uw legitieme afzenders hebt geverifieerd en eventuele afstemmingsproblemen hebt opgelost.

2. Hoe kan ik controleren of mijn nieuwe DMARC-record zichtbaar is?

Gebruik een DMARC-opzoektool om de openbare DNS-records van je domein op te vragen.

Controleer of het record bij de juiste _dmarc-hostnaam staat en of de syntaxis en het beleid ervan geldig zijn. Zodra de DNS-caches zijn vernieuwd, verstuur je een nieuwe test-e-mail naar de betreffende Microsoft-ontvanger om te controleren of de bezorging is verbeterd.

3. Kan de ontvanger deze fout zelf verhelpen?

Over het algemeen niet. DMARC wordt geconfigureerd in de DNS van het verzendende domein, dus de domeineigenaar of e-mailbeheerder moet dit onderzoeken en de nodige wijzigingen aanbrengen.

Als u een afgewezen bericht hebt ontvangen, neem dan contact op met de afzender en stuur hem of haar het volledige afwijzingsbericht door. De e-mailbeheerder van de afzender kan dan de authenticatiegegevens van het verzendende domein controleren en nagaan waarom het bericht is afgewezen.

Als de afzender bevestigt dat de authenticatie correct is geconfigureerd, maar het probleem blijft bestaan, moet de kwestie mogelijk worden onderzocht door zijn e-mailprovider of door Microsoft.

Hoe PowerDMARC je helpt bij het onderzoeken van afwijzingen van Microsoft-e-mails

Het beheren van e-mailauthenticatie voor meerdere domeinen en verzendservices vereist voortdurende monitoring. PowerDMARC helpt organisaties bij het controleren van hun authenticatieconfiguraties, het onderzoeken van storingen en het bijhouden van hun voortgang bij de implementatie van DMARC.

Met PowerDMARC kun je:

• E-mailverificatie controleren: DMARC-records valideren en de resultaten van SPF-, DKIM- en DMARC-verificatie voor al uw domeinen bijhouden.
• Onderzoek mislukte authenticatiepogingen: maak gebruik van geconsolideerde rapportages en authenticatieanalyses om problematische verzendbronnen, afstemmingsfouten en ongeautoriseerde activiteiten op te sporen.
• De voortgang van de handhaving volgen: houd uw DMARC-beleid bij, bekijk geaggregeerde rapporten en schakel over naar p=quarantine of p=reject met meer inzicht in uw e-mailecosysteem.

Start je gratis proefperiode van 15 dagen van PowerDMARC en krijg meer inzicht in uw e-mailauthenticatie, domeinbeveiliging en afleverbaarheid.