E-mail deliverability: zorgen dat je mail aankomt en niemand uit jouw naam kan mailen

Of een e-mail aankomt, wordt grotendeels bepaald voordat de ontvanger ook maar iets ziet. Ontvangende mailservers van bijvoorbeeld Gmail, Outlook en zakelijke providers controleren bij binnenkomst een reeks technische signalen: klopt de afzender, is de mail onderweg niet aangepast, en mag deze server eigenlijk wel mailen namens jouw domein. Die signalen staan niet in je e-mailprogramma, maar in de DNS-zone van je domein. Daar regel je per recordtype een stukje van het vertrouwen.

Het vervelende is dat alles op het oog gewoon werkt, ook als de records ontbreken of fout staan. Je verstuurt een mail, jij ziet hem in je verzonden items, en je merkt pas dat er iets mis is als een klant zegt dat hij niets heeft ontvangen. Tegen die tijd is de schade (een gemiste afspraak, een offerte die te laat komt) al geleden. Daarom is het verstandig om deliverability proactief te controleren in plaats van te wachten op klachten.

De tweede kant van hetzelfde verhaal is misbruik. Zonder de juiste records kan iemand een e-mail opstellen met jouw domein in het afzenderveld en die versturen via een willekeurige server. Voor de ontvanger lijkt het alsof het bericht echt van jou komt. SPF, DKIM en DMARC zijn samen de techniek die dit tegenhoudt. Ze beschermen dus niet alleen jouw aankomst, maar ook je reputatie en je klanten.

Het MX-record (Mail Exchange) bepaalt waar inkomende post voor jouw domein naartoe gaat. Voor elke domeinnaam waar je mail op wilt ontvangen, wijst het MX-record naar de server van je e-mailprovider. Een typisch record ziet er zo uit: 'voorbeeld.nl. IN MX 10 mail.provider.nl.', waarbij het getal 10 de prioriteit is (lager getal gaat voor). Ontbreekt het MX-record, dan kun je geen mail ontvangen op dat domein. Het is ook het eerste dat je controleert wanneer inkomende mail wegblijft.

SPF (Sender Policy Framework) doet het omgekeerde: het vertelt de wereld welke servers namens jouw domein mogen versturen. Je publiceert een TXT-record op je domein dat de toegestane bronnen opsomt. Een voorbeeld voor een bedrijf dat via Microsoft 365 mailt: 'v=spf1 include:spf.protection.outlook.com -all'. Gebruik je daarnaast een nieuwsbriefdienst, dan voeg je die include toe. Het sluitstuk '-all' betekent: alles wat niet in deze lijst staat, is niet toegestaan. Dat is strenger en veiliger dan '~all' (softfail), dat verdachte mail enkel markeert.

Twee veelvoorkomende valkuilen bij SPF zijn belangrijk om te kennen. Ten eerste mag je per domein maar een SPF-record hebben; twee losse records breken de validatie. Ten tweede geldt een limiet van tien DNS-lookups: stapel je te veel includes op, dan faalt SPF stilletjes. Houd je record daarom zo kort mogelijk en verwijder includes van diensten die je niet meer gebruikt.

DKIM (DomainKeys Identified Mail) zet een digitale handtekening onder elke uitgaande e-mail. Je e-mailserver tekent het bericht met een geheime sleutel, en de bijbehorende publieke sleutel publiceer je in DNS. De ontvangende server haalt die publieke sleutel op en controleert of de handtekening klopt. Klopt hij, dan staat vast dat de mail echt van jouw domein komt en onderweg niet is aangepast.

De publieke sleutel staat op een zogeheten selector-subdomein, bijvoorbeeld 'selector1._domainkey.voorbeeld.nl', met als inhoud een TXT-record dat begint met 'v=DKIM1; k=rsa; p=' gevolgd door een lange sleutel. De selectornaam krijg je van je e-mailprovider; bij Microsoft 365 zijn dat vaak 'selector1' en 'selector2', bij Google Workspace meestal 'google'. Je hoeft de sleutel niet zelf te bedenken: de provider genereert hem, jij plaatst alleen het record en zet DKIM daarna aan in het beheerpaneel.

Een subtiel maar belangrijk punt: DKIM aanzetten in je provider zonder het DNS-record te plaatsen (of andersom) levert juist een mislukte controle op, wat slechter kan uitpakken dan helemaal geen DKIM. Zet daarom eerst het record klaar, controleer dat het publiek zichtbaar is, en activeer pas daarna de ondertekening. Bij sommige diensten roteren de sleutels automatisch met twee selectors, zodat een nieuwe sleutel kan ingaan zonder onderbreking.

DMARC (Domain-based Message Authentication, Reporting and Conformance) is de regel die SPF en DKIM aan elkaar knoopt en bepaalt wat er gebeurt als een mail de controle niet doorstaat. Zonder DMARC zijn SPF en DKIM losse signalen die ontvangers naar eigen inzicht mogen interpreteren. Met DMARC zeg je expliciet: als een mail namens mijn domein niet authentiek is, doe er dan dit mee. Je publiceert het als TXT-record op '_dmarc.voorbeeld.nl'.

