Alles wat je moet weten over e-mail authenticatie

Wat is authenticatie?

Authenticatie is eigenlijk een verzamelnaam voor een aantal technische instellingen waarmee jij als verzender kan bewijzen dat de e-mail die je verstuurt:

• In eerste plaats echt is
• En dat de mailserver waarmee de werd verzonden dit ook effectief mag doen.

Hoe bepalen mailservers of ze jouw mail mogen doorlaten naar de inbox?

De ontvangende mailserver zal bij het in ontvangst nemen van je e-mail onder andere deze technische instellingen controleren, kijken naar de inhoud van je bericht, naar eventuele eerdere berichten die door jou werden verzonden en op welke manier hun gebruikers met jouw bericht omgingen.

Op deze manier zal de ontvangende server proberen in te schatten wat er met het bericht moet gebeuren.

Het komt er eigenlijk op neer dat de mailserver zich afvraagt:

‘Is deze e-mail afkomstig van de afzender die hij beweert te hebben?’ 
‘Hoe kan ik dit verifiëren?’
‘Wat moet ik doen indien een e-mail niet correct geauthenticeerd werd?’

Aan de hand van het antwoord op deze vragen zal de server bepalen wat er met bericht zal gebeuren: in de inbox plaatsen, naar de spam folder verbannen of het bericht in zijn geheel weigeren.

Waarom is dit zo belangrijk?

Omdat e-mail nog steeds vaak wordt ingezet voor ongewenste mails en ook steeds meer voor berichten met slechte intenties zoals phishing, zijn de grote e-mailproviders (Denk Gmail, Yahoo, Hotmail etc) steeds op zoek naar manieren om dit soort mails zo goed mogelijk te weren.

Wanneer jij als authentieke afzender helemaal geen authenticatie toepast bij het versturen van je e-mails is de kans daardoor ook steeds groter dat ze worden bestempeld als spam, ongewenst of - in het slechtste geval - zelfs helemaal niet meer aankomen bij je ontvanger.

Gmail weigert niet geauthenticeerde e-mails volledig

Google is een van deze grote spelers die zich de laatste jaren heeft geprofileerd als voorvechter van authenticatie.

In een ver verleden waren ze net eerder terughoudend om e-mails te blokkeren, waardoor de spam folders van een Gmail account steeds goed gevuld waren.

Geleidelijk aan zijn ze steeds strenger geworden in hun beleid en blokkeren ze intussen net sneller e-mails waarmee problemen zijn. Denk daarbij aan mislukte authenticatie controles, e-mail headers die de webstandaarden niet volgen, enz. Het lijkt er op dat wanneer ze in de toekomst nog andere gegronde reden zouden vinden om slechte of fout geconfigureerde mails te weren, ze dit ook zonder pardon zullen doen.

Het is met andere woorden nu belangrijker dan ooit dat je e-mail systemen juist geconfigureerd staan.

Hoe kan ik mijn e-mails authenticeren?

Er zijn verschillende manieren om authenticatie toe te passen, maar de twee meest gebruikte manieren om e-mail te authenticeren zijn Sender PolicyFramework en DomainKeys Identified Mail.

Beide maken daarvoor gebruik van DNS records op het domein van jouw website, maar elk focust zich dan weer op een ander onderdeel van de e-mail.


Je domeinbeheerder (of jij) zal deze records moeten toevoegen via het portaal van je webhosting of de plaats waar je domeinnaam staat.

SPF is een mechanisme dat je toelaat om aan te geven vanaf welke IP adressen (servers) er e-mails gestuurd mogen worden in naam van jouw domein.

DKIM laat je dan weer toe om een e-mail digitaal te ondertekenen voor echtheid zodat de ontvanger kan verifiëren dat er onderweg niets werd aangepast.

Daarnaast heb je ook nog DMARC. Dit is een overkoepelend geheel voor de SPF- en DKIM controles en doet daarbovenop nog een extra controle op het overeenstemmen van het domein van adressen in de header van je e-mail (later meer hierover).

