DMARC in vier weken: naar p=reject zonder uw eigen mail te blokkeren

Wat DMARC is en waar hotels staan

DMARC (Domain-based Message Authentication, Reporting and Conformance) is een regel tekst in de DNS van uw domeinnaam. De DNS is het openbare register van het internet voor domeinnamen. DMARC vertelt ontvangende mailservers wat ze moeten doen met een bericht dat uw domeinnaam in het afzenderadres gebruikt, maar niet kan bewijzen dat het van u komt. Voor onze index over e-mailvervalsing bij hotels keken we op 28 september 2026 naar 732 domeinnamen van Vlaamse hotels. 52,7% had geen geldig DMARC-record en 34,3% had p=none, wat ontvangers vraagt om niets te ondernemen. Daarmee geeft 87,0% geen enkele instructie om een vervalste e-mail tegen te houden. Slechts 7,2% stond op p=quarantine en 5,7% op p=reject, en 157 van de 251 domeinnamen met p=none hadden ook geen rapporten aangevraagd. Het Centrum voor Cybersecurity België (CCB) en DNS Belgium noemen SPF, DKIM en DMARC in hun gezamenlijke richtlijnen tegen e-mailfraude (DNS Belgium). Onze e-mailcontrole toont hoe uw domeinnaam ervoor staat en legt uit hoe spoofing, het vervalsen van een afzender, werkt.

Week 1: breng elke afzender in kaart en ruim SPF op

SPF (Sender Policy Framework) is een DNS-record met de diensten die mail mogen versturen voor uw domeinnaam. DKIM (DomainKeys Identified Mail) zet een digitale handtekening op elk bericht, die gecontroleerd wordt aan de hand van een openbare sleutel in uw DNS. Een bericht slaagt voor DMARC als SPF of DKIM slaagt voor een domeinnaam die overeenkomt met die in het afzenderadres dat uw gast ziet. Die overeenstemming heet alignment (RFC 9989, sectie 4.4).

Noteer alles wat e-mail verstuurt met uw domeinnaam in het afzenderadres:

• de mailboxen in Microsoft 365 of Google Workspace
• uw boekingssysteem
• uw hotelbeheersysteem (PMS) of receptiesysteem
• uw facturatieprogramma of boekhoudpakket
• het programma waarmee u uw nieuwsbrief verstuurt
• het contactformulier op uw website, een scanner die documenten mailt, meldingen van het alarm of de camera's
• een extern bureau of uw boekhouder, als die in uw naam mailt

Vraag elke leverancier welke DNS-records hij nodig heeft voor SPF en DKIM.

Een SPF-record is een TXT-record dat begint met v=spf1. Elke externe dienst voegt u meestal toe met een include:-vermelding, zoals include:spf.protection.outlook.com voor Microsoft 365. Uw domeinnaam mag maar één SPF-record hebben; met twee faalt SPF met een permanente fout (RFC 7208, sectie 4.5). SPF laat ook hoogstens 10 DNS-opzoekingen toe (RFC 7208, sectie 4.6.4). Elke include kost minstens één opzoeking, en de includes die daarin genest zitten, tellen ook mee. Een record boven die limiet faalt met een permanente fout (Microsoft). Verwijder diensten die u niet meer gebruikt. Microsoft raadt aan om massamail zoals een nieuwsbrief te versturen vanaf een subdomein zoals nieuws.uwhotel.be, dat een eigen SPF-record en eigen 10 opzoekingen heeft.

Week 2: DKIM voor elke afzender, daarna DMARC op p=none

Microsoft 365 ondertekent mail van uw eigen domeinnaam pas met DKIM als u dat instelt. Het Defender-portaal geeft u twee CNAME-records (selector1._domainkey en selector2._domainkey) die u aanmaakt bij uw DNS-provider, en daarna zet u de ondertekening aan (Microsoft). Een CNAME-record verwijst van de ene naam naar een andere, zodat de provider de sleutel bijhoudt en kan vervangen. In Google Workspace maakt u in de beheerdersconsole een sleutel aan (van 2048 bits als uw DNS-provider dat aanvaardt), publiceert u het TXT-record dat daar verschijnt en start u de authenticatie. Volgens Google kan het tot 48 uur duren voordat DKIM werkt (Google).

