Een Elementaire Uitleg van DMARC

DMARC 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.

Bescherm je merk

DMARC geeft, 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.

Bescherm je klanten

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.

Opbouw DMARC record

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

TXT | 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

"v=DMARC1"

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 none, quarantine 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.

"rua=mailto:" & "ruf=mailto:"

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.

"fo=1"

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.

Overige (optionele) onderdelen in een DMARC record

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);
• 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.