Outlook en Hotmail weigeren e-mail zonder DMARC: zo los je het op

07 november 2026

Sinds donderdag 5 november 2026 weigert Microsoft een deel van de e-mail naar Outlook.com-, Hotmail-, Live- en MSN-adressen. Het gaat om e-mail van domeinnamen zonder DMARC-record. Je krijgt dan een bounce met de melding "Message lacks SPF/DKIM/DMARC Auth Records". Microsoft heeft dit niet aangekondigd, en het raakt niet alleen grote verzenders, maar ook een gewoon kantoor dat een offerte stuurt.

Hieronder lees je wat er aan de hand is, hoe je controleert of jouw domein risico loopt, en hoe je het oplost.

1. Wat is er aan de hand?

Begin 2024 schreef ik over de bezorging van je e-mails. Daarin legde ik uit hoe SPF, DKIM en DMARC werken, en dat Google strenger was geworden voor e-mail naar Gmail-adressen. Nu doet Microsoft iets vergelijkbaars, maar dan zonder aankondiging.

Sinds 5 november 2026 zien beheerders en e-maildiensten bounces van de servers die de consumenten-mailboxen van Microsoft afhandelen. Het gaat dus om adressen die eindigen op @outlook.com, @hotmail.com, @live.com en @msn.com (en de landversies zoals @hotmail.nl). Zakelijke Microsoft 365-mailboxen met een eigen domeinnaam vallen er voor zover bekend niet onder.

1.1 De foutmelding

De bounce die de afzender terugkrijgt, ziet er zo uit:

550 5.7.1 Message rejected:
Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)

Op de eerste dag kwam dezelfde melding nog zonder de code (AS9031519). Soms staat er nog een SPF-fout vóór:

550 5.7.23 The message was rejected because of
Sender Policy Framework violation

De tekst klinkt alsof je helemaal geen e-mailbeveiliging hebt. Dat valt meestal mee. Bij de domeinen die tot nu toe zijn onderzocht, stond SPF vaak goed en DKIM vaak ook. Wat ontbrak, was het DMARC-record.

1.2 Waarom je het makkelijk mist

Microsoft weigert niet alle e-mail van een getroffen domein, maar een deel. Het ene bericht naar een Hotmail-adres komt aan, het volgende niet, en als je het opnieuw verstuurt, lukt het soms wel. De medewerker die de e-mail verstuurde, ziet een bounce vol afkortingen, denkt aan een storing en gaat door. De ontvanger weet niet eens dat er een bericht was.

Voor bedrijven die veel e-mail sturen naar particulieren is dat vervelend. Denk aan facturen, afspraakbevestigingen, bevestigingen van een webshop-bestelling, of het antwoord op een contactformulier. Het lijkt dan alsof je iemand negeert.

1.3 Even opfrissen: SPF, DKIM en DMARC

Alle drie staan als record in de DNS van je domeinnaam:

SPF (Sender Policy Framework): de lijst met mailservers die e-mail mogen versturen namens jouw domein.
DKIM (DomainKeys Identified Mail): een digitale handtekening op elke e-mail. De ontvanger controleert daarmee dat de e-mail echt van jouw domein komt en onderweg niet is aangepast.
DMARC (Domain-based Message Authentication, Reporting and Conformance): controleert of SPF of DKIM past bij het domein dat de ontvanger als afzender ziet, en vertelt wat de ontvanger moet doen als dat niet zo is.

Een uitgebreidere uitleg lees je in mijn eerdere artikel.

2. Wat Microsoft en Google al eerder eisten

Strengere regels voor e-mail zijn niet nieuw. Ze begonnen bij de grote verzenders.

Wanneer	Wie	Voor wie	Wat
Februari 2024	Google (Gmail) en Yahoo	Alle verzenders: SPF of DKIM. Bulkverzenders (meer dan 5.000 berichten per dag): alles hieronder	SPF, DKIM en DMARC (minimaal `p=none`), plus eenvoudig afmelden voor nieuwsbrieven
Mei 2025	Microsoft (Outlook.com)	Verzenders van 5.000 of meer berichten per dag	SPF en DKIM moeten slagen, DMARC minimaal `p=none`. Anders: `550 5.7.515 Access denied`
November 2026	Microsoft (Outlook.com)	Ook kleine verzenders	Een deel van de e-mail zonder DMARC-record wordt geweigerd met `550 5.7.1`