Ook kun je als afzender via je DMARC policy aangeven wat de ontvangende mailserver met het bericht moet doen indien de DMARC controle niet zou slagen voor een e-mail.


In onderstaande puntjes gaan we nog dieper in op elk van deze records.

1. SPF - Sender Policy Framework

Wat doet een SPF record precies?

Sender Policy Framework is een controlemechanisme dat werd ontwikkeld om het vervalsen van afzenderadressen bij de aflevering van een e-mail tegen te gaan en in een keer de betrouwbaarheid van e-mail te verhogen.

Het protocol dat we gebruiken om e-mail naar elkaar te kunnen sturen, SMTP, laat het namelijk toe dat eender welke computer berichten kan versturen en zich daarbij kan voordoen als eender welke afzender. Niet meteen de werking die je in praktijk zou willen.

Een SPF record staat in de DNS records van jouw domein en bevat een lijst met alle IP adressen die toestemming hebben om e-mails te versturen in naam van dat domein.

Wanneer er bijvoorbeeld iemand met slechte bedoelingen een e-mail zou versturen in jouw naam – door jouw gebruikelijke afzender e-mailadres na te bootsen – dan zou zonder SPF de oorsprong van deze e-mail voor de ontvangende partij niet te onderscheiden zijn van een echte e-mail die wél door jou werd verzonden.

Dankzij SPF records kan de ontvangende mailserver eenvoudig controleren dat de e-mail die in eerste instantie afkomstig lijkt vanaf jouw afzendadres wel delijk werd verzonden vanaf een IP adres dat daar de toestemming voor heeft.

Wanneer dit het geval is dan zal de authenticatie op basis van SPF slagen.

Wanneer je jouw marketingcampagnes via Flexmail verstuurt is het daarom belangrijk dat je onze IP adressen aan jouw SPF record toevoegt en je ons op die manier de toestemming geeft om mails in naam van jouw domein te versturen.

Hoe ziet zo’n SPF record er uit?

Elk SPF record moet aan specifieke richtlijnen voldoen zodat de mailserver de inhoud juist kan interpreteren.

Even een concreet voorbeeld om het wat visueler te maken:

v=spf1 ip4:185.18.8.192/26 include:spf.flexmail.eu
include:spf.protection.outlook.com -all

In dit voorbeeld geeft de server aan over welk soort DNS record het gaat, welke IP adressen zijn toegelaten, welke derde partijen toestemming hebben voor dit domein en wat er moet gebeuren wanneer e-mails zouden zijn die niet in het rijtje passen.

Laten we het record verder opdelen ter verduidelijking:

• Het stukje v=spf1 geeft aan dat het over een SPF record gaat. Elk geldig SPF record moet dus beginnen met dit onderdeel.
• Dan hebben we een opsomming van alle toegelaten partijen.
  Er zijn verschillende mechanismen die hiervoor gebruikt kunnen worden gaande van (reeksen van) specifieke IP adressen zoals ip4:185.18.8.192/26 tot het opnemen van een volledig ander extern SPF record van een derde partij zoals Flexmail include:spf.flexmail.eu of bijvoorbeeld Microsoft include:spf.protection.outlook.com
• Tot slot is er de qualifier -all die aangeeft dat alle adressen die niet zijn opgenomen in het record niet gemachtigd zijn om mails te sturen in jouw naam en geweigerd moeten worden.
• Alternatief bestaat ook de qualifier ~all die aangeeft dat alle IP adressen die niet zijn opgenomen in het record moeten beschouwd worden als onveilig of SPAM, maar wel nog aangenomen mogen worden. Dit zou je kunnen toepassen als je ook gebruikmaakt van DMARC met als policy quarantaine of reject.

Hoe stel ik dit juist in?

Om Flexmail als een geautoriseerde afzender op te nemen in je SPF record volstaat het om include:spf.flexmail.eu toe te voegen aan je bestaande record. Op die manier worden de IP adressen van al onze mailservers automatisch in jouw SPF record opgenomen.

