Преходът в DNS: MX, SPF, DKIM и DMARC

Модул 4: Преместване на имейл · Време за четене: 12 минути

Учебна цел: След този урок ще можете да планирате и изпълните смяната на DNS записите за имейл в правилната последователност, така че да не се губи поща, изходящата Ви поща да не попада в спам и Outlook да не продължава тайно да се свързва със стария доставчик.

Основни понятия: TTL, смяна на MX, SPF (един запис), DKIM селектор, DMARC (p=none, rua), autodiscover, autoconfig, верификационен запис, приет домейн (accepted domain)

Пет записа, един момент

За имейл на собствен домейн в DNS има няколко записа, които заедно определят дали пощата пристига и дали на Вашата поща се има доверие:

При преместване се променя почти всичко от изброеното. Изкуството е в последователността. Ако смените MX, докато SPF и DKIM все още важат само за Microsoft, пощата ще пристига, но изпратената от Вас поща ще попада в спам. Ако смените първо SPF, Microsoft вече няма да може да изпраща правилно от Ваше име през дните преди прехода.

Този урок разглежда последователността. Как точно е устроен всеки запис, можете да прочетете в курса по DNS (уроци 4.1 до 4.5).

Стъпка 1, два дни предварително: намаляване на TTL и резервно копие

Всеки DNS запис има TTL (time to live): колко дълго други сървъри могат да запомнят отговора. Ако TTL на Вашия MX е 86400 секунди (едно денонощие), някои сървъри ще продължат да изпращат към стария сървър до едно денонощие след смяната.

Затова намалете предварително, най-малко с продължителността на стария TTL, стойността на TTL за MX, SPF и autodiscover на 300 или 3600 секунди. При TTL от едно денонощие това правите най-малко едно денонощие предварително; два дена е достатъчен запас. Едновременно с това направете резервно копие на Вашата DNS зона или запишете всички текущи записи. Така винаги можете да се върнете назад.

Bakkerij De Korrel вижда:

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 вече е 3600 (един час). Те задават MX и SPF на 300.

Стъпка 2, преди смяната: подготовка на DKIM и SPF за новия доставчик

Записи, които не могат да повредят нищо, подготвяте предварително:

• DKIM на новия доставчик. Новият доставчик дава селектор и ключ, например x._domainkey с TXT запис v=DKIM1; k=rsa; p=.... Тъй като селекторът се казва различно от този на Microsoft (selector1 и selector2), двата могат спокойно да съществуват едновременно. Всеки получател гледа само селектора, посочен в подписа на писмото.
• Разширете SPF, не го заменяйте. Може да има само един SPF запис. Добавете новия доставчик в същия запис, така че през дните на прехода и двамата да имат право да изпращат:

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

Пекарната е имала -all. По време на прехода временно избират ~all (softfail): ако все пак липсва сървър, писмото по скоро ще бъде отбелязано като подозрително, отколкото отхвърлено. Това следва правилото: ~all, когато не сте напълно сигурни, -all, когато сте сигурни, че всички изпращачи са включени.

Не забравяйте другите изпращачи от Вашия списък от урок 4.1: онлайн магазина, услугата за бюлетини, счетоводството. Те остават в SPF записа.

Стъпка 3, моментът на смяната: MX и autodiscover

В уговорения момент, след като е готово първото копие на пощенските кутии (урок 4.2):

1. Заменете MX записите с тези на новия доставчик. Премахнете стария MX; не го оставяйте като "резерва" с по-висок приоритет, защото тогава поща ще пристига при стария доставчик, щом новият забави за момент.
2. Коригирайте autodiscover. Outlook търси настройките си чрез autodiscover.example.com. Ако това все още сочи към autodiscover.outlook.com, Outlook ще продължи да се опитва да влезе при Microsoft, дори при добавяне на нов акаунт. Премахнете записа или го насочете към това, което посочва новият доставчик. Някои доставчици използват вместо това autoconfig.example.com (Thunderbird) или SRV записи като _imaps._tcp и _submission._tcp (RFC 6186).
3. Направете второ копие на пощенските кутии, така че пощата от последните часове да бъде включена.

При Microsoft 365 има една изненада, която изненадва мнозина. Докато example.com е зададен в средата на Microsoft 365 като приет домейн (accepted domain), Microsoft доставя поща между потребители от същата среда вътрешно, без да проверява MX записа. Ако колега, който все още работи в Outlook при Microsoft, изпрати поща до друг колега, тя ще пристигне в старата пощенска кутия. Затова сменяте всички служители в един и същ ден и премахвате домейна от средата на Microsoft след края на преходния период.

Стъпка 4, DMARC: наблюдение по време на прехода

