MX, SPF, DKIM, DMARC, MTA-STS en de records voor automatische configuratie die niemand met de hand opzet. Wat elk record doet, welke twee families we bewust weglaten, en waarom onze controle je bestaande SPF-record samenvoegt in plaats van je te vertellen dat je het moet vervangen.
E-mail op je eigen domein instellen betekent DNS-records publiceren, en DNS is precies de plek waar migraties stil misgaan. Niet omdat die records moeilijk zijn, maar omdat het er meer zijn dan iemand verwacht, omdat een paar ervan lange reeksen cryptografisch materiaal zijn, en omdat één subtiele fout betekent dat je mail blijft werken tot precies de dag dat het niet meer werkt.
Ons standpunt is daarom dat je dit nooit zelf hoeft uit te zoeken. Voeg je een domein toe aan email.eu, dan genereren wij exact de records die jouw domein nodig heeft, laten we zien wat er vandaag gepubliceerd staat, en vertellen we welke er nog niet goed staan. Deze post gaat over welke records dat zijn, wat we er bewust uit laten, en hoe die controle werkt.
Het korte antwoord: zo'n twintig records, in zes families. Waar ze voor dienen, in gewone taal.
| Record | Wat het doet |
|---|---|
| MX | Wijst het internet naar de servers die mail voor je domein aannemen. Zonder dit komt er niets aan. |
| SPF | Somt op wie er namens jou mag verzenden. Ontvangers gebruiken het om vervalsingen te weigeren. |
| DKIM | Publiceert de publieke helft van een ondertekeningssleutel, zodat ontvangers kunnen controleren dat je mail onderweg niet is aangepast. |
| DMARC | Vertelt ontvangers wat ze moeten doen als SPF en DKIM elkaar tegenspreken, en waar ze rapporten daarover naartoe sturen. |
| MTA-STS en TLS-RPT | Zeggen dat mail naar je domein over TLS bezorgd moet worden, en waar het gemeld moet worden als dat niet kan. |
| SRV en CNAME | Laten mailprogramma's je serverinstellingen zelf vinden, in plaats van dat je mensen poortnummers laat intypen. |
Die laatste familie zet bijna niemand met de hand op, en het is het verschil tussen een collega die zijn adres intypt en klaar is, of een collega die zijn adres intypt en daarna op zoek gaat naar poortnummers.
De mailserver zelf weet wat hij nodig heeft. Stalwart, de mailserver achter email.eu, kan een volledige zone voor een domein opleveren zodra dat domein bestaat, inclusief de DKIM-sleutel die net voor je is aangemaakt. Die zone lezen wij uit en zetten we om in twee dingen: een leesbare tabel in je dashboard, en een zonebestand dat je bij de meeste DNS-providers in één keer kunt importeren.
Wat we niet doen, is in jouw DNS reiken en de records zelf wegschrijven. Dan zouden we API-toegang tot je registrar moeten hebben, en dat is nogal wat toegang om te vragen zodat wij jou één keer plakken kunnen besparen. Je domein blijft van jou. Wij vertellen precies wat je moet publiceren, en controleren daarna of het er staat.
De ruwe zone die de mailserver genereert bevat ongeveer achtenvijftig records. Wij laten er ongeveer tweeëntwintig zien. Het verschil zijn twee families die we er bewust uit halen, en beide keuzes zijn het uitleggen waard, want "ons systeem genereerde het" is geen reden om je iets te geven waar je later last van krijgt.
DANE-records (TLSA). DANE zet het exacte certificaat van je mailserver vast in DNS. Het is echt goede beveiliging, en het is een valkuil voor DNS die je met de hand bijhoudt, want die vastzetting moet opnieuw gepubliceerd worden elke keer dat het certificaat vernieuwt. Bij certificaten die ongeveer elke zestig dagen vernieuwen is een DANE-record dat je één keer hebt geplakt en daarna vergeten een record dat op een stil moment je mail gaat weigeren. Wij geven je geen tijdbom met een lont van twee maanden, dus die records laten we weg.
CAA-records. Een CAA-record zegt welke certificaatautoriteit certificaten voor je domein mag uitgeven, en het geldt voor je hele domein, niet alleen voor de mail. De versie die een mailserver genereert wijst naar de certificaatadministratie van die mailserver zelf. Publiceer je die, dan heb je stilletjes aan de wereld verteld dat alleen die administratie certificaten voor jouw bedrijf mag uitgeven, en daar valt ook het certificaat op je website onder, dat niets met ons te maken heeft. Certificaatbeleid voor je domein is een beslissing die je bewust neemt, geen bijeffect van het instellen van e-mail. Dus van CAA blijven we af.
Dat is de algemene regel die we aanhouden: de set die we aanraden is de set die werkt, blijft werken zonder onderhoud, en alleen over mail gaat.
Zodra je gepubliceerd hebt, controleren wij. Elk record krijgt een van een paar eerlijke uitkomsten: goed gepubliceerd, ontbreekt, of aanwezig maar anders dan wij verwachten. Ontbreekt en anders zijn bewust verschillende antwoorden, want ze vragen iets anders van je.
Bij SPF verdient zo'n controle zijn geld. Een domein mag maar één SPF-record hebben, dus als je je facturen al via je boekhoudpakket verstuurt en je nieuwsbrief via een mailtool, dan bestaat je SPF-record al en staan die er al in. Een naïeve controle ziet dat ons voorgestelde record er niet staat, meldt dat het ontbreekt, en nu krijg je het advies om je facturen te breken.
Die van ons doet het juiste. Hij leest wat je gepubliceerd hebt, kijkt of het ons al toestaat, en zo niet, dan bouwt hij het samengevoegde record dat je echt moet publiceren: je bestaande afzenders, plus wij, met jouw eigen beleid aan het eind. Heb je voor softfail gekozen in plaats van hard falen, dan houden we jouw keuze. Dat is jouw beslissing over jouw domein, niet de onze.
Daarvoor komt nog één klein record dat iets anders doet: een verificatiecode op _email-eu-verify op je domein. Die bestaat zodat niemand jouw domein aan zijn eigen werkomgeving kan toevoegen en jouw mail kan gaan ontvangen. Publiceer hem, wij zoeken hem op, en het domein is in ons systeem van jou.
Daarna ziet de hele reeks er zo uit.
Bij die laatste stap houden we het in het bijzonder eerlijk. Op "ga live" klikken zorgt er niet voor dat je dashboard beweert dat je live bent. Er staat live zodra een DNS-controle het MX-record van de buitenwereld echt naar ons heeft zien wijzen. Bedoeling en werkelijkheid zijn twee verschillende dingen, en een statusweergave die die twee door elkaar haalt is erger dan geen statusweergave.
Nog een detail dat op de lange duur uitmaakt: je recordset wordt opnieuw uit de mailserver opgehaald elke keer dat je de domeinpagina opent, en niet bevroren op het moment dat je je aanmeldde. Groeit het mailcluster met een tweede MX-host, of verhuist een van de records voor automatische configuratie, dan laat de pagina waar je uit kopieert de nieuwe waarheid al zien. Niemand hoeft je een correctie te mailen.
Niets hiervan is spannend. Het is het deel van het weggaan bij je oude provider waar mensen afhaken, of erger, halverwege stoppen en een jaar lang mail hebben die meestal aankomt. Door er een tabel, een keer plakken en een controle van te maken, wordt een uitzoekproject een middag werk.
Wil je de echte recordset voor je eigen domein zien voordat je je aan iets vastlegt, dan zit die achter de eerste stap van aanmelden, en de migratiegids voor een weekend loopt de hele overstap van begin tot eind door.