Skiftet i DNS'en: MX, SPF, DKIM og DMARC

Modul 4: Flytning af e-mail · Læsetid: 12 minutter

Læringsmål: Efter denne lektion kan du planlægge og udføre DNS-skiftet for e-mail i den rigtige rækkefølge, så der ikke går mail tabt, din udgående mail ikke havner i spam, og Outlook ikke i al hemmelighed bliver ved med at banke på hos den gamle udbyder.

Kernebegreber: TTL, MX-skifte, SPF (ét record), DKIM-selector, DMARC (p=none, rua), autodiscover, autoconfig, verifikationsrecord, accepteret domæne

Fem records, ét tidspunkt

For e-mail på dit eget domæne findes der nogle records i DNS'en, som tilsammen afgør om mail bliver afleveret, og om din mail bliver stolet på:

Ved en flytning ændres næsten det hele. Kunsten ligger i rækkefølgen. Skifter du MX'en, mens SPF og DKIM stadig kun gælder for Microsoft, så kommer din mail nok ind, men den mail du selv sender ud, havner i spam. Skifter du SPF først, kan Microsoft ikke længere sende mail korrekt på dine vegne i dagene forinden.

Denne lektion handler om rækkefølgen. Hvordan hvert record nøjagtigt fungerer, kan du læse i DNS-kurset (lektion 4.1 til 4.5).

Trin 1, to dage forinden: sænk TTL og tag backup

Hvert DNS-record har en TTL (time to live): hvor længe andre servere må huske svaret. Står TTL'en for din MX på 86400 sekunder (et døgn), vil nogle servere efter skiftet stadig sende til den gamle server i op til et døgn.

Sænk derfor mindst én gammel TTL i forvejen, TTL'en for MX, SPF og autodiscover til 300 eller 3600 sekunder. Ved en TTL på et døgn gør du det altså mindst et døgn i forvejen; to dage er rigeligt. Tag samtidig en backup af din DNS-zone, eller skriv alle de nuværende records ned. Så kan du altid gå tilbage.

Bageriet Korn (Bakkerij De Korrel) ser:

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"

TTL'en er allerede 3600 (en time). De sætter MX og SPF til 300.

Trin 2, før skiftet: gør DKIM og SPF klar til den nye udbyder

Records der ikke ødelægger noget, sætter du op allerede i forvejen:

• DKIM fra den nye udbyder. Den nye udbyder giver en selector og en nøgle, for eksempel x._domainkey med et TXT-record v=DKIM1; k=rsa; p=.... Fordi selectoren hedder noget andet end Microsofts (selector1 og selector2), kan de roligt stå ved siden af hinanden. Hver modtager kigger kun på den selector, der står i mailens underskrift.
• Udvid SPF, erstat den ikke. Der må kun findes ét SPF-record. Tilføj den nye udbyder i det samme record, så begge må sende mail i overgangsdagene:

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

Bageriet havde -all. Under overgangen vælger de midlertidigt ~all (softfail): hvis der alligevel mangler en server, bliver mailen snarere anset for mistænkelig end afvist. Det følger tommelfingerreglen: ~all hvis du ikke er helt sikker, -all hvis du er sikker på, at alle afsendere er med.

Glem ikke de andre afsendere fra din liste fra lektion 4.1: webshoppen, nyhedsbrevstjenesten, bogføringen. De skal blive stående i SPF-recordet.

Trin 3, selve skiftetidspunktet: MX og autodiscover

På det aftalte tidspunkt, efter at den første kopi af postkasserne er klar (lektion 4.2):

1. Erstat MX-recordene med den nye udbyders. Fjern den gamle MX; lad den ikke stå som "reserve" med en højere prioritet, for så kommer der mail ind hos den gamle udbyder, så snart den nye er en smule langsom.
2. Tilpas autodiscover. Outlook finder sine indstillinger via autodiscover.example.com. Peger det stadig mod autodiscover.outlook.com, bliver Outlook ved med at forsøge at logge ind hos Microsoft, også når du tilføjer en ny konto. Fjern det, eller lad det pege mod det, din nye udbyder angiver. Nogle udbydere bruger i stedet autoconfig.example.com (Thunderbird) eller SRV-records som _imaps._tcp og _submission._tcp (RFC 6186).
3. Kør en ny kopi af postkasserne, så mailen fra de sidste timer kommer med.

Der er en overraskelse ved Microsoft 365, som rammer mange. Så længe example.com står som accepteret domæne i Microsoft 365-miljøet, leverer Microsoft mail mellem brugere i samme miljø internt, uden at kigge på MX'en. Sender en kollega, der stadig arbejder i Outlook hos Microsoft, til en anden kollega, havner den mail i den gamle postkasse. Derfor skifter du alle medarbejdere om på samme dag, og fjerner du domænet fra Microsoft-miljøet efter overgangsperioden.

Trin 4, DMARC: lyt med under overgangen

