DMARC voor Office 365: Stap voor stap instellen en best practices

Microsoft ondersteunt en stimuleert het instellen van DMARC voor gebruikers van Microsoft 365 (ook wel Office 365 of M365 genoemd), waardoor zij e-mailverificatieprotocollen uniform kunnen toepassen op al hun geregistreerde domeinen. In deze blog leggen we uit hoe je DMARC voor Office 365 configureert om alle Office 365-e-mails te valideren die:

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

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

DMARC is een protocol voor e-mailverificatie dat domeinen beschermt tegen spoofing en phishing. (Domain-based Message Authentication, Reporting, and Conformance) bouwt voort op SPF en DKIM, stemt de verificatieresultaten af op het domeinbeleid en geeft ontvangende servers aan hoe ze berichten moeten behandelen die deze controles niet doorstaan.

In een Microsoft 365-omgeving vervult DMARC een dubbele rol. Het beschermt uw domein tegen identiteitsfraude door aanvallers en zorgt er bovendien voor dat uw legitieme e-mails door externe ontvangers als betrouwbaar worden beschouwd.

Regelt Microsoft 365 DMARC voor u?

Een van de meest voorkomende misvattingen onder beheerders is dat Microsoft 365 DMARC voor je regelt.

Microsoft 365 voert wel DMARC-validatie uit, maar alleen voor inkomende e-mail. Exchange Online Protection (EOP) controleert automatisch de SPF-, DKIM- en DMARC-verificatie van berichten die uw organisatie ontvangt. Dat betekent dat uw gebruikers tot op zekere hoogte beschermd zijn tegen vervalste e-mails.

Voor uitgaande e-mail onderneemt Microsoft echter geen actie, tenzij u dit zelf instelt. Als u uw domein wilt beveiligen en aan de huidige compliance-eisen wilt voldoen, moet u een DMARC-record in uw DNS publiceren.

Dit onderscheid is van cruciaal belang. Microsoft beschermt uw inbox, maar DMARC beschermt de reputatie van uw domein. Daarom heeft Microsoft 365 DMARC nodig, zelfs als EOP al is geïmplementeerd. De configuratie die u gaat implementeren, heeft betrekking op de bescherming van uitgaande e-mail.

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, maar vertrouwt volledig op 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 (Sender Policy Framework) bepaalt welke mailservers bevoegd zijn om namens uw domein e-mails te versturen. In een Microsoft 365-omgeving zijn dit doorgaans de eigen mailservers van Microsoft en eventuele diensten van derden die u gebruikt.

SPF handmatig instellen (via DNS)

Om SPF handmatig in te stellen:

1. Ga naar je DNS-hostingprovider (bijv. GoDaddy, Cloudflare, enz.)
2. Maak een TXT-record aan voor uw hoofddomein of werk deze bij

Gebruik het volgende standaard SPF-record voor Microsoft 365:

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

Als je gebruikmaakt van aanvullende diensten (zoals Mailchimp of Salesforce), moet je die ook vermelden. Bijvoorbeeld:

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

Geautomatiseerde SPF-configuratie (met PowerDMARC)

Het handmatig aanmaken van SPF-records kan ingewikkeld zijn, vooral wanneer er meerdere diensten bij betrokken zijn. Fouten zoals het overschrijden van limieten voor DNS-lookups of verkeerde configuraties komen vaak voor.

Het gebruik van de SPF-tools van PowerDMARC vereenvoudigt dit proces. De SPF-generator stelt automatisch een geldig record samen op basis van uw verzendbronnen.

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 of het daadwerkelijk afkomstig is van uw domein.

In tegenstelling tot SPF vereist DKIM in Microsoft 365 zowel een DNS-configuratie als activering in het beheercentrum.

Handmatige DKIM-configuratie (DNS + Admin Center)

DKIM handmatig inschakelen:

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

Bron

Voordat u DKIM kunt inschakelen, vraagt Microsoft u om twee CNAME-records aan uw DNS toe te voegen.

Deze zien er doorgaans als volgt uit:

selector1._domainkey.uwdomein.com → selector1-uwdomein-com._domainkey.uwdomein.onmicrosoft.com

selector2._domainkey.uwdomein.com → selector2-uwdomein-com._domainkey.uwdomein.onmicrosoft.com

