Handleiding voor het instellen van DMARC voor Office 365 (2026)

Gebruik deze stapsgewijze handleiding om DMARC voor Office 365 in te stellen. Ontdek welke wijzigingen er op het gebied van naleving zijn doorgevoerd, welke veelgebruikte methoden er zijn voor het oplossen van problemen en waarom Microsoft 365 alleen niet voldoende is voor e-mailbeveiliging.

Microsoft ondersteunt en stimuleert het instellen van DMARC voor Office 365, ook wel Microsoft 365 of M365 genoemd. Hierdoor kunnen klanten e-mailverificatieprotocollen uniform toepassen op al hun geregistreerde domeinen. Als autoriteit op het gebied van verificatieprotocollen lichten we in deze blog uit hoe je DMARC voor Office 365 kunt configureren om e-mails te valideren die:

• Online e-mailadressen doorsturen met Microsoft
• Aangepaste domeinen toegevoegd in het beheercentrum
• Geparkeerde of inactieve, maar geregistreerde domeinen

Lees deze handleiding om meer te weten te komen over DMARC voor Microsoft 365, de stappen om het in te stellen, het aanpassen van authenticatievereisten en waarom tools zoals PowerDMARC onmisbaar zijn om de handhaving geleidelijk door te voeren.

Kort antwoord

Als je de korte versie wilt, volgt hier het basisproces voor het instellen van DMARC in Microsoft 365:

1. SPF configureren: voeg v=spf1 include:spf.protection.outlook.com -all toe aan je DNS
2. DKIM inschakelen: ga naar Microsoft 365 Defender → E-mail en samenwerking → Beleid en regels → Beleid inzake bedreigingen → DKIM → selecteer domein → Inschakelen (hiervoor zijn twee CNAME-records nodig)
3. DMARC publiceren: maak een TXT-record aan op _dmarc.jouwdomein.com dat begint met v=DMARC1; p=none; rua=mailto:[email protected]
4. Houd de rapporten 2–4 weken in de gaten en schakel daarna geleidelijk over naar p=quarantaine → p=afwijzen

Lees deze blog tot het einde voor een meer gedetailleerde handleiding die je kunt volgen.
Opmerking: Deze snelle methode werkt alleen als alle legitieme verzendbronnen van Microsoft 365 en van derden correct zijn geauthenticeerd en op elkaar zijn afgestemd. Als u platforms gebruikt zoals CRM-systemen, marketingautomatiseringstools, helpdesksystemen of factureringstools, identificeer deze dan voordat u overgaat tot handhaving.

Wat is DMARC en waarom is het belangrijk voor Microsoft 365?

DMARC staat voor Domain-based Message Authentication, Reporting, and Conformance. Het is een e-mailverificatieprotocol dat domeinen helpt beschermen tegen spoofing, phishing en ongeoorloofd gebruik.

DMARC bouwt voort op SPF en DKIM. Het controleert of een bericht voldoet aan SPF of DKIM en of het domein dat aan deze controles voldoet, overeenkomt met het zichtbare „Van”-domein. Vervolgens geeft het aan de ontvangende e-mailservers door wat ze moeten doen met berichten die de authenticatie niet doorstaan.

Voor gebruikers van Microsoft 365 is DMARC om twee redenen van belang:

• Het helpt voorkomen dat aanvallers zich voordoen als uw domein.
• Het vergroot het vertrouwen en de afleverbaarheid van legitieme uitgaande e-mail.

Exchange Online Protection controleert DMARC voor inkomende e-mail, maar dat biedt niet automatisch bescherming tegen het misbruik van uw eigen domeinnaam elders. Om de identiteit van uitgaande e-mail te beschermen, moet u SPF-, DKIM- en DMARC-records voor uw domein publiceren.

Voor meer informatie over de implementatie, zie de DMARC-handleiding van PowerDMARC.

DMARC 2026: De update van RFC 9989, 9990 en 9991

