De ultieme gids voor DMARC

Met een DMARC record geef je als e‑mailverzender aan dat je beveiliging van je e‑maildomein serieus neemt. Het is ontworpen om jouw e‑maildomeinen te beschermen tegen spoofing. Spoofing is een methode die internetcriminelen gebruiken om zich voor te doen als een legitieme verzender en valse e‑mails te sturen. Het uit zich dan ook meestal in spam of in phishing, waarmee criminelen proberen vertrouwelijke informatie of geld te ontfutselen. Door DMARC goed in te stellen, ben je beter beschermd tegen spoofing. Toch blijft het belangrijk om alert te zijn, want DMARC beschermt niet tegen alles.

De functie van DMARC

Met DMARC haal je alles uit je SPF en/of DKIM record. Met deze twee methodes beperk je misbruik van je domeinen. DMARC bepaalt vervolgens wat een ontvangende mailserver mag doen met een e‑mail waarbij één van de twee records niet klopt.

Bij het ontvangen van een e‑mail controleert de ontvangende mailserver namelijk of deze (één of beide) records in orde zijn, alvorens de e‑mail daadwerkelijk in de inbox belandt. Het voordeel dat DMARC hier biedt is dat het vervolgens aangeeft wat er met de e‑mail mag gebeuren als een controle faalt.

DMARC geeft de ontvangende mailserver dus meer zekerheid en laat het belanden in de inbox niet meer over aan giswerk door die server. Het biedt jou als verzender meer zekerheid over je deliverability en geeft je inzicht in je e‑mailstromen.

Hoe werkt het?

Bij het verzenden van je e‑mail, wordt vanuit jouw (verzendende) mailserver gecommuniceerd richting de ontvangende mailserver. Deze ontvangende mailserver bepaalt op basis van jouw ‘From’‑domein of je e‑mail doorgelaten mag gaan worden. Dat gebeurt als volgt:

Bij het beoordelen van de e‑mail, checkt de ontvangende mailserver middels de public key van het domein of SPF en DKIM goed geregeld is. Daarnaast checkt het of er een DMARC policy aanwezig is. Die staat opgenomen in het DMARC record, waarbij de p= het beleid bepaald omtrent e‑mails die niet voldoen.

De policy kan op drie manieren ingesteld worden: ‘none’‘quarantine’ en ‘reject’. Bij none laat de domeineigenaar weten dat de mailserver niets hoeft te doen met het gefaalde bericht, quarantaine zorgt ervoor dat het bericht aangemerkt wordt en reject elimineert het gehele bericht.

Waar beschermt DMARC tegen?

DMARC geeft dus, kort gezegd, bij de ontvangende mailserver aan dat de e‑mail die jij verstuurt ‘goed’ is, en die van de phisher ‘fout’. Hierdoor weet de mailserver wat hij vervolgens met die specifieke e‑mail moet gaan doen.  Zo elimineert het fout e‑mailverkeer en maakt het een einde aan misbruik van jouw domein.

Dat is echter ook waar DMARC stopt met functioneren. Het is zo ontworpen dat het een specifiek domein beschermt, maar niet de nevendomeinen of de displaynaam. Hierdoor is het nog steeds mogelijk om in plaats vanuit het legitieme example.org, vanuit een foutief example.net of exampl3.org te e‑mailen.

Daarnaast kan ook met de displaynaam (bijvoorbeeld: “Tom van Flowmailer”) gespeeld worden. Die is namelijk niet per sé verbonden aan het verzendende domein. Op desktop‑applicaties is dat nog niet een enorm probleem, omdat hier beide worden weergegeven. Verschillende mobiele apparaten krijgen in hun mailbox echter alleen de displaynaam te zien, waardoor dat op korte termijn het enige referentiemateriaal is voor de ontvanger.

Door bovenstaande omwegen wordt het voor DMARC vrij lastig gemaakt om alle phishing vanuit ‘jouw’ domein tegen te gaan. Daarom is het raadzaam om, náást een goede implementatie van DMARC, klanten te informeren over de e‑mailadressen die jij gebruikt om te e‑mailen. Zo weet een klant zeker welke e‑mail wèl van jou komt en welke niet. Of een klant daadwerkelijk steeds zijn of haar e‑mails nauwkeurig checkt op legitimiteit blijft dan nog onzeker, maar door te informeren geef je in ieder geval aan dat je de veiligheid van je klanten (en je eigen domein) zeer serieus neemt.

De effectiviteit