De regel van mei 2025 was bedoeld voor nieuwsbrieven en andere grote verzenders. De meeste kleine bedrijven dachten terecht dat die niet voor hen gold. De nieuwe weigering is anders:

Hij raakt ook kleine verzenders. Een kort antwoord van een klein kantoor kan al terugkomen.
Hij is niet aangekondigd. Op 6 november had Microsoft nog niets gepubliceerd: geen bericht voor postmasters, geen blog, geen melding in de servicestatus.
Hij zegt niet wat er mis is. Een 5.7.515-bounce noemt de uitkomst van SPF, DKIM en DMARC. Deze melding zegt alleen dat er records ontbreken.

3. Is jouw domein getroffen?

Je domein loopt risico als het geen DMARC-record heeft. Dat kun je eenvoudig online controleren, zonder technische kennis.

3.1 Online controleren

Ga naar de DMARC Lookup van MXToolbox.
Vul je domeinnaam in, bijvoorbeeld jouwdomein.nl, en klik op DMARC Lookup.
Je ziet nu of je domein een DMARC-record heeft, en of daar fouten in zitten.

Meldt MXToolbox dat er geen DMARC-record is gevonden? Dan loopt je domein risico. Vraag je hostingprovider of websitebeheerder om het record in te stellen. In sectie 4 staat wat erin moet.

Wil je alles in een keer controleren? Gebruik dan de e-mailtest van Internet.nl. Dat is een Nederlandse test van onder andere de overheid en de internetsector. Die controleert je SPF-, DKIM- en DMARC-records en legt in het Nederlands uit wat er niet klopt.

Let op: een DMARC-record betekent nog niet dat al je e-mail goed aankomt. Ook SPF en DKIM moeten goed staan. Daarover lees je meer in sectie 4.

3.2 Welk domein controleer je?

Controleer het domein dat in het Van-adres (From) van je e-mail staat. Verstuur je e-mail vanuit meerdere domeinnamen, controleer ze dan allemaal.

3.3 Voor wie de terminal gebruikt

Op Linux en macOS kun je het ook in de terminal controleren. Vervang jouwdomein.nl door je eigen domeinnaam:

dig +short TXT _dmarc.jouwdomein.nl

Begint het antwoord met "v=DMARC1, dan heb je een DMARC-record. Krijg je niets terug, dan heb je er geen.

4. De oplossing: een DMARC-record

4.1 Begin met p=none

Voeg bij je DNS-beheer een TXT-record toe:

Veld	Waarde
Type	TXT
Naam	`_dmarc` (bij sommige DNS-beheerders `_dmarc.jouwdomein.nl`)
Waarde	`v=DMARC1; p=none; rua=mailto:Dit e-mailadres wordt beveiligd tegen spambots. JavaScript dient ingeschakeld te zijn om het te bekijken.`

Met p=none zeg je: mijn domein gebruikt DMARC, maar doe nog niets met e-mail die de controle niet haalt. Je verandert hiermee dus niets aan hoe Gmail of andere providers jouw e-mail behandelen. Microsoft noemt p=none zelf als voorbeeld in de uitleg bij de 5.7.515-fout.

Het deel rua= is niet verplicht. Het is het adres waar providers dagelijks een rapport naartoe sturen. Daarin zie je welke servers e-mail versturen namens jouw domein. Die informatie heb je later nodig als je de regels strenger wilt maken. Let op: dat zijn XML-bestanden, en het kunnen er veel zijn. Gebruik dus een apart adres.

Zet maar één DMARC-record bij je domein. Staan er twee, dan negeren ontvangers ze allebei.

4.2 SPF of DKIM moet bij je domein passen

Een DMARC-record alleen is niet genoeg. DMARC slaagt pas als SPF of DKIM slaagt voor hetzelfde domein als in je Van-adres. Dat heet alignment:

SPF moet slagen voor het domein in het technische retouradres (de envelope sender of Return-Path), en dat domein moet passen bij je Van-adres.
DKIM moet slagen met een handtekening van jouw domein (het d=-domein in de handtekening), niet van het domein van je e-maildienst.