DMARC fortæller modtagere, hvad de skal gøre, hvis en mail ikke består SPF eller DKIM, og den sender dig rapporter. Bageriet havde p=quarantine. Det er godt, men farligt under et skifte: hvis DKIM hos den nye udbyder endnu ikke er sat op, havner deres egen mail i spam hos kunderne.

Den sikre fremgangsmåde:

• Har du endnu ikke DMARC, så begynd med p=none og en rua-adresse. Så sker der ikke noget med din mail, men du får rapporter.
• Har du allerede quarantine eller reject, så kontroller før skiftet med en testmail, at DKIM fra den nye udbyder virker (headeren i en modtaget mail viser dkim=pass med d=example.com). Er du i tvivl, så sæt midlertidigt p=none og læs rapporterne et par uger.
• Stram derefter op trin for trin: none, så quarantine, og eventuelt til sidst reject. Ifølge den nye DMARC-standard (RFC 9989) kan du i testfasen også bruge t=y; det gamle tag pct udgår.

Trin 5, efter et par uger: ryd op

Virker alt godt efter et par uger, rydder du op i de gamle records:

• det gamle include fra SPF (og eventuelt tilbage til -all);
• de gamle DKIM-records (selector1 og selector2);
• verifikationsrecordet MS=ms... og eventuelle andre records for Microsoft, som enterpriseregistration og lyncdiscover, hvis du havde dem;
• TTL'en tilbage til en normal værdi, som 3600;
• domænet ud af det gamle Microsoft- eller Google-miljø.

Lader du det gamle include blive stående, kan den gamle udbyder sende mail på dit domænes vegne i årevis endnu. Det er en åben dør.

I praksis: sådan ser det ud hos en udbyder

I Mit WebOké finder du under fanebladet DNS kortet E-mail-indstillinger. Det viser MX, SPF og DMARC med en farvet prik, og øverst til højre hvilken mailudbyder det genkender ud fra din MX. Med Hurtig opsætning sætter du alle records for en udbyder op på én gang, og den gule besked advarer om, at eksisterende MX- og SPF-records bliver erstattet. Tag derfor først en DNS-backup, og kontroller bagefter, om SPF-recordet stadig indeholder dine andre afsendere. På produktsiden for en hostingpakke finder du kortet Angiv e-mail, som viser pr. record om det er Korrekt, Bemærk, Forkert eller Ikke fundet, og giver værdien med en kopiknap. Ligger DNS'en hos en anden udbyder, overfører du de værdier derhen. Andre udbydere og DNS-paneler har tilsvarende oversigter; selve recordene er de samme overalt.

Opsummering

• Sænk TTL'en mindst én gammel TTL i forvejen, og tag en backup af din DNS-zone.
• Gør DKIM fra den nye udbyder og et udvidet SPF-record (ét record, begge udbydere) klar allerede før skiftet.
• Skift MX og autodiscover samtidig, og skift alle medarbejdere om på samme dag; ellers leverer Microsoft stadig intern mail i de gamle postkasser.
• Gør ikke DMARC strengere under overgangen, end du er sikker på; begynd uden DMARC med p=none og rapporter.
• Ryd efter et par uger op i det gamle include, DKIM-records, verifikationsrecords og domænet i det gamle miljø.

Quiz

Opgave

Opgave A4.3: Dine mailposter i overblik. Indtast dit domæne og DKIM-selectoren fra din (nye) udbyder. Programmet kontrollerer, om MX'en peger mod din udbyder, om der findes præcis ét SPF-record, om DKIM-nøglen findes på den selector, og om der findes præcis ét DMARC-record. Det måler også TTL'en for din MX hos den autoritative nameserver: ved et planlagt skifte skal den være 3600 eller lavere.

Opgave E4.3: Dit skiftescript. Skriv driftsplanen for dit eget domæne, som beskrevet i denne lektion: for hvert trin datoen og tidspunktet, records før og efter (gammel og ny SPF som én linje), hvem der gør det, og hvad du kontrollerer efter hvert trin.

Videre læsning

Trinene i disse artikler gælder for WebOkés tjenester; hos andre udbydere fungerer det på tilsvarende vis.

• WebOké vejledning 6.7: Kortet Opsæt e-mail (MX, SPF, DKIM, DMARC)
• WebOké vejledning 5.6: Opsæt e-mail hurtigt i DNS
• WebOké vejledning 5.7: DNS gendannelse og oprettelse af DNS-backup
• DirectAdmin vejledning 10.4: Efter flytningen: MX-poster og dine enheder
• Gratis DNS-kursus 4.3: SPF: hvem må sende mail på vegne af dit domæne?
• Gratis DNS-kursus 4.4: DKIM: underskriften under din mail
• Gratis DNS-kursus 4.5: DMARC: hvad modtagere skal gøre med falsk mail
• Gratis DNS-kursus 6.3: DNS ved en flytning
• RFC 7208 (SPF), RFC 6376 (DKIM), RFC 9989 (DMARC), RFC 6186 (SRV-records til mailprogrammer)