In mei 2026 werd DMARC bijgewerkt via drie IETF-RFC’s:

RFC 9989 vervangt RFC 7489 en RFC 9091 en verheft DMARC tot de status van voorgestelde standaard. Voor domeineigenaren is de belangrijkste praktische verandering de overgang van het op de Public Suffix List gebaseerde opsporen van organisatiedomeinen naar DNS Tree Walk.

Bestaande DMARC-records beginnen nog steeds met:

txt

v=DMARC1

De meeste Microsoft 365-beheerders doen dus hun DNS-records hun DNS-records niet onmiddellijk opnieuw hoeven in te stellen. U dient echter het volgende te controleren:

• sp= gedrag van het subdomeinbeleid
• Elke complexe structuur van gedelegeerde subdomeinen
• Domeinen en subdomeinen die e-mail versturen via Microsoft 365 of platforms van derden
• Domeinen die geen e-mail verzenden en inactief zijn, en die moeten worden geblokkeerd

Als uw organisatie een complexe domeinhiërarchie hanteert, publiceer dan expliciete DMARC-records voor elk domein en subdomein dat e-mail verstuurt. Dit vermindert onduidelijkheid wanneer ontvangers overschakelen van de oudere DMARC-verwerking naar het gedrag volgens RFC 9989.

Zie voor meer informatie de handleiding van PowerDMARC over de DMARC RFC 9989, 9990 en 9991-update.

Regelt Microsoft 365 DMARC voor u?

Microsoft 365 voert DMARC-validatie uit voor inkomende e-mail, maar de uitgaande domeinbeveiliging voor uw eigen domein is niet volledig geconfigureerd.

Exchange Online Protection controleert automatisch de SPF-, DKIM- en DMARC-instellingen van berichten die uw organisatie ontvangt. Dit helpt gebruikers te beschermen tegen vervalste inkomende e-mail.

Voor uitgaande e-mail liggen de verantwoordelijkheden anders. U moet voor elk verzendend domein SPF configureren, DKIM inschakelen en een DMARC-record in DNS publiceren.

De eenvoudigste manier om dit onderscheid te begrijpen is als volgt: Microsoft beveiligt je Microsoft 365-inbox, terwijl DMARC de identiteit van je domein binnen het bredere e-mailecosysteem beschermt.

Als u uitsluitend gebruikmaakt van de standaardbesturingselementen van Microsoft 365, kan het zijn dat u nog steeds het volgende mist:

• Voor mensen begrijpelijke DMARC-rapportage
• Inzicht in externe afzenders
• Richtlijnen voor de overgang van p=none naar handhaving
• Gecentraliseerde monitoring over verschillende domeinen heen
• Beheer van de limiet voor SPF-opzoekingen
• Waarschuwingen wanneer leveranciers of DNS-records niet meer synchroon lopen

Zie voor een gedetailleerd overzicht waarom Microsoft 365-gebruikers nog steeds DMARC nodig hebben.

Vereisten: SPF en DKIM instellen voor Microsoft 365

Voordat u een DMARC-record publiceert, moet u ervoor zorgen dat zowel SPF als DKIM correct zijn geconfigureerd voor uw domein. DMARC verifieert e-mails niet zelf; het is volledig afhankelijk van de resultaten van SPF en/of DKIM. Als deze ontbreken of niet goed zijn afgestemd, zal DMARC mislukken en kunnen legitieme e-mails hierdoor worden beïnvloed zodra de handhaving is ingeschakeld.

Stap 1: SPF configureren voor Microsoft 365

SPF, oftewel Sender Policy Framework, bepaalt welke mailservers bevoegd zijn om e-mail namens uw domein te verzenden.

Voor een domein dat uitsluitend voor Microsoft 365 wordt gebruikt, is het standaard SPF-record:

v=spf1 include:spf.protection.outlook.com -all

Als u gebruikmaakt van externe afzenders, neem deze dan op in hetzelfde SPF-record:

