Електронна пошта: змішані DNS-записи — помилка, що вбиває доставку (і як виправити)

Що насправді означають «змішані DNS-записи» (і чому електронна пошта страждає першою)

«Змішані DNS-записи» — це не формальний термін з RFC. Це SRE-термін, який означає: дані DNS, що публікує ваш домен, внутрішньо несумісні, частково мігровані або по-різному видимі для різних резолверів. Іноді це трапляється під час перехо́ду. Іноді — бо хтось вставив налаштування двох постачальників в одну зону. Іноді — через внутрішні DNS-переопреділення, які виглядають «допоміжними» в офісі, але проходять зовнішні тести й провалюють зовнішні перевірки.

Електронна пошта ламається першою, бо маршрутизація та довіра в ній — це шар DNS-запитів, а не один запит. Веб-трафіку зазвичай достатньо A/AAAA і, можливо, CAA. Пошта потребує MX, потім A/AAAA для MX-цілей, додатково SPF TXT записи, DKIM TXT записи, DMARC TXT записи, зворотний DNS для підключаючого IP і все частіше MTA-STS або TLS-звітність. Помішайте будь-що з цього неправильно — і система все ще «якось працює», поки не натрапите на великого провайдера, який суворо перевіряє саме ту частину, яку ви зіпсували.

Три найпоширеніші шаблони «змішаних записів»

• Розділена маршрутизація: одночасно присутні MX-хости від різних провайдерів (або старі MX плюс нові), через що вхідна пошта іноді потрапляє не туди.
• Розділена авторизація: SPF дозволяє Постачальнику A, але насправді ви відправляєте через Постачальника B (або власний MTA). Або SPF синтаксично валідний, але логічно зламаний (занадто багато DNS-запитів, неправильні квантифікатори).
• Розділена ідентичність: DKIM-ключі для однієї платформи, DMARC-політика очікує вирівнювання, якого ваш фактичний From/Return-Path не забезпечує. Все «відправляється», але доставлення падає.

Ще один шаблон заслуговує на особливу згадку: split horizon DNS — коли внутрішні резолвери повертають інші відповіді, ніж публічний DNS. Це чудово для внутрішніх сервісів. Це — катастрофа для пошти, якщо ви не дисципліновані, бо потоки пошти за визначенням перетинають межі.

Жарт №1: Пропагування DNS — єдине місце, де «eventual consistency» означає «згодом ваш пейджер задзвонить».

Плейбук швидкої діагностики (перевірити спочатку / потім / в кінці)

Це високосигнальний робочий порядок, коли доставлення не працює і потрібно швидко знайти вузьке місце. Не відкривайте спочатку дашборди постачальників. Почніть з публічної істини.

Спочатку: чи детерміновано вхідна маршрутизація?

1. Перевірте MX-записи з кількох резолверів (ваш резолвер, публічний і авторитетні імена серверів).
2. Резольвіть A/AAAA для кожної MX-цілі — переконайтеся, що вони існують, не вказують на виведені з експлуатації IP і не є CNAME-ланцюгами в нікуди.
3. Шукайте «змішаних провайдерів»: старі MX все ще присутні, неправильні пріоритети або кореневий MX вказує на хост, який більше не існує.

По-друге: чи ви провалюєте автентифікацію так, що це призводить до відхилень?

1. Перевірте синтаксис SPF і кількість DNS-запитів. Якщо бачите permerror, вважайте його зламаним.
2. Підтвердіть, що DKIM-селектори опубліковані і відповідають тим, які використовує ваш відправник.
3. Перевірте, чи існує DMARC, чи має він розумну політику і чи не вказує на нісенітні адреси звітів.

Впо-третє: чи підключаючий IP виглядає легітимним?

1. Перевірте PTR (зворотний DNS) для ваших вихідних IP.
2. Переконайтеся у forward-confirmed reverse DNS (FCrDNS): PTR-хостнейм резольвиться назад в той же IP.
3. Перевірте, чи ваш вихідний IP несподівано не надходить з нової адресної підмережі (корисна зміна мережі, NAT або новий SaaS-ретранслятор).

Правило рішення

Якщо вхід неправильно маршрутується: спочатку виправте MX. Якщо вхід ок, але ви потрапляєте в спам або отримуєте відхилення від великих провайдерів: виправте вирівнювання SPF/DKIM/DMARC і ідентичність IP (PTR/HELO). Не полірте DMARC, поки MX все ще відправляє половину вашої пошти на закинутий поштовий ящик попереднього провайдера.

Факти та історичний контекст, які варто знати

