Deliverability 101 deel 3: Verzenden en authenticatie

Nu we weten hoe we onze verzendlijst goed opbouwen en waar we bij de content van de e-mail op moeten letten, kunnen we daadwerkelijk gaan versturen. In deze editie van Deliverability 101 gaan we dieper in op het technische aspect van de verzending. Hoe komt mijn e-mail in de juiste inbox en waarom moet ik een sender domain instellen?

Op basis van profieldata en content wordt in Copernica voor ieder profiel een gepersonaliseerd bericht klaargezet. Als we dit bericht willen versturen naar de ontvanger moeten we deze verplaatsen naar de ontvangende server. Dit is de server waar de mailbox van de ontvanger op staat. Dit is in feite wat het versturen van een e-mail inhoudt. Deze ontvangende servers kunnen zowel van gratis mailboxproviders zoals Hotmail en Gmail zijn, als private servers van bedrijven of personen.

Het versturen van e-mails is op zichzelf redelijk technisch. In de loop van de jaren is dit nog ingewikkelder geworden door de komst van nieuwe authenticatieprotocollen. Daarnaast is het afleveren van de mail op de server één ding (delivery), maar we willen dat het bericht ook in de inbox wordt geplaatst (deliverability). Voor een goede deliverability moeten onder andere de DNS-instellingen van je website goed geconfigureerd zijn. Copernica helpt je hierbij door de juiste instellingen aan te bieden in een sender domain.

Hoe dit technische verzendproces in zijn werk gaat, wordt in dit artikel op een begrijpelijke manier uitgelegd. Let op: hierom zijn bepaalde processen en claims wat versimpeld.

Hoe vinden servers elkaar?

Iedere server heeft een uniek IP-adres. Dit is in feite de naam van de server. Op basis van dat adres kan een server gevonden worden. Dit gebeurt via het Domain Name System (DNS), een soort telefoonboek waarbij domeinnamen als tekst worden vertaald naar IP-adressen en vice versa. Wanneer je het IP-adres van een domein (bijvoorbeeld copernica.com) in de URL-balk van je browser typt, kom je op de betreffende website uit. Probeer dit maar eens met 81.171.13.214.

Hoe wordt het bericht aangeboden bij de server?

Wanneer de ontvangende server wordt gevonden, opent de verzendende server een SMTP-connectie. Gedurende deze connectie vindt er een dialoog plaatst die vergelijkbaar is met een menselijke dialoog. De verzendende server opent met de begroeting EHLO en identificeert zich daarbij met zijn afzenderdomein of IP-adres. Daarna wordt het verzendende e-mailadres, het ontvangende e-mailadres en het bericht met e-maildata doorgegeven. Deze communicatie vindt plaats tussen de verzendende en ontvangende MTA (Mail Transfer Agent). De MTA van Copernica is het zelfontwikkelde product MailerQ. In onderstaande visualisatie is een gesimplificeerde visualisatie te zien van het zojuist beschreven SMTP-protocol. In dit voorbeeld stuurt Joost vanaf joost@copernica.com een e-mail naar derek@example.com.

De ontvangende server kan het bericht aannemen of weigeren. Wanneer het bericht wordt aangenomen zorgt de ontvangende server ervoor dat deze in de juiste mailbox terechtkomt. Wanneer het bericht wordt geweigerd resulteert dat in een bounce. Dit is een bericht terug naar de verzendende server waarin een statuscode en beschrijving worden gegeven met de reden waarom het bericht niet afgeleverd kon worden.

Zoals besproken in deel 1 van deze serie, is het belangrijk om goed met deze terugkoppeling van de ontvangende server om te gaan. Profielen die herhaaldelijk bounces terugkrijgen, moeten op den duur uit de verzendlijst gefilterd worden. Wanneer bounces worden genegeerd, kan dit leiden tot blokkades bij de mailboxprovider. Bounces zijn op te splitsen in softbounces (tijdelijke errors, bijvoorbeeld: de mailbox van de ontvanger is vol) en hardbounces (permanente errors, bijvoorbeeld: de opgevraagde mailbox bestaat niet). Wanneer er structureel te veel adressen worden gemaild is dat voor een mailboxprovider een sterke indicatie dat er geen lijstmanagement wordt toegepast of dat het verkeer spam is.

Waarom moet ik een sender domain instellen in Copernica?

Zoals in de inleiding beschreven, is er in de afgelopen jaren een scala aan authenticatieprotocollen in het leven geroepen ter beveiliging van het hierboven beschreven SMTP-protocol. Een nadeel van het SMTP-protocol is namelijk dat het niet in staat is te achterhalen of de verzender daadwerkelijk is wie die beweert te zijn. Daardoor is het SMTP-protocol gevoelig voor praktijken als phishing. Deze protocollen dienen dus als beveiliging voor e-mailgebruikers. In dit artikel behandelen we de volgende drie protocollen: Sender Policy Framework (SPF), DomainKey IdentifiedMail (DKIM) en Domain-based Message Authentication, Reporting and Conformance (DMARC). Deze dienen als standaard en worden door bijna alle mailboxproviders gehanteerd.

