Bytet i DNS: MX, SPF, DKIM och DMARC

Modul 4: Flytta e-post · Lästid: 12 minuter

Lärandemål: Efter den här lektionen kan du planera och genomföra DNS-bytet för e-post i rätt ordning, så att ingen post går förlorad, din utgående post inte hamnar i skräpposten och Outlook inte i smyg fortsätter att knacka på hos den gamla leverantören.

Nyckelbegrepp: TTL, MX-byte, SPF (en post), DKIM-selector, DMARC (p=none, rua), autodiscover, autoconfig, verifieringspost, accepterad domän

Fem poster, ett ögonblick

För e-post på din egen domän finns det några poster i DNS som tillsammans avgör om posten kommer fram och om din post litas på:

Vid en flytt ändras nästan allt detta. Konsten ligger i ordningen. Byter du MX medan SPF och DKIM fortfarande bara gäller för Microsoft, kommer din post fram, men posten du skickar hamnar i skräpposten. Byter du SPF först, kan Microsoft inte längre skicka korrekt för din räkning under dagarna innan.

Den här lektionen handlar om ordningen. Hur varje post exakt är uppbyggd läser du i DNS-kursen (lektion 4.1 till 4.5).

Steg 1, två dagar innan: sänk TTL och ta backup

Varje DNS-post har en TTL (time to live): hur länge andra servrar får komma ihåg svaret. Står TTL för din MX på 86400 sekunder (ett dygn), fortsätter vissa servrar att skicka till den gamla servern i upp till ett dygn efter bytet.

Sänk därför minst en gammal TTL i förväg, TTL:en för MX, SPF och autodiscover, till 300 eller 3600 sekunder. Vid en TTL på ett dygn gör du det alltså minst ett dygn i förväg; två dagar är gott om tid. Ta samtidigt en backup av din DNS-zon, eller skriv upp alla nuvarande poster. Då kan du alltid gå tillbaka.

Bageriet Gryn 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 är redan 3600 (en timme). De sätter MX och SPF till 300.

Steg 2, före bytet: förbered DKIM och SPF för den nya leverantören

Poster som inte förstör något sätter du dit redan i förväg:

• DKIM från den nya leverantören. Den nya leverantören anger en selector och en nyckel, till exempel x._domainkey med en TXT-post v=DKIM1; k=rsa; p=.... Eftersom selectorn heter något annat än Microsofts (selector1 och selector2), finns de lugnt sida vid sida. Varje mottagare tittar bara på den selector som anges i mejlets signatur.
• Utöka SPF, ersätt inte. Det får bara finnas en SPF-post. Lägg till den nya leverantören i samma post, så att båda får skicka under övergångsdagarna:

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

Bageriet hade -all. Under övergången väljer de tillfälligt ~all (softfail): saknas ändå en server betraktas posten snarare som misstänkt än att den nekas. Det följer tumregeln: ~all om du inte är helt säker, -all när du vet säkert att alla avsändare finns med.

Glöm inte de andra avsändarna från din lista i lektion 4.1: webbutiken, nyhetsbrevstjänsten, bokföringen. De ska finnas kvar i SPF-posten.

Steg 3, bytesögonblicket: MX och autodiscover

Vid det överenskomna ögonblicket, efter att den första kopian av brevlådorna är klar (lektion 4.2):

1. Ersätt MX-posterna med den nya leverantörens. Ta bort den gamla MX, låt den inte stå kvar som "reserv" med en högre prioritet, för då kommer post in hos den gamla leverantören så fort den nya är lite långsam.
2. Justera autodiscover. Outlook söker sina inställningar via autodiscover.example.com. Pekar det fortfarande på autodiscover.outlook.com, fortsätter Outlook försöka logga in hos Microsoft, även om du lägger till ett nytt konto. Ta bort det eller låt det peka dit din nya leverantör anger. Vissa leverantörer använder istället autoconfig.example.com (Thunderbird) eller SRV-poster som _imaps._tcp och _submission._tcp (RFC 6186).
3. Kör en andra kopia av brevlådorna, så att posten från de senaste timmarna följer med.

Det finns en överraskning hos Microsoft 365 som tar många på sängen. Så länge example.com står som accepterad domän i Microsoft 365-miljön, levererar Microsoft post mellan användare i samma miljö internt, utan att titta på MX. Mejlar en kollega som fortfarande arbetar i Outlook hos Microsoft till en annan kollega, hamnar posten i den gamla brevlådan. Byt därför alla medarbetare samma dag, och ta bort domänen från Microsoft-miljön efter övergångsperioden.

Steg 4, DMARC: läs med under övergången

DMARC talar om för mottagare vad de ska göra om ett mejl inte klarar SPF eller DKIM, och skickar rapporter till dig. Bageriet hade p=quarantine. Det är bra, men farligt under ett byte: fungerar inte DKIM hos den nya leverantören ännu, hamnar deras egen post hos kunder i skräpposten.