• MX-записи замінили маршрутизацію пошти по A-запису на ранніх етапах історії DNS, бо «просто підключатися до домену» не масштабувалося для кількох поштових хостів і шаблонів відмовостійкості.
• TXT-записи стали сміттєвим ящиком DNS частково тому, що вони широко підтримувалися і були гнучкими; SPF спочатку мав власний тип RR, але TXT переміг на практиці.
• Ліміт у 10 DNS-запитів для SPF існує тому, що приймачі мають оцінювати його під час SMTP, і нестримна рекурсія була б подарунком для DoS.
• DKIM спроєктували, щоб виживати при пересиланні краще, ніж SPF, бо він підписує вміст повідомлення, а не підключаючий IP — але він все ще може ламатися при модифікаціях, як-от футери або деякі листові списки.
• DMARC ввів вирівнювання: недостатньо просто «пройти SPF». SPF має проходити для домену, вирівняного з видимим From, або DKIM має проходити і бути вирівняним.
• TTL у DNS носять рекомендаційний характер; резолвери можуть обмежувати, продовжувати або поводитися дивно під навантаженням. Низький TTL — не універсальна кнопка «пропагувати швидше».
• Деякі приймачі кешують негативні відповіді (NXDOMAIN) на основі SOA minimum / negative TTL правил, отже короткочасна відсутність DKIM-запису може переслідувати вас кілька годин.
• Посилення вимог провайдерами стало після масштабного спуфінгу; багато великих поштярських сервісів тепер трактують слабку автентифікацію як штраф для доставляння, а не просто «приємність».

Як насправді пошта використовує DNS: MX, SPF, DKIM, DMARC, PTR, TLSA та інші

MX: куди йде вхідна пошта (і як змішані записи розділяють ваш ящик)

MX-записи — це диспетчери трафіку для вхідної пошти. Кожен MX вказує на хостнейм і значення пріоритету (preference). Менше число має пріоритет. Якщо кілька MX мають однаковий пріоритет, відправник зазвичай рандомізує вибір між ними.

Де буває проблема:

• Ви залишаєте старі MX-записи «на випадок», створюючи випадкове розділення пошти між двома провайдерами.
• Ви вказуєте MX на CNAME, який працює в деяких резолверах, але ламається в інших (MX-цілі мають бути хостнеймами з A/AAAA; CNAME для MX-цілей широко не рекомендовано і може бути відхилено суворими відправниками).
• Ви додаєте IPv6 AAAA для MX-хоста, який фактично не приймає пошту по IPv6, що спричинює таймаути у відправників, які віддають перевагу IPv6.

SPF: хто має право відправляти (і чому «воно проходить» ≠ «воно працює»)

SPF — це TXT-запис (зазвичай на корені домену), який повідомляє приймачу, які IP/хости авторизовані відправляти від імені цього домену. Він оцінюється відносно SMTP envelope sender (Return-Path / MAIL FROM) або, якщо він порожній, ідентифікатора HELO/EHLO.

Помилки SPF, що виглядають як «змішаний DNS»:

• Багато SPF TXT-записів на одному імені (два рядки з v=spf1). Багато приймачів трактують це як постійну помилку.
• Перекриті міграції: include:_spf.oldvendor.example і include:_spf.newvendor.example обидва присутні, що штовхає вас за ліміт DNS-запитів.
• Тестові хакі: хтось додає +all або ~all «тимчасово», і це стає постійним, підриваючи екзекуцію й доставляння.

DKIM: криптографічні підписи (і друкарська помилка селектора, що псує тиждень)

DKIM публікує відкритий ключ у DNS за адресою selector._domainkey.example.com. Ваша вихідна система підписує повідомлення приватним ключем і включає селектор у заголовок DKIM-Signature. Приймачі забирають публічний ключ і верифікують підпис.

Шаблони змішаних записів:

• Ви обертаєте селектори, але не публікуєте новий селектор у всіх місцях (багатопровайдерний DNS або оновлення тільки у внутрішньому DNS).
• Ви публікуєте селектор у невірному піддомені (поширено при відправці як mail.example.com vs example.com).
• Ви порушуєте форматування TXT-запису (лапки, переноси рядків), через що деякі інструменти DNS показують його, але деякі приймачі не можуть його розпарсити.

DMARC: політика, вирівнювання, звітування (і як none все одно може допомогти)

DMARC публікується в _dmarc.example.com і повідомляє приймачам, що робити, коли SPF/DKIM не вирівняні з видимим доменом From. Він також надає адреси звітів для отримання агрегованих та форензичних відгуків (де підтримується).

Шаблони змішаних записів:

