Copernica rolt DMARC uit voor copernica.com en copernica.nl

Practice what you preach, of in het Nederlands: je kunt wel mooie praatjes hebben over DMARC, maar dan moet je het ook zelf in de praktijk brengen. En dat is precies wat we met de copernica.com en copernica.nl domeinen nu aan het doen zijn.

Wat is DMARC ook alweer?

Laten we bij het begin beginnen. Sinds een aantal jaar bestaat DMARC. Dit is een technologie die, heel kort gezegd, het vreemd'lingen onmogelijk maakt om e-mailberichten vanuit jouw naam te versturen. DMARC stelt domeineigenaren in staat om een DNS record publiceren dat beschrijft of DKIM en SPF goed zijn geregeld, en wat ontvangers moeten doen met berichten zonder DKIM signatuur en/of met berichten die niet van jouw servers afkomstig zijn.

Met DMARC kan iemand bijvoorbeeld (in gewone mensentaal) het volgende zeggen: "Ja, alle mail die afkomstig is van mijndomeinnaam.nl wordt altijd gestuurd met een geldige DKIM key, en ook de SPF is altijd goed. Mocht je toch een keer een mail ontvangen die niet in orde is, dan maakt iemand misbruik van mijn domeinnaam, en moet je die mail negeren."

E-mailontvangers (zoals Gmail, Yahoo, enzovoort) controleren deze DMARC instellingen, en gooien e-mailberichten daadwerkelijk weg als er iets met een bericht niet in orde is. DMARC is daarom voor domeineigenaren een heel belangrijke tool om misbruik tegen te gaan: als je het DMARC record maar streng genoeg instelt, weet je zeker dat misbruik niet mogelijk is. Voor organisaties die vertrouwelijke berichten versturen is dit belangrijk - maar eigenlijk zou elk bedrijf dat serieus zijn merknaam wil beschermen DMARC moeten gebruiken.

Verschillende policies

In de praktijk is het uitrollen van DMARC lastiger dan je denkt. De strengste instelling is "p=reject". Met deze policy vertel je ontvangers dat je alles goed doet en dat alle email van het domein in orde is. Mocht er door een ontvanger toch een niet-matchend bericht worden ontvangen, dan draagt de "p=reject" instelling op om zulke email te negeren: foute email moet immers wel misbruik zijn.

Naast de strenge "p=reject" instelling zijn er ook wat slappere instellingen voor domeineigenaren die niet zo zeker weten of ze alles wel goed hebben gedaan. Bijvoorbeeld "p=none". In gewone mensentaal betekent die instelling zoiets als "ja, ik ben de enige die vanuit mijn domein email verstuurt, maar als je toch een keer een mail ontvangt die niet van mij lijkt te zijn, dan moet je dat bericht toch gewoon in de inbox plaatsen. Er is namelijk een goede kans dat ik nog een fout in de configuratie van mijn servers heb gemaakt."

Tussen de strengste (en beste) "p=reject" policy en de slapste "p=none" policy zit nog een heel scala van andere mogelijkheden. Deze policies staan gewoon in DNS, en je kunt daarom van elk bedrijf zien met welke policy er wordt verstuurd. Een eenvoudige rondgang langs de domeinnamen van wat grote bedrijven, waaronder banken en verzekeringsmaatschappijen, leert dat het overgrote deel van de organisaties in Nederland nog helemaal geen DMARC policy heeft, en bij de bedrijven die dat wel hebben, staat het nog vaak op (de slappe instelling) "p=none". Kortom, er is werk aan de winkel.

Uitrol bij Copernica

Wij van Copernica adviseren onze klanten om DMARC goed in te stellen, en zo snel mogelijk naar een "p=reject" instelling over te gaan. Maar hoe doen wij het eigenlijk zelf? Ons eigen "copernica.com" en "copernica.nl" domeinen: staan die wel op "p=reject"?

Schaamrood op de kaken: Nee, nog niet. We gebruiken nog steeds "p=none".

Dit zijn we echter nu aan het veranderen. Maar dat heeft wel wat consequenties. Een "p=reject" policy werkt namelijk alleen als 100% (en dus niet 99%) van alle uitgaande berichten ook daadwerkelijk van onze servers afkomstig is (of meer precies: afkomstig is van IP adressen die matchen met onze SPF records), of met onze DKIM key zijn ondertekend. Dit geldt dus voor de berichten van de desktop computers en mobiele telefoons van onze collega's, voor de transactionele berichten afkomstig van de website en bijvoorbeeld de notificaties van supportmeldingen. Ook de nieuwsbrief moet hier natuurlijk aan voldoen.

Bovenstaande hebben we inmiddels aardig voor elkaar - we zijn immers specialisten of dit gebied. Maar het blijkt dat er nog veel meer valide berichten met een @copernica.nl of een @copernica.com afzenderadres worden verstuurd. Sommige van onze gebruikers hebben namelijk opvolgacties ingesteld. Zodra iemand op een link klikt, sturen ze een notificatiebericht naar zichzelf met afzenderadres "info@copernica.com". Met andere woorden: ze gebruiken ons domein voor hun eigen berichten. Dit stelde ons voor een dilemma: moeten we dergelijke opvolgacties van ons DKIM signatuur voorzien zodat we DMARC naar "p=reject" kunnen uitrollen? Wij hebben besloten om dat niet te doen en voor een andere oplossing te kiezen.

Consequenties voor opvolgacties

Wanneer een DKIM signatuur aan een mail is toegevoegd, staat expliciet vast dat het bericht inderdaad vanuit het from-domein is verstuurd. Een DKIM signatuur geeft als het ware aan dat de mail wat de domeineigenaar betreft valide is, en dat er geen sprake is van misbruik. Maar wat nou als een kwaadwillende Copernica gebruiker in een onbewaakt moment een opvolgactie maakt met daarin een vals bericht vanuit onze naam - zonder dat wij de inhoud van het bericht kennen? Moeten we dergelijke berichten van ons DKIM signatuur voorzien zodat het bericht toch betrouwbaar overkomt, ook al is het een opvolgactie die is ingesteld door een kwaadwillende gebruiker? Liever niet.

Toch zijn er nu heel wat opvolgacties of automatische exports actief die gebruik maken van ons "info@" afzenderadres. Als we uitrollen naar "p=reject" zonder de mails te signen met onze DKIM key, dan worden deze opvolgacties opeens door ontvangers geblokkeerd. Dat willen we niet. Maar als we ze voorzien van een DKIM signatuur bieden we de mogelijkheid aan kwaadwillenden om mail te versturen vanuit onze naam. Het is kiezen tussen twee kwaden.

Daarom veranderen bestaande opvolgacties een klein beetje. Als je nu gebruik maakt van een opvolgactie met een copernica.com of copernica.nl afzenderadres, dan wordt het bericht binnenkort vervangen door een waarschuwing. De inhoud van de waarschuwing hebben we zelf geschreven, en kunnen we daarom in alle eerlijkheid voorzien van ons DKIM signatuur. Het oorspronkelijke bericht (waarvan we de oprechtheid van de inhoud niet kunnen garanderen) wordt als attachment bijgevoegd.

Vervolgstappen

We streven er naar om zo snel mogelijk over te stappen naar "p=reject". We stuiten bij deze uitrol helaas regelmatig op automatische berichten en notificaties die door klanten zijn ingesteld, en die gebruik maken van een @copernica.com of @copernica.nl afzenderadres. Al deze uitzonderingen gaan we stuk voor stuk aanpakken voordat we definitief op "p=reject" overstappen. We houden je via dit kanaal op de hoogte van de ontwikkelingen.