Nadat u deze gegevens hebt gepubliceerd, keert u terug naar het beheerdersportaal en klikt u op ‘Inschakelen’ voor DKIM. Zodra deze functie is geactiveerd, zal Microsoft alle uitgaande e-mails met DKIM ondertekenen.

Geautomatiseerde DKIM-configuratie (met PowerDMARC)

Het instellen van DKIM kan verwarrend zijn, vooral voor beheerders die niet bekend zijn met CNAME-records en selectorformaten.

PowerDMARC vereenvoudigt dit door automatisch de juiste DKIM-records voor uw domein te genereren, automatische DNS-publicatie aan te bieden om fouten bij handmatige invoer te voorkomen, en een DKIM-controlefunctie te bieden om te controleren of DKIM correct is ingeschakeld

Hoe stel je DMARC in voor Office 365?

Zodra SPF en DKIM correct zijn geconfigureerd, kunt u doorgaan met het instellen van DMARC. In Microsoft 365 gebeurt dit op DNS-niveau, maar om dit goed te doen, moet u inzicht hebben in uw e-mailomgeving, het juiste beleid kiezen en de resultaten controleren voordat u het beleid daadwerkelijk toepast.

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. Dit is een van de belangrijkste stappen, omdat het over het hoofd zien van een legitieme afzender later tot bezorgingsproblemen kan leiden.

Uw verzendbronnen zijn doorgaans:

• Microsoft 365 (Exchange Online)
• Marketingplatforms (Mailchimp, HubSpot, enz.)
• CRM-systemen (Salesforce)
• Ondersteuningsprogramma’s (Zendesk, Freshdesk)
• Interne applicaties of servers

Als een van deze niet correct is geverifieerd via SPF of DKIM, zullen ze niet voldoen aan DMARC zodra de handhaving is ingeschakeld.

Stap 2: Maak je DMARC-record aan

Een DMARC-record is een TXT-record dat in uw DNS wordt gepubliceerd. Het beschrijft uw beleid en geeft ontvangende servers aan hoe ze e-mails moeten behandelen die de authenticatie niet doorstaan. U kunt een uniek Office 365 DMARC-record voor uw domein aanmaken met behulp van de tool van PowerDMARC voor het direct genereren van DMARC-records.

Een standaard DMARC-record ziet er als volgt uit: v=DMARC1; p=none; rua=mailto:[email protected]; fo=1

Laten we dit eens op een rijtje zetten:

v=DMARC1 – Geeft de DMARC-versie aan
p=none – Controlemodus (geen handhaving)
rua=mailto:[email protected] – Waar de geaggregeerde rapporten naartoe worden gestuurd
fo=1 – Schakelt foutmeldingen in

Dit is het aanbevolen startpunt, omdat je hiermee gegevens kunt verzamelen zonder dat dit invloed heeft op de bezorging van e-mails.

Stap 3: Publiceer het DMARC-record in DNS

Zodra je record klaar is, moet je het aan je DNS toevoegen.

Gebruik de volgende instellingen:

Recordtype: TXT
Host/naam: _dmarc
Waarde: Uw DMARC-record
TTL: 1 uur (of standaard)

Stap 4: DMARC-rapporten controleren

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

DMARC-rapporten worden doorgaans in XML-formaat verzonden en zijn vaak moeilijk handmatig te interpreteren. Zonder een grondige analyse is het gemakkelijk om verkeerde configuraties of ongeautoriseerde afzenders over het hoofd te zien.

Stap 5: Ga geleidelijk over tot handhaving

Zodra u uw rapporten hebt doorgenomen en hebt gecontroleerd of alle legitieme afzenders correct zijn geverifieerd, kunt u beginnen met het aanscherpen van uw DMARC-beleid.

Een typisch verloop ziet er als volgt uit:

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

↓

Verplaatsen naar quarantaine (verdachte e-mails worden naar de spamfolder gestuurd): v=DMARC1; p=quarantine; rua=mailto:[email protected];

↓

Tot slot, afwijzing afdwingen: v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=r; aspf=r

Stap 6: DMARC configureren voor verschillende soorten domeinen

De werkwijze kan verschillen, afhankelijk van 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 stappenplan dat begint met monitoring, gevolgd door quarantaine en ten slotte afwijzing. De duur van elke fase hangt af van de complexiteit van uw e-mailomgeving, maar het overslaan van stappen vergroot het risico op onbedoelde bezorgingsfouten.

Hoe Exchange Online omgaat met inkomende DMARC