Doe hetzelfde voor elke externe afzender. Veel van hen vragen CNAME-records onder _domainkey, zodat ze de sleutel kunnen vervangen zonder het u te vragen (M3AAWG, sectie 3.1.3). Verwijdert u later zo'n CNAME, dan trekt u de toestemming van die afzender in. Een dienst die alleen met zijn eigen domeinnaam ondertekent en zijn eigen retouradres gebruikt, haalt nooit alignment. Vraag of hij met uw domeinnaam kan ondertekenen, of een retouradres op uw domeinnaam kan gebruiken (vaak custom MAIL FROM genoemd).

Google raadt aan om na SPF en DKIM 48 uur te wachten voordat u DMARC publiceert (Google). Voeg daarna een TXT-record toe met de naam _dmarc en deze waarde:

v=DMARC1; p=none; rua=mailto:dmarc@uwhotel.be

Met p=none verandert er niets aan de aflevering van uw mail. De rua-tag vraagt ontvangers om verzamelrapporten (aggregate reports) te sturen: dagelijkse overzichten van wie er mail in uw naam verstuurde. Gebruik daarvoor dus een aparte mailbox. Staat die mailbox op een andere domeinnaam, dan moet die andere domeinnaam een record publiceren dat dit toelaat (RFC 9990, sectie 4). Zet de TTL (time to live: hoelang andere servers het record in hun cache mogen bewaren) op één uur, zodat een wijziging of een terugdraaiing snel effect heeft.

Sinds februari 2024 eist Gmail van wie meer dan 5.000 berichten per dag naar persoonlijke Gmail-adressen stuurt: SPF, DKIM, een DMARC-record (p=none volstaat), een afzenderdomein dat overeenkomt met SPF of DKIM, en uitschrijven met één klik (Google). Yahoo legt bulkafzenders dezelfde regels op, maar noemt geen aantal (Yahoo, veelgestelde vragen). Sinds 5 mei 2025 eist Microsoft SPF, DKIM en DMARC met alignment van wie meer dan 5.000 berichten per dag naar adressen van Outlook.com, Hotmail en Live stuurt, en weigert het mail die niet slaagt met foutcode 550 5.7.515 (Microsoft). Een nieuwsbrief naar uw volledige gastenlijst kan over die grens gaan.

Week 2 en 3: lees de rapporten en los op wat faalt

De rapporten komen binnen als een XML-bestand, meestal gecomprimeerd, in bijlage bij een e-mail, meestal dagelijks van elke grote mailprovider. Elke rij toont een verzendend IP-adres, een aantal berichten, of SPF en DKIM slaagden, en of ze overeenkwamen met uw domeinnaam (RFC 9990, sectie 3.1). Eenmaal uitgepakt opent het bestand in een browser, en het gratis opensource-opdrachtregelprogramma parsedmarc kan veel rapporten samenvoegen tot één tabel (een CSV-bestand).

Overloop de rijen afzender per afzender (Microsoft):

• Een dienst die u kent, slaagt voor SPF of DKIM en faalt toch voor DMARC. Hij ondertekent of verstuurt met zijn eigen domeinnaam; stel daar DKIM in met uw domeinnaam.
• Een dienst die u kent, faalt voor allebei. Hij ontbreekt in SPF en heeft geen DKIM; voeg beide toe.
• Een verzendend IP-adres dat u niet herkent, faalt overal. Vaak is dat iemand die uw domeinnaam vervalst, en precies die mail moeten quarantine en reject tegenhouden.
• Doorgestuurde mail faalt voor SPF, omdat de server die doorstuurt niet in uw record staat. DKIM blijft bij doorsturen meestal intact, nog een reden om elke afzender te laten ondertekenen.

U bent klaar voor week 4 als elke dienst die u gebruikt, in minstens een week aan rapporten DKIM of SPF met alignment toont. De standaard waarschuwt dat dit vele maanden kan duren als een deel van de mail maar af en toe vertrekt (RFC 9989, sectie 5.1.7). Gaan uw facturen maandelijks de deur uit, wacht dan tot u die verzending hebt zien slagen, ook als het plan daardoor langer duurt.

