Ви змінили MX-записи, щоб «додати відмовостійкість», пішли додому, а вранці прокинулись у вирі тикетів:
деякі відправники не можуть доставити, інші доставляють повільно, а кілька повідомлень повертаються з помилками, що нагадують роман Кафки.
Поштова система «працює», але доставка — не бінарний стан. Це узгоджений процес між DNS, SMTP-клієнтами, політикою та часом.
Кілька MX-записів — одна з тих простих на перший погляд ручок, яка тихо контролює, хто до вас звертається, коли і як наполегливо вони намагаються.
«Пріоритет» реальний, але не той, яким його багато хто уявляє. Якщо трактувати його як чіткий активний/резервний вимикач, він покарає вас.
MX «пріоритет»: що це насправді означає (і чого не означає)
MX-запис каже: «Для цього домену ось імена хостів, які приймають SMTP-пошту, і ось порядок уподобань.»
Числове значення називають preference (неформально «пріоритет»). Менші числа віддаються перевагою. Це та частина, яку всі запам’ятовують.
Частина, яку часто забувають: SMTP-відправники не зобов’язані виконувати ваші бажання; вони слідують стандартам і власним оперативним політикам.
Пріоритет MX не є перевіркою здоров’я.
Він не підтверджує, що сервер досяжний, налаштований, авторизований або готовий.
Він навіть не гарантує, що відправник спробує найнижчий запис першим, якщо локальне кешування або політика каже інакше.
Це підказка. Гарна підказка. Але все ж підказка.
Практичне значення кількох MX-записів таке:
- Нижчий preference пробують першим у нормальному випадку.
- Вищий preference пробують, якщо нижчий зазнає невдачі (відмова з’єднання, таймаут, 4xx тощо), і тоді відправники зазвичай ставлять у чергу й повторюють спроби пізніше.
- Однаковий preference використовують для розподілу навантаження (не гарантовано рівномірно, але така ідея).
- Переключення — ймовірнісне та часово залежне: воно залежить від того, як швидко відбуваються відмови, скільки зберігаються черги і як працюють графіки повторних спроб.
Думайте про пріоритет MX як про маршрутну політику для чужого програмного забезпечення, що виконується за їхнім розкладом.
Це менше схоже на світлофор і більше на набір дорожніх знаків у іншому місті.
Дві правила, що рятують кар’єру
- Якщо hostname присутній у MX, він має вміти приймати пошту для домену (і обробляти її правильно), інакше ви підписуєтесь на недетерміновані втрати, затримки та відмови.
-
Ніколи не публікуйте MX-ціль, яку ви не можете моніторити та експлуатувати.
«Це лише резерв» — це шлях до несподіваного ретрансляції спаму, несподіваних відмов і неприємних юридичних розмов.
Один цитат і одна перевірка реальності
Парафразована думка (часто з підходів надійності систем): Надія — не стратегія; потрібні проєктування й перевірка.
Це саме той підхід, який вам потрібен, коли ви публікуєте DNS, що впливає на доставку пошти в глобальному масштабі.
Алгоритм вибору: як відправники обирають серед MX-цілей
Ось спрощений алгоритм, якому зазвичай слідують SMTP-клієнти, базований на стандартній поведінці:
- Проведіть запит MX для домену отримувача.
- Якщо їх немає, відкотіться до A/AAAA-lookup самого домену (так, ще досі трапляється).
- Відсортуйте MX-цілі за зростанням preference (спочатку найменше число).
- Для цілей з однаковим preference випадковим чином або ротуючи змінюють порядок.
- Для кожної цілі в порядку:
- Вирішіть A/AAAA для імені MX.
- Спробуйте доставку на одну з отриманих IP-адрес (політика варіює: деякі пробують всі, деякі обирають одну, деякі віддають перевагу IPv6).
- Якщо доставка зазнає тимчасової помилки, переходять до наступної цілі або ставлять у чергу й повторюють пізніше.
- Якщо доставка зазнає постійної помилки (5xx), повертають повідомлення.
Це «щасливий шлях». У продакшні починається цікаве:
- DNS-кешування означає, що відправник може довго використовувати старі відповіді MX довше, ніж ваш вікно змін, залежно від TTL і поведінки резолверів.
- Локальна політика може змінити вашу архітектуру: деякі великі провайдери трактують певні діапазони IP по-іншому або використовують «прилипання» для зменшення обертів з’єднань.
- Недоліки на рівні з’єднання не рівнозначні: швидка «відмова з’єднання» викликає швидкий відхід; таймаут з’їдає секунди і може блокувати пропускну здатність черги.
- Greylisting і обмеження частоти можуть перетворити ваш «резерв» на магніт для повільних повторних спроб.
Якщо ви хочете чіткого переключення, тільки MX не дасть вам чіткої відмовостійкості. Він забезпечує поступову доставку за розумних умов.
Якщо вам потрібне детерміністичне маршрутування — це вже сфера управління трафіком перед SMTP (або використання поштової служби, що це надає).
Жарт №1: пріоритет MX — як органіграма. Виглядає авторитетно, поки не подивишся, як реально приймаються рішення.
Цікаві факти та історичний контекст
Пошта старша за більшість ваших систем моніторингу і несе в собі деякі спадкові поведінки, що досі важливі.
Ось конкретні факти, які пояснюють, чому «просто додати ще один MX» рідко буває «просто».
- MX-записи були введені, щоб розділити маршрутизацію пошти від імен хостів. Ранні маршрутизатори пошти сильно покладалися на таблиці хостів і прямі адреси; MX зробив це гнучкішим.
- Пріоритет MX навмисно простий. Це механізм впорядкування, а не система ваг і здоров’я, як сучасні балансувальники навантаження.
- Fallback до A/AAAA, коли MX відсутній, досі частина поведінки. Саме тому «голі» домени іноді «приймають пошту» випадково.
- Деякі відправники трактують однакові preference як множину для ротації. Мета — розподіл, але реальний розподіл залежить від реалізації й кешування.
- «Резервний MX» раніше був поширеним шаблоном. Зберігання та пересилка мало сенс, коли канали були ненадійні; сьогодні це часто ризик, якщо не контрольовано.
- SMTP побудований навколо повторних спроб. Тимчасові помилки очікуються; черги й відступи — це функції, а не баги.
- Оппортунистичний TLS змінив поняття «досяжності». Сервер може приймати TCP/25, але все одно не пройти політику доставки, якщо відправник вимагає TLS або перевірку сертифіката.
- Впровадження IPv6 додало нові асиметрії. Відправник може віддавати перевагу IPv6, а ваш шлях v6 може бути «увімкнений» у маршрутизації, але «зламаний» насправді (фаєрволи, rDNS, репутація).
- Великі провайдери застосовують поведінку поза стандартами. Тротлінг, репутація і евристики можуть домінувати над тим, що ви вважаєте «доставкою».
Де багатомісні MX-дизайни дають збій у продакшені
Спокуслива неправильна думка: «Більше число означає standby»
Люди публікують MX 10 як первинний, MX 20 як резервний і вважають, що резервний буде використовуватися лише коли первинний недоступний.
Це не гарантовано. «Недоступний» — неоднозначно: недосяжний? відмовляє? повільний? тимчасово повертає 4xx? DNS застарілий? IPv6 не працює?
Багато відправників спробують вторинний, якщо первинний просто повільний або періодично відмовляє.
Тоді ваш резервний стане робочим шляхом прийому без виробничого загартування.
Він може не мати правильної TLS-конфігурації, або перебувати в іншому фільтруючому шляху, або не бути авторизованим для правильного формування bounce-повідомлень.
Однаковий пріоритет як «балансування навантаження» без симетрії
Якщо ви публікуєте два MX з однаковим preference, ви запрошуєте розподіл навантаження.
Це нормально лише якщо обидва кінці операційно ідентичні з точки зору SMTP:
та сама антиспам-позиція, ті ж обмеження швидкості, та сама TLS-політика, такий самий банер, такий самий внутрішній роутинг, та ж здатність приймати для всіх отримувачів.
У реальному світі один вузол трішки старіший, трішки неправильно налаштований, трішки менш моніториться.
Вгадайте, звідки приходить більшість дивних відмов.
«Резервний MX», що приймає для всіх, стає пасткою для спаму
Класичний режим відмови: резервний MX приймає пошту для доменів, яку він фактично не доставляє, бо налаштований як inbound-міст для будь-яких отримувачів.
Не відкритий ретранслятор у очевидному сенсі «відправляй куди завгодно», але в сенсі «приймай будь-якого отримувача під час SMTP, а потім не доставляй» — саме це.
Спамери обожнюють це, бо воно ховає валідність отримувача і перекладає біль на вашу чергу.
Якщо ваш резервний MX не має валідації отримувачів (або не може її виконати через відсутність доступу до довідника), його треба дуже обережно конфігурувати.
Інакше ви будуєте зобов’язання з відмінною доступністю.
Помилки DNS: MX, що вказує на IP, CNAME або некоректні імена
MX-цілі мають бути іменами хостів, які вирішуються в A та/або AAAA записи. Вони не можуть бути сирими IP-адресами.
Багато DNS-провайдерів дозволяють вводити нісенітницю. SMTP-відправники так не роблять.
CNAME-на-MX сильно не рекомендується і часто відхиляється валідаторами. Деякі резолвери його підтримують; деякі системи трактують це як помилку конфігурації.
Ви не хочете «деякі», коли глобальна екосистема пошти — ваш клієнт.
Негативне кешування та міфи про пропагацію
Коли ви «фіксуєте DNS», ви не одразу виправляєте пошту. Резолвери кешують.
Деякі кешують занадто довго. Деякі ігнорують ваш TTL. Деякі мають застарілі відповіді через проміжні резолвери.
Ваш моніторинг може показувати правильну відповідь, тоді як великий відправник усе ще бачить стару.
Швидкий план діагностики
Коли доставка пошти поводиться дивно, не починайте з перебору номерів MX.
Почніть з того, щоб знайти, де відбувається збій: відповідь DNS, досяжність TCP, SMTP-діалог, відхилення політикою або поведінка черги.
Перше: підтвердьте, що бачить світ (DNS, з кількох точок спостереження)
- Запитайте MX і A/AAAA для домену і для кожної MX-цілі.
- Перевірте TTL і чи відрізняються відповіді між резолверами.
- Підтвердьте, що немає CNAME на MX-цілі.
Друге: протестуйте TCP/25 та SMTP-банер на кожній MX-цілі (IPv4 і IPv6)
- Швидкі відмови (refused) — хороші сигнали; таймаути — вбивці пропускної здатності.
- Перевірте фаєрвол, маршрутизацію та блокування від провайдера.
- Підтвердьте правильне ім’я хоста та TLS-можливості, якщо це вимагається.
Третє: подивіться на серверне приймання та поведінку черги
- Відхиляєте при підключенні, під час HELO/EHLO, під час MAIL FROM чи під час RCPT TO?
- Відкладаєте (4xx) через greylisting, обмеження частоти, DNSBL чи політику?
- Чи ваша «резервна» черга стоїть довго, бо не може доставити внутрішнім шляхом?
Четверте: корелюйте з логами та шаблонами відправників
- Які зовнішні IP підключаються до якої MX-цілі?
- Чи великі провайдери послідовно використовують вторинний?
- Чи зосереджуються відмови на IPv6, одній зонах доступності або на конкретному імені хоста?
Практичні завдання: команди, виводи та рішення
Ось завдання, які я насправді виконую, коли хтось каже «MX failover не працює» або «пошта затримується».
Кожне завдання містить: команду, що означає її вивід, і рішення, яке ви приймаєте.
Завдання 1: побачити MX-набір так, як його бачить ваш резолвер
cr0x@server:~$ dig +nocmd example.com MX +noall +answer
example.com. 300 IN MX 10 mx1.example.net.
example.com. 300 IN MX 20 mx2.example.net.
Значення: Preference 10 пробують перед 20. TTL — 300 секунд.
Рішення: Якщо набір неправильний — виправте DNS спочатку. Якщо правильний — рухайтесь далі; одні лише номера MX не пояснюють «затримки».
Завдання 2: перевірити, чи MX-цілі справді вирішуються (A і AAAA)
cr0x@server:~$ dig +nocmd mx1.example.net A mx1.example.net AAAA +noall +answer
mx1.example.net. 300 IN A 203.0.113.10
mx1.example.net. 300 IN AAAA 2001:db8:10::10
Значення: Опубліковані і IPv4, і IPv6.
Рішення: Якщо ви публікуєте AAAA — ви повинні експлуатувати IPv6. Якщо IPv6 зламаний — або виправте його, або перестаньте його рекламувати.
Завдання 3: виявити CNAME, що ховається за іменем MX
cr0x@server:~$ dig +nocmd mx2.example.net CNAME +noall +answer
mx2.example.net. 300 IN CNAME mail-gw.provider.example.
Значення: Ваше ім’я MX — це CNAME.
Рішення: Замініть на ім’я з прямими A/AAAA записами. Деякі відправники відмовляться або трактуватимуть це як помилку конфігурації.
Завдання 4: порівняти відповіді від різних резолверів (виявити питання пропагації/кешування)
cr0x@server:~$ dig @1.1.1.1 example.com MX +noall +answer
example.com. 300 IN MX 10 mx1.example.net.
example.com. 300 IN MX 20 mx2.example.net.
cr0x@server:~$ dig @8.8.8.8 example.com MX +noall +answer
example.com. 3600 IN MX 5 oldmx.example.org.
Значення: Різні резолвери не погоджуються. Один все ще віддає старий MX з довшим TTL.
Рішення: Очікуйте затриманого перехідного періоду. Тримайте стару інфраструктуру живою, поки кеші не вичерпаються, або заздалегідь зменшіть TTL перед міграціями.
Завдання 5: швидко перевірити досяжність TCP/25 (IPv4)
cr0x@server:~$ nc -vz -w 3 203.0.113.10 25
Connection to 203.0.113.10 25 port [tcp/smtp] succeeded!
Значення: Порт 25 досяжний і хост слухає.
Рішення: Якщо це не вдається — виправте фаєрвол/маршрутизацію/блокування провайдера перш ніж торкатись DNS. MX «failover» не допоможе, якщо обидва заблоковані.
Завдання 6: перевірити досяжність TCP/25 (IPv6)
cr0x@server:~$ nc -6 -vz -w 3 2001:db8:10::10 25
nc: connect to 2001:db8:10::10 port 25 (tcp) failed: No route to host
Значення: Шлях IPv6 зламаний.
Рішення: Якщо ви не можете швидко виправити IPv6 — видаліть AAAA для імені MX (або виправте маршрути/фаєрвол). Інакше деякі відправники будуть зависати на таймаутах.
Завдання 7: перевірити SMTP-банер і базовий діалог
cr0x@server:~$ openssl s_client -starttls smtp -connect mx1.example.net:25 -servername mx1.example.net -crlf
CONNECTED(00000003)
220 mx1.example.net ESMTP Postfix
EHLO test.example
250-mx1.example.net
250-STARTTLS
250 PIPELINING
Значення: Сервер відповідає й пропонує STARTTLS. Ідентичність банера виглядає адекватно.
Рішення: Якщо STARTTLS не працює або банер неправильний (наприклад загальний хост у хмарі), очікуйте проблем з репутацією та політиками. Виправте TLS та ідентичність перед додаванням додаткових MX.
Завдання 8: дізнатися, який MX обирає ваш MTA (з Linux-хоста)
cr0x@server:~$ postconf -n | grep -E 'myhostname|mydestination|relayhost'
myhostname = app1.internal.example
mydestination = $myhostname, localhost.localdomain, localhost
relayhost =
Значення: Цей хост доставлятиме напряму (relayhost не налаштовано).
Рішення: Якщо ви планували ретрансляцію через smart host — налаштуйте relayhost. Інакше ця машина тепер частина поверхні вашої доставки пошти.
Завдання 9: простежити рішення про вихідну доставку (Postfix)
cr0x@server:~$ postmap -q example.com /etc/postfix/transport
smtp:
Значення: Немає спеціального транспорту; використовуватиметься звичайний MX-lookup по SMTP.
Рішення: Якщо потрібно примусово направити наступний хоп (наприклад, уникнути зламаного MX під час інциденту), використайте тимчасовий запис у transport map.
Завдання 10: подивитись на відкладання і чому вони відбуваються (інспекція черги)
cr0x@server:~$ mailq
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
7F2A51C02F 4210 Mon Jan 4 10:12:19 alerts@example.com
(connect to mx1.example.net[203.0.113.10]:25: Connection timed out)
user@example.com
-- 1 Kbytes in 1 Request.
Значення: Відправник таймаутиться до первинного. Це slow-fail, найгірший тип.
Рішення: Виправте досяжність або фаєрвол. Якщо не можна — тимчасово зменшіть timeout-налаштування (обережно) і переконайтесь, що вторинний здоровий.
Завдання 11: підтвердити, які зовнішні IP потрапляють на який MX (вибірка логів)
cr0x@server:~$ sudo grep -E 'connect from' /var/log/mail.log | tail -n 5
Jan 4 10:15:01 mx2 postfix/smtpd[18422]: connect from mail-oi1-f170.google.com[209.85.167.170]
Jan 4 10:15:09 mx2 postfix/smtpd[18422]: connect from mta7.am0.yahoodns.net[67.195.228.94]
Jan 4 10:15:14 mx2 postfix/smtpd[18422]: connect from outbound.protection.outlook.com[40.92.72.65]
Jan 4 10:15:18 mx2 postfix/smtpd[18422]: connect from mail.example-sender.net[198.51.100.44]
Jan 4 10:15:22 mx2 postfix/smtpd[18422]: connect from unknown[192.0.2.55]
Значення: Великі провайдери підключаються до mx2 ( «вторинного»).
Рішення: Ставтеся до mx2 як до продакшн. Якщо він не еквівалентний mx1 — ви створили «спліт-брейн» прийомних політик.
Завдання 12: протестувати прийняття отримувача під час SMTP (поведінка RCPT TO)
cr0x@server:~$ swaks --to nonexistent-user@example.com --server mx2.example.net --timeout 10
=== Trying mx2.example.net:25...
=== Connected to mx2.example.net.
<- 220 mx2.example.net ESMTP Postfix
-> EHLO client.example
<- 250-mx2.example.net
<- 250 PIPELINING
-> MAIL FROM:<test@client.example>
<- 250 2.1.0 Ok
-> RCPT TO:<nonexistent-user@example.com>
<- 250 2.1.5 Ok
-> DATA
<- 554 5.7.1 Service unavailable; Client host blocked
Значення: mx2 приймає неіснуючого отримувача на RCPT (250), але пізніше відмовляє. Це рецепт для backscatter і росту черги.
Рішення: Налаштуйте валідацію отримувачів (відхиляйте невідомих на RCPT TO) або переконайтесь, що mx2 не вказаний як MX для доменів, які він не може перевіряти.
Завдання 13: перевірити зворотній DNS для IP MX (основи репутації)
cr0x@server:~$ dig +short -x 203.0.113.10
mx1.example.net.
Значення: PTR збігається з іменем хоста, яке використовується в ідентичності SMTP.
Рішення: Якщо PTR відсутній або загальний — виправте його. Деякі приймаючі трактують невідповідний rDNS як сигнал недовіри і будуть тротлити або відхиляти.
Завдання 14: перевірити SPF-алайнмент для шлюзів, які можуть генерувати bounce-и
cr0x@server:~$ dig +short example.com TXT
"v=spf1 ip4:203.0.113.10 ip4:203.0.113.20 -all"
Значення: Тільки ці IP авторизовані надсилати від імені example.com.
Рішення: Якщо ваш «вторинний» відправляє будь-яку пошту, що претендує на ваш домен (включно з DSN), переконайтесь, що SPF (і DKIM/DMARC за потреби) не викличуть відмов.
Завдання 15: підтвердити DMARC-політику (щоб передбачити суворість приймачів)
cr0x@server:~$ dig +short _dmarc.example.com TXT
"v=DMARC1; p=reject; rua=mailto:dmarc-rua@example.com"
Значення: Сувора політика; невирівняна пошта відхиляється.
Рішення: Якщо ви маршрутуєте пошту через різні шлюзи, зберігайте підписи/вирівнювання. Інакше деякі шляхи зламаються й виглядатимуть «випадковими».
Завдання 16: визначити таймаути SMTP проти відмов (kernel counters підкажуть)
cr0x@server:~$ sudo ss -tn state syn-sent '( dport = :25 )' | head
State Recv-Q Send-Q Local Address:Port Peer Address:Port
SYN-SENT 0 1 10.0.0.15:45822 203.0.113.10:25
SYN-SENT 0 1 10.0.0.15:45824 203.0.113.10:25
Значення: Багато SYN-SENT-з’єднань вказують на таймаути або відфільтровані пакети, а не відмови на прикладному рівні.
Рішення: Перевірте правила фаєрволу та upstream-фільтрацію. Якщо бачите накопичення SYN-SENT, зміна priority MX не допоможе.
Три корпоративні міні-історії (анонімізовані, але болісно реальні)
Міні-історія 1: інцидент через неправильне припущення («Standby означає невикористовуваний»)
Середня компанія обслуговувала вхідну пошту на парі MTA у різних дата-центрах. MX 10 вказував на первинний.
MX 20 вказував на «резервний» сервер, до якого не торкались місяцями, бо він був «тільки на випадок аварії».
Команда відчувала себе відповідально. Два MX! Стійкість досягнута! Вони навіть казали керівництву, що це «active-passive».
Потім зміна в фаєрволі внесла переривчасту втрату пакетів у первинний дата-центр. Не повний збій — просто достатньо скинутих SYN/ACK, щоб викликати таймаути.
Деякі відправники повторювали й у кінці кінців потрапляли на вторинний. Інші стояли в черзі годинами, перш ніж спробувати вторинний.
Декілька відмовилися після вичерпання власної політики повторних спроб. Симптом виглядав як випадкова втрата пошти. Це найгірший тип інциденту.
Резервний MTA працював зі старішою конфігурацією, що не перевіряла отримувачів на RCPT time.
Він приймав пошту для помилково введених отримувачів, а потім пізніше не доставляв її внутрішньо. Диски черги заповнились. Потім почалися відмови й із легітимною поштою.
Тим часом первинний був «майже вгору», тому моніторинг не кричав, поки люди не втрутились.
Виправлення було болісно нудним: зробити обидва MTA еквівалентними, додати коректні перевірки отримувачів, узгодити політики й TLS, і моніторити доставлюваність, а не лише працездатність процесу.
Вони також навчилися трактувати таймаути як подію першої важливості. Відмови падають швидко; таймаути падають повільно і забирають пропускну здатність.
Міні-історія 2: оптимізація, що обернулась проти («Однаковий пріоритет навантаження розподілить добре»)
Інша організація хотіла зменшити вхідне навантаження на один шлюз. Вони опублікували два MX з preference 10.
Очікували чистий 50/50 поділ і похвалили себе за уникнення балансувальника.
DNS-базований розподіл навантаження! Класика.
Це в основному працювало — поки не перестало. Один шлюз мав трохи суворішу TLS-конфігурацію: новіші шифри, інший ланцюжок сертифікатів, трохи інша поведінка TLS-хендшейку.
Деякі старіші стеки відправників не проходили STARTTLS і віддавали перевагу plaintext — або зовсім відмовлялися залежно від політики.
Раптом «деякі партнери не можуть нам писати» стало регулярним тикетом.
Ще гірше, фільтрація спаму була не ідентична. Один шлюз навчався швидше (більше CPU, новіші правила), тож спамери тягнулися до слабшого.
IP-репутація цього шлюзу деградувала, і легітимна пошта від певних провайдерів стала приходити повільніше через тротлінг.
Всі звинувачували DNS, бо це змінилося. DNS був невинний; асиметрія — винувата.
Зрештою вони перейшли до моделі, де обидва MX-цілі були по-справжньому ідентичні в політиках і графіку патчів, і вони перевірили TLS-інтероперабельність у стейджингу.
Однаковий пріоритет MX не «помилка». Помилка — нерівні кінці за однакового пріоритету.
Міні-історія 3: нудна, але правильна практика, що врятувала день («Тримайте старий MX активним, зменшуйте TTL заздалегідь»)
Велике підприємство мігрувало від локального шлюзу до хостингового сервісу захисту пошти.
План міграції не був гламурним. Це був чекліст: знизити TTL MX за кілька днів, опублікувати новий MX з вищим preference спочатку, перевірити прийняття,
потім під час тихого вікна поміняти пріоритети. Тримати старий шлюз онлайн протягом повного періоду старіння кешу.
Під час переносу несподівана регіональна проблема резолвера DNS спричинила, що деякі клієнти отримували застарілі MX-відповіді.
Як і слід чекати, ці клієнти надсилали пошту на старий шлюз. Але старий шлюз все ще працював, все ще приймав і пересилав до нового сервісу.
Бізнес не зауважив. Це найкращий результат: невидимо правильно.
Моніторинг команди теж був нудним і ефективним: у них були синтетичні SMTP-тести до кожної MX-цілі, що відстежували латентність підключення і успіх STARTTLS.
Коли хостований сервіс мав короткий бліп з тротлінгом, синтетичні тести одразу помітили зростання 4xx-відкладів.
Команда відреагувала, координуючись з вендором і тимчасово підлаштувавши власні вхідні обмеження.
Ніхто не отримав трофей. Але ніхто і не проспав о 3:00 ранку, а це найкраще, що може трапитись в операціях.
Жарт №2: «Це лише DNS» — поштова еквівалент фрази «це лише невелика зміна». Обидві фрази швидко старіють.
Типові помилки: симптом → корінна причина → виправлення
1) Симптом: Деякі відправники доставляють на вторинний, навіть коли первинний «в роботі»
Корінна причина: Первинний повільний або періодично таймаутить; відправники відкочуються за власною логікою повторних спроб. Може також бути зламаний IPv6 на первинному.
Виправлення: Усуньте таймаути. Перевірте TCP-досяжність, SYN-SENT, падіння фаєрволом і IPv6. Забезпечте швидку відмову первинного при нездоров’ї (або видаліть зламані шляхи).
2) Симптом: Пошта затримується на години, потім приходить хвилею
Корінна причина: Відправники ставлять у чергу через тимчасові помилки (4xx) або таймаути. Ваше «failover» відбувається, але за довгим графіком повторних спроб.
Виправлення: Знайдіть точний SMTP-етап, що повертає 4xx. Виправте обмеження швидкості, greylisting, тригери DNSBL або upstream-фільтрацію. Зменшіть таймаути, що викликають затримки.
3) Симптом: Випадкові bounce-и з посиланням на одне ім’я MX
Корінна причина: Нерівна конфігурація між MX-цілями (TLS, антиспам, вимоги auth, валідація отримувачів або внутрішній роутинг).
Виправлення: Зробіть MX-цілі симетричними або видаліть слабший. Якщо не можете тримати їх рівними — не рекламуйте їх однаково (або взагалі не рекламуйте).
4) Симптом: Цикли доставки або «relaying denied» від вторинного
Корінна причина: Вторинний не налаштований приймати пошту для домену або не може маршрутизувати до внутрішнього призначення. Часто трапляється з «backup MX», що не знає ваших доменів.
Виправлення: Переконайтесь, що вторинний авторитивний для отримуючого домену і має правильні транспортні маршрути. Перевірте через SMTP RCPT тести та end-to-end доставку.
5) Симптом: «Host not found» bounce-и після зміни MX
Корінна причина: Ім’я MX-цілі не має A/AAAA, або помилка в наборі, або використовує CNAME-ланцюг, що ламається в деяких резолверах.
Виправлення: Публікуйте прямі A/AAAA для MX-цілей; видаліть CNAME-на-MX; перевірте за допомогою dig з кількох резолверів.
6) Симптом: Збої доставки лише від відправників з підтримкою IPv6
Корінна причина: AAAA існує, але шлях IPv6 зламаний (маршрутизація, фаєрвол, NAT64, блокування провайдера) або відсутній зворотній DNS для IPv6.
Виправлення: Або експлуатуйте IPv6 повноцінно (досяжність, rDNS, репутація), або не публікуйте AAAA для MX-хостів.
7) Симптом: Збільшення спаму після додавання резервного MX
Корінна причина: Резервний MX приймає для некоректних отримувачів (немає валідації отримувачів), стаючи привабливою ціллю й навантаженням черги.
Виправлення: Відхиляйте невірних отримувачів на RCPT time, або забезпечте резервний MX доступом до каталогу/мап отримувачів. Додайте суворі правила ретрансляції і моніторинг.
8) Симптом: «Працює в наших тестах», але партнери повідомляють про збої
Корінна причина: Ви тестували з однієї мережі/резолвера. Партнери потрапляють на інші резолвери, кешовані відповіді, інші TLS-стеки або політичні обмеження.
Виправлення: Тестуйте з кількох мереж і резолверів. Перевірте TLS-інтероперабельність та SMTP-діалог. Моніторте зовнішніми пробами, а не лише внутрішніми.
Контрольні списки / покроковий план
Контрольний список: проєктування кількох MX-записів (що робити, а не на що сподіватися)
- Визначте намір: розподіл (однаковий пріоритет) або впорядкування уподобання (primary/secondary). Не мішайте концепції.
- Зробіть кожен опублікований MX виробничого рівня: патчі, моніторинг, потужність, логи, резервне копіювання і відповідальність on-call.
- Узгоджуйте політику: TLS, політика шифрів, антиспам, обмеження швидкості, валідація отримувачів і банер ідентичності.
- Експлуатуйте IPv6 свідомо: публікуйте AAAA лише після тестів досяжності, rDNS і шляхів фаєрвола.
- Встановіть розумний TTL: зменшуйте TTL задовго до запланованих міграцій; уникайте панічних змін TTL в той самий день.
- Уникайте CNAME-на-MX: публікуйте A/AAAA безпосередньо для імені MX.
- Плануйте черги: зрозумійте, що failover може означати відкладену доставку. Повідомте зацікавлені сторони.
- Підтверджуйте end-to-end: тестуйте прийняття SMTP і внутрішній роутинг, а не тільки «порт відкритий».
Покроково: безболісний cutover MX (мінімум драм)
- T-7 днів: Зменшіть TTL MX (наприклад, 3600 → 300). Тримайте старий TTL достатнім для безпечної пропагації.
- T-3 дні: Запустіть новий MX. Переконайтесь, що він приймає пошту для домену та доставляє внутрішньо.
- T-2 дні: Опублікуйте новий MX з вищим preference (як канарку). Наприклад: існуючий MX 10, новий MX 20.
- T-2 до T-1 днів: Спостерігайте логи. Підтвердіть, хто підключається до нового MX і що повідомлення доставляються правильно.
- T-0: Поміняйте пріоритети місцями (новий стає з меншим числом). Тримайте старий MX онлайн з вищим preference.
- T+1 день: Продовжуйте моніторинг з кількох резолверів і синтетичних SMTP-чеків.
- T+період старіння кешу: Видаліть старий MX лише після впевненості, що застарілі резолвери більше не посилають на нього трафік.
Контрольний список: «backup MX» правильно (рідко, але можливо)
- Валідація отримувачів — безальтернативна: відхиляйте невідомих отримувачів на RCPT time.
- Обмеження store-and-forward: обмежте ріст черги; попередньо сповіщайте; забезпечте ресурс диска й I/O.
- Строга політика ретрансляції: ніколи не дозволяйте йому стати загальним ретранслятором.
- Узгоджена політика: той самий TLS і фільтрація, що й у першиного, щоб уникнути дрейфу репутації.
- Операційна відповідальність: моніторинг, патчі, тести та участь у тренуваннях з інцидентів.
Питання й відповіді (FAQ)
1) Чи гарантує нижчий MX-номер, що відправники завжди використовуватимуть цей сервер?
Ні. Це порядок уподобань, а не механізм примусу. Відправники можуть кешувати старі відповіді, застосовувати власні політики
і відкотитись, якщо обраний хост повільний, таймаутить або тимчасово відхиляє.
2) Якщо мій первинний MX впав, чи одразу пошта піде на вторинний?
Інколи. Якщо «впав» означає швидкі відмови (connection refused), багато відправників швидко спробують наступний MX.
Якщо «впав» виглядає як таймаути, вони можуть витрачати час на кожну спробу, потім ставити в чергу й повторювати пізніше, що призводить до затримок.
3) Чи варто ставити однакові значення пріоритету для балансування навантаження?
Тільки якщо обидва кінці операційно та політично еквівалентні. Однаковий пріоритет означає «підходять обидва».
Якщо один слабший — ви отримаєте дивні часткові збої, що виглядають випадково.
4) Чи може MX-запис вказувати напряму на IP-адресу?
Ні. MX-цілі мають бути іменами хостів, які вирішуються в IP через A/AAAA записи.
Якщо вам потрібен прямий контроль маршрутизації за IP — MX не той інструмент.
5) Чи нормально, що MX-ціль — CNAME?
Це сильно не рекомендується і викликає проблеми сумісності. Деякі системи підтримують CNAME; інші вважають це неправильним або поводяться непослідовно.
Публікуйте A/AAAA прямо для імені MX.
6) Скільки MX-записів мені слід публікувати?
Два — поширена практика. Більше трьох рідко допомагає і часто збільшує площу для помилок.
Кожен опублікований MX треба підтримувати як реальний приймач трафіку — бо він ним і буде.
7) Чи можна використовувати «backup MX», що лише зберігає пошту й пересилає пізніше?
Можна, але він має валідувати отримувачів (інакше прийматимете сміття, яке не зможете доставити), і повинен бути захищений і моніторитися.
Багато сучасних організацій віддають перевагу використанню надійного сервісу вхідної безпеки замість самостійного store-and-forward.
8) Чому я бачу пошту на вторинному MX навіть коли все здається здоровим?
Бо деякі відправники розподіляють трафік при однаковому пріоритеті, через кешований DNS, через власні евристики відправника,
або через те, що ваш первинний інколи повільно відмовляє (таймаути), штовхаючи повтори на вторинний.
9) Чи вступає в силу зміна TTL миттєво?
Зміни TTL впливають лише кеші, що запитують після зміни. Резолвери, які кешували старий запис, триматимуть його до закінчення TTL,
а деякі проміжні резолвери поводяться погано. Плануйте зниження TTL заздалегідь.
10) Чи впливає пріоритет MX на вихідну пошту з мого домену?
Не безпосередньо. MX — для вхідного маршруту до вашого домену. Вихідна керується конфігурацією вашого MTA, relayhost і маршрутизацією провайдерів.
Люди постійно це плутають, особливо під час міграцій.
Висновок: кроки, які можна зробити сьогодні
Кілька MX-записів — не магічний прапорець відмовостійкості. Це опублікований договір зі світом:
«Ось двері, якими ви можете користуватись, щоб доставляти нам пошту.» Кожна двері має надійно відчинятися.
Практичні кроки:
- Перевірте інвентар вашого MX-набору і підтвердьте, що кожна ціль вирішується (A/AAAA) і відповідає на TCP/25 ззовні вашої мережі.
- Якщо ви публікуєте IPv6 — протестуйте IPv6 SMTP досяжність і rDNS. Якщо не можете це експлуатувати — припиніть рекламувати.
- Зробіть MX-ендпоїнти політично-ідентичними: поведінка TLS, валідація отримувачів, антиспам і внутрішній роутинг.
- Побудуйте простий синтетичний монітор: підключення, читання банера, EHLO, спроба STARTTLS і запис латентності. Сповіщайте про таймаути й зростання 4xx-відкладів.
- Для майбутніх змін зменшіть TTL заздалегідь і тримайте старий MX активним достатньо довго, щоб кеші зістарілися.
Зробіть це — і «пріоритет MX» стане корисним інструментом замість постійної загадки.