Ook als onze IP adressen zouden veranderen blijft jouw SPF record op deze manier helemaal up-to-date!

Als je nog geen SPF record hebt zou je er een kunnen aanmaken met daarin minimaal het onderstaande:

v=spf1 include:spf.flexmail.eu -all

SPF juist gebruiken

Om er zeker van te zijn dat je SPF record correct zijn werk kan doen, zijn er een aantal zaken die je in het achterhoofd moet houden:

• Er mag slechts één SPF record zijn op het domein. Als je al een SPF record hebt, zal je jouw bestaande record moeten wijzigen om de verwijzing naar Flexmail te bevatten.
• Elk subdomein heeft zijn eigen SPF record. Je zou subdomeinen kunnen inzetten om verschillende e-mailstromen van elkaar gescheiden te houden.
• Het record moet staan op het domein waar je vandaan stuurt; bijvoorbeeld op het domein flexmail.be wanneer je verstuurt vanaf info@flexmail.be.
• Het record moet altijd eindigen met het all onderdeel voorafgegaan door een geldige qualifier.
• Een SPF record mag in totaal slechts 10 lookups bevatten over alle mechanismen zoals include: en mx: heen. Wanneer een extern SPF record een verwijzing bevat naar andere externe records, tellen deze ook mee voor de lookups van jouw record. Controleer je SPF record bij twijfel met een van de gratis SPF validatie tools die je online kan vinden.

2. DKIM - DomainKeys Identified Mail

Wat doet DKIM precies?

Door de manier waarop e-mail achterliggend werkt, zal een SPF record het doorsturen van het bericht tussen meerdere (interne) mailservers niet overleven en is om die reden op zichzelf niet voldoende voor authenticatie.

Het tweede onderdeel van e-mailauthenticatie dat we daarom onder de loep nemen is DomainKeys Identified Mail.

Je kan DKIM het beste zien als een digitale handtekening die door de afzender wordt toegevoegd aan de e-mail. Een deel van deze handtekening, de privé sleutel, is daarbij enkel gekend door de afzender.

Doordat er bij het digitaal ondertekenen bepaalde onderdelen en de volledige inhoud van het bericht worden gebruikt (hierover later meer), kan er op die manier worden gegarandeerd dat er aan alle onderdelen die werden gebruikt bij het handtekenen niets is veranderd tussen het verzenden en ontvangen van de e-mail.

De ontvanger kan de digitale handtekening van de afzender controleren met behulp van een publieke sleutel in de DNS records van jouw domein.

Wanneer de handtekening klopt, kan de ontvanger met andere woorden met zekerheid zeggen dat de afzender is wie hij beweert te zijn en dat het bericht dat ontvangen werd ook echt is.

Waaruit bestaat een DKIM record?

Een DKIM record is net zoals het SPF record een DNS TXT record dat aan bepaalde richtlijnen moet voldoen.

Laten we het volgende voorbeeld bekijken:

flexmail._domainkey.flexmail.be. IN TXT
v=DKIM1;g=*;k=rsa;p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAs/Gs/1IM67pWCo4Q37eLNEz+rhqQJO/B0tXPlApbdPi8gq4kxbXlq3MFbRsni5VDm/ivrueebOqzytM/
MYDcDx6izyYHfqwzW6PX3RRvRoASROq6oAM1jFde1CMtIwKYviSq5XLJ3mIeIt6mKW5pDOZdr9PLlj2YjdXY9ZeLDS2BiHkIJsFQ23t2wkwXwRQzxitTZUwEeWgnZll4kFClO6TzBmr9MFajEgnLPCdsKnkVCrVf36ahNZbZna2Q0dVBuoC+6N+3iYi25VdioqxNy6uc5Ubp9bAm9cNBi6tE8Te2sSU4gvmZCjI1Ak2jYBKr1iWFfK314gcIpUMunv7icwIDAQAB

Naam van het record

In tegenstelling tot de meeste normale TXT records, worden DKIM records opgeslagen onder een specifieke naam op je domein en niet gewoon onder het domein zelf.

