DMARC, DKIM en SPF instellen: van inventarisatie naar p=reject

Criminelen hoeven je mailbox niet te hacken om uit naam van je bedrijf te mailen. Zonder goede domeinbeveiliging kunnen zij proberen berichten te versturen met een afzender als facturen@jouwbedrijf.nl. Voor een ontvanger lijkt zo'n bericht op het eerste gezicht echt. Dat vergroot de kans op factuurfraude, phishing en reputatieschade.

SPF, DKIM en DMARC helpen ontvangende mailservers om te beoordelen of een bericht werkelijk namens jouw domein mag worden verstuurd. De technieken vullen elkaar aan. SPF beschrijft toegestane verzendroutes, DKIM voorziet berichten van een controleerbare digitale handtekening en DMARC verbindt die controles aan het domein dat de ontvanger ziet. DMARC bepaalt bovendien wat er met een verdacht bericht moet gebeuren en levert rapportages.

De grootste fout is om meteen een streng DMARC-beleid te publiceren zonder te weten welke systemen namens je bedrijf mailen. Microsoft 365 is vaak maar één afzender. Denk ook aan een CRM, salarispakket, nieuwsbriefdienst, websiteformulier, boekhoudpakket, servicedesk, scanner en leveranciersportaal. Deze gids helpt je daarom niet alleen records te begrijpen, maar vooral een veilige uitrol en blijvend beheer te organiseren.

Wil je weten of je domeinen, mailboxbeveiliging en beheerproces op elkaar aansluiten? Breng de belangrijkste risico's in kaart met de gratis IT-scan.

Wat SPF, DKIM en DMARC ieder bewijzen

SPF staat voor Sender Policy Framework. In een DNS-record publiceer je welke servers of diensten e-mail namens een domein mogen verzenden. De ontvangende server vergelijkt de verzendende infrastructuur met dat record. SPF beoordeelt de technische envelop-afzender, ook wel MAIL FROM genoemd. Dat is niet altijd hetzelfde domein als het zichtbare Van-adres.

DKIM staat voor DomainKeys Identified Mail. De verzendende dienst ondertekent delen van een bericht met een privésleutel. De ontvanger haalt de publieke sleutel op via DNS en controleert of de handtekening klopt. Zo ontstaat bewijs dat een bevoegde dienst het bericht heeft ondertekend en dat de ondertekende inhoud onderweg niet ongemerkt is gewijzigd.

DMARC staat voor Domain-based Message Authentication, Reporting and Conformance. DMARC controleert of een geslaagde SPF- of DKIM-controle aansluit bij het zichtbare afzenderdomein. Dit heet alignment. Het gepubliceerde beleid vertelt ontvangers vervolgens of zij berichten die niet voldoen normaal mogen behandelen, in quarantaine moeten plaatsen of moeten afwijzen.

Controle: SPF en DKIM leveren technisch bewijs; DMARC beoordeelt of dat bewijs bij het zichtbare afzenderdomein past en koppelt er beleid en rapportage aan.

Een bericht hoeft voor DMARC niet zowel SPF als DKIM te halen. Eén correct uitgelijnde controle kan voldoende zijn. In de praktijk is het verstandig beide technieken goed in te richten. Doorsturen kan SPF bijvoorbeeld breken, terwijl een geldige, uitgelijnde DKIM-handtekening het bericht dan nog kan laten slagen.

Waarom dit ook een leveringsvraagstuk is

Domeinauthenticatie is beveiliging, maar inmiddels ook een voorwaarde voor betrouwbare aflevering. Microsoft stelt voor domeinen die meer dan 5.000 berichten per dag naar Outlook.com-, Hotmail.com- en Live.com-adressen sturen SPF, DKIM en DMARC verplicht. Deze eis geldt voor de consumentenmaildienst van Microsoft, niet automatisch voor iedere Microsoft 365-tenant. Andere grote mailboxproviders hanteren vergelijkbare eisen.

Ook als je volume lager ligt, is wachten onverstandig. Facturen, offertes en afspraakbevestigingen moeten aankomen. Een plotselinge aanscherping onder tijdsdruk leidt juist tot fouten. Richt authenticatie daarom in voordat een campagne, acquisitiepiek of nieuwe applicatie het verzendvolume verhoogt.

Authenticatie garandeert geen inboxplaatsing. Ontvangers beoordelen ook reputatie, klachten, inhoud, volume en verzendgedrag. SPF, DKIM en DMARC vormen de technische toegangsdrempel, niet het volledige reputatiebeheer.

Maak eerst een register van alle e-mailstromen

Begin met inventariseren, niet met DNS wijzigen. Maak één register met ieder systeem dat mail gebruikt. Leg per stroom minimaal vast:

