De overstap in de DNS: MX, SPF, DKIM en DMARC

Module 4: E-mail verhuizen · Leestijd: 12 minuten

Leerdoel: Na deze les kun je de DNS-wissel voor e-mail in de goede volgorde plannen en uitvoeren, zodat er geen mail verloren gaat, je uitgaande mail niet in de spam valt en Outlook niet stiekem bij de oude aanbieder blijft aankloppen.

Kernbegrippen: TTL, MX-wissel, SPF (één record), DKIM-selector, DMARC (p=none, rua), autodiscover, autoconfig, verificatierecord, geaccepteerd domein

Vijf records, één moment

Voor e-mail op je eigen domein staan er een paar records in de DNS die samen bepalen of mail aankomt en of jouw mail vertrouwd wordt:

Bij een verhuizing verandert bijna alles hiervan. De kunst is de volgorde. Zet je de MX om terwijl SPF en DKIM nog alleen voor Microsoft gelden, dan komt je mail wel binnen, maar valt de mail die je verstuurt in de spam. Zet je SPF eerst om, dan kan Microsoft niet meer goed namens je mailen in de dagen ervoor.

Deze les gaat over de volgorde. Hoe elk record precies in elkaar zit, lees je in de DNS-cursus (lessen 4.1 tot 4.5).

Stap 1, twee dagen vooraf: TTL omlaag en back-up

Elk DNS-record heeft een TTL (time to live): hoe lang andere servers het antwoord mogen onthouden. Staat de TTL van je MX op 86400 seconden (een dag), dan blijven sommige servers na de wissel nog tot een dag lang naar de oude server sturen.

Verlaag daarom minstens één oude TTL vooraf de TTL van MX, SPF en autodiscover naar 300 of 3600 seconden. Bij een TTL van een dag doe je dat dus minstens een dag van tevoren; twee dagen is ruim. Maak tegelijk een back-up van je DNS-zone, of schrijf alle huidige records op. Dan kun je altijd terug.

Bakkerij De Korrel ziet:

example.com.            3600  IN  MX   0 example-com.mail.protection.outlook.com.
example.com.            3600  IN  TXT  "v=spf1 include:spf.protection.outlook.com -all"
selector1._domainkey    3600  IN  CNAME selector1-example-com._domainkey.korrel.onmicrosoft.com.
selector2._domainkey    3600  IN  CNAME selector2-example-com._domainkey.korrel.onmicrosoft.com.
_dmarc.example.com.     3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
autodiscover            3600  IN  CNAME autodiscover.outlook.com.
example.com.            3600  IN  TXT  "MS=ms12345678"

De TTL is al 3600 (een uur). Ze zetten MX en SPF op 300.

Stap 2, vóór de wissel: DKIM en SPF voor de nieuwe aanbieder klaarzetten

Records die niets kapotmaken, zet je er al vooraf bij:

• DKIM van de nieuwe aanbieder. De nieuwe aanbieder geeft een selector en een sleutel, bijvoorbeeld x._domainkey met een TXT-record v=DKIM1; k=rsa; p=.... Omdat de selector anders heet dan die van Microsoft (selector1 en selector2), staan ze rustig naast elkaar. Elke ontvanger kijkt alleen naar de selector die in de handtekening van de mail staat.
• SPF uitbreiden, niet vervangen. Er mag maar één SPF-record zijn. Zet de nieuwe aanbieder erbij in hetzelfde record, zodat in de overgangsdagen beide mogen versturen:

"v=spf1 include:spf.protection.outlook.com include:spf.mailaanbieder.example ~all"

De bakkerij had -all. Tijdens de overgang kiezen ze tijdelijk ~all (softfail): als er toch een server ontbreekt, wordt de mail eerder als verdacht gezien dan geweigerd. Dat volgt de vuistregel: ~all als je niet helemaal zeker bent, -all als je zeker weet dat alle verzenders erin staan.

Vergeet de andere verzenders uit je lijstje van les 4.1 niet: de webwinkel, de nieuwsbriefdienst, de boekhouding. Die blijven in het SPF-record staan.

Stap 3, het wisselmoment: MX en autodiscover

Op het afgesproken moment, nadat de eerste kopie van de mailboxen klaar is (les 4.2):

1. Vervang de MX-records door die van de nieuwe aanbieder. Haal de oude MX weg; laat hem niet als "reserve" staan met een hogere prioriteit, want dan komt er mail bij de oude aanbieder binnen zodra de nieuwe even traag is.
2. Pas autodiscover aan. Outlook zoekt zijn instellingen via autodiscover.example.com. Wijst dat nog naar autodiscover.outlook.com, dan blijft Outlook proberen bij Microsoft in te loggen, ook als je een nieuw account toevoegt. Haal het weg of laat het wijzen naar wat je nieuwe aanbieder opgeeft. Sommige aanbieders gebruiken in plaats daarvan autoconfig.example.com (Thunderbird) of SRV-records als _imaps._tcp en _submission._tcp (RFC 6186).
3. Draai een tweede kopie van de mailboxen, zodat de mail van de laatste uren meekomt.