De naamgeving van DKIM records houdt daarbij het volgende formaat aan:

[selector]._domainkey.[jouwdomein.be]

De selector is een specifieke waarde die aangeeft welke DKIM sleutel er door de afzender werd gebruikt bij het ondertekenen van de e-mail, zodat de ontvanger de juiste publieke sleutel kan opvragen.

Het is door deze specifieke naamgeving ook mogelijk om meerdere DKIM keys te gebruiken op hetzelfde domein, bijvoorbeeld een aparte selector per dienstverlener waarvan je gebruik maakt of om gebruikte DKIM sleutels te roteren voor extra veiligheid.

In het voorbeeld hierboven kan je stellen dat we onze e-mail versturen vanaf een @flexmail.be adres en gebruik maken van de flexmail selector.

Inhoud van het record

Nu je weet waar het record moet komen te staan, rest nog de inhoud van het record. Dit is eigenlijk de publieke sleutel die de ontvanger gebruikt om de handtekening van het bericht te controleren.

Laten we eens naar de onderdelen in detail kijken:

• Het stuk v=DKIM1; in het voorbeeld geeft aan dat het om een DKIM record gaat.
• g=*; geeft de granulariteit van de publieke sleutel aan en zou ingezet kunnen worden om het gebruik van die sleutel te beperken tot één specifieke afzender.
  Wij gebruiken voor deze waarde een asterisk, zodat de sleutel voor elke gevalideerde afzender van het domein kan worden ingezet.
• Het stuk k=rsa; geeft aan dat de gebruikte encryptie methode RSA is.
• Alles wat na p= volgt is de eigenlijke publieke sleutel en heeft in ons geval een lengte van 2048 bit.

Hoe werkt dat handtekenen dan?

De verzendende server stelt de handtekening samen door gebruik te maken van e-mailheaders, de inhoud van het bericht en een privé sleutel. Deze handtekening wordt aan het bericht toegevoegd als onderdeel van de DKIM header.

Die DKIM header is een van de vele e-mailheaders die een e-mail bevat. Deze headers zijn technisch van aard en worden daarom door de meeste e-mailprogramma’s in de meeste gevallen verborgen voor de gebruiker.

Deze headers kunnen door ontvangers wel zichtbaar gemaakt worden door in de instellingen van hun e-mailprogramma te duiken.

Hieronder een (vereenvoudigd) voorbeeld van zo’n DKIM header:

v=1;
a=rsa-sha1;
s=flexmail;
d=flexmail.be;
h=Date:To:From:Subject;
i=support@flexmail.be;
bh=PQqKzsjcrGzED4VQPw+9jhU9dP4=;
b=eruM0kNDvSH/+/7cK+FItpViMi+7iwRAwRWGAinTgNZZpIB6achCj4GzBLwod9nsqiMTjlvKbzPkgaK/EskZC4tQ599eAitNbeamq4AIMkqiqdOzvL4Nc9POm6Ftxdy8ns6c9aj8q13cOAtboGjc+q39QyClLe62UJgnu6jAcPHNRh21MsemW5UpioC57QLRT0fD5LIau5ZKNkkSvTJZqtEKJI9wa6y3PPWNcTJgAds2T5Z88uOBAUxUql52HQkkVJPy4VaSAaTxUK0X5nYnYOyGk4dYW6ICyPGdVvIHt/wcDw77EHvdjgR9FqNIWrDDJ+4d4b8wdhU0ko+1s8UKOw==

• v= geeft aan welke versie van DKIM werd gebruikt. In praktijk is dit altijd 1.
• s= geeft aan welke selector gebruikt moet worden om het bijbehorende DNS record op te vragen.
• d= het domein dat zal worden gebruikt om het bijbehorende DNS record op te vragen en weerspiegelt het domein van de afzender.
• h= lijst alle header velden op die werden gebruikt om de digitale handtekening, b=, samen te stellen. De volgorde van deze onderdelen speelt ook een rol bij de controle.
  In dit vereenvoudigde voorbeeld maken we gebruik van de e-mailheaders datum,aan, van en onderwerp.