• DMARC існує на example.com, але насправді ви відправляєте з sub.example.com без власного DMARC, або покладаєтеся на поведінку організаційного домену, не розуміючи її.
• Політика DMARC встановлена в p=reject перед тим, як DKIM стабільно підписує зі всіх джерел.
• Існує кілька DMARC-записів (таке трапляється), і приймачі трактують це як недійсний запис.

PTR і FCrDNS: перевірка «виглядаєш як справжній поштовий сервер»

Зворотний DNS (PTR) відображає IP назад у хостнейм. Багато приймачів серйозно оцінюють коректність PTR, особливо для самохостингових MTA. Навіть для SaaS-ретрансляторів раптова зміна ідентичності вихідного IP може поховати доставлення. FCrDNS додає другу перевірку: PTR-ім’я має резольвитися назад у той самий IP.

MTA-STS і TLSA: не всюди обов’язкові, але дедалі важливі

MTA-STS використовує DNS TXT-запис (_mta-sts.example.com) і HTTPS-політику хосту (mta-sts.example.com), щоб сигналізувати, що вхідний SMTP має використовувати TLS і закріплювати очікувані MX-хости. TLSA (DANE) використовує DNSSEC для публікації обмежень TLS-сертифікатів. Це не «першочергові» вимоги для багатьох організацій, але якщо ви їх розгортаєте — вони додають ще один вектор, де змішані DNS можуть зламати пошту.

Жарт №2: Хороша новина про пошту — це зрілий протокол. Погана новина — це теж зрілий протокол.

Нагадування про надійність, перефразоване від відомого операційного голосу: оптимізуйте для швидкого відновлення та навчання, бо збої неминучі в складних системах — John Allspaw.

Практичні завдання: команди, виводи та рішення

Ці завдання можна виконати з будь-якого Linux-боксу з встановленими звичайними DNS-інструментами. Запустіть їх з принаймні двох мереж, якщо можете (корпоративний LAN + хмарна VM), бо «працює тут» — це пастка.

Завдання 1: Запит MX у вашого за замовчуванням резолвера

cr0x@server:~$ dig +nocmd example.com MX +noall +answer
example.com.     300 IN MX 10 mx1.newmail.example.
example.com.     300 IN MX 20 mx2.newmail.example.

Що це означає: Публічний DNS (як його бачить ваш резолвер) каже, що пошта йде до двох хостів, пріоритет 10 і 20.

Рішення: Якщо ви очікували одного провайдера, а бачите два несумісні набори (старий і новий), зупиніться і приберіть зайве. Змішаний MX — це не «додаткова відмовостійкість», якщо ви не контролюєте обидві системи і не знаєте точно, як вони взаємодіють.

Завдання 2: Запит MX у конкретного публічного резолвера

cr0x@server:~$ dig @1.1.1.1 example.com MX +noall +answer
example.com.     300 IN MX 10 mx1.oldmail.example.
example.com.     300 IN MX 20 mx2.oldmail.example.

Що це означає: Інший резолвер — інша істина. Ви перебуваєте у стадії пропагування або маєте несумісні авторитетні відповіді (або проблему з DNSSEC, що викликає поведінку fallback).

Рішення: Перед подальшими змінами опитайте авторитетні імена серверів. Якщо вони узгоджені — чекайте; якщо вони неузгоджені — виправляйте шлях публікації зони.

Завдання 3: Запитайте авторитетні імена серверів безпосередньо

cr0x@server:~$ dig +short NS example.com
ns1.dns-host.example.
ns2.dns-host.example.

cr0x@server:~$ dig @ns1.dns-host.example example.com MX +noall +answer
example.com.     300 IN MX 10 mx1.newmail.example.
example.com.     300 IN MX 20 mx2.newmail.example.

cr0x@server:~$ dig @ns2.dns-host.example example.com MX +noall +answer
example.com.     300 IN MX 10 mx1.newmail.example.
example.com.     300 IN MX 20 mx2.newmail.example.

Що це означає: Авторитетні сервери погоджуються на новий MX.

Рішення: Якщо публічні резолвери неузгоджені — ви чекаєте на закінчення кешу. Повідомте про це чітко: «Деякі відправники все ще потраплятимуть на старі MX, поки не мине TTL.» Якщо авторитетні сервери неузгоджені — у вас проблема синхронізації публікації/зони, і пропагування вам не допоможе.

Завдання 4: Підтвердіть, що MX-цілі резольвляться в A/AAAA

cr0x@server:~$ dig mx1.newmail.example A +noall +answer
mx1.newmail.example. 300 IN A 203.0.113.10

cr0x@server:~$ dig mx1.newmail.example AAAA +noall +answer

Що це означає: IPv4 є, IPv6 відсутній (порожня AAAA-відповідь).