Det säkra tillvägagångssättet:

• Har du ingen DMARC ännu, börja med p=none och en rua-adress. Då händer inget med din post, men du får rapporter.
• Har du redan quarantine eller reject, kontrollera innan bytet med ett testmejl att DKIM från den nya leverantören fungerar (sidhuvudet på ett mottaget mejl visar dkim=pass med d=example.com). Är du osäker, sätt tillfälligt p=none och läs rapporterna i några veckor.
• Skärp sedan steg för steg: none, sedan quarantine, sedan eventuellt reject. Enligt den nya DMARC-standarden (RFC 9989) kan du under testfasen också använda t=y; den gamla taggen pct utgår.

Steg 5, efter några veckor: städa upp

Fungerar allt bra efter några veckor, städar du upp de gamla posterna:

• den gamla include i SPF (och eventuellt tillbaka till -all);
• de gamla DKIM-posterna (selector1 och selector2);
• verifieringsposten MS=ms... och eventuella andra poster för Microsoft, som enterpriseregistration och lyncdiscover om du hade sådana;
• TTL:en tillbaka till ett vanligt värde, till exempel 3600;
• domänen ur den gamla Microsoft- eller Google-miljön.

Låter du den gamla include finnas kvar, får den gamla leverantören fortsätta skicka post för din domäns räkning i åratal framöver. Det är en öppen dörr.

I praktiken: så ser det ut hos en leverantör

I Mitt WebOké finns på fliken DNS kortet E-postinställningar. Det visar MX, SPF och DMARC med en färgad prick, och uppe till höger vilken e-postleverantör som känns igen utifrån din MX. Med Snabbinställning sätter du alla poster för en leverantör på en gång, och det gula meddelandet varnar om att befintliga MX- och SPF-poster ersätts. Ta därför först en DNS-backup och kontrollera sedan om SPF-posten fortfarande innehåller dina andra avsändare. På produktsidan för ett webbhotellpaket finns kortet Ange e-post, som för varje post visar om den är Korrekt, Observera, Felaktig eller Hittades inte, och ger värdet med en kopieringsknapp. Ligger DNS hos en annan part, för du över de värdena där. Andra leverantörer och DNS-paneler har liknande översikter; posterna i sig är desamma överallt.

Sammanfattning

• Sänk TTL:en minst en gammal TTL i förväg och ta en backup av din DNS-zon.
• Förbered DKIM från den nya leverantören och en utökad SPF-post (en post, båda leverantörerna) redan innan bytet.
• Byt MX och autodiscover samtidigt, och byt alla medarbetare samma dag; annars levererar Microsoft intern post fortfarande till de gamla brevlådorna.
• Sätt inte DMARC strängare under övergången än vad du vet säkert; har du ingen DMARC, börja med p=none och rapporter.
• Städa efter några veckor bort den gamla include, DKIM-posterna, verifieringsposterna och domänen i den gamla miljön.

Quiz

Uppgift

Uppgift A4.3: Dina e-postposter i översikt. Fyll i din domän, och DKIM-selectorn från din (nya) leverantör. Programmet kontrollerar om MX pekar på din leverantör, om det finns exakt en SPF-post, om DKIM-nyckeln finns på den selectorn och om det finns exakt en DMARC-post. Det mäter också TTL:en för din MX hos den auktoritativa namnservern: för ett planerat byte ska den vara 3600 eller lägre.

Uppgift E4.3: Din växlingsplan. Skriv ner draaiboken från den här lektionen för din egen domän: för varje steg datum och tid, posterna före och efter (gammal och ny SPF som en rad), vem som gör det, och vad du kontrollerar efter varje steg.

Läs mer

Stegen i dessa artiklar gäller för WebOkés tjänster; hos andra leverantörer fungerar det på liknande sätt.

• WebOké manual 6.7: Kortet Ställ in e-post (MX, SPF, DKIM, DMARC)
• WebOké manual 5.6: Ställ in e-post snabbt i DNS
• WebOké manual 5.7: Återställa DNS och skapa en DNS-backup
• DirectAdmin-guide 10.4: Efter flytten: MX-poster och dina enheter
• Gratis DNS-kurs 4.3: SPF: vem får skicka e-post i din domäns namn?
• Gratis DNS-kurs 4.4: DKIM: signaturen under din e-post
• Gratis DNS-kurs 4.5: DMARC: vad mottagare ska göra med falsk e-post
• Gratis DNS-kurs 6.3: DNS vid en flytt
• RFC 7208 (SPF), RFC 6376 (DKIM), RFC 9989 (DMARC), RFC 6186 (SRV-poster för e-postprogram)