Onderdeel	Voorbeelden	Wat je controleert
Persoonlijke mail	Exchange Online, andere mailprovider	domein, connectoren, DKIM-status
Bedrijfsapplicaties	CRM, ERP, HR, facturatie	verzenddomein, authenticatie, leverancier
Marketing	nieuwsbrief, campagneplatform	eigen subdomein, SPF- en DKIM-instructies
Website	formulieren, webshop, meldingen	afzender, retouradres, maildienst
Apparaten	printer, scanner, alarmsysteem	SMTP-route, eigenaar, modern alternatief
Leveranciers	boekhouder, brancheportaal, servicedesk	toestemming, contract, beëindigingsproces

Gebruik niet alleen interviews. Controleer ook berichttracering, bestaande DNS-records, facturen van cloudleveranciers en configuraties van applicaties. Vraag afdelingen welke systemen automatisch offertes, loonstroken, meldingen of afspraakbevestigingen sturen. Een vergeten stroom wordt vaak pas zichtbaar wanneer streng beleid de mail blokkeert.

Geef elke stroom een eigenaar. "Marketingtool" is geen eigenaar. Een naam of functie met beslisbevoegdheid wel. Leg ook vast hoe de stroom wordt getest, wanneer zij voor het laatst is gebruikt en hoe je haar uitschakelt. Verwijder oude leveranciers uit SPF en DKIM wanneer zij aantoonbaar niet meer mogen verzenden.

Richt SPF beheerst in

Een domein hoort één SPF-record te hebben. Meerdere losse SPF-records kunnen een permanente fout veroorzaken. Voeg toegestane diensten daarom samen in één geldige policy en houd rekening met de limiet van tien DNS-opzoekingen tijdens de SPF-evaluatie. Geneste include-verwijzingen tellen mee. Een record dat er kort uitziet kan daardoor toch te complex zijn.

Voor Microsoft 365 is include:spf.protection.outlook.com meestal onderdeel van het record voor een aangepast domein dat via Exchange Online verzendt. Kopieer nooit blind een voorbeeld. Je volledige mailarchitectuur bepaalt wat nodig is. Voeg een leverancier alleen toe wanneer duidelijk is welke verzendroute die gebruikt en wie de toestemming beheert.

Microsoft adviseert voor Microsoft 365-domeinen -all, in combinatie met DKIM en DMARC. Doe dat pas nadat de verzendinventaris klopt. SPF is niet de plek om een onbekend probleem snel op te lossen door ieder zichtbaar IP-adres toe te voegen. Gedeelde cloud-IP-adressen zijn vaak geen veilige of stabiele autorisatie-eenheid.

Ieder subdomein dat zelf mail verzendt, heeft een eigen SPF-record nodig. Het SPF-record van jouwbedrijf.nl geldt niet automatisch voor marketing.jouwbedrijf.nl.

Activeer DKIM per legitieme verzenddienst

DKIM wordt per maildienst ingericht. De leverancier maakt een selector en sleutel aan. Jij publiceert de gevraagde DNS-records en activeert daarna ondertekening in de dienst. Alleen een DNS-record plaatsen zonder de verzenddienst te laten ondertekenen is niet genoeg.

Voor aangepaste Microsoft 365-domeinen moet DKIM expliciet worden geconfigureerd. Microsoft geeft hiervoor twee CNAME-records die naar de tenantconfiguratie verwijzen. Controleer de actuele waarden in Microsoft Defender of met de ondersteunde beheerinterface, want de bestemming is tenant- en domeinspecifiek.

Controleer na activering een echt ontvangen testbericht en bekijk de Authentication-Results-header. Let op dkim=pass en het ondertekenende header.d-domein. Voor DMARC moet dat domein aansluiten bij het zichtbare Van-domein. Een leverancier kan technisch een geldige DKIM-handtekening plaatsen die toch niet bij jouw afzenderdomein hoort.

Microsoft adviseert voor bulk- of andere externe maildiensten een apart subdomein, bijvoorbeeld nieuws.jouwbedrijf.nl. Daarmee beperk je reputatie- en configuratierisico voor het hoofddomein. Configureer SPF, DKIM en DMARC ook voor dat verzendende subdomein.

Plan sleutelrotatie volgens het ondersteunde proces van de verzenddienst. Documenteer selectors, eigenaar, activeringsdatum en laatste rotatie. Verwijder oude selectors pas nadat je hebt vastgesteld dat geen legitieme dienst ze nog gebruikt.

Start DMARC met rapportage

Een DMARC-record staat onder _dmarc.jouwdomein.nl. Begin doorgaans met een monitorbeleid (p=none) en een adres voor geaggregeerde rapportages. Die rapporten laten per verzendende bron zien hoeveel berichten SPF en DKIM halen en of alignment klopt. Gebruik bij voorkeur een rapportageservice die XML veilig omzet in een beheerbaar overzicht.