Рішення: Це нормально, якщо ви не обслуговуєте IPv6. Чого не хочете — це зламаний AAAA, що вказує на IP з закритим портом 25, бо деякі відправники віддають перевагу IPv6 і чекатимуть таймауту.

Завдання 5: Виявлення «CNAME на MX-цілі»

cr0x@server:~$ dig mx1.newmail.example CNAME +noall +answer
mx1.newmail.example. 300 IN CNAME vendor-lb.mailhost.example.

Що це означає: MX-ціль є CNAME.

Рішення: Якщо ви контролюєте це і воно відоме як надійне у ваших приймачів, ви можете пережити. Якщо ви усуваєте проблеми з доставкою — приберіть цю змінну: використайте рекомендовані провайдером MX-хостнейми, які резольвляться безпосередньо в A/AAAA.

Завдання 6: Перевірка наявності та кількості SPF

cr0x@server:~$ dig example.com TXT +noall +answer
example.com. 300 IN TXT "v=spf1 include:_spf.newvendor.example -all"
example.com. 300 IN TXT "v=spf1 include:_spf.oldvendor.example -all"

Що це означає: Два SPF-записи. Це не «два джерела істини», це «рулетка permerror».

Рішення: Об’єднайте в один запис v=spf1. Якщо вам справді потрібні обидва провайдери під час міграції, поєднайте include у один рядок і дотримуйтесь ліміту запитів.

Завдання 7: Оцініть SPF проти відомого IP відправника

cr0x@server:~$ spfquery -ip 203.0.113.55 -sender bounce@example.com -helo mail.example.com
result=permerror
smtp.comment=Two or more type TXT records found

Що це означає: Оцінка SPF постійно помилкова через множинні записи.

Рішення: Виправте SPF негайно. Багато приймачів трактують permerror як fail або як сильний негативний сигнал.

Завдання 8: Перевірка перевантаження DNS-запитів у SPF

cr0x@server:~$ spfquery -ip 203.0.113.55 -sender bounce@example.com -helo mail.example.com
result=permerror
smtp.comment=SPF Permanent Error: too many DNS lookups

Що це означає: Ваші include/redirect перевищують ліміт SPF.

Рішення: Сплощуйте SPF (обережно), видаліть невикористовувані include, або консолідуйте відправників за одним ретранслятором зі стабільним SPF-слідом.

Завдання 9: Забрати публічний DKIM-ключ для селектора, який ви вважаєте вживаним

cr0x@server:~$ dig s1._domainkey.example.com TXT +noall +answer
s1._domainkey.example.com. 300 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Що це означає: Селектор існує і повертає публічний ключ.

Рішення: Якщо повідомлення не проходять DKIM, проблема, ймовірно, у конфігурації підписування (неправильний селектор, неправильний домен, проблеми з канонізацією тіла/заголовків) або у проміжних модифікаціях повідомлень.

Завдання 10: Піймати друкарську помилку селектора DKIM / відсутній запис

cr0x@server:~$ dig s2._domainkey.example.com TXT +noall +answer

Що це означає: Немає TXT-запису для селектора s2.

Рішення: Або опублікуйте s2, або перевстановіть відправник на використання опублікованого селектора. Якщо ви в процесі ротації, публікуйте одночасно старий і новий селектор, поки стара пошта не буде опрацьована і всі відправники не оновляться.

Завдання 11: Перевірити коректність DMARC

cr0x@server:~$ dig _dmarc.example.com TXT +noall +answer
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=quarantine; adkim=s; aspf=s; rua=mailto:dmarc-reports@example.com"

Що це означає: DMARC існує, політика — quarantine, увімкнено суворе вирівнювання.

Рішення: Суворе вирівнювання підходить лише якщо ви дисципліновані щодо From-доменів і підписування. Якщо у вас багато систем, що відправляють пошту, суворе вирівнювання може зіграти проти вас. Розгляньте пом’якшення під час прибирання, а потім посилення.

Завдання 12: Виявлення кількох DMARC-записів

cr0x@server:~$ dig _dmarc.example.com TXT +noall +answer
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

Що це означає: Два DMARC-записи. Приймачі можуть трактувати це як недійсний запис і ігнорувати DMARC взагалі.

Рішення: Опублікуйте рівно один DMARC-запис у _dmarc. Об’єднайте теги в одну політику.

Завдання 13: Перевірити зворотний DNS (PTR) для вихідного IP

cr0x@server:~$ dig -x 203.0.113.55 +noall +answer
55.113.0.203.in-addr.arpa. 3600 IN PTR mailout.example.com.

Що це означає: IP має PTR, що вказує на mailout.example.com.