• bh= is een berekende waarde, oftewel hash, voor de inhoud van de e-mail. Om een hash te kunnen berekenen wordt er gebruikgemaakt van een gespecialiseerde wiskundige functie.
  Deze hash wordt daarna toegevoegd aan het bericht zodat de ontvangende e-mailserver de handtekening al kan berekenen voordat het volledige bericht wordt geladen. Omdat e-mails een onbepaalde lengte kunnen hebben, kan er op deze manier tijd bespaard worden.
• a= geeft het algoritme weer dat werd gebruikt bij het berekenen van de digitale handtekening, b=, en de hash van de e-mailinhoud, bh=. In dit voorbeeld wordt er gebruik gemaakt van RSA-SHA1.
• b= is de digitale handtekening, gegenereerd met de waarden uit h= en bh=.

Deze digitale handtekening zorgt ervoor dat de ontvangende server enerzijds de versturende mailserver kan authenticeren en anderzijds ook zeker kan zijn dat er niet met de e-mail werd geprutst.

De ontvangende server doet dit door dezelfde inhoud (die wordt opgesomd in h= ) en de body hash (bh=) te combineren en af te toetsen tegen de publieke sleutel van het DKIM record. Enkel wanneer de bijhorende privé sleutel werd gebruikt en indien de inhoud niet werd aangepast (zowel headers als inhoud) zal deze controle lukken en zal de e-mail slagen voor de DKIM controle.

3. DMARC - Domain-based Message Authentication Reporting and Conformance

Wat is DMARC?

Domain-based Message Authentication Reporting and Conformance, kortweg DMARC, is een overkoepelend geheel voor het SPF en DKIM controles . De bijhorende DMARC policy geeft aan wat de ontvangende mailserver met het bericht moet doen indien de DMARC controle zou falen voor een e-mail.

Hoe werkt DMARC?

DMARC kan alleen zijn ding doen wanneer je minimaal een SPF of een DKIM record hebt ingesteld. In het beste geval heb je natuurlijk beide.

Het is in dit verhaal belangrijk om te weten dat er bij e-mail ook een envelop rond het bericht zit, net zoals bij briefpost. Op deze envelop staan een aantal extra gegevens van de versturende mailserver, zoals een afzenderadres. Dit adres op de envelop zal worden gebruikt om een reactie te versturen naar de verzendende mailserver wanneer de e-mail niet kon worden bezorgd.

Bij ontvangst van een e-mail zal de ontvangende mailserver controleren of er voor het verzendende domein een DMARC record bestaat en daarna de gewoonlijke SPF/DKIM controles van hierboven uitvoeren.

Daarna zal er ook een zogenaamde ‘DMARC alignment test’ worden uitgevoerd om te controleren dat:

• Bij SPF het domein van het afzender adres van de e-mail overeenstemd met dat van het terugstuur adres dat op de envelop staat.
• Bij DKIM het domein dat in het d= onderdeel van de DKIM header staat overeenstemt met het domein van het afzender adres.

Je kan daarbij nog aangeven deze alignment controle “strict” moet gebeuren (de domeinen moeten exact overeenstemmen) of het gebruikelijke “relaxed” (hoofddomein moet gelijk zijn, maar het gebruik van een subdomein is toegelaten).

De DMARC controle zal slagen in de volgende gevallen:

• Indien er slechts één authenticatiemethode is ingesteld (SPF of DKIM), moet de authenticatie controle slagen én moet de domeinen in lijn liggen met elkaar.
• Als beide authenticatiemethodes zijn ingesteld, moet slechts een van beide controles slagen inclusief de bijhorende alignment test.

Omdat een afbeelding vaak meer zegt dan 1000 woorden zetten we het nog even in een duidelijk schema:

Waaruit bestaat een DMARC record?