Er is een verrassing bij Microsoft 365 die veel mensen overvalt. Zolang example.com in de Microsoft 365-omgeving staat als geaccepteerd domein, levert Microsoft mail tussen gebruikers van diezelfde omgeving intern af, zonder naar de MX te kijken. Mailt een collega die nog in Outlook bij Microsoft werkt naar een andere collega, dan komt die mail in de oude mailbox. Daarom zet je alle medewerkers op dezelfde dag om, en haal je het domein na de overgangsperiode uit de Microsoft-omgeving.

Stap 4, DMARC: meelezen tijdens de overgang

DMARC zegt tegen ontvangers wat ze moeten doen als een mail niet door SPF of DKIM komt, en het stuurt je rapporten. De bakkerij had p=quarantine. Dat is goed, maar tijdens een wissel gevaarlijk: als DKIM bij de nieuwe aanbieder nog niet aanstaat, belandt hun eigen mail bij klanten in de spam.

De veilige aanpak:

• Heb je nog geen DMARC, begin dan met p=none en een rua-adres. Dan gebeurt er niets met je mail, maar krijg je rapporten.
• Heb je al quarantine of reject, controleer dan vóór de wissel met een testmail dat DKIM van de nieuwe aanbieder werkt (de kopregel van een ontvangen mail toont dkim=pass met d=example.com). Twijfel je, zet dan tijdelijk p=none en lees de rapporten een paar weken mee.
• Scherp daarna stap voor stap aan: none, dan quarantine, dan eventueel reject. Volgens de nieuwe DMARC-standaard (RFC 9989) kun je in de testfase ook t=y gebruiken; de oude tag pct vervalt.

Stap 5, na een paar weken: opruimen

Werkt alles een paar weken goed, dan ruim je de oude records op:

• de oude include uit SPF (en eventueel terug naar -all);
• de oude DKIM-records (selector1 en selector2);
• het verificatierecord MS=ms... en eventuele andere records voor Microsoft, zoals enterpriseregistration en lyncdiscover als je die had;
• de TTL terug naar een gewone waarde, zoals 3600;
• het domein uit de oude Microsoft- of Google-omgeving.

Laat je de oude include staan, dan mag de oude aanbieder nog jaren namens jouw domein mailen. Dat is een open deur.

In de praktijk: zo ziet het eruit bij een aanbieder

In Mijn WebOké staat op het tabblad DNS de kaart E-mail-instellingen. Die toont MX, SPF en DMARC met een gekleurd puntje, en rechtsboven welke mailaanbieder hij herkent aan je MX. Met Snel instellen zet je in één keer de records voor een aanbieder, en de gele melding waarschuwt dat bestaande MX- en SPF-records worden vervangen. Maak daarom eerst een DNS-back-up en controleer daarna of het SPF-record nog je andere verzenders bevat. Op de productpagina van een hostingpakket staat de kaart E-mail instellen, die per record laat zien of hij Correct, Let op, Onjuist of Niet gevonden is en de waarde met een kopieerknopje geeft. Staat de DNS bij een andere partij, dan neem je die waarden daar over. Andere aanbieders en DNS-panelen hebben vergelijkbare overzichten; de records zelf zijn overal hetzelfde.

Samenvatting

• Verlaag de TTL minstens één oude TTL vooraf en maak een back-up van je DNS-zone.
• Zet DKIM van de nieuwe aanbieder en een uitgebreid SPF-record (één record, beide aanbieders) al vóór de wissel klaar.
• Wissel MX en autodiscover tegelijk, en zet alle medewerkers op dezelfde dag om; Microsoft levert interne mail anders nog in de oude mailboxen af.
• Zet DMARC tijdens de overgang niet strenger dan wat je zeker weet; begin zonder DMARC met p=none en rapporten.
• Ruim na een paar weken de oude include, DKIM-records, verificatierecords en het domein in de oude omgeving op.

Quiz

Opdracht

Opdracht A4.3: Je mailrecords op een rij. Vul je domein in, en de DKIM-selector van je (nieuwe) aanbieder. Het programma controleert of de MX naar je aanbieder wijst, of er precies één SPF-record is, of de DKIM-sleutel op die selector staat en of er precies één DMARC-record is. Het meet ook de TTL van je MX bij de gezaghebbende nameserver: voor een geplande wissel moet die 3600 of lager zijn.

Opdracht E4.3: Je wisseldraaiboek. Schrijf voor je eigen domein het draaiboek uit deze les: per stap de datum en tijd, de records voor en na (oud en nieuw SPF als één regel), wie het doet, en wat je controleert na elke stap.

Verder lezen

De stappen in deze artikelen gelden voor de diensten van WebOké; bij andere aanbieders werkt het vergelijkbaar.

• WebOké handleiding 6.7: De kaart E-mail instellen (MX, SPF, DKIM, DMARC)
• WebOké handleiding 5.6: E-mail snel instellen in de DNS
• WebOké handleiding 5.7: DNS terugzetten en een DNS-back-up maken
• DirectAdmin handleiding 10.4: Na de verhuizing: MX-records en je apparaten
• Gratis DNS-cursus 4.3: SPF: wie mag mailen namens jouw domein?
• Gratis DNS-cursus 4.4: DKIM: de handtekening onder je mail
• Gratis DNS-cursus 4.5: DMARC: wat ontvangers moeten doen met nepmail
• Gratis DNS-cursus 6.3: DNS bij een verhuizing
• RFC 7208 (SPF), RFC 6376 (DKIM), RFC 9989 (DMARC), RFC 6186 (SRV-records voor mailprogramma's)