Рішення: Переконайтеся, що цей хостнейм також резольвиться вперед у той же IP (FCrDNS). Якщо PTR відсутній або загальний, виправляйте його через вашого ISP/хмарного провайдера; часто це неможливо змінити самостійно, але це критично для доброї доставки.

Завдання 14: Перевірити forward-confirmed reverse DNS (FCrDNS)

cr0x@server:~$ dig mailout.example.com A +noall +answer
mailout.example.com. 300 IN A 203.0.113.55

Що це означає: Форвард відповідає зворотному. Це нудна базова вимога, якої чекають багато приймачів.

Рішення: Якщо форвард не збігається, виправте або PTR, або A-запис. Не лишайте «достатньо близько». Поштові системи не відомі своїм терпінням.

Завдання 15: Перевірити split horizon DNS (публічний vs внутрішній)

cr0x@server:~$ dig @10.0.0.53 example.com MX +noall +answer
example.com. 300 IN MX 10 mx1.internal.example.

cr0x@server:~$ dig @1.1.1.1 example.com MX +noall +answer
example.com. 300 IN MX 10 mx1.newmail.example.

Що це означає: Внутрішній DNS повертає інший MX, ніж публічний DNS.

Рішення: Якщо у вас немає дуже специфічної, добре протестованої архітектури — уніфікуйте їх. Щонайменше, переконайтеся, що внутрішні клієнти, які надсилають пошту зовні, не використовують внутрішні ідентичності, які ламають SPF/DKIM/DMARC і плутають маршрутизацію пошти.

Завдання 16: Підтвердіть TTL DNS і підказки негативного кешування

cr0x@server:~$ dig example.com SOA +noall +answer
example.com. 300 IN SOA ns1.dns-host.example. hostmaster.example.com. 2026010401 3600 900 1209600 300

Що це означає: SOA показує серій зони і останнє поле (minimum) часто впливає на поведінку негативного кешування.

Рішення: Якщо ви короткочасно опублікували відсутній DKIM-селектор (NXDOMAIN), деякі резолвери можуть пам’ятати цей збій. Плануйте ключові ротації з накладанням і уникайте «суттєвих зникнень запису на хвилину» під час деплою.

Завдання 17: Інспектувати реальні заголовки повідомлення (Authentication-Results)

cr0x@server:~$ grep -E "Authentication-Results|Received-SPF|DKIM-Signature|DMARC" -n message.eml | head
12:Authentication-Results: mx.google.com; spf=fail (google.com: domain of bounce@example.com does not designate 203.0.113.55 as permitted sender) smtp.mailfrom=bounce@example.com; dkim=pass header.i=@example.com; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.com
33:DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=s1; ...

Що це означає: DKIM проходить, SPF не проходить, DMARC не проходить. Це може статись, якщо DKIM вирівняний, але DMARC все одно не проходить через невідповідність вирівнювання або через відмінності в оцінці приймача.

Рішення: Зосередьтеся на вирівнюванні: переконайтеся, що DKIM d= домен та/або SPF mailfrom домен вирівняні з видимим From. Якщо DMARC жорсткий і ваш mailfrom — домен стороннього bounce, можливо, потрібен кастомний return-path або інша схема надсилання.

Завдання 18: Переконатися, що ваш MX насправді приймає SMTP-з’єднання (мережева реальність)

cr0x@server:~$ nc -vz mx1.newmail.example 25
Connection to mx1.newmail.example 25 port [tcp/smtp] succeeded!

Що це означає: Порт 25 доступний.

Рішення: Якщо це не вдається з публічного Інтернету, але працює внутрішньо, у вас є проблеми з фаєрволом або маршрутизацією — не DNS-проблема. Не продовжуйте редагувати TXT-записи, щоб виправити закритий порт.

Три корпоративні міні-історії з практики

Міні-історія №1: Інцидент через хибне припущення

Компанія мала два бренди під одним холдингом. Маркетинг вирішив уніфікувати вихідну пошту, щоб кампанії надсилалися з однієї платформи. Документ онбордингу поштового вендора сказав: «Додайте ці SPF include і DKIM-ключі». Нічого незвичного.

Хибне припущення прийшло непомітно: хтось вважав, що SPF оцінюється відносно видимого From-домену. Вони оновили SPF для brandA.com, додавши вендора, і вважали справу зробленою. Насправді транзакційна пошта використовувала bounces.brandA-mail.com як envelope sender, бо інша система обробляла return-path. SPF того домену все ще вказував на старий релей.

Доставлення не впало повністю. Воно падало для певних високосигнальних приймачів, які дуже вагали SPF для того потоку. Служба підтримки отримувала тікети «деякі клієнти не отримують скидання пароля» — найгірша категорія, бо користувачі не розрізняють «маркетинг» і «мій акаунт не працює».

