e-mailbeveiliging
voor het mkb

dmarc (domain-based message authentication, reporting, and conformance) is een e-mailauthenticatieprotocol. het is uw digitale bodyguard die controleert of een e-mail die namens u wordt verzonden, ook echt van u afkomstig is. het werd cruciaal nadat grote providers als google en yahoo in 2024 strengere eisen stelden: zonder dmarc lopen uw e-mails, zoals nieuwsbrieven of facturen, een groot risico om in de spamfolder te belanden of zelfs helemaal niet aan te komen.

zie het als een team:
• spf (sender policy framework) is de gastenlijst. u definieert welke servers (ip-adressen) namens uw domein mogen mailen.
• dkim (domainkeys identified mail) is het zegel op de envelop. het voegt een digitale handtekening toe die bewijst dat de inhoud van de e-mail onderweg niet is veranderd.
• dmarc is de baas van het team. het vertelt de ontvangende server wat te doen als een e-mail niet slaagt voor de spf- of dkim-check (negeren, in quarantaine plaatsen of weigeren) en vraagt om rapportages hierover.

de gouden regel is: begin altijd met een `p=none` beleid (policy=none). dit wordt de 'monitoring-modus' genoemd. uw e-mails worden niet geblokkeerd, maar u ontvangt wel rapporten (rua-rapporten) over wie er namens uw domein e-mails verstuurt. dit geeft u de tijd om al uw legitieme verzendbronnen (zoals mailchimp, uw website, uw crm-systeem) correct te configureren in uw spf- en dkim-records, voordat u het beleid aanscherpt.

dit zijn de drie beleidsopties:
• p=none: doe niets met de e-mail, maar stuur mij wel een rapport. ideaal om te starten.
• p=quarantine: plaats de e-mail in de spam- of junkmap als deze niet slaagt voor de dmarc-check. dit is de tussenstap.
• p=reject: weiger de e-mail volledig. de e-mail komt helemaal niet aan bij de ontvanger. dit is het uiteindelijke doel voor maximale veiligheid.

• rua (reporting uri for aggregate reports) stuurt u dagelijks een samengevat xml-rapport. hierin staat welke ip-adressen namens uw domein mailen en of ze slagen voor spf/dkim. dit is essentieel voor het monitoren en opzetten van dmarc.
• ruf (reporting uri for forensic reports) stuurt een kopie van de individuele e-mail die de dmarc-check niet heeft doorstaan. vanwege privacy-implicaties (de inhoud van de mail wordt meegestuurd) wordt dit minder vaak gebruikt en ondersteund.

dit is een cruciale stap. externe diensten die namens u e-mailen (zoals nieuwsbriefplatforms, transactionele e-maildiensten) moeten worden geautoriseerd. u doet dit door hun specifieke spf- en dkim-records toe te voegen aan uw dns-instellingen. elke serieuze provider heeft hier duidelijke documentatie voor. als u dit niet doet, zullen hun e-mails falen voor de dmarc-check zodra uw beleid op `quarantine` of `reject` staat.

de `pct` (percentage) tag is een veiligheidsmechanisme. het stelt u in staat om uw dmarc-beleid (`quarantine` of `reject`) gefaseerd uit te rollen. bijvoorbeeld, `pct=10` betekent dat het beleid slechts op 10% van de falende e-mails wordt toegepast. dit geeft u de kans om de impact te monitoren en te controleren of u geen legitieme e-mails blokkeert, voordat u naar 100% gaat.

alignment controleert of het domein in het 'van'-adres (het adres dat de ontvanger ziet) overeenkomt met het domein in de dkim-handtekening en het spf-record.
• relaxed (standaard): subdomeinen zijn toegestaan. een e-mail van `nieuws@nieuwsbrief.uwdomein.nl` slaagt voor de check voor `uwdomein.nl`.
• strict: het domein moet exact overeenkomen. dit is veiliger, maar vereist een nauwkeurigere configuratie, vooral als u veel subdomeinen gebruikt voor het verzenden van e-mail.

dit varieert sterk per organisatie. voor een simpel bedrijf kan het een paar weken duren. voor een complexe organisatie met veel externe verzenders kan het maanden duren. de fasen zijn doorgaans:
1. inventarisatie & p=none: enkele weken data verzamelen.
2. configuratie: spf/dkim voor alle bronnen correct instellen.
3. aanscherpen naar p=quarantine: monitoren of er legitieme mails in de spam belanden.
4. overstap naar p=reject: de laatste stap voor volledige bescherming.

de `sp` (subdomain policy) tag definieert een specifiek dmarc-beleid voor al uw subdomeinen. als u deze niet instelt, erven subdomeinen het hoofddomeinbeleid (`p=`). u kunt `sp=reject` gebruiken om alle subdomeinen streng te beveiligen, zelfs als uw hoofddomein nog op `p=quarantine` staat, of andersom. dit geeft granulaire controle.

dit is een veelvoorkomend probleem. een spf-record mag maximaal 10 dns-lookups bevatten. als u veel externe diensten gebruikt, overschrijdt u deze limiet snel. de oplossing is 'spf flattening' of 'spf compression'. dit kan handmatig door ip-adressen direct in het record te plaatsen (minder flexibel) of via gespecialiseerde diensten die uw spf-record dynamisch "plat maken" en up-to-date houden.

ja, en dat is een zeer sterke aanbeveling! voor domeinen die nooit e-mail versturen (zoals geparkeerde domeinen of domeinen die alleen voor interne systemen worden gebruikt), kunt u een zeer strikt dmarc-record instellen. dit voorkomt dat criminelen deze domeinen misbruiken voor phishing. een typisch record hiervoor is: `v=dmarc1; p=reject; rua=...;` in combinatie met een leeg spf-record (`v=spf1 -all`).

hoewel de rua-rapporten in een machine-leesbaar xml-formaat zijn, zijn ze voor mensen vrijwel onleesbaar. het is sterk aan te raden om een dmarc-analysedienst te gebruiken (zoals dmarcian, postmark, of onze eigen managed service). deze diensten verwerken de xml-bestanden en presenteren de data in overzichtelijke dashboards, waardoor u direct ziet welke bronnen aandacht nodig hebben.

automatisch doorsturen (forwarding) kan dmarc breken. wanneer een e-mail wordt doorgestuurd, verandert de verzendende server, waardoor de spf-check faalt. als de doorsturende server ook de inhoud licht aanpast, kan dkim ook breken. moderne mailservers gebruiken arc (authenticated received chain) om dit probleem op te lossen door de authenticatieresultaten mee te sturen. als u veel problemen ervaart hiermee, is het belangrijk dat de mailservers van uw communicatiepartners arc ondersteunen.

dmarc is een extreem effectieve verdediging tegen *exact domain spoofing*. het is echter geen zilveren kogel voor alle e-mailbedreigingen. het stopt bijvoorbeeld geen 'look-alike' domeinen (`info@spoef-nl.com`) of aanvallen waarbij de naam van de afzender wordt vervalst maar het e-mailadres anders is. daarom blijft een gelaagde beveiligingsaanpak, inclusief geavanceerde threat protection en security awareness training, essentieel.