DMARC указва на получателите какво да правят, ако писмо не премине проверката на SPF или DKIM, и изпраща доклади. Пекарната е имала p=quarantine. Това е добре, но по време на смяна е рисковано: ако DKIM при новия доставчик все още не е активиран, собствената им поща ще попада в спам при клиентите.

Безопасният подход:

• Ако все още нямате DMARC, започнете с p=none и адрес за rua. Тогава с Вашата поща не се прави нищо, но получавате доклади.
• Ако вече имате quarantine или reject, проверете преди смяната с тестово писмо дали DKIM на новия доставчик работи (заглавната част на получено писмо показва dkim=pass с d=example.com). При съмнение временно задайте p=none и наблюдавайте докладите няколко седмици.
• След това затягайте настройките постепенно: none, после quarantine, после евентуално reject. Според новия стандарт на DMARC (RFC 9989) във фазата на тестване можете да използвате и t=y; старата отметка pct отпада.

Стъпка 5, след няколко седмици: почистване

Ако всичко работи добре няколко седмици, почистете старите записи:

• старото include от SPF (и евентуално връщане към -all);
• старите DKIM записи (selector1 и selector2);
• верификационния запис MS=ms... и евентуални други записи за Microsoft, като enterpriseregistration и lyncdiscover, ако сте ги имали;
• връщане на TTL към обичайна стойност, например 3600;
• премахване на домейна от старата среда на Microsoft или Google.

Ако оставите старото include, старият доставчик ще може да изпраща поща от името на Вашия домейн още с години. Това е отворена врата.

На практика: така изглежда при доставчик

В Моят WebOké, в раздела DNS, има карта Настройки на имейл. Тя показва MX, SPF и DMARC с цветна точка, а в горния десен ъгъл, кой имейл доставчик разпознава по Вашия MX запис. С Бързо настройване задавате наведнъж записите за даден доставчик, а жълтото съобщение предупреждава, че съществуващите MX и SPF записи ще бъдат заменени. Затова първо направете резервно копие на DNS и след това проверете дали SPF записът все още съдържа другите Ви изпращачи. На страницата на хостинг пакета има карта Настройка на имейл, която за всеки запис показва дали е Правилен, Внимание, Грешен или Не е намерен, и дава стойността с бутон за копиране. Ако DNS се управлява от друга страна, пренасяте тези стойности там. Други доставчици и DNS панели имат подобни прегледи; самите записи са едни и същи навсякъде.

Обобщение

• Намалете TTL най-малко с продължителността на стария TTL предварително и направете резервно копие на Вашата DNS зона.
• Подгответе DKIM на новия доставчик и разширен SPF запис (един запис, и двамата доставчици) още преди смяната.
• Сменете MX и autodiscover едновременно и сменете всички служители в един и същи ден; иначе Microsoft продължава да доставя вътрешна поща в старите пощенски кутии.
• По време на прехода не задавайте DMARC по строго, отколкото сте сигурни; ако нямате DMARC, започнете с p=none и доклади.
• След няколко седмици почистете старото include, DKIM записите, верификационните записи и домейна в старата среда.

Тест

Задача

Задача A4.3: Вашите пощенски записи накратко. Въведете Вашия домейн и DKIM селектора на Вашия (нов) доставчик. Програмата проверява дали MX сочи към Вашия доставчик, дали има точно един SPF запис, дали DKIM ключът е зададен на този селектор и дали има точно един DMARC запис. Измерва се също TTL на Вашия MX при оторизирания name сървър: за планирана смяна той трябва да е 3600 или по-нисък.

Задача E4.3: Вашият сценарий за прехода. Напишете за Вашия собствен домейн сценария от този урок: за всяка стъпка датата и часа, записите преди и след (старото и новото SPF като един ред), кой я извършва и какво проверявате след всяка стъпка.

Продължете с четенето

Стъпките в тези статии важат за услугите на WebOké; при други доставчици процесът е подобен.

• Ръководство на WebOké 6.7: Картата Настройване на имейл (MX, SPF, DKIM, DMARC)
• Ръководство на WebOké 5.6: Бързо настройване на имейл в DNS
• Ръководство на WebOké 5.7: Връщане на DNS и създаване на резервно копие на DNS
• Ръководство за DirectAdmin 10.4: След преместването: MX записи и Вашите устройства
• Безплатен курс по DNS 4.3: SPF: кой може да изпраща имейли от името на Вашия домейн?
• Безплатен курс по DNS 4.4: DKIM: цифровият подпис под Вашата поща
• Безплатен курс по DNS 4.5: DMARC: какво трябва да правят получателите с фалшива поща
• Безплатен курс по DNS 6.3: DNS при трансфер
• RFC 7208 (SPF), RFC 6376 (DKIM), RFC 9989 (DMARC), RFC 6186 (SRV записи за пощенски програми)