Aan de slag met SPF, DKIM en DMARC
Hieronder leggen we uit wat SPF, DKIM en DMARC precies doen en hoe je dit configureert, zodat je je domeinen beschermt tegen misbruik.
SPF
Het Sender Policy Framework (SPF) is een techniek waarmee een domeinnaamhouder aangeeft welke mailservers e-mail namens deze domeinnaam mogen versturen. Ontvangende mailservers kunnen met behulp van SPF controleren of een e-mail is verzonden door een geautoriseerde mailserver. In een SPF-policy geef je aan welke mailservers e-mail mogen versturen namens een domeinnaam. De policy wordt als TXT-record toegevoegd aan de desbetreffende DNS-zone.
Een SPF policy voor het domein uit ons voorbeeld ‘example.nl’ kan er als volgt uitzien: example.nl. TXT "v=spf1 mx a:mail.example.nl ~all"
De policy in dit voorbeeld geeft aan:
- v=spf1: de huidige versie van SPF.
- mx: de ontvangende mailservers die in het MX DNS-record genoemd staan van example.nl mogen ook e-mail versturen.
- a:mail.example.nl: de mailserver met deze naam is geautoriseerd voor het versturen van e-mail. Hier kunnen ook IPv4 en IPv6 adressen in worden opgenomen.
- ~all: Hier zijn meerdere opties mogelijk. Een hardfail wordt aangegeven met minteken (-). In dit geval worden niet geautoriseerde mails afgewezen. Een softfail wordt aangegeven met het kringelteken (~). Niet geautoriseerde mails kunnen als verdacht worden aangemerkt. Voor verzendende domeinen heeft het gebruik van ~all (softfail) meestal de voorkeur. De reden hiervoor is dat wanneer de SPF-authenticatie faalt met een SPF hardfail, een ontvangende mailserver de verbinding al kan blokkeren zonder de DKIM-handtekening en het DMARC-beleid te evalueren. Dit kan leiden tot ten onrechte geblokkeerde mails.
Een ontvangende mailserver die op basis van SPF e-mail controleert, stuurt een DNS-query om te zien of de domeinnaam van het afzenderadres over een SPF-beleid beschikt. Als dit het geval is, wordt bepaald of de verzendende mailserver is opgenomen in het SPF-beleid. Als de mailserver in het beleid voorkomt, concludeert de mailserver dat de e-mail authentiek is.
Met SPF kan inkomende e-mail worden gefilterd op spam- en phishingmail. SPF biedt echter op zichzelf nog niet een effectieve bescherming tegen e-mailspoofing.SPF maakt gebruik van het voor de gebruiker doorgaans onzichtbare ‘5321.From header’ veld. Het afzenderadres dat getoond wordt aan de gebruiker (‘5322.From header’) wordt niet gebruikt bij authenticatie door SPF, maar wel door DMARC. SPF kan bovendien niet overweg met e-mailforwarding. DKIM is hiervoor een noodzakelijke aanvulling.
Takeaway SPF: Klopt de afzender?
Met SPF kan een domeinnaamhouder aangeven welke mailservers e-mail namens een domeinnaam mogen verzenden. SPF is een belangrijke stap in het beschermen tegen e-mailspoofing. Het biedt echter nog geen volledige bescherming. SPF moet je in combinatie met DKIM en DMARC gebruiken wil het e-mailspoofing effectief bestrijden.
DKIM
Domain Keys Identified Mail (DKIM) is een techniek waarmee een domeinnaamhouder kan aangeven met welke sleutel e-mails namens deze domeinnaam ondertekend dienen te zijn. Verzendende mailservers ondertekenen alle uitgaande e-mail namens deze domeinnaam met deze sleutel. Ontvangende mailservers kunnen met behulp van DKIM controleren of de e-mail door een geautoriseerde partij is verzonden.
DKIM wordt voor uitgaande e-mail ingesteld door het toevoegen van een TXT-record aan de desbetreffende DNS-zone. Het daadwerkelijk ondertekenen van de e-mail gebeurt door software op de mailserver.
De verzendende mailserver voegt het veld "DKIM-Signature" toe aan de header van een e-mail. Dit veld bevat een digitale handtekening dat van toepassing is op de inhoud van de e-mail; de body en de headers. Let op: niet alle headers worden standaard meegenomen, dit kan apart worden geconfigureerd in de instellingen van de verzendende mailserver.
De ontvangende mailserver gebruikt de domeinnaam van de afzender, dit staat aangegeven met de tag: (d), en een selector (s), uit de DKIM-Signature om een DNS-query te sturen. Een selector vertelt ontvangende mailservers waar ze de juiste publieke sleutel in DNS kunnen vinden om een e-mail te verifiëren.
Een voorbeeld: DKIM-Signature: v=1; a=rsa-sha256; d=example.nl; s=mail2025; ...
Het selector-veld maakt het mogelijk om verschillende keys te gebruiken voor eenzelfde domeinnaam. Als antwoord ontvangt de mailserver de publieke sleutel van de afzender, waarmee de handtekening gecontroleerd wordt. Als de controle slaagt betekent het dat de e-mail daadwerkelijk afkomstig is van de legitieme domeinnaameigenaar en niet aangepast is gedurende het transport. Daarnaast is het goed te overwegen om – als je bijvoorbeeld andere partijen namens jouw domein laat mailen of gebruik maakt van nieuwsbrieven – dit via sub-domeinen in te regelen (nieuwsbrief.example.nl) en daar eigen DKIM-sleutels voor te maken. Het NCSC raadt aan om RSA-SHA256 of ED25519-SHA256 met een sleutellengte van 2048-bits te gebruiken (niet hoger vanwege compatibiliteitsissues). Maak geen gebruik meer van RSA-SHA1, dit algoritme wordt als niet meer veilig beschouwd.
Het is daarnaast een goed gebruik periodiek DKIM-sleutels te roteren (bijvoorbeeld jaarlijks) en meerdere selectors te gebruiken voor beheer en migratie. Sleutelbeheer vermindert het risico bij compromittatie.
Takeaway DKIM: waarborg de integriteit van e-mail
Met DKIM worden uitgaande e-mails ondertekend met een digitale handtekening (signature). De ontvanger van de ondertekende mail controleert de handtekening waarmee de authenticiteit en integriteit van de mail kan worden gecontroleerd.
Net als SPF biedt DKIM-ontvangers een extra mogelijkheid om inkomende e-mail te filteren. Een mogelijk nadeel is dat de DKIM-handtekening beschadigd kan raken wanneer het bericht tijdens verzending wordt aangepast (denk aan mailinglijsten). Een effectieve bestrijding van e-mailspoofing vergt naast SPF en DKIM ook DMARC omdat een aanvaller de handtekening eenvoudigweg kan verwijderen.
DMARC
DMARC staat voor Domain-based Message Authentication, Reporting and Conformance. DMARC is een techniek waarmee een domeinnaamhouder beleid kan publiceren voor de afhandeling van e-mail die niet aan het SPF- of DKIM-beleid voldoet. Het is daarmee een essentiële stap in het bestrijden van e-mailspoofing. Zonder DMARC weet de ontvangende mailserver immers niet wat er gebeuren moet met een e-mail die niet voldoet aan de SPF of DKIM-regels.
DMARC heeft de volgende functionaliteiten:
- Terugkoppeling. Ontvangende mailservers sturen een rapport (XML-bestand) naar de verzendende organisatie terug wanneer dat nodig is (afhankelijk van de instellingen in DMARC). De verzendende organisatie kan daarmee inzicht verkrijgen in de e-mails die verzonden worden namens hun domeinnamen. Dit inzicht kunnen zij gebruiken om mailstromen te identificeren en de werking van SPF en DKIM te verbeteren.
- Policy. Een DMARC-beleid instrueert ontvangende mailservers bij het afhandelen van e-mail die niet voldoet aan het SPF- en DKIM-beleid van de verzendende domeinnaam. Mogelijke instructies zijn ‘reject’ (weggooien), ‘quarantine’ (markeren als spam) en ‘none’ (accepteren).
In ons voorbeeld van ‘example.nl’ kan DMARC er als volgt uit zien: v=DMARC1; p=reject; rua=mailto:dmarc-authfail.example.nl; aspf=s; pct=100;
DMARC bestaat uit een TXT-record (_dmarc.example.nl) dat toegevoegd wordt aan de DNS-zone.
Hierin staat het volgende:
- v =DMARC1: De huidige versie van DMARC.
- p: wat de ontvangende mailserver moet doen met email die niet voldoet aan DKIM- of SPF-beleid (none, quarantine of reject). Aanbevolen is om reject als beleid toe te passen.
- pct: Het percentage dat aangeeft op welk deel van de e-mailstroom het DMARC-beleid toegepast moet worden. Dit is vooral bedoeld om te testen als je bijvoorbeeld van p=none naar p=quarantine of p=reject wilt veranderen en gradueel de impact van deze wijziging wilt meten.. Als ‘pct’ is weggelaten, staat deze standaard op pct=100.
- rua: Het e-mailadres waarnaar de ontvangende mailproviders de DMARC rapportages kunnen sturen. Er bestaan ook ruf-rapportages (reporting URI forenics). Deze raden we echter af te gebruiken om AVG-compliant te werken. In de ruf-rapportages worden persoonsgegevens zoals ip-adressen, e-mailadressen en delen van de e-mailbody verwerkt.
- aspf=s: De mate van alignment. De ontvangende mailserver controleert of het getoonde afzenderadres overeenkomt met het domein opgegeven onder SPF (aspf) en DKIM (adkim). De waarde ‘strict’ (‘s’) zorgt voor een exacte vergelijking, terwijl de mailserver bij ‘relaxed’ (‘r’) controleert of het afzendadres binnen hetzelfde domein valt. Dit kan worden aangegeven door aspf of adkim toe te voegen met de r=relaxed en s=strict. Standaard staat de waarde op relaxed. Let op: voor een geslaagde DMARC-validatie is minimaal één van de twee mechanismen (SPF of DKIM) vereist mét geldige alignment. Een SPF- of DKIM-pass zonder alignment resulteert alsnog in een DMARC-fail. Let wel: op het moment dat je zowel SPF en DKIM gebruikt, maar één van beiden faalt, dan geeft DMARC alsnog een pass indien de alignment niet strict is.
Takaway DMARC: beleidsregels
Met DMARC wordt vastgesteld wat een ontvanger van e-mail moet doen met e-mails die wel of niet voldoen aan de SPF en DKIM regels. Het vormt hiermee het sluitstuk van effectieve bescherming tegen e-mailspoofing.
DMARC is ontworpen om in combinatie met SPF en DKIM gebruikt te worden. Wanneer een e-mail niet voldoet aan het SPF- en het DKIM-beleid, of wanneer alleen SPF of DKIM is geconfigureerd het niet voldoet aan een van de twee, dan zal de e-mail als niet-authentiek worden aangemerkt.
Juiste configuratie hiervan is belangrijk omdat de volgende situaties problemen kunnen geven:
- Domeinnamen waarvandaan e-mails worden gestuurd aan mailinglijsten. De beheerder van een mailinglijst kan deze zo instellen dat het geen problemen oplevert met SPF, DKIM en DMARC.
- Automatisch doorgestuurde e-mails. Deze voldoen niet aan het SPF-beleid van de verzendende domeinnaam. Als de e-mail niet met DKIM ondertekend is, zal de e-mail als niet authentiek worden aangemerkt.
Tot slot
Maak het aanvallers lastiger door SPF, DKIM en DMARC te implementeren op al je domeinnamen, inclusief de domeinen waarvan geen e-mail wordt verzonden. Houd er rekening mee dat het niet mogelijk is om volledig te voorkomen dat phishingmails jouw klanten bereiken omdat aanvallers nog steeds andere, vergelijkbare, domeinen kunnen gebruiken en het valideren van mails in naam van jouw domein afhangt van de mate waarin validatie correct wordt toegepast bij de ontvanger. Zorg er daarom voor dat je jouw klanten en partners goed uitlegt hoe je met hen communiceert en wat zij kunnen doen als zij toch phishing e-mail uit naam van jouw organisatie ontvangen. Een good practice is om het aantal domeinen waar je e-mail mee verzendt zo beperkt als mogelijk te houden. Stimuleer daarnaast het melden van phishing vanuit je domeinnamen en richt dit in zodat slachtoffers dat eenvoudig kunnen doen. Het snel acteren op een phishing aanval of een poging daartoe is immers van groot belang om verdere schade te voorkomen.