Een DMARC record is - net zoals alle andere die eerder aan bod kwamen - ook een TXT record dat in je DNS records van je domein staat. Een praktisch voorbeeld van zo’n record:

v=DMARC1; p=reject; rua=mailto:55465eddd9f1@report.example.com;
ruf=mailto:5b0ddsfd54d9f1@report.example.com; sp=none;

Ook dit record begint met v= om aan te geven welke versie het gaat, bij DMARC is dat v=DMARC1;

Wanneer de DMARC controle om welke reden dan ook zou falen, zal er worden gekeken naar de ingestelde policy in p=.

Je hebt 3 mogelijkheden:

• p=none; De e-mail moet gewoon behandeld worden zoals zou gebeuren wanneer er geen DMARC record zou zijn. Dit gebruik je meestal als je jouw e-mailstromen in kaart wil brengen, zonder daarbij afleverbaarheid te beïnvloeden.
• p=quarantine; laat toe dat de ontvangende mailserver de e-mail aanneemt, maar deze zou niet in de inbox mogen belanden. In veel gevallen zal het bericht zo in de SPAM folder terechtkomen.
• p=reject; Het bericht moet volledig geweigerd worden. Dit zal resulteren in een bounce.

Met rua= geef je aan naar welke mailbox de samenvattende rapporten verzonden mogen worden. Dit is eigenlijk een verplichte waarde als je de kracht van DMARC wil kunnen benutten en zulke samenvattende rapporten wil ontvangen.

Je ontvangt zo’n samenvattend rapport als een XML document en bevat per E-mail Service Provider informatie (Gmail, Yahoo,...) over de status van de DMARC, SPF en DKIM controle en de bijhorende domeinen. Ook zal je het verzendende IP adres terugzien in die rapporten om zo de oorsprong van je verkeersstromen te kunnen volgen.

Doordat deze rapporten moeilijk leesbaar zijn voor mensen zijn er tal van diensten die deze XML-documenten in zinvolle rapporten omzetten, vaak compleet met visualisaties in grafieken.

Met ruf= kan je aangeven naar welke mailbox de DMARC forensische rapporten en rapporten bij het falen van een DMARC controle verstuurd mogen worden. Niet elke provider zal deze instelling volgen door privacy redenen.

Wanneer je nog maar net met DMARC start, kan je beter inzetten op de samenvattende rapporten die je krijgt via rua=.

Verder kan via je DMARC record via adkim= en aspf= voor iedere alignment controle aangeven of deze “strict” (adkim=s; / aspf=s;) moet gebeuren. In dat geval moeten de domeinen van de vergeleken elementen exact overeenstemmen.

Wanneer je niets expliciet meegeeft zal de controle “relaxed” gebeuren. Dit betekent dat het hoofddomein wel gelijk moet zijn, maar het gebruik van een subdomein is toegestaan. Je kan dit ook expliciet aangeven door de waarde r mee te geven.


Via sp= kan je optioneel een afwijkende policy aangeven voor subdomeinen. Als je deze waarde achterwege laat, en er op het subdomein zelf geen DMARC record bestaat, zal de policy van het hoofddomein automatisch worden toegepast.

Met pct= kan je verder nog bepalen op hoeveel percent van het e-mailverkeer je DMARC policy moet worden toegepast. Wanneer je deze waarde achterwege laat, zal pct=100 gebruikt worden en zal de policy voor alle e-mails worden toegepast.

Hoe doe ik dit nu in praktijk?

Waar kan ik de SPF en DKIM records in Flexmail terugvinden?

In je accountinstellingen kan je onder het kopje ‘Verzenden’ doorklikken naar Afzenders toevoegen of verwijderen.

Op deze pagina zal je al jouw afzenderadressen gegroepeerd zien staan per domein en kan je via de knop ‘Authenticatie instellen’ meer details tonen over de records van dat specifieke domein.

Heb je dit nog niet eerder gedaan? Dan zal je eerst nog even een selector moeten kiezen om je geheime en publieke DKIM te kunnen genereren.

