Overgangen i DNS: MX, SPF, DKIM og DMARC

Modul 4: Flytte e-post · Lesetid: 12 minutter

Læringsmål: Etter denne leksjonen kan du planlegge og gjennomføre DNS-overgangen for e-post i riktig rekkefølge, slik at det ikke går tapt e-post, utgående e-post ikke havner i spam, og Outlook ikke i hemmelighet fortsetter å banke på hos den gamle leverandøren.

Kjernebegreper: TTL, MX-bytte, SPF (ett record), DKIM-selector, DMARC (p=none, rua), autodiscover, autoconfig, verifikasjonsrecord, akseptert domene

Fem records, ett tidspunkt

For e-post på ditt eget domene finnes det noen records i DNS som sammen avgjør om e-posten kommer frem og om e-posten din blir stolt på:

Ved en flytting endrer nesten alt dette seg. Kunsten ligger i rekkefølgen. Bytter du MX mens SPF og DKIM fortsatt bare gjelder for Microsoft, kommer e-posten inn, men e-posten du sender ut havner i spam. Bytter du SPF først, kan Microsoft ikke lenger sende e-post riktig på dine vegne i dagene før.

Denne leksjonen handler om rekkefølgen. Hvordan hvert enkelt record er bygget opp i detalj, kan du lese i DNS-kurset (leksjon 4.1 til 4.5).

Steg 1, to dager i forveien: TTL ned og sikkerhetskopi

Hvert DNS-record har en TTL (time to live): hvor lenge andre servere har lov til å huske svaret. Står TTL-en til MX-en din på 86400 sekunder (ett døgn), fortsetter enkelte servere å sende til den gamle serveren i opptil et døgn etter byttet.

Senk derfor minst én gammel TTL i forveien, TTL-en til MX, SPF og autodiscover, til 300 eller 3600 sekunder. Ved en TTL på et døgn gjør du dette minst et døgn i forveien; to dager er romslig. Lag samtidig en sikkerhetskopi av DNS-sonen din, eller skriv ned alle nåværende records. Da kan du alltid gå tilbake.

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 setter MX og SPF til 300.

Steg 2, før byttet: gjøre klar DKIM og SPF for den nye leverandøren

Records som ikke ødelegger noe, setter du opp i forveien:

• DKIM fra den nye leverandøren. Den nye leverandøren oppgir en selector og en nøkkel, for eksempel x._domainkey med et TXT-record v=DKIM1; k=rsa; p=.... Siden selectoren har et annet navn enn hos Microsoft (selector1 og selector2), kan de trygt stå side om side. Hver mottaker ser kun på selectoren som står i signaturen til e-posten.
• Utvid SPF, ikke erstatt det. Det kan bare finnes ett SPF-record. Legg den nye leverandøren til i det samme recordet, slik at begge har lov til å sende i overgangsdagene:

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

Bakeriet hadde -all. Under overgangen velger de midlertidig ~all (softfail): mangler det likevel en server, blir e-posten heller sett på som mistenkelig enn avvist. Dette følger tommelfingerregelen: ~all når du ikke er helt sikker, -all når du vet sikkert at alle avsendere er med.

Ikke glem de andre avsenderne fra listen din i leksjon 4.1: nettbutikken, nyhetsbrevtjenesten, regnskapet. De blir stående i SPF-recordet.

Steg 3, byttetidspunktet: MX og autodiscover

På avtalt tidspunkt, etter at den første kopien av postboksene er klar (leksjon 4.2):

1. Erstatt MX-recordene med dem fra den nye leverandøren. Fjern den gamle MX-en; ikke la den stå som «reserve» med lavere prioritet, for da kommer det e-post inn hos den gamle leverandøren så snart den nye er litt treg.
2. Tilpass autodiscover. Outlook leter etter innstillingene sine via autodiscover.example.com. Peker det fortsatt til autodiscover.outlook.com, fortsetter Outlook å prøve å logge inn hos Microsoft, selv når du legger til en ny konto. Fjern det, eller la det peke dit den nye leverandøren din oppgir. Enkelte leverandører bruker i stedet autoconfig.example.com (Thunderbird) eller SRV-records som _imaps._tcp og _submission._tcp (RFC 6186).
3. Kjør en ny kopi av postboksene, slik at e-posten fra de siste timene blir med.

Det er en overraskelse hos Microsoft 365 som tar mange på senga. Så lenge example.com står som akseptert domene i Microsoft 365-miljøet, leverer Microsoft e-post mellom brukere i det samme miljøet internt, uten å se på MX-en. Sender en kollega som fortsatt jobber i Outlook hos Microsoft en e-post til en annen kollega, havner den e-posten i den gamle postboksen. Derfor bytter du om alle medarbeidere samme dag, og fjerner domenet fra Microsoft-miljøet etter overgangsperioden.

Steg 4, DMARC: lytte med under overgangen

DMARC forteller mottakere hva de skal gjøre hvis en e-post ikke består SPF eller DKIM, og den sender deg rapporter. Bakeriet hadde p=quarantine. Det er bra, men farlig under et bytte: er ikke DKIM hos den nye leverandøren aktivert ennå, havner deres egen e-post i spam hos kundene.

