Az átállás a DNS-ben: MX, SPF, DKIM és DMARC

Modul 4: Az e-mail átköltöztetése · Olvasási idő: 12 perc

Tanulási cél: E lecke után Ön képes lesz a megfelelő sorrendben megtervezni és végrehajtani az e-mailhez tartozó DNS-váltást, úgy, hogy ne vesszen el levél, a kimenő posta ne kerüljön spambe, és az Outlook ne próbáljon titokban továbbra is a régi szolgáltatóhoz kapcsolódni.

Kulcsfogalmak: TTL, MX-váltás, SPF (egyetlen rekord), DKIM-szelektor, DMARC (p=none, rua), autodiscover, autoconfig, hitelesítő rekord, elfogadott domain

Öt rekord, egyetlen pillanat

A saját domainen futó e-mailhez néhány rekord tartozik a DNS-ben, amelyek együtt határozzák meg, hogy a levelek megérkeznek-e, és hogy az Ön levelei megbízhatónak számítanak-e:

Egy költözés során szinte minden megváltozik ezek közül. A lényeg a sorrend. Ha átállítja az MX-et, miközben az SPF és a DKIM még csak a Microsoftra vonatkozik, a levelei megérkeznek, de a kimenő levelei spambe kerülnek. Ha előbb az SPF-et állítja át, a Microsoft az azt megelőző napokban már nem tud rendesen levelet küldeni az Ön nevében.

Ez a lecke a sorrendről szól. Hogy az egyes rekordok pontosan hogyan épülnek fel, azt a DNS-tanfolyamon olvashatja (4.1-től 4.5-ig terjedő leckék).

1. lépés, két nappal előtte: TTL csökkentése és biztonsági mentés

Minden DNS-rekordnak van egy TTL-je (time to live): meddig jegyezhetik meg a választ más szerverek. Ha az MX TTL-je 86400 másodpercre (egy napra) van állítva, akkor a váltás után egyes szerverek akár egy napig még a régi szerverhez küldhetik a leveleket.

Ezért csökkentse előre, legalább egy régi TTL-lel korábban, az MX, az SPF és az autodiscover TTL-jét 300 vagy 3600 másodpercre. Ha a TTL egy nap, akkor ezt legalább egy nappal korábban tegye meg; két nap bőséges időt ad. Ezzel egyidejűleg készítsen biztonsági mentést a DNS-zónáról, vagy írja fel az összes jelenlegi rekordot. Így mindig vissza tud térni.

A Bakkerij De Korrel a következőt látja:

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"

A TTL már 3600 (egy óra). Az MX-et és az SPF-et 300-ra állítják.

2. lépés, a váltás előtt: a DKIM és az SPF előkészítése az új szolgáltatóhoz

Azokat a rekordokat, amelyek semmit nem rontanak el, már előre beállíthatja:

• Az új szolgáltató DKIM-je. Az új szolgáltató ad egy szelektort és egy kulcsot, például x._domainkey néven, egy TXT-rekorddal: v=DKIM1; k=rsa; p=.... Mivel a szelektor neve eltér a Microsoftétól (selector1 és selector2), nyugodtan egymás mellett létezhetnek. Minden címzett csak azt a szelektort nézi, amely a levél aláírásában szerepel.
• Bővítse az SPF-et, ne cserélje le. Csak egyetlen SPF-rekord lehet. Adja hozzá az új szolgáltatót ugyanahhoz a rekordhoz, hogy az átmeneti napokban mindkettő küldhessen levelet:

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

A pékségnek -all volt beállítva. Az átmenet idejére ideiglenesen ~all-ra (softfail) váltanak: ha mégis hiányzik egy szerver, a levelet inkább gyanúsnak tekintik, mint elutasítják. Ez követi az ökölszabályt: ~all, ha nem teljesen biztos a dolgában, -all, ha biztosan tudja, hogy minden küldő szerepel a listán.

Ne feledkezzen meg a 4.1 leckében összeállított listájának többi küldőjéről sem: a webáruház, a hírlevélszolgáltató, a könyvelés. Ezek maradnak az SPF-rekordban.

