DMARC is de derde afkorting die je vaak hoort als het gaat om authenticatie van je e-mails, naast SPF en DKIM. DMARC is de afkorting voor Domain-based Message Authentication, Reporting and Conformance. Simpel uitgelegd bepaalt DMARC het deurbeleid van jouw domein op het gebied van e-mails. Met een DMARC-record op je server stel je in wat er moet gebeuren met e-mails die bij ontvangende servers aankomen maar niet aan jouw eisen voldoen. Daarmee is dit een belangrijk middel in de strijd tegen phishing en spoofing. Zo kan je het bijvoorbeeld partijen die willen doen alsof ze jou zijn heel erg lastig maken.
De belangrijkste afweging bij het instellen van DMARC
Op basis van jouw wensen en beveiligingsbehoeften kan je eenvoudig zelf het DMARC-beleid instellen. DMARC kijkt naar de uitkomsten van de checks die SPF en DKIM doen. En jij kan vervolgens aangeven wat er moet gebeuren in de situaties waarin een e-mail een of beide checks niet haalt. Je hebt daarin drie keuzes:
- Niks doen (none): Als je voor deze situatie kiest doe je dus niks tegen e-mails die de controles niet halen. Dit is de minst veilige instelling. Je kan hiermee wel zien óf iets of iemand je domein misbruikt. Dat kan je dan in de rapportages zien. Hoe je de rapportages instelt, staat iets verderop.
- Als spam markeren (quarantine): In deze instelling markeer je richting de ontvangende e-mailserver e-mails als spam wanneer ze niet door jouw SPF en DKIM beleid komen. Het is dan aan de ontvangende server om dit dan ook echt in de Ongewenste e-mail-map te plaatsen. Maar jij geeft aan dat het geen zuivere koffie is in elk geval.
- Weigeren (reject): Hiermee zeg je dat elk bericht dat jouw checks niet doorstaat niet afgeleverd mag worden. Dit is de meest strenge optie, maar ook de meest veilige. Deze is absoluut de beste maar je moet wel zeker weten dat álle e-mails die echt van jouw bedrijf zijn dan ook de SPF- en DKIM-checks halen.
Hoe ziet een DMARC-record eruit?
Hier zie je een voorbeeld van een DMARC-record zoals je die zou kunnen instellen:
v=DMARC1; p=reject; rua=mailto:dmarc-reports@voorbeeld.nl;Deze drie instellingen zouden eigenlijk altijd in je DMARC-record moeten staan. De versie bij de letter ‘v’. Het beleid (je ‘policy’) bij de letter ‘p’ en een e-mailadres waar de DMARC-rapporten naartoe mogen achter ‘rua’.
Eigenlijk is dit al een heel volledig DMARC-record. Er staat dus duidelijk in waar de rapporten heen gaan. En dat in dit geval dat alle e-mails die de checks niet halen geweigerd worden. Er zijn nog meer instellingen die je zou kunnen toevoegen aan het record als je dat zou willen.
De verplichte parameters
- v: Met deze parameter geef je de versie aan van het DMARC-protocol dat gebruikt moet worden. Het staat nagenoeg altijd op DMARC1, net als in het voorbeeld hierboven. Dit is een verplichte parameter en moet bovendien altijd vooraan staan.
- p: Hiermee stel je zoals gezegd het beleid in wordt gehanteerd. Je kan deze instellen op ‘none’, ‘quarantine’ of ‘reject’. Deze parameter is verplicht in je DMARC-record.
De optionele parameters
- rua: Je stelt hierbij een e-mailadres in waar de rapporten over inkomende e-mails worden verzonden in een geaggregeerde, leesbare vorm. Deze rapporten bevatten informatie over e-mails die niet hebben voldaan aan je ingestelde beleid.
- ruf: Deze instelling werkt hetzelfde als de ‘rua’ hierboven maar in plaats van de laatste letter ‘a’ voor ‘aggregated’, eindig je nu met de ‘f’ van ‘forensic’. Je krijgt dan zeer gedetailleerde rapporten. Dat is handig voor als je hele specifieke e-mails zou willen onderzoeken.
- fo: Wanneer je voor een specifieke situatie rapporten wil ontvangen gebruik je deze parameter. Je stelt hier dan mee in wanneer de ontvangende e-mailserver moet rapporterenkan hier ook vier opties kiezen.
- fo=0: Geen actie ondernemen met falende DKIM- of SPF-controles.
- fo=1: Rapporteren op e-mails waarvoor SPF of DKIM mislukt is.
- fo=s: Rapporteren op e-mails waarvoor SPF mislukt is.
- fo=d: Rapporteren op e-mails waarvoor DKIM mislukt is.
Je kan deze ook combineren door bijvoorbeeld ‘fo=0:1:s’ in te stellen.
- pct: Het percentage van de berichten dat doorkomt waarop je het DMARC-beleid wil toepassen. Dit kan bijvoorbeeld handig zijn als je het effect van een bepaalde instelling wil testen voordat je het voor álle e-mails laat gelden. Als je deze niet instelt, wordt standaard 100% van je e-mails getoetst aan je beleid.
- rf: Hiermee stel je de rapportage-indeling in. De meestvoorkomende zijn ‘afrf’ (Authentication Failure Reporting Format) en ‘iodef’ (Incident Object Description Exchange Format). Met de eerste optie ontvang je een generiek rapport voor de momenten waarop de checks niet gehaald zijn. De tweede gaat in op specifieke incidenten waarbij de checks niet gehaald zijn en is een stuk uitgebreider. De standaard als je niks instelt is ‘afrf’en dit is ook het meestgebruikt.
- ri: Hiermee stel je het rapportage-interval in, in seconden. Als je deze bijvoorbeeld op ‘86400’ instelt, krijg je dus elke 24 uur een rapport opgestuurd.
De optionele parameters voor DMARC met subdomeinen
- sp: Met deze instelling kun je het beleid instellen voor subdomeinen, wanneer je dat anders zou willen laten zijn dan de instelling van je hoofddomein. Ook hier kies je dan voor ‘none’, ‘quarantine’ of ‘reject’.
- aspf: Wanneer je werkt met subdomeinen is het verstandig om deze (en de volgende) parameter op te nemen in je DMARC-record. Hiermee stel je de uitlijning in tussen het SPF-record op je hoofddomein en hoe deze zich verhoudt tot subdomeinen. Je hebt hier twee keuzes. ‘r’ voor ‘relaxed’ en ‘s’ voor ‘strict’. Wanneer je een e-mail stuurt met als afzenderdomein bijvoorbeeld ‘@mail.voorbeeld.nl’ en je hebt deze parameter op ‘r’ staan in je DMARC-record op ‘voorbeeld.nl’, zal de e-mail (als die verder wel alle checks haalt) gewoon doorgelaten worden. Wanneer je deze parameter op ‘s’ zet, wordt de e-mail geweigerd, omdat het subdomein niet overeenkomt met het hoofddomein.
- adkim: Deze werkt precies hetzelfde als de ‘aspf’ hierboven, maar dan van toepassing op het domein in je DKIM-record. Ook deze stel je in op ‘r’ voor ‘relaxed’ en ‘s’ voor ‘strict’.
DMARC moet je langzaam opschalen
Het is belangrijk om wanneer je begint met DMARC, niet meteen je beleid op ‘reject’ te zetten. Ja, dat is de meest veilige optie. En naar mijn idee ook degene waar je uiteindelijk op zou moeten eindigen. Maar in het begin is het wel handig om eerst een beeld te krijgen van wat er allemaal over de lijn gaat.
Stap 1: Begin met ‘none’
Door meteen alles te weigeren, weiger je misschien ook wel e-mails uit een systeem dat je wel echt zelf gebruikt maar (nog) niet had meegenomen in je beleid. Zeker bij grote organisaties waarbij e-mails uit meerdere systemen en vanaf meerdere servers kunnen komen. Het is slim om dit zeker een dag of 7 aan te houden om een goed beeld te kunnen vormen.
Stap 2: Schaal op naar ‘quarantine’
Wanneer je een aardig beeld hebt van alles wat gemaild wordt wat jouw domeinnaam gebruikt en je wil dit verder inperken schaal je op naar ‘p=quarantine’. Je zegt daarmee dat ontvangende mailservers die een e-mail ontvangen die niet door de SPF en/of DKIM controle komt, als spam moet worden gemarkeerd.
Als je geen goed beeld hebt van de omvang van deze situatie zou je in combinatie met de ‘pct’-parameter bijvoorbeeld kunnen beginnen met ‘pct=10’. Het kan bijvoorbeeld zijn dat je daarna een groot aantal bounces terugkrijgt of bijvoorbeeld merkt dat veel minder mensen je e-mails hebben ontvangen. Dan ga je terug naar de rapportage om dit probleem in kaart te brengen. Blijft alles werken zoals je verwacht? Dan kan je het percentage gaan ophogen.
Stap 3: Zet alles dicht met ‘reject’
Je kan ervoor kiezen om het beleid op ‘quarantine’ te laten staan. Maar dan is het theoretisch nog steeds mogelijk dat kwaadwillenden zich voordoen als jouw domein. Al worden ze dan hoogstwaarschijnlijk wel als spam gemarkeerd. Het is daarom – zeker als je heel veel belang hebt bij je merkreputatie en je geloofwaardigheid – aan te raden om uiteindelijk naar een volledige reject als beleid te gaan. Daarmee is het praktisch onmogelijk om uit jouw naam te e-mailen vanuit een systeem dat niet in jouw SPF-record voorkomt of tussendoor is onderschept.
Geef cybercriminelen geen kans
Heb je al deze stappen doorlopen? En een goede SPF-record, DKIM-verificatie en DMARC-beleid ingesteld? Dan heb je een stevige verdedigingslinie staan in de strijd tegen phishing en spoofing.