Exchange Online Protection controleert automatisch de DMARC-validatie van alle inkomende berichten, en sinds juli 2023 volgt Microsoft standaard het door de afzender gepubliceerde beleid. Wanneer het MX-record van het ontvangende domein rechtstreeks naar Microsoft 365 verwijst, worden berichten die niet voldoen aan de DMARC-validatie volgens een p=reject-beleid bij de gateway geweigerd. Op dezelfde manier worden berichten die niet voldoen aan het p=quarantine-beleid naar quarantaine gestuurd. Dit wordt geregeld door de instelling'DMARC-recordbeleid naleven wanneer het bericht als spoof wordt gedetecteerd'in het anti-phishingbeleid, dat standaard is ingeschakeld.

Bron

Het gedrag van "oreject" uitgelegd

Vóór juli 2023 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 actie oreject.

Microsoft heeft hiervoor bewust gekozen, omdat doorgestuurde e-mails en berichten op mailinglijsten tijdens het verzendproces vaak niet voldoen aan de SPF- en DKIM-vereisten. Dit betekent dat een legitiem bericht dat bij de oorspronkelijke afzender de authenticatie doorstaat, deze kan mislukken tegen de tijd dat een secundaire ontvanger het ontvangt. Een harde afwijzing met de instelling `p=reject` zou naast de vervalste berichten ook een aanzienlijke hoeveelheid legitieme e-mail hebben geweigerd. De map met ongewenste e-mail was een compromis: ontvangers konden de e-mail indien nodig nog steeds terugvinden en het beleid van de afzender werd technisch gezien nageleefd.

Het nadeel was dat vervalste berichten die eigenlijk hadden moeten worden geweigerd, toch in de inboxen van gebruikers terechtkwamen (in de map met ongewenste e-mail), waar een onoplettende ontvanger ze zou kunnen openen. Voor beveiligingsteams betekende dit dat de handhaving van DMARC nooit zo streng aanvoelde als het beleid deed vermoeden.

Wanneer je vandaag nog steeds 'oreject' te zien krijgt

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

1. „Honor DMARC“ is uitgeschakeld in uw anti-phishingbeleid.

Om dit probleem op te lossen: controleer de instelling onder Microsoft 365 Defender → E-mail en samenwerking → Beveiligingsbeleid → Anti-phishing → Instellingen voor spoofing. Deze schakelaar staat standaard aan, maar bij tenants die vanuit oudere configuraties zijn gemigreerd, kan deze zijn uitgeschakeld.

2. E-mail wordt via een gateway van een derde partij geleid voordat deze Microsoft 365 bereikt.

Als uw MX-record verwijst naar een beveiligingsapparaat (Proofpoint, Mimecast, enz.) dat de e-mail vervolgens doorstuurt naar EOP, kan Microsoft DMARC niet opnieuw beoordelen, tenzij u ‘Enhanced Filtering for Connectors’ inschakelt in het Defender-portaal. Zonder deze instelling vertrouwt EOP op de beoordeling van de upstream-gateway en wordt standaard het ‘oreject’-gedrag toegepast voor e-mail die niet voldoet aan de criteria.

3. Een toegangsregel op huurdersniveau omzeilt de filtering.

Afzenders op de witte lijst, vertrouwde inkomende verbindingen of transportregels die een Spam Confidence Level (SCL -1) toekennen, worden volledig buiten de DMARC-handhaving gehouden en het bericht komt in de inbox terecht, ongeacht het beleid.

Voor een strengere aanpak schakelt u in het Defender-portaal naast ‘Honor DMARC’ ook ‘Spoof Intelligence’ in. Spoof Intelligence beoordeelt de reputatie van afzenders los van DMARC en plaatst berichten die op pogingen tot identiteitsfraude lijken in quarantaine, zelfs als de authenticatie technisch gezien geslaagd is.

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 oplossing.

Hoe stel je de regel op:

1. Ga naar het Exchange-beheercentrum → E-mailstroom → Regels en maak een nieuwe regel aan.
2. Stel de voorwaarde in: een berichtheader bevat een van deze woorden. Naam van de header: Authentication-Results. Waarde van de header: dmarc=fail action=oreject.
3. Stel de actie in: het bericht weigeren met een toelichting — voer bijvoorbeeld het volgende in: „Het bericht is niet geslaagd voor de DMARC-authenticatie en is geweigerd volgens het beleid van de organisatie.”
4. (Optioneel) Voeg een uitzondering toe voor vertrouwde interne afzenders of bekende legitieme doorstuurdiensten om valse positieven te voorkomen.
5. Stel de regelmodus de eerste week in op ‘Testen met beleidsaanbevelingen’. Bekijk de berichten die aan de regel voldoen in het berichtentrace voordat u overschakelt naar ‘Handhaven’.