Publiceer geen rapportageadres zonder beheerproces. Wijs iemand aan die afwijkingen onderzoekt. Controleer in de monitorperiode:

• bekende Microsoft 365- en leveranciersstromen;
• onbekende verzendende IP-adressen;
• bronnen die SPF halen maar niet uitgelijnd zijn;
• bronnen die DKIM gebruiken maar met het verkeerde domein ondertekenen;
• pieken, nieuwe landen of plotselinge volumes;
• foutieve subdomeinen en vergeten testomgevingen.

Los legitieme fouten op bij de bron. DKIM met je eigen domein is voor externe verzenddiensten vaak robuuster dan een steeds langer SPF-record. Als een leverancier geen nette alignment ondersteunt, overweeg dan een apart subdomein of een andere verzenddienst.

Verscherp met meetbare acceptatiecriteria

Na een representatieve monitorperiode kun je naar p=quarantine gaan. Gebruik eventueel de DMARC-instelling pct om een deel van de falende berichten onder beleid te brengen. Volg rapportages en servicedeskmeldingen en vergroot gecontroleerd. Ontvangende partijen bepalen uiteindelijk hoe zij quarantaine toepassen.

Ga pas naar p=reject wanneer alle bedrijfskritische stromen zijn getest, onverwachte bronnen zijn afgehandeld en er een terugvalbesluit klaarligt. Afwijzen biedt de sterkste instructie tegen directe domeinspoofing, maar maakt slechte inventarisatie direct zichtbaar als bedrijfsuitval.

Uitrol: Een volwassen DMARC-uitrol verscherpt beleid pas nadat rapportages en praktijktests bewijzen dat legitieme afzenders correct authenticeren.

Gebruik per fase aantoonbare criteria:

Fase	Minimale controle voor doorgang
Inventarisatie	Iedere kritieke stroom heeft een eigenaar en testbericht
p=none	Bekende bronnen zijn verklaard en alignmentfouten hebben een actie
p=quarantine	Geen onverklaarde uitval, support weet hoe incidenten worden gemeld
p=reject	Alle kritieke stromen slagen, rollback en change-eigenaar zijn vastgelegd

Bewaar rapportages, testresultaten en goedkeuringsbesluiten als beheerbewijs. Dat helpt bij een ISO 27001- of NIS2-controle, maar vooral bij de volgende wijziging.

Bescherm ook subdomeinen en ongebruikte domeinen

Een DMARC-record kan met sp= beleid voor subdomeinen aangeven. Subdomeinen zonder eigen DMARC-record erven in beginsel het bovenliggende beleid. SPF en DKIM werken anders: ieder gebruikt verzendend subdomein vereist een eigen inrichting.

Vergeet geregistreerde domeinen die je niet voor mail gebruikt niet. Microsoft adviseert voor zulke geparkeerde domeinen een SPF-record dat verzending uitsluit en een DMARC-beleid dat mail afwijst. Publiceer geen DKIM-sleutels voor een domein dat niet verzendt. Neem ook het onmicrosoft.com-domein mee in de beoordeling. Als dat niet voor normale mail wordt gebruikt, voorkom dan dat het een vergeten route blijft.

Domeinauthenticatie voorkomt niet iedere vorm van phishing. Een aanvaller kan een sterk lijkend domein registreren met een typefout of andere extensie. Combineer DMARC daarom met MFA, domeinmonitoring, gebruikersbewustzijn en een veilig betaalproces. Lees hoe je MFA voor je organisatie instelt en hoe je Exchange Online-spam en quarantaine beheert.

Diagnoseer een storing zonder de beveiliging open te zetten

Wanneer legitieme mail niet aankomt, verlaag dan niet direct het hele DMARC-beleid. Verzamel eerst één volledig testbericht of foutmelding en controleer de resultaten:

1. spf=fail: controleer de werkelijke MAIL FROM, de verzendende bron, het juiste DNS-record en de opzoeklimiet.
2. spf=pass, maar dmarc=fail: SPF kan slagen voor een leverancierdomein dat niet aansluit bij het zichtbare Van-domein. Herstel alignment of gebruik uitgelijnde DKIM.
3. dkim=none: activeer ondertekening in de verzenddienst. Alleen DNS-records publiceren is niet voldoende.
4. dkim=fail: controleer selector, publieke sleutel en of een tussenliggende dienst de ondertekende inhoud wijzigt.
5. Doorgestuurde mail faalt: doorsturen kan SPF breken. Een geldige DKIM-handtekening of correct ingerichte ARC-keten kan helpen. Maak geen brede allowregel voor een volledig domein als een gerichte oplossing mogelijk is.
6. Onbekende bron in DMARC-rapportage: onderzoek eigenaar en gebruik. Autoriseer de bron pas nadat de bedrijfsreden en configuratie zijn bevestigd.