Allereerst is DMARC pas effectief als de ontvanger elk bericht controleert en de verzender de juiste instellingen hanteert. Steeds meer providers doen dit al, waardoor met name onder consumenten een groot percentage ontvangers al bescherming geniet. Wanneer DMARC aan beide kanten wordt ondersteund, kun je als ontvanger de echtheid van een e‑mail bepalen door het afzender adres goed te controleren. Klopt het domein van de afzender precies, dan kun je ook zeker zijn van een legitiem bericht.

Voor alle betrokken partijen is het belang daarom groot om zo snel mogelijk alle e‑mailcommunicatie DMARC compliant te maken. Dit vereist echter wel een actieve aanpak, waarbij ook bestaande berichtstromen tegen het licht gehouden moeten worden. In Nederland maken veel banken, financiele instellingen en overheden al gebruik van DMARC of werken aan de implementatie.

De onderdelen van een DMARC record

Wanneer je het domein flowmailer.com door een DMARC record check heen haalt, zul je ongeveer het volgende te zien krijgen:

v=DMARC1; p=reject; rua=mailto:e‑mailadres; ruf=mailto:e‑mailadres; fo=1

Zoals je ziet bestaat die uit een vijftal onderdelen, waarop gecheckt wordt:

  1. v=DMARC1
  2. p=reject
  3. rua=mailto:
  4. ruf=mailto:
  5. fo=1

De v‑tag geeft aan waar het record over gaat. Het is daarbij altijd belangrijk om deze als eerste te vermelden. De v‑tag wordt ook gebruikt voor SPF, waardoor het voor je eigen DNS‑instellingen alsmede de ontvangende mailserver van belang is om te weten.

“p=reject”

De p‑tag bepaalt het beleid (“policy”) dat de ontvangende mailserver mag uitvoeren. Er zijn hiervoor drie verschillende mogelijkheden. Je kunt je policy op nonequarantine en reject zetten. Alle drie laten de ontvangende mailserver iets doen met berichten die zich lijken voor te doen als jouw domein. Wij raden een reject‑policy aan, om te garanderen dat niemand anders uit jouw naam kan en mag e‑mailen.

Zowel rua als ruf zijn rapportage‑tags. Met de rua-tag ontvang je zogeheten ‘Aggregated Data Reporting’, welke data afgeven over welke e‑mails wèl en niet geauthentiseerd zijn. Het geeft geen informatie over de exacte inhoud van die e‑mails, waar de ruf-tag wel meer inzicht in geeft.

De ruf-tag produceert namelijk zogeheten ‘Forensic Data Reporting’, waarmee een domeineigenaar gedetailleerde informatie kan ontvangen over ongeauthoriseerde e‑mails. Hiermee wordt een rapportage geboden over de inhoud, “To”‑ en “From”‑adressen en het IP‑adres van de verzender.

De fo‑tag geeft, in navolging van de ruf‑tag, aan hoe dit forensische rapport er dan vervolgens uit moeten komen te zien. Voor de fo‑tag (Failure reporting Options) zijn vier mogelijkheden:

  1. (0): Genereert rapportage als alle mechanismen niet door de DMARC‑check heen komen;
  2. (1): Genereert rapportage wanneer een enkel mechanisme al faalt;
  3. (d): Genereert enkel wanneer de DKIM‑signatuur niet geverifiëerd kon worden;
  4. (s): Wanneer het SPF record niet geverifiëerd kon worden.

Logischerwijs is de fo‑tag afhankelijk van de ruf‑tag. Als die tag niet gedefiniëerd is, kan er geen rapportage worden verzonden aan een e‑mailadres.

Verplichte en niet verplichte onderdelen

In een DMARC record zijn enkel de v‑ en de p‑tag vereist. Alle andere elementen zijn optioneel. De ontvangde mailserver heeft de v‑ en de p‑tag nodig om te herkennen dat het om een DMARC‑record gaat èn wat hij moet doen van dit record. De rest is optioneel. Zo hoef je dus geen rapportage te ontvangen als dit niet gewenst is.

Er zijn, naast de al eerder genoemde onderdelen, nog een aantal optionele onderdelen in een DMARC record. Die worden hieronder kort toegelicht:

  • sp: Geeft de policy weer voor subdomeinen (bijvoorbeeld: mail.flowmailer.com) – ook met none, quarantine en reject;
  • aspf: In welke mate SPF geauthenticeerd moet worden (s=strict)
  • adkim: In welke mate DKIM geauthenticeerd moet worden
  • pct: Het percentage van de berichten die onderhevig zijn aan filtering.

Een DMARC record instellen

Een DMARC record instellen bestaat hoofdzakelijk uit verplichte en niet-verplichte onderdelen. Voor het functioneren van DMARC moet een ontvangende mailserver namelijk twee dingen weten: a) Welk type record het is en b) welk beleid uitgevoerd moet worden.