Raadpleeg de uitgebreide documentatie van Microsoft over regels voor e-mailverkeer voor meer informatie.

Wanneer deze aanpak te gebruiken:

Transportregels zijn zinvol wanneer regelgeving of intern beleid voorschrijft dat ongeldige e-mail daadwerkelijk moet worden geweigerd, wanneer uw organisatie een aantrekkelijk doelwit is voor spoofing (bijvoorbeeld op het gebied van financiën, juridische zaken of communicatie op directieniveau), of wanneer u wilt dat direct-MX- en gateway-stromen van derden op dezelfde manier worden afgehandeld.

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.

In grote lijnen sluiten de vereisten van Microsoft voor e-mailverzenders aan bij de bredere trend in de sector naar strengere authenticatie en verantwoordingsplicht voor verzenders. De update introduceert duidelijke drempels, handhavingsmaatregelen en verwachtingen die voorheen minder strikt werden toegepast.

Belangrijkste wijzigingen die door Microsoft zijn doorgevoerd

• Verplichte DMARC voor bulkverzenders: domeinen die dagelijks meer dan 5.000 e-mails versturen naar de consumentendiensten van Microsoft, moeten voortaan beschikken over een geldig DMARC-record.
• Dit geldt voor Outlook.com, Hotmail.com en Live.com: de handhaving is specifiek gericht op het ecosysteem van Microsofts e-mailboxen voor consumenten, en niet alleen op zakelijke klanten.
• Minimale vereiste: DMARC met p=none: zelfs een beleid waarbij alleen wordt gecontroleerd, is acceptabel, maar het ontbreken van een DMARC-record wordt op grote schaal niet langer getolereerd.
• Meer nadruk op domeinafstemming: authenticatie alleen is niet voldoende; SPF en DKIM moeten overeenkomen met het zichtbare „Van“-domein om DMARC te laten slagen.
• Strikte afwijzing wegens niet-naleving: E-mails die niet aan de vereisten voldoen, kunnen worden geblokkeerd met de melding: 550 5.7.515 Toegang geweigerd, het verzendende domein [SendingDomain] voldoet niet aan het vereiste authenticatieniveau.

Door deze wijziging sluit Microsoft zich aan bij Google en Yahoo, die in februari 2024 soortgelijke eisen hebben ingevoerd, waardoor de drie grootste e-mailproviders nu allemaal authenticatie voor bulkverzenders verplicht stellen.

Platforms zoals PowerDMARC vullen deze leemte door speciale nalevingsprogramma’s aan te bieden die voldoen aan de eisen van e-mailproviders voor al uw verzendbronnen.

Waarom Microsoft 365 alleen niet voldoende is

Hoewel Microsoft 365 een krachtige bescherming tegen inkomende bedreigingen biedt, zijn de mogelijkheden voor het op grote schaal beheren en monitoren van DMARC beperkt – mogelijkheden die wel worden geboden door gespecialiseerde platforms voor e-mailverificatie.

Gebrek aan voor mensen begrijpelijke rapportage

Hoewel Microsoft nu DMARC-rapporten verstuurt naar zakelijke gebruikers, ontbreekt er een ingebouwd systeem om deze rapporten op een zinvolle manier te bundelen en te interpreteren. Deze rapporten worden in XML-formaat verzonden en zijn zonder gespecialiseerde tools vaak moeilijk te analyseren. Daardoor hebben organisaties vaak geen inzicht in wie er namens hen e-mails verstuurt en of die afzenders 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 ruwe rapporten om in bruikbare inzichten. Deze oplossing maakt 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 standaard niet biedt.

Problemen met DMARC in Office 365 oplossen

1. Er is geen DMARC-record gepubliceerd

Dit is het meest voorkomende probleem. „Geen DMARC-record gepubliceerd“ betekent in feite dat er voor uw domein geen DMARC TXT-record in de DNS staat, waardoor ontvangers geen beleid hebben om op te reageren.

Om dit probleem op te lossen, moet u eerst