v=spf1 include:spf.protection.outlook.com include:_spf.salesforce.com -all

Belangrijk: Er kan slechts één SPF TXT-record per domein bestaan. Meerdere SPF-records leiden tot een SPF PermError en kunnen de authenticatie verstoren.

SPF kent ook een strikte limiet van 10 DNS-lookups. Als deze limiet wordt overschreden, leidt dit tot een SPF PermError, wat door DMARC als een fout wordt geïnterpreteerd. Als u meerdere SaaS-diensten gebruikt, maak dan gebruik van de gehoste SPF met macro’s van PowerSPF om permanent onder de limiet te blijven zonder handmatige DNS-aanpassingen. Je kunt ook je huidige SPF-record controleren of deze SPF-generator gratis gebruiken.

Stap 2: DKIM inschakelen voor Microsoft 365

DKIM (DomainKeys Identified Mail) voegt een cryptografische handtekening toe aan uw e-mails. Hierdoor kunnen ontvangende servers controleren of het bericht niet is gewijzigd en daadwerkelijk afkomstig is van uw domein.

⚠️  DKIM in Microsoft 365 is standaard niet ingeschakeld voor aangepaste domeinen. U moet dit expliciet inschakelen in het beheercentrum.

DKIM handmatig instellen: DNS + Beheercentrum

1. Ga naar het Microsoft 365 Defender-portaal
2. Ga naar E-mail en samenwerking → Beleid en regels → Beleid inzake bedreigingen → Instellingen voor e-mailverificatie → DKIM
3. Kies uw domein.

Voordat u deze functie kunt inschakelen, vraagt Microsoft u om twee CNAME-records toe te voegen:

selector1._domainkey
selector1-<CustomDomainWithDashes>._domainkey.<InitialDomainPrefix>.<DynamicPartitionCharacter>-v1.dkim.mail.microsoft

selector2._domainkey
selector2-<CustomDomainWithDashes>._domainkey.<InitialDomainPrefix>.<DynamicPartitionCharacter>-v1.dkim.mail.microsoft

1. Ga na het publiceren van deze CNAME-records terug naar het Defender-portaal en schakel ‘Inschakelen’ in voor DKIM

Zodra deze functie is geactiveerd, begint Microsoft alle uitgaande e-mails met DKIM te ondertekenen. Controleer je instellingen met behulp van de gratis DKIM-checker.

DMARC instellen voor Office 365

Nadat SPF en DKIM zijn geconfigureerd, kun je DMARC publiceren. Voor de meeste aangepaste domeinen vindt het DMARC-configuratieproces van Microsoft 365 plaats in DNS, en niet in het Microsoft 365-beheercentrum.

Stap 1: Breng alle bronnen van e-mailverzending in kaart

Voordat u een DMARC-record publiceert, moet u een volledig overzicht hebben van wie er namens uw domein e-mails verstuurt. Als er een legitieme afzender ontbreekt, kan dit leiden tot bezorgingsfouten zodra de handhaving is ingeschakeld.

Veelgebruikte verzendbronnen voor Microsoft 365 zijn onder meer:

• Microsoft 365 (Exchange Online)
• Marketingplatforms (Mailchimp, HubSpot, Klaviyo)
• CRM-systemen (Salesforce, HubSpot CRM)
• Ondersteuningshulpmiddelen (Zendesk, Freshdesk, Intercom)
• Interne applicaties of lokale e-mailservers
• E-mailgateways of beveiligingsapparaten van derden

Dit is waar veel DMARC-implementaties mislukken. Een domein lijkt misschien „alleen voor Microsoft 365” te zijn, maar facturen, nieuwsbrieven, wachtwoordherstelberichten, updates over tickets en HR-meldingen komen vaak van buiten Microsoft 365.

Als je niet zeker weet welke systemen namens jou e-mails versturen, begin dan met p=none en gebruik de geaggregeerde DMARC-rapporten om ze te achterhalen.

