De drie authenticatietechnieken SPF, DKIM en DMARC vormen samen een effectieve beveiliging van je e-maildomein. Je moet deze technieken wel correct implementeren om van die beveiliging te kunnen profiteren. Implementatie van SPF, DKIM en DMARC kan complex zijn en je hebt er goede kennis van de bijbehorende standaarden voor nodig. Het gaat dan ook nog wel eens mis met SPF-, DKIM- en DMARC-implementaties We zien de volgende problemen regelmatig terug.
Om DMARC te laten werken voor de beveiliging van je e-maildomeinen moet je eerst SPF en DKIM correct instellen. Voor elk van deze drie protocollen moet je o.a. een regel aan je DNS toevoegen. Daarmee vertel je aan ontvangende e-mailservers hoe jij wilt dat ze de DMARC-, DKIM- en SPF-beveiliging toepassen op e-mails die afkomstig zijn van jouw domein. Als je een of meer van deze regels vergeet toe te voegen aan je DNS of verkeerd toepast, werkt je e-mailbeveiliging niet.
DMARC, DKIM en SPF bieden gezamenlijk in totaal zo’n 35 opties (!) waarover je moet nadenken of en hoe je ze gaat gebruiken. Interpreteer je deze opties op een verkeerde manier, dan kun je schijnveiligheid introduceren. Voorbeelden daarvan zijn een pct-optie in je DMARC-instellingen die een andere waarde heeft dan 100 (zie ‘Waarvoor is de pct-optie van DMARC?’) en het gebruik van de DMARC-policy p=none in plaats van p=reject (zie ‘Wat is het verschil tussen een sterke en een zwakke DMARC-policy?’).
Naast de 35 configuratie-opties die DMARC, DKIM en SPF samen bieden, zijn er ook zo’n 20 verschillende uitkomsten die je kan verwachten als de controles met DMARC, DKIM en SPF worden uitgevoerd. Deze uitkomsten vind je terug in de monitoringsrapportages die je van DMARC ontvangt. Ze komen goed van pas om vast te stellen of je beveiliging werkt, of de configuratie klopt en of er verdachte situaties zijn opgetreden. Maar dat kan alleen, als je weet hoe je deze verschillende uitkomsten correct moet interpreteren. Anders zie je mogelijke beveiligingsproblemen of verdachte situaties over het hoofd.
De rapportages die je binnenkrijgen zijn opgemaakt met ruwe metadata. Om nuttige informatie en trends eruit te halen, heb je een tool nodig die de rapportages verwerkt en de informatie op een gestructureerde manier toont. Het blijkt dat niet alle tools de rapportages op een correcte manier verwerken en interpreteren. Het is belangrijk om de juiste tool te kiezen voor betrouwbare resultaten.
Maak je per ongeluk een typefout of een syntaxerror in een regel die je voor DMARC, DKIM of SPF aan je DNS hebt toegevoegd, dan leidt dat vaak direct tot een verkeerde e-mail aflevering of mis je mogelijk zelfs de beveiliging voor jouw e-mail. Je krijgt helaas over een dergelijke fout niet tot een automatische foutmelding. Je moet er dus zelf een keer achterkomen.
Dat komt omdat er geen hygiënecontrole op deze syntax wordt uitgevoerd. Een regel met een syntaxerror wordt eenvoudigweg niet of verkeerd toegepast. Je e-mailbeveiliging werkt dus niet zoals je verwacht en daar krijg je bovendien geen feedback over.
Een aantal van de 35 opties die DMARC, DKIM en SPF bieden, hebben een defaultwaarde. Als je die optie niet zelf instelt, wordt deze defaultwaarde toegepast. Zo heeft de pct-optie van DMARC de defaultwaarde 100. Dat is een prima waarde voor deze optie. Er is dan geen reden om nog eens expliciet pct=100 in je DMARC-configuratie op te nemen. Sterker nog, doe je dat wel, dan maak je de configuratie onnodig onoverzichtelijk. En dat is met name vervelend als je een syntaxerror in deze configuratie probeert op te sporen.
Organisaties maken steeds meer gebruik van SaaS-diensten die e-mail verzenden. Als je DMARC correct wilt instellen en laten uitvoeren op alle uitgaande e-mail, moet je alle SaaS-diensten van je organisatie kennen en toevoegen aan het SPF-record in je DNS. Vervolgens moet je een cryptografische privésleutel voor DKIM toevoegen aan de verzendende e-mailserver(s) en zorgen dat DMARC de juiste configuratie gebruikt in het record.
Als je bijvoorbeeld een remote e-mailsysteem bent vergeten op te nemen dat slechts eenmaal per kwartaal een financiële rapportage naar de directie verzendt, dan bestaat het risico dat de e-mails met de kwartaalrapportages niet meer bij de directeur aankomen.
DMARC vergt ook onderhoud. Als er een nieuwe dienst bijkomt, moet je die direct proactief aan je instellingen toevoegen, zodat e-mail die met die dienst wordt verstuurd niet wordt geweigerd.
En als je een oud systeem uit gebruik haalt, moet je die ook uit het SPF-record in je DNS verwijderen, de cryptografische DKIM-privésleutel verwijderen van het systeem en zorgen dat de DMARC-configuratie weer klopt. Anders blijf je een SaaS-dienst die je niet meer gebruik toestemming geven om e-mail uit jouw naam te versturen. Kwaadwillenden zouden deze systemen dan kunnen misbruiken voor spoofing of phishing met jouw e-maildomein.
DKIM maakt gebruik van een cryptografisch sleutelpaar voor het ondertekenen van e-mailberichten met een digitale handtekening. Het sleutelpaar is een unieke combinatie van een privésleutel waarmee je e-mailsysteem e-mails ondertekent en een bijbehorende publieke sleutel waarmee ontvangers de digitale handtekening kunnen controleren.
Je moet vanwege de veiligheid periodiek het cryptografisch sleutelpaar verversen. Hoe langer je hetzelfde sleutelpaar gebruikt, hoe meer tijd je aanvallers geeft om deze sleutels te ‘kraken’. Ook kan een aanvaller met een zogenaamde
Bij het periodiek onderhoud:
Monitoringsrapportages zijn een groot pluspunt van DMARC ten opzichte van SPF en DKIM. Dagelijks ontvang je per e-mail de resultaten van de SPF-, DKIM- en DMARC-checks voor jouw e-maildomein. Met die informatie kun je vaststellen of je beveiliging werkt of dat je wijzigingen aan je configuratie moet maken. Ook kun je er verdacht e-mailverkeer mee identificeren. Zonder DMARC heb je deze functionaliteit niet.
Maar je ontvangt de rapportages alleen als je in je DMARC-instellingen hebt vermeld op welk e-mailadres ze binnen moeten komen. Vreemd genoeg stelt DMARC de rua-optie waarmee je dit e-mailadres specificeert niet verplicht. Als je de rua-optie vergeet in te stellen, werkt DMARC zonder klagen. Maar je krijgt dan geen rapportages en daardoor weet je niet wat er gebeurt!
Je hoeft de DMARC-monitoringsrapportages over jouw e-maildomein A niet per se naar een e-mailadres op datzelfde domein A te laten sturen. Je kunt ze ook prima naar een e-mailadres op een ander domein B laten sturen, als dat domein ook van jou is. Maar dan is het wel belangrijk dat je in het DNS van domein B een regel opneemt die bevestigt dat domein B de e-mails met monitoringsrapportages van domein A wil ontvangen.
Voordat een ontvangende e-mailserver een DMARC-rapportage over domein A naar het e-mailadres op domein B stuurt, kijkt deze e-mailserver eerst of een DNS-regel met deze autorisatie aanwezig is. Is die regel niet aanwezig, dan verstuurt de e-mailserver de rapportage niet.
Deze external reporting authorization voorkomt dat aanvallers het DMARC-rapportagemechanisme misbruiken om domein B met grote hoeveelheden ongewenste e-mail te bestoken. De keerzijde is, dat als je wél rapportages over domein A op een e-mailadres op domein B wilt ontvangen en je vergeten bent om de nodige autorisatieregel in het DNS van domein B te zetten, je een deel van de DMARC-monitoringrapportages over domein A niet ontvangt. Deze security-informatie mis je dan. Hiervan wordt je echter ook niet automatisch op de hoogte gesteld. Je moet er zelf achterkomen.
Veel organisaties stellen eerst SPF in, dan DKIM en ten slotte DMARC. Dat is immers de volgorde waarin deze standaarden het licht zagen. Maar hanteer je deze volgorde, dan maak je het jezelf lastig. Van de drie is SPF namelijk het moeilijkst in te regelen. Je moet daarvoor eerst alle e-mailsystemen van je organisatie identificeren, inclusief de externe diensten die wellicht door andere afdelingen op eigen gelegenheid worden gebruikt en waarvan je het bestaan niet eens vermoedde (‘shadow IT’).
Om een compleet beeld te krijgen, zul je een inventarisatie moeten doen naar alle e-mail verzendende systemen en diensten bij alle afdelingen van je organisatie.
Een complicerende factor daarbij is, dat je zonder DMARC geen feedbackrapportages ontvangt over de status van SPF, DKIM en DMARC. Dat maakt het lastig om veilig en geleidelijk DMARC toe te passen en gecontroleerd te zien wat er misgaat bij de configuratie. Je krijgt er geen feedback over – behalve van boze klanten of managers.
Draai daarom de volgorde waarmee je je e-mailbeveiliging inricht om: begin bij DMARC, doe dan SPF en stel als laatste DKIM in. Zo krijg je vanaf het begin van het proces via rapportages feedback over het effect van je configuratie en over mogelijke shadow-IT- e-mailsystemen. Zo kun je veilig geleidelijk de security strenger toepassen.
Een andere mogelijkheid is om gebruik te maken van een managed DMARC dienst die jou het werk geheel uit handen neemt.