• Controleer dit met behulp van een DMARC-checker.
• Als de tool de foutmelding „DMARC-record ontbreekt“ weergeeft, kun je dit oplossen door een record te publiceren dat begint met v=DMARC1; p=none; rua=mailto:[email protected], zodat je rapporten kunt gaan verzamelen voordat je het beleid aanscherpt.
• Zodra u vertrouwd bent met uw configuratie, kunt u geleidelijk overgaan tot handhaving, terwijl u uw rapporten in de gaten houdt.

2. Doorsturen schendt SPF en DKIM

Het doorsturen van e-mail is de belangrijkste oorzaak van legitieme e-mails die niet aankomen. Wanneer een tussenpersoon (een mailinglijst, doorstuurservice of beveiligingsapparaat) een header in de DKIM-handtekening wijzigt, kan de handtekening niet meer worden geverifieerd en mislukt DKIM. SPF faalt meestal tegelijkertijd, omdat het IP-adres van de doorstuurserver niet in uw record staat.

Hier volgen drie mogelijke aanbevolen werkwijzen om dit probleem op te lossen:

• Geef de voorkeur aan DKIM-conforme ondertekening bij de bron, aangezien DKIM beter bestand is tegen doorsturen dan SPF wanneer headers niet worden herschreven
• Gebruik Sender Rewriting Scheme (SRS) niet als oplossing, aangezien dit weliswaar SPF corrigeert, maar de afstemming van het ‘From’-domein niet herstelt, waardoor DMARC nog steeds faalt
• Stel vertrouwde ARC-sealers (Authenticated Received Chain) in Microsoft Defender in voor elke doorstuurservice die uw e-mail op legitieme wijze wijzigt. Microsoft zal het authenticatieresultaat van de bovenliggende server via de ARC-keten accepteren in plaats van het bericht direct af te wijzen.

3. SPF-permanente fout als gevolg van te veel DNS-opzoekingen

Als SPF plotseling voor elke legitieme bron niet meer werkt en een permanente foutmelding geeft, ligt de oorzaak meestal in de structuur en niet in de configuratie.

Hiervoor zijn mogelijk twee oorzaken:

• Ten eerste heb je de limiet van 10 lookups overschreden die SPF oplegt voor de mechanismen include, a, mx, redirect, exists en ptr. Geneste lookups binnen includes van leveranciers tellen ook mee, dus een record dat op het eerste gezicht in orde lijkt, kan stilletjes al 12 of 13 lookups bevatten. Zodra deze limiet wordt overschreden, retourneert elke ontvanger een permerror en stort de op SPF gebaseerde DMARC-afstemming voor het hele domein in één keer in.

Wat u kunt doen: Begin met het controleren van uw gegevens met behulp van een SPF-opzoektool en verwijder leveranciers die u niet meer gebruikt. Dit is echter slechts een tijdelijke oplossing. Een oplossing voor de lange termijn is het gebruik van een gehoste SPF-oplossing zoals PowerSPF, met optimalisatie van SPF-macro’s voor het dynamisch beheer van SPF-opzoekingen.

• De tweede oorzaak, als je specifiek „temperror“-fouten ziet bij Microsoft-bestemmingen, kunnen DNS-time-outs zijn. Als de time-outs bij een specifieke vermelding optreden, is dat de leverancier die je moet verwijderen of uit het record halen.

4. Het beleid inzake 'p=reject' wordt niet nageleefd

Sinds juli 2023 hanteert Microsoft standaard de instelling ‘p=reject’, wat betekent dat een bericht dat niet voldoet, direct moet worden afgewezen. Als dat niet gebeurt, is er sprake van een van de volgende vier situaties:

• Het naleven van DMARC kan in uw anti-phishingbeleid zijn uitgeschakeld: zorg ervoor dat de optie „DMARC-recordbeleid naleven wanneer het bericht als vervalsing wordt gedetecteerd“ is ingeschakeld en dat de actie voor p=reject is ingesteld op „Weigeren“ (niet op „In quarantaine plaatsen“).
• Er staat een gateway van een derde partij vóór Microsoft 365: als uw MX-recorder naar een beveiligingsgateway van een derde partij verwijst, zal Microsoft DMARC niet afdwingen, tenzij u ‘Verbeterde filtering voor connectoren’ inschakelt.
• Samengestelde authenticatie heeft voorrang op het resultaat: Microsoft voegt reputatiesignalen toe aan DMARC. Een bericht kan de DMARC-controle niet doorstaan en toch worden afgeleverd als compauth=pass
  (Lees hier meer over in de leergemeenschap van Microsoft).