Stap 2: Maak je DMARC-record aan

Een DMARC-record is een TXT-record dat in uw DNS is gepubliceerd op _dmarc.uwdomein.com. Gebruik de DMARC-recordgenerator om binnen enkele seconden een geldig, foutloos record aan te maken.

Een aanbevolen startrecord ziet er als volgt uit:

v=DMARC1; p=none; rua=mailto:[email protected];

Dit eens nader bekeken:

• v=DMARC1 — geeft de DMARC-versie aan
• p=none — bewakingsmodus (geen handhaving; uitsluitend gegevensverzameling)
• rua=mailto:… — waar de geaggregeerde (RUA) rapporten naartoe worden gestuurd

Stap 3: Publiceer het DMARC-record in DNS

Voeg het volgende TXT-record toe bij uw DNS-hostingprovider:

Opmerking: Na publicatie kan het enige tijd duren (meestal enkele minuten tot enkele uren) voordat het record wereldwijd is bijgewerkt.

Controleer je record na het publiceren met behulp van een DMARC-checker om te verifiëren dat er geen syntaxisfouten zijn en dat het record correct wordt omgezet.

Stap 4: DMARC-rapporten controleren

Nadat u DMARC hebt ingeschakeld met een p=none-beleid, ontvangt u DMARC-geaggregeerde rapporten (RUA) van ontvangende servers. Deze rapporten bieden inzicht in: wie er e-mails verstuurt via uw domein, welke berichten de authenticatie doorstaan of niet doorstaan, en de afstemmingsstatus voor SPF en DKIM.

DMARC-rapporten worden in onbewerkte XML-vorm aangeleverd, wat het zonder speciale tools moeilijk maakt om ze te interpreteren. De rapportanalysator van PowerDMARC zet deze om in overzichtelijke dashboards, zodat u problemen kunt identificeren en op een veilige manier kunt toewerken naar handhaving.

Stap 5: Ga geleidelijk over tot handhaving

Zodra je hebt gecontroleerd of alle legitieme afzenders correct zijn geauthenticeerd, kun je je DMARC-beleid stapsgewijs aanscherpen:

Fase 1 — Monitoring (p = geen):

v=DMARC1; p=none; rua=mailto:[email protected]

Fase 2 — Quarantaine (verdachte e-mails worden naar de spamfolder verplaatst):

v=DMARC1; p=quarantaine; rua=mailto:[email protected]; pct=25; t=y

Fase 3 — Handhaving (niet-geverifieerde e-mail afwijzen):

v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=r; aspf=r

Tip: Wees niet te snel met het afwijzen van berichten. Voortijdige handhaving is de meest voorkomende oorzaak van het blokkeren van legitieme e-mails tijdens de implementatie.

Stap 6: DMARC configureren voor verschillende soorten domeinen

De werkwijze verschilt naargelang het domein dat u configureert.

Stap 7: Controleer en onderhoud uw Microsoft 365 DMARC-configuratie

DMARC is geen eenmalige instelling. Naarmate uw e-mailomgeving verandert, moet uw configuratie mee evolueren. Zelfs nadat u de instelling p=reject hebt bereikt, blijft voortdurende monitoring essentieel om de afleverbaarheid en beveiliging te waarborgen.

Je moet regelmatig:

• DMARC-rapporten bekijken
• Werk de SPF bij wanneer je nieuwe afzenders toevoegt
• Zorg ervoor dat DKIM ingeschakeld en correct geconfigureerd blijft
• Controleer op ongeoorloofde activiteiten

Invoering van het DMARC-beleid: waarom een geleidelijke handhaving belangrijk is

Direct overgaan op een afwijzingsbeleid is een van de meest voorkomende fouten bij de implementatie van DMARC. Zonder inzicht in uw e-mailstromen kan het handhaven van dit beleid legitieme communicatie verstoren.

