DMARC veilig invoeren: begin niet met p=reject

Begin op een actief maildomein met een inventaris van alle verzenders, controleer per mailstroom de SPF- of DKIM-uitlijning en publiceer daarna een DMARC-record met p=none. Gebruik de rapporten om vergeten diensten en mislukte controles te vinden. Pas wanneer legitieme mail aantoonbaar goed aankomt, komt p=quarantine in beeld; p=reject vraagt een afzonderlijke afweging.

Een directe overstap naar p=reject kan ook facturen, nieuwsbrieven en systeemmeldingen raken die via een externe dienst vertrekken. De implementatiehandleiding van SIDN begint daarom met p=none en gebruikt binnenkomende rapporten om vergeten verzendservers en problemen met DKIM te herstellen voordat het beleid strenger wordt.

Inventariseer de mail die je domein gebruikt

Noteer voor ieder domein en subdomein welke systemen daadwerkelijk berichten versturen. Denk aan gebruikersmail uit Microsoft 365, maar ook aan boekhoudsoftware, een nieuwsbriefdienst, webshop, helpdesk, websiteformulier en automatische meldingen. Vraag de beheerders van die toepassingen naar incidentele verzending: een factuurrun of campagne kan ontbreken in rapporten die slechts een korte periode bestrijken.

Leg per mailstroom het zichtbare Van-adres, de verzenddienst, het technische MAIL FROM-domein, het DKIM-ondertekeningsdomein en een verantwoordelijke vast. Bewaar de volledige headers van een representatief bericht dat bij een externe ontvanger is aangekomen. Daarmee kun je een afwijkende verzendbron later aan een bekende toepassing koppelen, zonder een onbekend IP-adres op goed geluk voor SPF te autoriseren.

Neem een gewone gebruikersmail en een geautomatiseerd bericht uit Microsoft 365 afzonderlijk mee.
Controleer een echte factuur, nieuwsbrief en systeemmelding via hun gebruikelijke verzendroute.
Markeer welke subdomeinen mail versturen en welke ongebruikt zijn voordat je hun beleid verandert.

Maak de inventaris per verzenddomein, niet alleen per leverancier. Een dienst kan verschillende Van-adressen of routes gebruiken voor transactieberichten en campagnes. Het relevante controlepunt is telkens het domein dat de ontvanger in het Van-adres ziet.

Controleer de uitlijning van SPF en DKIM

Een geslaagde SPF- of DKIM-controle is op zichzelf niet genoeg. De Microsoft 365-handleiding legt uit dat DMARC slaagt wanneer minstens één geldige controle uitlijnt met het zichtbare Van-domein: SPF via het MAIL FROM-domein of DKIM via het ondertekeningsdomein. Beide routes correct configureren geeft meer ruimte wanneer een bericht wordt doorgestuurd.

Controleer bij Microsoft 365 of de gebruikte verzendroute door SPF wordt gedekt en of DKIM namens je eigen domein ondertekent. Bij een externe factuur- of nieuwsbriefdienst kan SPF slagen voor het domein van de leverancier terwijl DMARC toch faalt. Stel dan, als de dienst het ondersteunt, een eigen MAIL FROM-domein of DKIM-ondertekening namens je domein in. Gebruik de DNS-waarden die bij jouw dienst en domein horen.

Verstuur na iedere aanpassing een bericht via de echte toepassing naar een mailbox buiten je eigen omgeving. Vergelijk in de ontvangen headers het Van-domein met smtp.mailfrom en het DKIM-domein achter d=. Lees ook het DMARC-resultaat: alleen spf=pass of dkim=pass zien, zegt nog niet dat de vereiste uitlijning is gelukt. Test iedere route apart, want een geslaagde gebruikersmail bewijst niets over de factuurdienst.

Publiceer eerst een record voor rapportage

Gebruik voor het voorbeelddomein example.com een TXT-record op _dmarc.example.com met de waarde ‘v=DMARC1; p=none; rua=mailto:[email protected]’. Dit is een voorwaardelijk voorbeeld: vervang het domein en het rapportadres door eigen waarden en zorg dat het postvak rapporten kan ontvangen en verwerken. Met p=none vraag je ontvangers niet om een bericht wegens een DMARC-fout tegen te houden; hun overige mailfilters blijven van toepassing.