3. lépés, a váltás pillanata: MX és autodiscover

A megbeszélt időpontban, miután a postafiókok első másolata elkészült (4.2 lecke):

1. Cserélje le az MX-rekordokat az új szolgáltatóéra. Távolítsa el a régi MX-et; ne hagyja meg "tartalékként" magasabb prioritással, mert akkor a levelek a régi szolgáltatóhoz érkeznek, amint az új egy kicsit lassabb.
2. Állítsa át az autodiscovert. Az Outlook a beállításait a autodiscover.example.com címen keresi. Ha ez még mindig a autodiscover.outlook.com felé mutat, az Outlook továbbra is megpróbál a Microsofthoz bejelentkezni, akkor is, ha új fiókot ad hozzá. Távolítsa el, vagy állítsa be úgy, hogy az új szolgáltató által megadott címre mutasson. Egyes szolgáltatók ehelyett a autoconfig.example.com (Thunderbird) címet vagy SRV-rekordokat használnak, mint a _imaps._tcp és _submission._tcp (RFC 6186).
3. Készítsen egy második másolatot a postafiókokról, hogy az utolsó órák levelei is átkerüljenek.

A Microsoft 365-nél van egy meglepetés, ami sok embert váratlanul ér. Amíg az example.com a Microsoft 365-környezetben elfogadott domainként szerepel, a Microsoft a saját környezetén belüli felhasználók között belsőleg kézbesíti a leveleket, anélkül hogy az MX-et megnézné. Ha egy kolléga, aki még a Microsoftnál lévő Outlookban dolgozik, levelet küld egy másik kollégának, az a levél a régi postafiókba kerül. Ezért állítsa át az összes munkatársat ugyanazon a napon, és az átmeneti időszak után távolítsa el a domaint a Microsoft-környezetből.

4. lépés, DMARC: figyelés az átmenet alatt

A DMARC megmondja a címzetteknek, mit tegyenek, ha egy levél nem felel meg az SPF-nek vagy a DKIM-nek, és jelentéseket küld Önnek. A pékségnek p=quarantine volt beállítva. Ez önmagában jó, de egy váltás során veszélyes: ha a DKIM még nincs bekapcsolva az új szolgáltatónál, a saját leveleik az ügyfeleknél spambe kerülnek.

A biztonságos megközelítés:

• Ha még nincs DMARC-ja, kezdje p=none-nal és egy rua címmel. Ekkor semmi nem történik a leveleivel, de jelentéseket kap.
• Ha már quarantine vagy reject van beállítva, a váltás előtt egy teszt üzenettel ellenőrizze, hogy az új szolgáltató DKIM-je működik (a beérkezett levél fejlécében dkim=pass szerepel d=example.com mellett). Ha kétségei vannak, állítsa ideiglenesen p=none-ra, és olvassa el a jelentéseket néhány héten keresztül.
• Ezután fokozatosan szigorítson: none, majd quarantine, majd esetleg reject. Az új DMARC-szabvány szerint (RFC 9989) a tesztfázisban a t=y jelölést is használhatja; a régi pct címke megszűnik.

5. lépés, néhány hét után: rendrakás

Ha néhány héten keresztül minden rendben működik, takarítsa el a régi rekordokat:

• a régi include-ot az SPF-ből (és esetleg térjen vissza a -all-ra);
• a régi DKIM-rekordokat (selector1 és selector2);
• a hitelesítő rekordot (MS=ms...) és az esetleges egyéb Microsoft-rekordokat, mint az enterpriseregistration és a lyncdiscover, ha ezek megvoltak;
• a TTL-t állítsa vissza szokásos értékre, például 3600-ra;
• a domaint a régi Microsoft- vagy Google-környezetből.

Ha meghagyja a régi include-ot, a régi szolgáltató még évekig küldhet levelet az Ön domainje nevében. Ez egy nyitva hagyott ajtó.

A gyakorlatban: így néz ki ez egy szolgáltatónál