Door een gefaseerde implementatie kunt u problemen opsporen en verhelpen voordat u strikte beleidsregels toepast. De meeste organisaties volgen een stapsgewijze aanpak: eerst monitoren, vervolgens in quarantaine plaatsen en ten slotte afwijzen. De duur van elke fase hangt af van de complexiteit van uw e-mailomgeving, en het overslaan van stappen vergroot alleen maar het risico op onbedoelde bezorgingsfouten.

Hoe Exchange Online omgaat met inkomende DMARC

Exchange Online Protection controleert automatisch de DMARC-instellingen van alle inkomende berichten. Sinds juli 2023houdt Microsoft zich standaard aan het gepubliceerde beleid van de afzender. Wanneer het MX-record van het ontvangende domein rechtstreeks naar Microsoft 365 verwijst, worden berichten die niet voldoen aan het DMARC-beleid met p=reject bij de gateway geweigerd. Op dezelfde manier worden berichten die niet voldoen aan het p=quarantine-beleid naar de quarantaine gestuurd. Dit wordt geregeld door het ‘Beleid voor DMARC-records naleven wanneer het bericht als spoof wordt gedetecteerd’ in het anti-phishingbeleid, dat standaard is ingeschakeld.

Raadpleeg de handleiding van PowerDMARC voor een gedetailleerde uitleg over het configureren van deze instelling en alle bijbehorende opties: het anti-phishingbeleid van Office 365.

Bron: Microsoft

Het ‘oreject’-gedrag uitgelegd

Voorheen paste Microsoft een interne overschrijving toe met de naam action=oreject (origin reject) op inkomende berichten die niet voldeden aan het p=reject-beleid van de afzender. In plaats van de e-mail direct bij de gateway te weigeren, leidde EOP deze door naar de map met ongewenste e-mail van de ontvanger en voorzag de header van de oreject-actie.

Microsoft heeft dit bewust gedaan; doorgestuurde e-mails en berichten op mailinglijsten schenden tijdens het transport vaak de SPF- en DKIM-verificatie, en een harde afwijzing met p=reject zou hebben geleid tot het verwijderen van aanzienlijke hoeveelheden legitieme e-mail. De map met ongewenste e-mail was een compromis: ontvangers konden de e-mail indien nodig terugvinden, en het beleid van de afzender werd technisch gezien nageleefd.

Wanneer je vandaag nog steeds 'oreject' te zien krijgt

Sinds de standaardinstelling is gewijzigd, beschouwt EOP ‘p=reject’ nu als een daadwerkelijke afwijzing voor directe MX-stromen. Het oude gedrag is echter nog niet helemaal verdwenen. Je zult ‘oreject’ nog steeds tegenkomen in drie scenario’s:

1. ‘Honor DMARC’ is uitgeschakeld in uw anti-phishingbeleid: kijk onder Microsoft 365 Defender → E-mail en samenwerking → Beleid inzake bedreigingen → Anti-phishing → Instellingen voor identiteitsfraude
2. E-mail wordt via een gateway van een derde partij (Proofpoint, Mimecast) geleid voordat deze Microsoft 365 bereikt: schakel ‘Verbeterde filtering voor connectoren’ in het Defender-portaal in
3. Een toelatingsregel op huurdersniveau omzeilt de filtering: afzenders op de toelatingslijst, vertrouwde inkomende connectoren of SCL -1-regels zorgen ervoor dat de DMARC-handhaving volledig wordt overgeslagen

Inzicht in compauth en samengestelde authenticatie

Microsoft voegt reputatiesignalen toe aan de DMARC-resultaten via een systeem dat ‘composite authentication’ (compauth) wordt genoemd. Dit betekent dat een bericht technisch gezien niet door de DMARC-controle komen, maar toch worden afgeleverd als de reputatiesignalen van Microsoft aangeven dat de afzender legitiem is (compauth=pass). Omgekeerd kan een bericht DMARC doorstaan en toch als ongewenst worden gemarkeerd als compauth faalt. Controleer bij het oplossen van DMARC-bezorgingsproblemen in M365 altijd de header ‘Authentication-Results’ op de ‘reason=’-code. Zie deze complete handleiding voor compauth-fouten en composietauthenticatie voor meer informatie.