• Een toelatingsregel voor afnemers omzeilt de filtering: een afzender op de toelatingslijst, een vertrouwde inkomende connector of een regel die het spamvertrouwensniveau SCL-1 toekent, zorgt ervoor dat de DMARC-handhaving volledig wordt overgeslagen.

Verdergaan met DMARC in Microsoft 365

DMARC in Microsoft 365 is een tweezijdig probleem. Exchange Online Protection voert de validatie van inkomende e-mail automatisch voor u uit, maar de bescherming van uitgaande e-mail is volledig uw verantwoordelijkheid. Door de wijzigingen in de handhaving die in mei 2025 van kracht worden, wordt die verantwoordelijkheid voor iedereen die grote hoeveelheden e-mail verstuurt, een dringende zaak.

De veiligste aanpak is de geleidelijke aanpak: begin met p=none, houd je rapporten twee tot vier weken in de gaten, corrigeer de afzenders die naar voren komen, ga vervolgens over op p=quarantine en uiteindelijk op p=reject. Het overslaan van stappen is de belangrijkste reden waarom legitieme e-mail tijdens de implementatie niet meer goed functioneert.

Zodra de handhaving van kracht is, verschuift de focus van het instellen naar het monitoren. Er komen nieuwe afzenders bij en externe leveranciers passen hun infrastructuur aan – en dit alles kan ongemerkt de afstemming verstoren als niemand de rapporten in de gaten houdt. Dat is waar een speciaal DMARC-platform zijn nut bewijst. De rapportage- en analysetools van PowerDMARC zetten ruwe XML-gegevens om in begrijpelijke inzichten en signaleren afwijkingen nog voordat deze tot een bezorgbaarheidsprobleem leiden.

Controleer eerst uw huidige DMARC-record om te zien hoe de stand van zaken op dit moment is.

Veelgestelde Vragen

Stelt Microsoft 365 DMARC automatisch in?

Microsoft controleert DMARC voor inkomende e-mail, maar stelt dit niet in voor uw eigen domein. U moet het uitgaande DMARC TXT-record zelf handmatig publiceren.

Is DMARC verplicht bij Microsoft?

Ja, Microsoft stelt DMARC verplicht voor afzenders met grote verzendvolumes. Het wordt ook ten zeerste aanbevolen voor alle organisaties om de afleverbaarheid en beveiliging te waarborgen.

Wat is foutmelding 550 5.7.515?

Deze foutmelding geeft aan dat uw e-mails worden geweigerd omdat er DMARC-beleidsregels ontbreken of niet voldoen aan de handhavingsregels van Microsoft.

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

Microsoft heeft in het verleden een interne overschrijvingsinstelling toegepast met de naam „oreject“ (origin reject), waardoor berichten die niet aan de DMARC-vereisten voldoen naar de map „Ongewenste e-mail“ worden doorgestuurd in plaats van direct bij de gateway te worden geweigerd. Dit was bedoeld om legitieme afzenders te beschermen tegen onbedoeld verlies, maar het zorgt er wel voor dat vervalste berichten zichtbaar blijven voor ontvangers.

Twee dingen die je moet weten:

1) Sinds de wijzigingen in de handhaving van mei 2025 streeft Microsoft naar een strengere, daadwerkelijke afwijzing van verzenders met grote volumes.

2) Als u wilt dat berichten binnen uw eigen Microsoft 365-tenant gegarandeerd worden geweigerd, maakt u een Exchange-transportregel aan waarmee berichten zonder meer worden geweigerd.

Moet ik 'quarantaine' of 'afwijzen' kiezen?

Begin met monitoring (p=geen) om uw verzendbronnen en e-mailkanalen te controleren, ga vervolgens over op quarantaine en pas de afwijzingsfunctie pas toe als u er zeker van bent dat alle legitieme bronnen in orde zijn.

• Over
• Laatste berichten

Yunes Tarada

Expert 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)

• Hoe een DKIM-record splitsen - 5 juni 2026
• compauth=fail: Uitleg over Microsoft Composite Authentication - 1 juni 2026
• Is Windows Defender voldoende voor de beveiliging van kleine bedrijven? - 14 mei 2026