Zodra je de DKIM sleutels hebt gegenereerd zal je zien dat je nu onderaan ook op een extra knop ‘Rapport Genereren’ kan klikken om het Authenticatie rapport te downloaden.

Hoe voeg ik deze records aan mijn DNS toe?

In veel gevallen kan je het authenticatie rapport van de vorige stap simpelweg aan de domeinbeheerder, webmaster of eventueel zelfs jouw IT afdeling doorspelen. Dit bestandje vertelt hen precies wat ze voor je moeten doen. Handig toch? En daarbij kan je nu ook steeds naar dit artikel doorverwijzen.

Heb je geen domeinbeheerder, webmaster of IT-held die zich hierover kan ontfermen?

Dan zou je contact kunnen opnemen met de support afdeling van jouw hostingproviderof op zoek kunnen gaan in de handleiding om te achterhalen hoe het toevoegen en aanpassen van TXT-records precies in zijn werk zou gaan.

Elk DNS portaal werkt net weer eenn beetje anders, maar in grote lijnen zal het neerkomen op:

• Open de DNS instellingen van het gewenste domein.
• SPF:
  • Heb je al een SPF record? Wijzig dit bestaande record met de inhoud uit het authenticatie rapport.
  • Nog geen SPF record? Maak een nieuw TXT record aan met de inhoud uit het authenticatie rapport.
  • De inhoud van je record start steeds met v=spf1.
• DKIM:
  • Voeg een nieuw TXT-record toe en hou daarbij rekening met speciale naamgeving en de eerder gekozen selector.
  • De inhoud van je record start steeds met v=DKIM1; en kan je terugvinden in je authenticatie rapport.

Goed starten met DMARC

Heb je je SPF en DKIM (al) op punt staan? Dan kan je overwegen om het nog een stap professioneler aan te pakken met DMARC.

Omdat een DMARC policy zware gevolgen kan hebben voor je afleverbaarheid wanneer je authenticatie niet helemaal op punt staat, is het aan te raden om je policy in stapjes te verstrengen en tussentijds het effect steeds te evalueren.

Stel dat je nog geen DMARC policy hebt en je zou hier mee willen beginnen, dan is het aan te raden om eerst een DMARC record aan te maken met p=none; en daarbij een rua= adres in te stellen om de samenvattende rapporten te ontvangen.

Je voegt hiervoor bijvoorbeeld het volgende TXT record toe:

v=DMARC1; p=none; rua=mailto:55465eddd9f1@report.example.com;

Het is ook aan te raden om meteen een tool te gebruiken om deze rapporten in een leesbaar formaat te gieten, zodat je gemakkelijker iets met de data kan doen die DMARC je oplevert.

Eenmaal je een idee hebt welke e-mailstromen er zijn en (dankzij de DMARC rapporten) weet welke zaken nog verbeterd moeten worden op het vlak van authenticatie kan je daarmee aan de slag.

Denk daarbij aan het instellen van DKIM, SPF of het in lijn brengen van alle domeinen. Zodra dit gebeurd is, kan je de policy aanpassen van p=none; naar p=quarantine;. Start initieel ook met een laag percentage dat moet afgetoetst worden, bijvoorbeeld pct=10;.


Merk je na een tijd dat alles goed gaat verhoog je het percentage geleidelijk tot je op 100 zit. Als je merkt dat ook bij 100% alles goed gaat, kan je de policy zelf verstrengen van p=quarantine; naar p=reject;.

Hou er rekening mee dat bij elke aanpassing of nieuwe verkeersstroom, bijvoorbeeld bij een nieuw platform voor e-mailmarketing, dit proces mogelijk herhaald of tijdelijk wat versoepeld zal moeten worden.

Tot slot

Met alles wat je in dit artikel hebt gezien zouden deze DNS records alvast geen grote geheimen meer voor je mogen hebben en kan je jouw authenticatie tip top in orde brengen.

Geraak je er niet helemaal uit? Of zie je door het bos de bomen niet meer?

Contacteer ons en we helpen je graag op weg!