Eén van de twee is genoeg. Omdat SPF breekt als iemand je e-mail doorstuurt, is DKIM de betrouwbaarste van de twee. Zorg dus dat in elk geval DKIM goed staat.

4.3 Controleer elke dienst die namens jou e-mail stuurt

Hier gaat het in de praktijk vaak mis. Een paar voorbeelden:

Microsoft 365 ondertekent je e-mail met het eigen onmicrosoft.com-domein van je organisatie, totdat je DKIM aanzet voor je eigen domeinnaam. Die handtekening slaagt wel, maar telt niet mee voor DMARC. Zet DKIM voor je eigen domein aan in het Microsoft Defender-portaal en voeg de twee CNAME-records (selector1 en selector2) toe aan je DNS. Microsoft 365 maakt ook geen DMARC-record voor je aan.
Google Workspace: zet DKIM aan in de Admin console en voeg het google._domainkey-record toe.
Nieuwsbriefdiensten zoals Laposta: stel de DKIM-records in die de dienst je geeft, zodat je nieuwsbrief met jouw domein wordt ondertekend.
Je website: contactformulieren, bestellingen, registratie- en activatiemails, wachtwoord-resets en meldingen van extensies van een Joomla-website gaan standaard via PHP mail van de webserver. Die server staat vaak niet in je SPF-record en ondertekent niet met DKIM voor jouw domein. Kies in Joomla bij Systeem → Algemene instellingen → Server → E-mail bij Mailer liever SMTP en verstuur via de mailserver van je domein of een betrouwbare SMTP-dienst.

4.4 Checklist

SPF: staan alle mailservers en diensten die namens jouw domein e-mail versturen in je SPF-record?
DKIM: ondertekent elke dienst je e-mail met jouw eigen domein?
DMARC: heeft je domein precies één geldig DMARC-record?
Website: verstuurt je Joomla-website e-mail via SMTP in plaats van PHP mail?
Bounces: krijg je bounces van Outlook.com of Hotmail? Bewaar de volledige foutmelding en kijk welke controle (SPF, DKIM of DMARC) wordt genoemd.

5. Daarna: van p=none naar strenger

Met p=none is je e-mail weer welkom bij Outlook.com, maar je domein is nog niet beschermd tegen misbruik. Iedereen kan nog steeds e-mail versturen die van jou lijkt te komen. Bekijk daarom een paar weken de DMARC-rapporten. Komt alle echte e-mail van jouw domein door SPF of DKIM? Dan kun je de regel stap voor stap aanscherpen:

p=quarantine: e-mail die de controle niet haalt, gaat naar de spammap.
p=reject: e-mail die de controle niet haalt, wordt geweigerd.

Doe dit niet te snel. Vergeet je een dienst die namens jou e-mail stuurt, dan weiger je met p=reject je eigen e-mail.

6. Wat nog niet bekend is

Eerlijk is eerlijk: Microsoft heeft deze nieuwe weigering (nog) niet bevestigd. De uitleg dat een ontbrekend DMARC-record de oorzaak is, komt van e-maildiensten zoals MailRoute en mxio, die het in hun eigen logbestanden zagen. Suped wijst erop dat er ook meldingen zijn van beheerders bij wie SPF, DKIM en DMARC wel goed stonden. Het kan dus zijn dat Microsoft de regels nog aanpast, of dat er meer speelt.

Dat verandert het advies niet. Een DMARC-record met goed ingestelde SPF en DKIM is al jaren de basis voor betrouwbare e-mail, en Google en Microsoft eisen het al van grote verzenders. Het ligt voor de hand dat het nu voor iedereen de norm wordt. Bewaar bij een bounce wel altijd de volledige foutmelding, zodat je kunt zien welke controle precies faalde.

7. Komt jouw e-mail niet aan?

Krijg je sinds kort bounces van Hotmail- of Outlook.com-adressen, of merk je dat klanten je e-mail niet ontvangen? Ik heb al verschillende klanten geholpen met hun SPF-, DKIM- en DMARC-instellingen, ook voor de e-mail van hun Joomla-website. Laat je e-mail DNS-authenticatie controleren.