Een verstandig startrecord is: 'v=DMARC1; p=none; rua=mailto:dmarc@voorbeeld.nl; fo=1'. Met 'p=none' blokkeer je nog niets, maar ontvang je wel rapporten (via rua) over wie er allemaal mailt namens jouw domein. Dat is de monitorfase: je ziet welke legitieme diensten je over het hoofd hebt gezien voordat je gaat afdwingen. Na een paar weken zonder verrassingen verscherp je naar 'p=quarantine' (verdachte mail naar spam) en uiteindelijk naar 'p=reject' (verdachte mail wordt geweigerd). Pas die laatste is jouw domein echt beschermd tegen misbruik.

Wat veel mensen niet weten, is dat DMARC werkt op basis van alignment: het afzenderdomein dat de ontvanger ziet, moet overeenkomen met het domein dat SPF of DKIM heeft gevalideerd. Een mail kan dus een geldige SPF-check hebben en toch op DMARC zakken als de domeinen niet uitlijnen, bijvoorbeeld bij doorgestuurde post of een verkeerd geconfigureerde nieuwsbriefdienst. De DMARC-rapporten maken precies dit zichtbaar, en daar zit de echte waarde van de monitorfase.

SPF, DKIM en DMARC gaan over echtheid, maar niet over of de verbinding tussen mailservers versleuteld is. Standaard is transportversleuteling (TLS) bij e-mail opportunistisch: servers proberen het, maar vallen terug op onversleuteld als het niet lukt. Dat opent de deur voor een aanvaller die de verbinding zo manipuleert dat de versleuteling wegvalt en hij kan meelezen. MTA-STS (Mail Transfer Agent Strict Transport Security) sluit die deur door af te dwingen dat verzendende servers alleen via geldige TLS mogen afleveren.

MTA-STS bestaat uit twee delen. Eerst een TXT-record op '_mta-sts.voorbeeld.nl' met als inhoud 'v=STSv1; id=20260619000000' (het id is een versienummer dat je bij elke wijziging ophoogt). Daarnaast publiceer je een policybestand op de URL 'https://mta-sts.voorbeeld.nl/.well-known/mta-sts.txt' waarin je de toegestane MX-hosts en de modus opsomt. In de testfase gebruik je 'mode: testing', wat nog niets blokkeert maar wel meet; daarna zet je hem op 'mode: enforce'. Dit vereist dus zowel een DNS-record als een geldige HTTPS-pagina met certificaat.

TLS-RPT (TLS Reporting) is het bijbehorende rapportagekanaal. Met een TXT-record op '_smtp._tls.voorbeeld.nl' met de inhoud 'v=TLSRPTv1; rua=mailto:tlsrpt@voorbeeld.nl' vraag je ontvangende servers om dagelijks te rapporteren wanneer een TLS-verbinding niet tot stand kwam. Zo merk je het meteen als je MTA-STS-beleid problemen veroorzaakt, voordat post stil blijft liggen. MTA-STS en TLS-RPT zijn de meest geavanceerde laag en zeker niet voor iedereen verplicht, maar voor bureaus die met gevoelige klantcommunicatie werken zijn ze een logische volgende stap.

Je kunt elk record met de hand nakijken, en dat is leerzaam, maar foutgevoelig. Een spatie te veel in een SPF-record, een DKIM-sleutel die wel in DNS staat maar niet in je provider is aangezet, of een DMARC-policy die op 'none' is blijven hangen: het zijn precies dit soort details die het verschil maken tussen aankomen en in de spam belanden. Daarom is het handig om periodiek een volledige, onafhankelijke controle te draaien in plaats van per record te gokken.

CheckBorg heeft hiervoor een live e-mail-deliverability-check (onderdeel van Pro) die in een keer MX, SPF, DKIM, DMARC, MTA-STS en TLS-RPT van je domein opvraagt en per onderdeel laat zien of het goed staat. Belangrijker nog: bij elk probleem krijg je de exacte fix, dus de letterlijke DNS-waarde die je moet plaatsen of aanpassen, in plaats van een vaag 'er is iets mis'. Dat scheelt zoeken en verkeerd overtypen, en je kunt het resultaat direct doorgeven aan je DNS-beheerder of provider.

De check is bedoeld om herhaalbaar te zijn. DNS verandert, je voegt een nieuwsbriefdienst toe, je migreert naar een andere mailomgeving, en bij elk van die momenten kan een record stilletjes ongeldig worden. Door na elke wijziging opnieuw te scannen, weet je zeker dat je instellingen kloppen voordat de eerste klant erover valt. Een gratis scan geeft je al een eerste indruk van je domein; de deliverability-check gaat daar dieper op door.