Dit bericht verscheen eerder op BIT
Wanneer je wilt voorkomen dat jouw e-mail als spam wordt gezien is het een ‘must’ dat je gebruikmaakt van authenticatiemiddelen als SPF en DKIM. Hoe e-mailontvangers omgaan met die authenticatie verschilt onderling waardoor de effectiviteit niet optimaal is. Hiervoor biedt DMARC de oplossing. Sinds kort gebruiken we bij BIT bovenop SPF en DKIM nu ook DMARC.
‘E-mail’ is een van de oudste functies van ons hedendaagse internet. Dan praat ik niet alleen specifiek over het ‘SMTP’-protocol zelf, maar ook over de afspraken rondom ‘wat een e-mail maakt’ stammen uit het jaar kruik. Tegelijkertijd is e-mail nog altijd razend populair. Voor communicatie met klanten, met collega’s, je familie of je vrienden, maar ook voor diegenen die er minder oprechte bedoelingen op na houden.
Ongevraagde e-mail, de zogenoemde spam, werd gauw een groot probleem. Iedereen kent vast de berichten waaruit zou blijken dat meer dan 90% van het e-mailverkeer op internet ongevraagde e-mail zou zijn. Daarnaast werden er steeds vaker phishingmails verstuurd en ontvangen. Berichten die lijken te komen van een bank, de Belastingdienst of een streaming service, maar in feite zijn verstuurd door criminelen. Juist op het gebied van die ‘authenticiteit’ van e-mails zijn de afgelopen jaren wat stappen gemaakt. Hierdoor kunnen we met z’n allen beter controleren of een e-mail echt is verstuurd door degene die zegt de afzender te zijn.
SPF, DKIM en DMARC
Termen als SPF (Sender Policy Framework) en DKIM (Domain Keys Identified Mail) staken de kop op. Even in het kort; met SPF vertel je ‘wie’ namens jouw domein e-mail mag versturen op het internet en met DKIM zet je een digitale handtekening op de ‘envelop’ die boven elke e-mail staat (de zogenaamde DKIM-header).
Maar wat moet je nu als je een e-mail ontvangt waar bijvoorbeeld alle SPF-checks kloppen, maar de DKIM-handtekening onjuist blijkt, of andersom? En moet je daar als ontvanger dan nog wat mee? Daar komt ‘DMARC’ om de hoek kijken. DMARC staat voor ‘Domain-based Message Authentication, Reporting and Conformance’ en bouwt voort op de implementatie van SPF en DKIM. Met DMARC kan de eigenaar van een domein, net als met SPF en DKIM, in zijn of haar DNS-instellingen publiceren welke acties ondernomen moeten worden als een of meerdere van deze checks falen.
Is dit nu dan de heilige graal? Vanaf nu nooit meer spam? Helaas. Die pet gaat niet op.
DMARC is géén ‘anti spam’ oplossing. Ook cybercriminelen zijn in staat om voor hun spamdomeinen DKIM, SPF en DMARC in te richten en domeinen waar geen SPF, DKIM of DMARC voor ingericht zijn, moeten we natuurlijk nog altijd netjes behandelen. Deze e-mailstandaarden zijn geen verplichting, hoewel ze wel op de ‘PTOLU (Pas Toe Of Leg Uit)’-lijst van de overheid staan.
Instanties doen er goed aan om deze standaarden te implementeren gezien de combinatie DKIM, SPF en DMARC ze kan helpen tegen het simpelweg impersoneren van hun domeinnaam in e-mail. Dit kan de meest simpele vorm van phishingmails helpen voorkomen.
Een goede implementatie vergt echter ook een diepgaande kennis van de e-mailstromen binnen de organisatie en de kans bestaat dat er meer stuk gaat dan verwacht. In een latere blog zullen we verder ingaan op de technische implicaties van het inrichten van SPF, DKIM en DMARC.
Waarom nu DMARC?
BIT is in der tijd begonnen met DNSSEC-validatie; als een bedrijf op internet publiceert dat de DNS-antwoorden altijd correct beveiligd dienen te zijn en dit blijkt niet het geval, dan weigeren wij het niet juist beveiligde antwoord door te geven. Met SPF hebben we hetzelfde gedaan; als een bedrijf op internet publiceert dat e-mail alleen vanaf bepaalde IP-adressen mag komen en dat is niet het geval, dan weigeren wij de e-mail aan te nemen. Sinds kort volgen we ook DMARC policies op. Wat kan inhouden dat e-mail wordt geweigerd, omdat de DMARC policy op ‘reject’ staat en er blijkbaar iets mis is met SPF of DKIM voor de betreffende e-mail.
Feedback rapportage binnen DMARC
DMARC voorziet in een rapportagefunctie, waarmee mailserverbeheerders elkaar laten weten welke e-mails er van domeinen zijn geweigerd en wat de eigenschappen zijn van die e-mails. BIT heeft deze functie nog niet actief aanstaan omdat een zeer groot deel van de rapportages nog niet kan worden afgeleverd op de in de DMARC ingestelde rapportage-adressen waarmee is getest. Misschien wat ironisch, maar helaas blijkt dus dat het overgrote deel van de rapportage e-mails wordt geweigerd door de ontvangers. We houden deze gegevens wel bij en zullen de rapportages mogelijk op een later moment wel uitsturen.
Door: Sander Smeenk
Dit bericht verscheen eerder op BIT