Aanscherping van de handhaving van invoervoorschriften

Voor organisaties die willen dat e-mail die niet aan de DMARC-vereisten voldoet gegarandeerd wordt geweigerd, is een transportregel in Exchange Online de meest betrouwbare methode:

1. Ga naar Exchange-beheercentrum → E-mailverkeer → Regels → maak een nieuwe regel aan
2. Voorwaarde instellen: Een berichtheader bevat een van deze woorden. Naam header: Authentication-Results. Waarde header: dmarc=fail action=oreject
3. Actie instellen: Het bericht afwijzen met de toelichting ‘Het bericht is niet geslaagd voor de DMARC-authenticatie en is afgewezen conform het beleid van de organisatie’

1. (Optioneel) Voeg een uitzondering toe voor vertrouwde interne afzenders of bekende legitieme doorstuurders
2. Stel de regelmodus de eerste week in op ‘Testen zonder beleid’ of ‘Testen met beleidstips’ (indien beschikbaar); bekijk de overeenkomende berichten in het berichttrace voordat u overschakelt naar ‘Afdwingen’

Pas deze aanpak toe wanneer regelgeving of intern beleid vereist dat ongeldige e-mail daadwerkelijk wordt geweigerd, wanneer uw organisatie een aantrekkelijk doelwit is voor spoofing (financiële, juridische of leidinggevende communicatie), of wanneer u consistent gedrag wilt zien bij zowel directe MX-stromen als stromen via gateways van derden.

Microsofts DMARC-handhaving vanaf mei 2025: wat is er veranderd?

In mei 2025 heeft Microsoft een ingrijpende wijziging doorgevoerd in de manier waarop het omgaat met niet-geverifieerde e-mails van externe afzenders. Deze wijziging heeft vooral gevolgen voor afzenders die grote hoeveelheden e-mails versturen, maar heeft bredere implicaties voor alle organisaties.

Vergelijking van handhavingsmaatregelen door e-mailproviders

Belangrijkste vereisten die door Microsoft zijn geïntroduceerd

• Verplichte DMARC voor bulkverzenders: domeinen die meer dan 5.000 e-mails per dag naar Microsoft-consumentendiensten verzenden, moeten een geldig DMARC-record hebben
• Dit geldt voor het ecosysteem van Microsoft-mailboxen voor consumenten: Outlook.com, Hotmail.com en Live.com
• Minimale vereiste: DMARC met p=none — zelfs een monitoringbeleid is acceptabel, maar het ontbreken van een DMARC-record wordt op grote schaal niet langer getolereerd
• Sterke nadruk op domeinafstemming: authenticatie alleen is niet voldoende; SPF en DKIM moeten overeenkomen met het zichtbare 'Van'-domein
• Harde afwijzing wegens niet-naleving: 550 5.7.515 Toegang geweigerd, het verzendende domein voldoet niet aan het vereiste authenticatieniveau

Door deze wijziging sluit Microsoft zich aan bij Apple, de e-mailverificatie-eisen van Google en Yahoo, wat betekent dat de grootste e-mailproviders nu allemaal authenticatie afdwingen voor bulkverzenders. Zie de DMARC-vereisten van Microsoft voor Outlook voor een volledige checklist voor naleving.

Waarom Microsoft 365 alleen niet voldoende is

Hoewel Microsoft 365 een krachtige bescherming tegen inkomend verkeer biedt, zijn de mogelijkheden voor het op grote schaal beheren en monitoren van DMARC beperkt.

Geen voor mensen leesbare rapportage