Belangrijk aan een record is dat het hoofdlettergevoelig is én dat spatiëring soms wèl en soms niet is toegestaan. Let dus goed op waar deze regels gelden!

Aan het begin van je nieuwe DMARC record komt altijd de versie van het record te staan. In het record wordt dat momenteel genoteerd als v=DMARC1. We gebruiken namelijk de eerste versie van DMARC. Dit verplichte onderdeel moet bovendien vooraan staan, anders moet het volgens de specificatie genegeerd worden.

Het tweede verplichte onderdeel is zogezegd het beleid. In dit beleid geef je weer wat de ontvangende mailserver mag doen met e-mails die niet conform jouw SPF- en DKIM-record zijn.

Sta je aan het begin van DMARC implementatie en heb je nog geen volledig zicht op alle e-mailstromen namens jouw bedrijf? Dan is het raadzaam om te starten met een ‘none’ beleid met rapportage. Zo krijg je langzaamaan inzicht in alle e-mailstromen, zonder dat je belangrijke e-mails verliest door een streng beleid.

Wil je namelijk e-mailstromen die niet uit jouw bedrijf afkomstig zijn, maar wel uit jouw naam bij klanten aankomen, blokkeren, dan is het nodig om een strenger beleid te gaan voeren. Je moet dan weten welke adressen namens jouw naam mogen e-mailen, om vervolgens ‘quarantine’ of ‘reject’ als beleid toe te passen. Het eindresultaat van je beleid is dan p=nonep=quarantineof p=reject.

Met enkel een “v=DMARC1, p=none” ben je er echter nog niet. Door je DMARC record op deze manier in te stellen, laat je nog steeds alles door en heb je geen inzicht in je e-mailstromen. Om inzicht te creëren, kun je gebruikmaken van de zogeheten rua en ruf-tag. Deze zorgen er allebei voor dat de ontvangende mailserver rapportage terugstuurt over de e-mails die het ontvangt.

rua is generieke feedback op basis van ontvangen e-mails. ruf geeft voor berichten die niet door de controle heenkwamen een gedetailleerd rapport. De rapportage wordt door ontvangende mailservers teruggestuurd naar het adres dat achter deze tag wordt weergegeven.  Het kan zo zijn dat je rua (‘aggregate feedback’) en ruf (‘message specific failure information’) gescheiden wilt houden, bijvoorbeeld wanneer twee verschillende partijen gebruik maken van de informatie.

Bij gebruik van een platform zoals Flowmailer, waarbij rapportage inzichtelijk wordt gemaakt op basis van die feedback, kan het juist wenselijk zijn om beide adressen hetzelfde te houden.

Anderzijds kan het zo zijn dat je de feedback op meerdere adressen wenst te ontvangen. In dat geval kunnen achter de tag meerdere e-mailadressen geplaatst worden, gescheiden met een komma:

Bijvoorbeeld: “rua=mailto:dmarc@flowmailer.net, dmarc@jouwdomein.nl”

Vervolgens kun je bepalen om welke reden je forensische rapportage wilt ontvangen. Hiervoor kan de fo-tag ingezet worden. Deze tag geeft aan welk type rapportage er teruggezonden dient te worden door de mailserver. De fo-tag is niet verplicht, maar ook niet voor ontvangende mailservers. Het kan zo zijn dat je daardoor andere rapportage krijgt dan je hebt ingesteld.

Je kunt voor de fo-tag vier typen rapportage instellen:

  • 0: Genereert een rapport wanneer alle mechanismen falen (SPF en DKIM). Dit type staat standaard ingesteld bij gebruik van de ruf-tag.
  • 1: Genereert een rapport wanneer een enkel mechanisme faalt.
  • d: Alleen wanneer DKIM faalt, wordt een rapport verzonden.
  • s: Alleen wanneer SPF faalt, wordt een rapport verzonden.

fo=1 is het meest stricte type, omdat deze alle mechanismen serieus neemt en al bij een enkele faal rapportage stuurt.

Ook voor het te voeren beleid kun je nog een en ander opnemen in het record. Zo heb je soms te maken met subdomeinen die je anders wilt beveiligen dan het hoofddomein. Stuur je bijvoorbeeld je maandelijkse facturen via ‘facturen.jouwbedrijf.nl’ en heb je een ‘reject’-policy op jouwbedrijf.nl gezet, dan kun je voor de facturen een apart beleid aanmaken. Dit doe je door middel van de sp-tag, die verder hetzelfde werkt als de p-tag. Zet je de sp-tag op none, quarantine of reject, dan weet de ontvangende mailserver dat hij iets anders moet doen met die e-mails dan met e-mails van jouw hoofddomein.