Дебаг зайняв довше, ніж мав би, бо тести робили з однієї поштової служби й однієї мережі. Команда нарешті подивилася Authentication-Results заголовки, побачила, що SPF не проходить за envelope sender, і зрозуміла, що вони налаштували не той домен.

Виправлення було нудним: опублікувати SPF і DKIM для фактичного bounce-домену, вирівняти DMARC для видимого From і стандартизувати обробку return-path у системах. Вони також записали величезними буквами, які домени за що відповідають. Продакшен любить великі літери.

Міні-історія №2: Оптимізація, що зіграла проти

Швидкозростаюча організація перейшла на DNS-провайдера, який підтримував «розумну маршрутизацію» і автоматичні health-check. Вони знизили TTL по всій зоні, бо хотіли «миттєвого переключення» під час інцидентів. Звучало розумно на зустрічі.

Потім вони мігрували вхідну пошту. Під час cutover їхня автоматизація продовжувала перемикати MX, бо один з нових MX-хостів періодично провалював TCP-перевірку. Деякі резолвери кешували «старий» MX, деякі — «новий», а деякі — версію п’ятихвилинної давності. Вхідна пошта стала ймовірнісною.

Стало гірше: низький TTL збільшив обсяг запитів і виявив другу проблему — rate limiting у авторитетного провайдера під час піку. Приймачі почали бачити інколи SERVFAIL. Ці відправники ставили в чергу й повторювали (пошта терпляча), але це створило хвилеподібну схему затримок, яка виглядала як баг у застосунку.

Висновок після інциденту не був «ніколи не знижуйте TTL». Він був: не використовуйте DNS як балансувальник, керований health-check’ами для пошти, якщо ви повністю не розумієте екосистему приймачів. SMTP-відправники вже мають логіку повторних спроб. Ваше завдання — стабільна маршрутизація й ідентичність, а не хитромудрі перемикання.

Міні-історія №3: Нудна, але правильна практика, що врятувала день

Інша команда мала план міграції, що здавався надто консервативним: вони документували кожне джерело відправки (система тикетів, CRM, оповіщення моніторингу, пошта продукту, маркетинг). Для кожного записували From-домен, envelope sender домен, DKIM-селектор і вихідний IP або релей.

Вони також запускали щотижневу перевірку «дрейфу DNS»: забирали записи з авторитетного API, порівнювали з шаблоном і сповіщали про відмінності. Це не було гламурно. Ніхто не отримав підвищення через те, що cronjob не спрацював. Але це запобігло сюрпризам.

Коли вони мігрували на новий вихідний релей, перевірка дрейфу виявила, що колега додав другий SPF-запис замість редагування існуючого. Це ніколи не потрапило в продакшен, бо зміна провалила передрелізну перевірку.

Міграція все одно мала звичні хиби — деякі кеші тримали старий MX довше, ніж очікували — але пошта не розділилася між провайдерами і DMARC не почав відхиляти легітимні відправлення. «Нудна» практика не була накладною; вона була паском безпеки.

Типові помилки (симптом → корінь → виправлення)

1) Симптом: Деякі відправники повертають помилку «host not found», інші доставляють нормально

Корінь: Невідповідна видимість MX між резолверами (вік пропагування, старі кеші або несумісні авторитетні відповіді). Іноді змішані набори NS під час зміни реєстратора.

Виправлення: Опитайте авторитетні NS напряму; переконайтеся, що обидва NS мають однакові серійні номери та записи. Уникайте одночасної зміни NS і MX, якщо ви не любите стрес. Підвищуйте TTL до планованих міграцій, а не під час них.

2) Симптом: Вхідна пошта випадково йде на старого провайдера

Корінь: Старі MX-записи все ще опубліковані, часто з тією ж або нижчою пріоритетністю, ніж нові.

Виправлення: Публікуйте лише набор MX для наміченого провайдера. Якщо потрібна подвійна доставка, робіть це свідомо через контрольований шар маршрутизації, а не залишайте сміття в DNS.

3) Симптом: SPF показує «permerror» у заголовках

Корінь: Кілька SPF TXT-записів або перевищення ліміту DNS-запитів через забагато include/redirect.

Виправлення: Консолідуйте в один SPF-запис. Зменшуйте include, видаляйте невикористовувані провайдери і тримайте кількість запитів менше 10.

4) Симптом: DKIM «selector not found» з’являється періодично

Корінь: Селектор опублікований в одному DNS-перегляді, але не в іншому (split horizon), або запис оновлено на одному авторитетному NS, але не на іншому, або ротація ключів видалила старий селектор зарано.