Microsoft verstuurt nu DMARC-rapporten voor zakelijke gebruikers wanneer de MX-record rechtstreeks naar Office 365 verwijst. Deze onbewerkte XML-bestanden zijn echter moeilijk te interpreteren zonder gespecialiseerde tools. Zonder een gedegen analyse hebben organisaties geen inzicht in wie er namens hen e-mail verstuurt en of die bronnen correct zijn geauthenticeerd.

Geen handhavingsrichtlijnen

Microsoft biedt geen geautomatiseerde ondersteuning voor de overgang van monitoring naar handhaving. Hierdoor moeten beheerders de gegevens handmatig interpreteren en beslissingen nemen die van invloed kunnen zijn op de bezorging van e-mail.

Niet geschikt voor doorlopend beheer

Een speciale DMARC-oplossing zet niet alleen ruwe rapporten om in bruikbare inzichten. Ze maakt ook continue monitoring mogelijk, vereenvoudigt het beleidsbeheer en helpt organisaties om op een veilige manier toe te werken naar volledige handhaving, op een schaal die Microsoft 365 simpelweg niet biedt.

Problemen met DMARC in Office 365 oplossen

Je kunt ook lid worden van de leergemeenschap van Microsoft om op de hoogte te blijven van Office 365 en de vereisten voor het authenticatieprotocol.

Verdergaan met DMARC in Microsoft 365

DMARC in Microsoft 365 is een tweezijdig probleem. Exchange Online Protection regelt de validatie van inkomende e-mail automatisch voor u, maar de bescherming van uitgaande e-mail is volledig uw verantwoordelijkheid. De wijzigingen in de handhaving die in mei 2025 van kracht worden, maken die verantwoordelijkheid urgent voor iedereen die grote hoeveelheden e-mail verstuurt, terwijl de publicatie van DMARCbis in mei 2026 aangeeft dat de e-mailbranche DMARC als een permanente, formele infrastructuur beschouwt.

De veiligste aanpak is weliswaar langzamer, maar wel doeltreffend: stel p=none in, houd je rapporten twee tot vier weken in de gaten, corrigeer de afzenders die naar voren komen, schakel vervolgens over naar p=quarantine en uiteindelijk naar p=reject. Door deze stappen over te slaan, raakt legitieme zakelijke e-mail tijdens de implementatie verstoord.

Zodra de handhaving van kracht wordt, verschuift de focus van het instellen naar het monitoren. Er komen nieuwe afzenders bij en externe leveranciers passen hun infrastructuur aan; dit alles kan ongemerkt de afstemming verstoren als niemand de rapporten in de gaten houdt. Geef prioriteit aan e-mailbeveiliging door uw huidige DMARC-record te controleren om te zien hoe u er op dit moment voor staat.

Raadpleeg de DMARC-gids.

Veelgestelde Vragen

Stelt Microsoft 365 DMARC automatisch in?

Microsoft controleert DMARC voor inkomende e-mail, maar configureert dit niet voor uw eigen domein. U moet het uitgaande DMARC TXT-record zelf handmatig publiceren. Voor domeinbeveiliging moet u de SPF-, DKIM- en DMARC-records zelf in DNS publiceren.

Is DMARC verplicht bij Microsoft?

Ja. Microsoft heeft voor 2025 DMARC (met minimaal p=none) verplicht gesteld voor domeinen die meer dan 5.000 e-mails per dag versturen naar Outlook.com, Hotmail.com en Live.com. Afzenders die niet aan deze eis voldoen, worden op serverniveau geweigerd en hun e-mails komen niet in de inbox terecht. Microsoft raadt alle afzenders bovendien ten zeerste aan om DMARC te implementeren, ongeacht het verzendvolume.

Wat is foutmelding 550 5.7.515?

Deze Microsoft 365-foutmelding betekent dat uw e-mails worden geweigerd omdat uw verzenddomein niet voldoet aan de authenticatievereisten. U kunt dit oplossen door een geldig DMARC-record te publiceren (minimaal p=none) en ervoor te zorgen dat zowel SPF als DKIM zijn geconfigureerd en afgestemd op uw ‘Van’-domein.