Om SPF, DKIM en DMARC goed in te stellen, moeten er extra regels worden ingesteld in het DNS van je website. Deze benodigde regels worden automatisch door Copernica gegenereerd wanneer je je (sub)domein registreert als sender domain. Op deze manier kun je als verzender snel en makkelijk je mails versturen, en regelt Copernica de technische instellingen.

Door deze sender domain-regels in je eigen DNS te plaatsen, worden de servers van Copernica geautoriseerd om vanuit jouw domein te mailen. Als deze instellingen niet in orde zijn, is de kans groot dat je e-mails door de meeste mailboxproviders worden geweigerd (bounce). Buiten het optimaliseren van je eigen deliverability, beveilig je met het instellen van een Copernica sender domain je afzenderdomein in het algemeen. Voor fraudeurs wordt het een stuk lastiger om jouw domein te misbruiken voor spam, phishing of andere schadelijke praktijken.

Hieronder staat de werking van de drie protocollen uitgelegd:

SPF

Met dit record in je DNS geef je aan welke IP-adressen (dus servers) namens jouw domein mails mogen versturen. Een ontvangende server vraagt de SPF-records op wanneer er een mail van jouw domein binnenkomt en vergelijkt het IP van de verzendende server met de IP-adressen in het SPF-record. Als er een match is, wordt het domein niet misbruikt door een verzender van een onbekende server.

Om dit te illustereren beschrijf ik hier een overdreven voorbeeld. Op deze manier kan CEO-fraude worden gepleegd.

Het is voor iedereen mogelijk een mail versturen vanuit bill.gates@microsoft.com met daarin een link om een geldbedrag te claimen (of in het geval van CEO-fraude: een bedrag over te maken). Voordat de e-mailserver dit bericht aanneemt, wordt er gekeken in de DNS-records van Microsoft of het IP-adres van de verzendende server wel gemachtigd is vanuit @microsoft.com te mailen. Zo niet, dan faalt de SPF-test.

In de praktijk komt het veel voor dat kwaadwillenden een domein kiezen dat ze wel zelf beheren en lijkt op een bestaand domein, denk aan micrsoft.com. Zodoende komen ze wel door de SPF-check. Check als ontvanger daarom altijd zelf goed het afzenderdomein (FROM-domein) en het envelope-adres. Dit laatste adres is een onzichtbaar adres (wel zichtbaar in de e-mailheaders), waar o.a. bounceberichten naartoe worden gestuurd.

Met een Copernica sender domain ontvang je een uniek SPF-record dat verwijst naar een domein. Deze verwijst weer door naar de betreffende IP-adressen. Op deze manier kunnen we gemakkelijk en snel met IP-adressen schakelen wanneer dat nodig is, om zo een optimale deliverability te waarborgen. Dit zonder aanpassingen in jouw DNS.

DKIM

Met behulp van DKIM-records wordt nagegaan of het verstuurde bericht daadwerkelijk komt van het opgegeven afzenderdomein. Daarnaast wordt gekeken of het bericht gedurende de verzending niet is aangepast, door bijvoorbeeld kwaadwillenden. Dit gebeurt allemaal op basis van versleuteling.

Op het moment van verzenden wordt er een cryptografische handtekening gemaakt van het complete e-mailbericht. Deze handtekening is een lange reeks van tekens en wordt berekend door een algoritme op basis van een geheime sleutel. Deze privésleutel is buiten de legitieme verzender voor niemand toegankelijk en staat veilig op de servers van Copernica. Tegelijkertijd staat de publieke sleutel opgenomen in de DNS-records, welke onderdeel uitmaakt van het sender domain in Copernica. Deze privé en publieke sleutel vormen een paar. De ontvangende server vraagt de publieke sleutel op van het domein waar de mail vandaan zegt te komen en kan hiermee controleren of de handtekening inderdaad afkomstig is van dit domein.

Omdat deze handtekening onder andere is gebaseerd op de content van de mail, vormt deze authenticatiemethode gelijk een check of er gedurende de verzending geen aanpassingen zijn gedaan door kwaadwillenden. Zo zouden er bijvoorbeeld URLs aangepast kunnen worden als onderdeel van een man-in-the-middle-aanval.

DMARC

In het DMARC-record staan in feite instructies opgenomen hoe de ontvangende server moet omgaan met e-mails die niet door de SPF- of DKIM-authenticatie komen. De mogelijkheden zijn: niets doen (het bericht aannemen), het bericht in quarantaine plaatsen of het bericht afwijzen. Je kunt zelfs instellen voor welk percentage van de foutieve e-mails je de actie wilt uitvoeren.

Verder kun je in het DMARC-record opgeven naar welk adres DMARC-rapportages gestuurd moeten worden. Deze worden verstuurd door mailboxproviders en stellen de beheerder van het domein in staat te onderzoeken of het domein wordt misbruikt voor het verzenden van mailings. Copernica raadt hier een standaardadres voor aan, omdat op deze manier de rapportages automatisch in onze ingebouwde DMARC-analyzer worden verwerkt. Deze tool is te vinden in het sender domain configuratiescherm. Je kunt aan dit record extra adressen toevoegen. Deze dienen door een komma gescheiden te zijn.

Conclusie