Виправлення: Публікуйте селектори послідовно на всіх авторитетних серверах. Під час ротації накладайте старий і новий селектори. Не видаляйте старий, поки не переконалися, що всі відправники перейшли.

5) Симптом: DMARC відхиляє легітимну пошту після зміни вендора

Корінь: Розрив вирівнювання — новий вендор використовує інший bounce-домен або DKIM підписує домен, що не вирівнюється з From, особливо при суворому вирівнюванні.

Виправлення: Налаштуйте кастомний return-path / envelope sender, де можливо. Переконайтеся, що DKIM d= вирівнюється з From. Розгляньте пом’якшення вирівнювання під час міграції, потім посиліть.

6) Симптом: Пошта до одного великого провайдера затримується на години

Корінь: Приймач невпевнено дістає ваш MX (перевага IPv6 на зламаний AAAA, блокування фаєрволом, greylisting + автентифікаційні збої), або DNS періодично повертає SERVFAIL через авторитетні проблеми.

Виправлення: Перевірте шлях IPv6, якщо ви публікуєте AAAA. Перевірте доступність порту 25 ззовні. Стабілізуйте авторитетний DNS і уникайте флапаючих записів.

7) Симптом: Ви проходите SPF, але все одно потрапляєте в спам

Корінь: SPF проходить для домену, що не вирівняний (або проходить лише HELO-ідентичність). DMARC не проходить або відсутній. Або погана репутація IP і слабкий PTR/HELO.

Виправлення: Впровадьте DKIM і DMARC з вирівнюванням. Виправте PTR/FCrDNS. Переконайтеся, що HELO/EHLO стабільний і змістовний.

8) Симптом: У вашому офісі все виглядає правильно, а у клієнтів — ні

Корінь: Split horizon DNS, що повертає внутрішні MX/SPF/DKIM відповіді, або внутрішній egress використовує інший NAT-IP, ніж зовнішні тести.

Виправлення: Тестуйте із зовнішніх мереж. Приберіть внутрішні переопреділення для публічних ідентичностей пошти. Документуйте і моніторьте вихідні IP.

Контрольні списки / покроковий план

Покроково: безпечно виправити змішану DNS-поломку для пошти

1. Заморозьте зміни. Припиніть редагувати випадкові записи, поки ще здогадуєтеся. Зафіксуйте поточний стан зони (MX, TXT, A/AAAA, NS, SOA).
2. Встановіть авторитетну істину. Опитайте кожен авторитетний NS напряму для MX, SPF TXT, DKIM-селекторів, DMARC. Якщо вони неузгоджені — виправляйте це першочергово.
3. Зробіть вхід детермінованим. Опублікуйте лише намічений набір MX. Перевірте, що MX-цілі резольвляться і приймають SMTP.
4. Виправте SPF в один запис. Об’єднайте include; перевірте лічильник запитів; переконайтеся, що ви авторизували всі легітимні джерела виходу (або маршрутизували їх через один релей).
5. Виправте DKIM-селектори. Переконайтеся, що кожен відправник підписує і селектор є в публічному DNS. Накладання старого/нового при ротації.
6. Встановіть DMARC відповідно до реальності. Почніть з p=none, якщо потрібно, потім рухайтеся до quarantine і reject, коли вирівнювання доведене для всіх джерел.
7. Перевірте ідентичність IP. PTR + FCrDNS; переконайтеся, що HELO/EHLO стабільний і співпадає з PTR-доменом там, де доречно.
8. Тестуйте з різних точок спостереження. Використайте принаймні одну зовнішню VM і одного споживчого ISP, якщо можливо.
9. Чекайте кеші розумно. Відстежуйте TTL; повідомляйте зацікавлених сторін про очікувані вікна конвергенції. Не обіцяйте миттєвого відновлення, якщо TTL — 1 год і великі резолвери липкі.
10. Замикайте процес реальними заголовками. Перевірте Authentication-Results від репрезентативних приймачів. Якщо ви не бачите заголовків, ви дебагуєте в темряві.

Контроль запобігання: як не дати DNS стати генератором простоїв пошти