Waarom worden e-mails nog steeds met de status „p=reject“ afgeleverd?

Er zijn vier veelvoorkomende redenen: (1) ‘Honor DMARC’ is uitgeschakeld in uw anti-phishingbeleid; (2) er is een gateway van een derde partij geïnstalleerd vóór Microsoft 365; (3) ‘Enhanced Filtering for Connectors’ is niet ingeschakeld; (4) de samengestelde authenticatie (compauth) van Microsoft overschrijft het DMARC-foutresultaat; (5) een toelatingsregel van de tenant omzeilt de filtering volledig. Hoewel Microsoft is overgestapt op een strengere, daadwerkelijke afwijzing voor afzenders met grote volumes, blijven deze overschrijvingen actief in verkeerd geconfigureerde omgevingen.

Moet ik 'quarantaine' of 'afwijzen' kiezen?

Begin met monitoring (p=none) om inzicht te krijgen in uw verzendbronnen, ga vervolgens over op quarantaine en pas ‘reject’ pas toe als u er zeker van bent dat alle legitieme bronnen correct zijn ingesteld. Direct naar ‘reject’ overschakelen zonder eerst te monitoren is de belangrijkste oorzaak van het verlies van legitieme e-mails tijdens de implementatie van DMARC.

Wat betekent DMARCbis voor Microsoft 365-beheerders?

DMARCbis (RFC 9989, gepubliceerd in mei 2026) verheft DMARC officieel tot een voorgestelde standaard. Voor de meeste M365-beheerders zijn er geen onmiddellijke DNS-wijzigingen nodig; bestaande DMARC-records blijven geldig. De belangrijkste wijziging om rekening mee te houden is de ‘DNS Tree Walk’-aanpak voor het bepalen van organisatiedomeinen, die de Public Suffix List vervangt. Controleer uw sp= (subdomeinbeleid)-tag om te bevestigen dat deze nog steeds correct van toepassing is volgens de nieuwe logica.

Is DMARC van toepassing op onmicrosoft.com-domeinen?

Ja. Het domein onmicrosoft.com (MOERA) wordt vaak over het hoofd gezien, maar aanvallers maken er actief gebruik van voor spoofing. SPF wordt door Microsoft automatisch ingesteld voor MOERA-domeinen, maar DKIM en DMARC moeten handmatig worden geconfigureerd. Pas op deze domeinen een strikt p=reject-beleid toe, aangezien ze doorgaans niet worden gebruikt voor legitieme uitgaande e-mail.

Is DMARC vereist voor naleving van de PCI DSS-normen?

Vanaf 31 maart 2025 zijn anti-phishingmaatregelen, waaronder DMARC, SPF en DKIM, op grond van paragraaf 5.4.1 van PCI DSS v4.0 volledig verplicht voor alle organisaties die betaalkaartgegevens verwerken. Alle beoordelingen in 2026 worden uitgevoerd op basis van PCI DSS v4.0.1, zonder overgangsperiode. Als uw organisatie kaartbetalingen verwerkt en gebruikmaakt van Microsoft 365, is DMARC een strikte nalevingsvereiste.

• Over
• Laatste berichten

Yunes Tarada

Expert op het gebied van domein- en e-mailbeveiliging bij PowerDMARC

Yunes is teamleider Operations bij PowerDMARC en heeft expertise in e-mailauthenticatie en -beveiliging. Hij is een door Microsoft gecertificeerde Azure Administrator Associate en beschikt over certificeringen zoals CompTIA A+ en vele andere.

Laatste berichten van Yunes Tarada (Bekijk alle berichten)

• Handleiding voor het instellen van Happyfox DKIM, DMARC en SPF - 13 augustus 2026
• Handleiding voor het instellen van Twikey SPF, DKIM en DMARC - 11 augustus 2026
• Wat is ‘whaling’ in de cyberbeveiliging? - 7 augustus 2026