Laat geaggregeerde rapporten aankomen in een afzonderlijk postvak of bij een verwerkingsdienst. Ze tonen verzendbronnen, aantallen en verificatieresultaten per rapporterende ontvanger. Beschouw ze niet als een volledige lijst van alle verzonden berichten: ontvangende systemen zijn niet verplicht rapporten te sturen. De optionele tag ruf vraagt meldingen over afzonderlijke fouten en vergt een bewuste keuze over de verwerking van die gegevens; voor dit wijzigingsplan volstaat rua.

Controleer na publicatie of de bedoelde TXT-waarde via DNS zichtbaar is en of bruikbare rapporten binnenkomen. Verander het beleid nog niet wanneer belangrijke verzendstromen ontbreken. Wacht tot ook minder frequente mail, zoals een factuurrun of nieuwsbriefcampagne, door de normale route is gegaan.

Herstel afwijkingen per verzendstroom

Vergelijk de bronnen in de rapporten met je inventaris. Een bekende dienst met SPF-pass maar mislukte SPF-uitlijning gebruikt mogelijk een MAIL FROM-domein dat niet bij het zichtbare Van-domein past. Ondertekent die dienst met haar eigen DKIM-domein, dan helpt een geldige handtekening van de leverancier evenmin voor de uitlijning van jouw Van-adres. Los het probleem op bij de betreffende dienst en controleer daarna opnieuw een ontvangen testbericht.

Een onbekende bron die op beide controles faalt, kan ongeoorloofd gebruik van je domein zijn, maar ook een vergeten toepassing of doorstuurroute. Vraag eerst wie de bron beheert en welk bericht zij verstuurt. Voeg haar niet uitsluitend toe aan SPF om het aantal fouten in rapporten te laten dalen. Bevestig voor kritieke stromen zowel ontvangst bij een externe mailbox als het DMARC-resultaat in de headers.

Verscherp per domein en leg de terugrol vast

Zijn de bekende stromen uitgelijnd en zijn de relevante verzendmomenten voorbijgekomen, wijzig dan voor één gekozen domein de voorbeeldwaarde naar ‘v=DMARC1; p=quarantine; rua=mailto:[email protected]’. Kijk of legitieme berichten bij ontvangers in ongewenste mail of quarantaine belanden. Gebeurt dat bij een belangrijke stroom, zet p terug op none en herstel de verzendroute voordat je opnieuw aanscherpt. Bewaar daarom de vorige TXT-waarde en wijs vooraf iemand aan die afleverproblemen opvolgt.

RFC 9989 schrapt de tag pct voor een procentuele uitrol, raadt p=reject af voor domeinen waarvan gebruikers naar internetmailinglijsten kunnen mailen en adviseert bij een toch overwogen overstap eerst minstens een maand p=none, gevolgd door even lang p=quarantine, te vergelijken. Ook als een producthandleiding nog een pct-voorbeeld toont, biedt die tag dus geen passende veiligheidsklep voor dit plan.

Doorsturen kan SPF-uitlijning verbreken; een mailinglijst die een bericht wijzigt, kan daarnaast de DKIM-handtekening ongeldig maken. Beoordeel daarom bij gewone gebruikersmail of p=quarantine het passende eindbeleid is. Voor een zorgvuldig afgebakende verzendstroom kun je na de controles eventueel ‘v=DMARC1; p=reject; rua=mailto:[email protected]’ publiceren. Vertrouw daarbij niet uitsluitend op SPF: zorg ook voor geldige DKIM-ondertekening namens het verzenddomein.

Een bevestigde DMARC-gerelateerde weigering van legitieme mail is het terugrolsignaal: zet p terug op quarantine of none en controleer wanneer de DNS-wijziging zichtbaar is. Herstel vervolgens de oorzaak en test dezelfde verzendroute opnieuw. Wijzig het hoofddomein en zijn subdomeinen niet tegelijk. Subdomeinen zonder eigen DMARC-record kunnen het beleid van het bovenliggende domein erven; leg een afwijkend beleid daarom expliciet vast voordat je het hoofdrecord aanscherpt.