Leg storing, oorzaak, wijziging en hertest vast. Zo wordt een incident een verbetering van het verzendregister in plaats van een tijdelijke DNS-uitzondering.

Maak er een vaste beheercyclus van

Controleer minimaal ieder kwartaal:

• welke domeinen en subdomeinen geregistreerd zijn;
• welke systemen namens ieder domein verzenden;
• of SPF binnen de technische limieten blijft;
• of DKIM actief is en sleutels volgens afspraak roteren;
• of DMARC-rapportages nieuwe of falende bronnen tonen;
• of p=reject nog voor alle actieve en geparkeerde domeinen geldt;
• of oude leveranciers en selectors verwijderd kunnen worden;
• of een test naar externe consumenten- en zakelijke mailboxen slaagt.

Koppel nieuwe verzenddiensten aan inkoop en wijzigingsbeheer. Geen leverancier mag namens het hoofddomein verzenden zonder eigenaar, DNS-review, DKIM-configuratie, test en beëindigingsafspraak. Daarmee wordt e-mailauthenticatie een beheerproces dat de IT-manager ontlast, in plaats van een verzameling DNS-records die niemand durft aan te raken.

Veelgestelde vragen

Zorgt DMARC ervoor dat al onze mail in de inbox komt?

Nee. DMARC helpt ontvangers de identiteit van je domein te beoordelen. Aflevering hangt ook af van reputatie, inhoud, volume, klachten en het beleid van de ontvanger. Correcte authenticatie is een noodzakelijke basis, geen garantie op inboxplaatsing.

Kunnen we meteen p=reject instellen?

Technisch kan dat, maar operationeel is het riskant wanneer niet alle afzenders bekend en getest zijn. Start met inventarisatie en rapportage, herstel legitieme stromen en verscherp daarna gecontroleerd.

Is SPF alleen voldoende?

Nee. SPF sluit niet altijd aan bij het zichtbare Van-domein en kan bij doorsturen breken. DKIM en DMARC voegen ondertekening, alignment, beleid en rapportage toe.

Mogen we meerdere SPF-records publiceren?

Nee. Publiceer één samenhangend SPF-record per domein. Meerdere records kunnen een permanente SPF-fout geven. Laat complexe records controleren op syntaxis, opzoeklimiet en ongebruikte leveranciers.

Moeten alle leveranciers in ons SPF-record?

Niet automatisch. Sommige diensten authenticeren beter via DKIM met jouw domein of gebruiken een apart retourdomein. Volg de officiële instructies, controleer DMARC-alignment en voeg alleen noodzakelijke, beheerde autorisaties toe.

Hoe lang moeten we monitoren voordat we handhaven?

Er is geen universeel aantal dagen. Kies een periode die normale én minder frequente bedrijfsstromen omvat, zoals maandfacturatie of salarisverwerking. Handhaaf pas wanneer de afgesproken acceptatiecriteria aantoonbaar zijn gehaald.

Geldt de Microsoft-grens van 5.000 berichten voor iedere organisatie?

De gepubliceerde eis richt zich op domeinen die meer dan 5.000 berichten per dag naar Outlook.com-, Hotmail.com- en Live.com-consumentenadressen sturen. Microsoft 365-bedrijfsontvangers vallen niet onder precies die aankondiging. SPF, DKIM en DMARC blijven ook bij lagere volumes de aanbevolen basis.

Gebruikte bronnen

De technische werking, Microsoft 365-inrichting, diagnose en verzendeisen zijn op 22 oktober 2026 gecontroleerd tegen deze bronnen zonder trackingparameters:

• How email authentication works in Microsoft 365
• Set up SPF for your Microsoft 365 domain
• Set up DKIM for your custom domain
• Set up DMARC for cloud senders
• Troubleshoot email authentication in Microsoft 365
• Outlook requirements for high-volume senders

Microsoft werkt productgedrag en documentatie regelmatig bij. Controleer de actuele tenant- en leveranciersconfiguratie voordat je DNS wijzigt.

Van DNS-project naar aantoonbaar beheer

Een sterk maildomein ontstaat niet door drie records één keer te publiceren. Inventariseer iedere verzendstroom, zorg voor uitgelijnde SPF of DKIM, gebruik DMARC-rapportage en verscherp pas na tests naar p=reject. Bescherm ook subdomeinen en geparkeerde domeinen, en behandel iedere nieuwe verzenddienst als een gecontroleerde wijziging.

Zo verklein je de kans op domeinmisbruik én op uitval van legitieme facturen, offertes en meldingen. Het resultaat is meetbare beveiliging, minder ad-hoc herstelwerk en een beheerproces dat directie en IT-manager kunnen uitleggen.