Week 4: eerst quarantine, dan reject

Wijzig het record naar p=quarantine. Mail die faalt, belandt dan meestal in de spammap. Volg de rapporten een paar dagen op en vraag aan de receptie of gasten melden dat ze een bevestiging niet ontvangen hebben. Als beide in orde zijn, schakelt u over naar p=reject, dat ontvangers vraagt om mail die faalt te weigeren. RFC 9989 is voorzichtiger voor domeinnamen waarvan de gebruikers berichten op mailinglijsten plaatsen: de standaard raadt dan minstens een maand p=none aan, en daarna even lang p=quarantine, voordat u naar p=reject gaat (sectie 7.4). Gebruiken uw medewerkers mailinglijsten, kies dan die tragere weg. U kunt SPF nu ook laten eindigen op -all in plaats van ~all, zoals Microsoft aanraadt zodra DKIM en DMARC ingesteld zijn.

RFC 9989, gepubliceerd in mei 2026, verving RFC 7489 en schrapte de pct-tag, waarmee een beleid op een percentage van de mail werd toegepast. Er kwam een testtag bij: met t=y vraagt u ontvangers om één niveau minder streng op te treden, zodat p=reject met t=y behandeld wordt als quarantine (sectie 4.7 en bijlage A.6). Ontvangers die nog de oude standaard volgen, negeren tags die ze niet kennen en passen het volledige beleid toe. Gebruik t=y dus pas als de rapporten in orde zijn.

Wat er mis kan gaan, en hoe u het terugdraait

• Een afzender die u over het hoofd zag, zoals een programma dat één keer per kwartaal mailt, belandt in de spam of komt terug als onbestelbaar. Voeg hem toe aan SPF en DKIM.
• Mail die het adres van een gast automatisch doorstuurt, of die via een mailinglijst loopt, kan falen voor DMARC. RFC 9989 bespreekt die gevallen en zegt dat een domeinnaam op p=reject zijn mail met DKIM moet ondertekenen, omdat SPF alleen niet meer werkt zodra mail doorgestuurd wordt (sectie 7.4).
• Door een tikfout kunnen ontvangers een fout melden of een deel van het record negeren, en heeft een domeinnaam twee DMARC-records, dan verwerpen ontvangers ze allebei (Microsoft, RFC 9989, sectie 4.10).
• Een nieuw boekingssysteem of nieuwsbriefprogramma dat al mail verstuurt voordat SPF en DKIM ervoor ingesteld zijn.

Terugdraaien is één aanpassing in de DNS: zet p=reject terug op p=quarantine of p=none. Met een TTL van één uur nemen ontvangers de wijziging binnen ongeveer een uur over. Behoud het rua-adres in elke fase, zodat de rapporten tonen wat er gebeurd is.

Wat DMARC niet tegenhoudt

DMARC beschermt uw eigen domeinnaam en de subdomeinen ervan. Een domeinnaam die erop lijkt en die iemand anders registreerde, met een extra woord of één andere letter, kan voor zichzelf voor elke controle slagen. Onze controle van domeinnamen die op de uwe lijken toont welke nauw verwante varianten van uw domeinnaam in gebruik zijn. DMARC ziet ook niet dat een echte mailbox overgenomen werd, want mail uit een gehackt account komt echt van uw systemen. Inloggen in twee stappen (tweestapsverificatie) op elke mailbox maakt dat veel moeilijker, en ons artikel over valse betaalverzoeken via Booking.com beschrijft wat de receptie kan doen.

Checklist

1. Breng elke dienst in kaart die met uw domeinnaam verstuurt.
2. Eén SPF-record, onder de 10 opzoekingen, met elke afzender erin.
3. DKIM aan in Microsoft 365 of Google Workspace en bij elke externe afzender.
4. DMARC op p=none, rua naar een aparte mailbox, TTL van één uur.
5. Rapporten gelezen tot elke gekende afzender een volle week alignment haalt.
6. Een paar dagen p=quarantine, daarna p=reject, en SPF dat eindigt op -all.
7. De e-mailcontrole opnieuw uitgevoerd na elke wijziging.