Den trygge fremgangsmåten:

• Har du ikke DMARC ennå, begynn da med p=none og en rua-adresse. Da skjer det ingenting med e-posten din, men du får rapporter.
• Har du allerede quarantine eller reject, kontroller da før byttet med en testmail at DKIM hos den nye leverandøren fungerer (topptekstene i en mottatt e-post viser dkim=pass med d=example.com). Er du i tvil, sett da midlertidig p=none og les rapportene i noen uker.
• Stram deretter til steg for steg: none, deretter quarantine, deretter eventuelt reject. Ifølge den nye DMARC-standarden (RFC 9989) kan du i testfasen også bruke t=y; den gamle taggen pct utgår.

Steg 5, etter noen uker: rydding

Fungerer alt bra i noen uker, rydder du opp i de gamle recordene:

• den gamle include-en fra SPF (og eventuelt tilbake til -all);
• de gamle DKIM-recordene (selector1 og selector2);
• verifikasjonsrecordet MS=ms... og eventuelle andre records for Microsoft, som enterpriseregistration og lyncdiscover hvis du hadde dem;
• TTL-en tilbake til en vanlig verdi, som 3600;
• domenet ut av det gamle Microsoft- eller Google-miljøet.

Lar du den gamle include-en stå, kan den gamle leverandøren fortsette å sende e-post på vegne av domenet ditt i mange år fremover. Det er en åpen dør.

I praksis: slik ser det ut hos en leverandør

I Min side står kortet E-postinnstillinger på fanen DNS. Det viser MX, SPF og DMARC med en farget prikk, og øverst til høyre hvilken e-postleverandør det gjenkjenner ut fra MX-en din. Med Hurtig oppsett setter du opp recordene for en leverandør i ett steg, og den gule meldingen varsler om at eksisterende MX- og SPF-records blir erstattet. Lag derfor først en DNS-sikkerhetskopi, og kontroller etterpå at SPF-recordet fortsatt inneholder de andre avsenderne dine. På produktsiden for en hostingpakke står kortet Sett opp e-post, som per record viser om det er Korrekt, Obs, Feil eller Ikke funnet, og gir verdien med en kopieringsknapp. Ligger DNS-en hos en annen aktør, overfører du de verdiene der. Andre leverandører og DNS-paneler har tilsvarende oversikter; selve recordene er like overalt.

Oppsummering

• Senk TTL-en minst én gammel TTL i forveien og lag en sikkerhetskopi av DNS-sonen din.
• Gjør klar DKIM fra den nye leverandøren og et utvidet SPF-record (ett record, begge leverandører) allerede før byttet.
• Bytt MX og autodiscover samtidig, og bytt om alle medarbeidere samme dag; ellers leverer Microsoft fortsatt intern e-post i de gamle postboksene.
• Ikke gjør DMARC strengere enn det du er sikker på under overgangen; begynn uten DMARC med p=none og rapporter.
• Rydd etter noen uker opp i den gamle include-en, DKIM-recordene, verifikasjonsrecordene og domenet i det gamle miljøet.

Quiz

Oppgave

Oppgave A4.3: Dine e-postposter samlet. Fyll inn domenet ditt, og DKIM-selectoren til din (nye) leverandør. Programmet kontrollerer om MX-en peker til leverandøren din, om det finnes nøyaktig ett SPF-record, om DKIM-nøkkelen står på den selectoren, og om det finnes nøyaktig ett DMARC-record. Det måler også TTL-en til MX-en din hos den autoritative navneserveren: for et planlagt bytte bør den være 3600 eller lavere.

Oppgave E4.3: Ditt overgangsmanus. Skriv overgangsmanuset fra denne leksjonen for ditt eget domene: per steg dato og klokkeslett, recordene før og etter (gammel og ny SPF som én linje), hvem som gjør det, og hva du kontrollerer etter hvert steg.

Les mer

Stegene i disse artiklene gjelder for tjenestene til WebOké; hos andre leverandører fungerer det på en tilsvarende måte.

• WebOké-veiledning 6.7: Kortet Sett opp e-post (MX, SPF, DKIM, DMARC)
• WebOké-veiledning 5.6: Sett opp e-post raskt i DNS
• WebOké-veiledning 5.7: Tilbakestille DNS og lage en DNS-sikkerhetskopi
• DirectAdmin-veiledning 10.4: Etter flyttingen: MX-poster og enhetene dine
• Gratis DNS-kurs 4.3: SPF: hvem kan sende e-post på vegne av domenet ditt?
• Gratis DNS-kurs 4.4: DKIM: signaturen under e-posten din
• Gratis DNS-kurs 4.5: DMARC: hva mottakere skal gjøre med falsk e-post
• Gratis DNS-kurs 6.3: DNS ved en flytting
• RFC 7208 (SPF), RFC 6376 (DKIM), RFC 9989 (DMARC), RFC 6186 (SRV-records for e-postprogrammer)