Vervolgens kun je ook per mechanisme bepalen hoe streng de authenticatie is. Voor zowel SPF als DKIM kun je instellen dat de controle hierop relaxed of strict moet zijn. Strict houdt in dat authenticatie alleen lukt als de gegevens in de e-mail exact overeenkomen met de gegevens zoals ze zijn aangegeven in de DNS-instellingen. Dat betekent dat een subdomein niet meer uit naam van het hoofddomein kan e-mailen. Relaxed gaat daar wat soepeler mee om.

Voorbeeld: als je DMARC-record het domein ‘jouwbedrijf.org’ omvat, kun je ook e-mails versturen vanuit het subdomein ‘nieuws.jouwbedrijf.org’. Normaliter komen die e-mails dus perfect aan, tenzij je SPF en DKIM authenticatie op strict staat. Relaxed laat deze e-mail gewoon door.

De tags die voor deze policies worden gehanteerd zijn respectievelijk aspf en adkim: strict(s) en relaxed(r). Zo kan je apsf=s zijn en je adkim=r.

Een laatste instelling die je in je DMARC record kunt toepassen, is het percentage dat onderhevig moet zijn aan het beleid. Deze instelling is ontworpen om de domeineigenaar langzaamaan een reject-policy te laten implementeren, in plaats van alles of niets. Het percentage (pct-tag) kan logischerwijs tussen de 0 en 100 ingesteld worden, met een default op 100% (pct=100).

Het verwerken van het DMARC record in de DNS-instellingen

Om het DMARC record werkend te krijgen, zul je het record moeten verwerken in de instellingen van je Domain Name System (DNS). Dat doe je als volgt:

  1. Zoek naar de DNS-instellingen van je domein – bij providers meestal onder ‘Productinstellingen’
  2. Kies ‘Een record toevoegen’
  3. Selecteer TXT als het recordtype
  4. Kies host / target en definieer die als _dmarc
  5. Vul je DMARC record in als waarde
  6. Publiceer je nieuwe record

Nu je het record hebt ingesteld, zul je rapportage binnenkrijgen als je rua hebt aangezet. Hierdoor krijg je actuele inzichten over welke e-mails uit jouw naam verzonden worden. Het is ook mogelijk om die rapportage naar eigen wens vorm te geven. Zo kun je een limiet stellen op de grootte van de rapportage, een interval zetten op de timing van rapportage of het format van rapportage aanpassen.

Om de grootte van rapportage in te stellen, moet een onderdeel in het DMARC record aangepast worden. Het is niet noodzakelijk om dit te doen, maar aangezien sommige mailservers maximale groottes hanteren, kan het wel handig zijn. Bij zowel ruf- als rua-adressen kun je al naar gelang een maximaal aantal megabytes (m), gigabytes (g), kilobytes (k) en terrabytes (t) instellen. De standaard is ‘ongelimiteerd’, maar je kunt achter de e-mailadressen het gewenste volume aangeven. Dat ziet er als volgt uit:

Stel je wilt op je rua-adres (dmarc@example.org) een limiet instellen van 10 gigabyte en op je ruf-adres (rufdmarc@example.org) een limiet van 80 megabyte, dan moeten je adressen in je DMARC record zo geschreven worden: rua=mailto:dmarc@example.org!10g; ruf=mailto:rufdmarc@example.org!80m. Het uitroepteken volgt direct op het adres en wordt ook direct opgevolgd door het limiet.

Rapportage op gefaalde berichten kan ontvangen worden in verschillende vormen. Hoewel de specificatie alleen ingaat op het afrf-format, wordt er gespeculeerd over een andere vorm van rapportage: iodef. Met iodef (Incident Object Description Exchange Format) ontvang je uitgebreide rapportage over het incident, terwijl afrf (Authentication Failure Reporting Format) specifieke rapportage stuurt wanneer SPF of DKIM faalt. De laatste is tevens de default vorm van rapportage. De gewenste vorm voor DMARC rapportage kun je aangeven door in het record “rf=iodef” of “rf=afrf” op te nemen.

De derde en tevens laatste optie voor rapportage is de interval waarmee dit gebeurt. Normaliter gebeurt dit binnen een dag (of twee), maar er kan ook voor gekozen worden dit te verkorten of juist te verlengen. Verkorten is vooral handig wanneer er iemand binnen je bedrijf elke dag bezig is met security van je e-maildomein. De standaard is dus een dag, maar de interval wordt gedefinieerd in seconden. Kies je dus voor een hele korte interval, kun je de ri instellen op 1, voor een dag op 86400.

Meer weten over DMARC?

Heb je nog vragen of wil je aan de slag om je e-maildomein en je e-mailverkeer te beschermen? Onze adviseurs helpen je graag verder en vertellen je er alles over.

Go to top
Direct Contact