A Fiókom felületen a DNS fülön található az E-mail-beállítások kártya. Ez megmutatja az MX, SPF és DMARC állapotát egy színes ponttal, jobb fent pedig azt, hogy mely levelezőszolgáltatót ismeri fel az MX alapján. A Gyors beállítás funkcióval egyszerre állíthatja be egy szolgáltató rekordjait, és a sárga figyelmeztetés jelzi, hogy a meglévő MX- és SPF-rekordok lecserélődnek. Ezért először készítsen DNS biztonsági mentést, és utána ellenőrizze, hogy az SPF-rekord még tartalmazza-e az összes többi küldőt. A tárhelycsomag termékoldalán található az E-mail cím megadása kártya, amely rekordonként megmutatja, hogy az Helyes, Figyelem, Hibás vagy Nem található állapotú-e, és az értéket egy másolás gombbal adja meg. Ha a DNS egy másik szolgáltatónál van, onnan vegye át az értékeket. Más szolgáltatóknak és DNS-panelnek hasonló áttekintése van; maguk a rekordok mindenhol ugyanazok.

Összefoglalás

• Csökkentse a TTL-t legalább egy régi TTL-lel korábban, és készítsen biztonsági mentést a DNS-zónáról.
• Állítsa be az új szolgáltató DKIM-jét és egy kibővített SPF-rekordot (egyetlen rekord, mindkét szolgáltatóval) már a váltás előtt.
• Az MX-et és az autodiscovert egyszerre váltsa, és minden munkatársat ugyanazon a napon állítson át; különben a Microsoft a belső leveleket továbbra is a régi postafiókokba kézbesíti.
• Az átmenet alatt ne állítsa a DMARC-ot szigorúbbra, mint amit biztosan tud; ha nincs DMARC-ja, kezdje p=none-nal és jelentésekkel.
• Néhány hét után takarítsa el a régi include-ot, a DKIM-rekordokat, a hitelesítő rekordokat és a domaint a régi környezetből.

Kvíz

Feladat

A4.3 feladat: Az Ön mailrekordjai áttekintve. Adja meg a domainjét és az (új) szolgáltatójának DKIM-szelektorát. A program ellenőrzi, hogy az MX a szolgáltatóhoz mutat-e, hogy pontosan egy SPF-rekord van-e, hogy a DKIM-kulcs megtalálható-e azon a szelektoron, és hogy pontosan egy DMARC-rekord van-e. Megméri az MX TTL-jét is az illetékes névkiszolgálónál: egy tervezett váltáshoz ennek 3600-nak vagy annál alacsonyabbnak kell lennie.

E4.3 feladat: Az átállási forgatókönyve. Írja meg a saját domainjéhez az e leckében szereplő forgatókönyvet: lépésenként a dátumot és időpontot, a rekordokat előtte és utána (régi és új SPF egy sorban), ki végzi el, és mit ellenőriz minden lépés után.

További olvasnivaló

Az ebben a cikkben szereplő lépések a WebOké szolgáltatásaira vonatkoznak; más szolgáltatóknál hasonlóan működik.

• WebOké útmutató 6.7: Az E-mail beállítása kártya (MX, SPF, DKIM, DMARC)
• WebOké útmutató 5.6: E-mail gyors beállítása a DNS-ben
• WebOké útmutató 5.7: DNS visszaállítása és DNS-mentés készítése
• DirectAdmin útmutató 10.4: A költözés után: MX-rekordok és az eszközei
• Ingyenes DNS-tanfolyam 4.3: SPF: ki küldhet levelet a domainje nevében?
• Ingyenes DNS-tanfolyam 4.4: DKIM: az aláírás a leveled alatt
• Ingyenes DNS-tanfolyam 4.5: DMARC: mit kell tenniük a címzetteknek a hamis levelekkel
• Ingyenes DNS-tanfolyam 6.3: DNS egy költözésnél
• RFC 7208 (SPF), RFC 6376 (DKIM), RFC 9989 (DMARC), RFC 6186 (SRV-rekordok levelezőprogramokhoz)