• Один власник за DNS-поверхнею пошти. Не «всі можуть редагувати TXT, бо це легко». Легко — це те, як з’являються множинні SPF-записи.
• Інвентар всіх систем відправки. Для кожної: From-домен, envelope sender домен, DKIM-селектор, вихідний IP/релей і чи підтримує вона кастомний return-path.
• Управління змінами для DNS. Стадійний огляд, підтвердження колег і план відкату, що не включає панічні кліки в веб-консолі.
• Моніторинг відповідей DNS з кількох резолверів. Сповіщення при несподіваних змінах MX/SPF/DMARC/DKIM або якщо авторитетні NS неузгоджені.
• План ротації ключів. Опублікуйте новий селектор спочатку, потім переключіть підписування, потім утилізуйте старий селектор пізніше.
• Не надто оптимізуйте TTL. Використовуйте TTL як інструмент планування. Знижуйте його перед запланованими змінами, потім підвищуйте назад для стабільності.
• Документуйте cutover-процеси постачальників. Особливо коли залучено два вендори (старий + новий). «Тимчасові» DNS-entries повинні мати дату видалення і власника.

Питання й відповіді (FAQ)

1) Що саме вважається «змішаними DNS-записами» для пошти?

Будь-яка комбінація, де маршрутизація пошти або дані автентифікації несумісні: два набори MX від різних провайдерів, кілька SPF-записів, дублювання DMARC, відсутні DKIM-селектори або різні відповіді внутрішнього/публічного DNS.

2) Чи можу я залишити старі й нові MX під час міграції «на всяк випадок»?

Можете, але зазвичай не варто. Це створює недетерміновану маршрутизацію, якщо ви не контролюєте обидві сторони і не маєте плану дедуплікації та видимості користувачів. Більшість організацій хоче детермінованої доставки в одну поштову систему.

3) Чому пошта все ще йде до старого провайдера після оновлення MX?

Бо системи відправників кешують DNS. Дехто кешує довше, ніж ваш TTL. Дехто також повторно намагається проти раніше розвʼязаних MX для поставлених у чергу повідомлень. Це нормально. Ваше завдання — забезпечити коректні та стабільні авторитетні відповіді.

4) Чи завжди неправильно мати два SPF-записи?

Так, по суті. Специфікація SPF очікує один політичний запис. Багато приймачів трактують кілька v=spf1 рядків як постійну помилку.

5) Якщо DKIM проходить, чи все одно потрібен SPF?

Для сучасної доставленості рекомендується мати обидва. DKIM часто є надійнішим сигналом при пересиланні, але SPF все ще важливий, і DMARC може проходити через будь-який із них — за умови вирівнювання.

6) Що таке DMARC-віравнювання простою мовою?

Це означає, що автентифікований домен (через SPF mailfrom або DKIM d=) збігається з видимим From-доменом або точно (суворе) або в межах того самого організаційного домену (розслаблене).

7) Як split horizon DNS ламає пошту?

Якщо внутрішні резолвери повертають інші MX/SPF/DKIM/DMARC ніж публічний Інтернет, внутрішні тести можуть проходити, а зовнішні відправники — падати. Також внутрішні додатки можуть надсилати з ідентичностей, які зовні не валідні.

8) Чи варто публікувати AAAA для моїх MX-хостів?

Лише якщо ви справді підтримуєте SMTP по IPv6 стабільно (зв’язність, фаєрволи, TLS-конфігурація, моніторинг). Публікація AAAA без готовності до експлуатації створює таймаути й затримки для відправників, які віддають перевагу IPv6.

9) Наскільки суворою має бути політика DMARC?

Почніть з p=none для спостереження, потім перейдіть до quarantine, а далі до reject, коли перевірите, що всі легітимні джерела вирівнюються і підписуються. Примус без інвентаризації — найшвидший шлях до блокування власної пошти.

10) Який найшвидший індикатор того, що DNS — причина проблеми?

Різні резолвери повертають різні MX або TXT відповіді для одного імені. Якщо авторитетні імена серверів неузгоджені — майже напевно проблема в публікації DNS, а не в поштовому сервері.

Висновок: наступні кроки, які ви можете зробити сьогодні

Якщо запам’ятаєте одне: пошта ламається, коли DNS розповідає дві історії одночасно. Ваше завдання — змусити її розповідати одну нудну, правильну історію — послідовно, для кожного резолвера, завжди.

1. Запустіть запити MX/SPF/DKIM/DMARC проти авторитетних іменних серверів і принаймні одного публічного резолвера. Збережіть виводи.
2. Зробіть MX детермінованими: приберіть записи старих провайдерів і перевірте, що MX-цілі резольвяться і приймають SMTP.
3. Зменшіть ентропію автентифікації: один SPF-запис, опубліковані DKIM-селектори, що відповідають підписуванню, один DMARC-запис з політикою, що відповідає вашому поточному рівню готовності.
4. Перевірте вихідну ідентичність: PTR + форвард-матч, стабільний HELO і відсутність несподіваних змін вихідних IP.
5. Запишіть інвентар відправників і встановіть gate змін для DNS-редагувань. Майбутній ви не буде ностальгувати за «швидкими виправленнями».