MTA-STS: чи варто ввімкнути і як уникнути перебоїв з вхідною поштою

Що MTA-STS фактично робить (і чого не робить)

MTA-STS (Mail Transfer Agent Strict Transport Security) — це спосіб для домену-одержувача повідомити відправні MTAs: «Коли ви доставляєте пошту на мої MX-хости, використовуйте TLS і перевіряйте сертифікати; якщо не вийшло — не знижуйте до відкритого тексту». Це, фактично, HSTS для SMTP — але SMTP дивніший, старіший і має довгу традицію «best effort» доставки.

Механічно MTA-STS — це дві речі:

1. DNS TXT запис на _mta-sts.<domain>, який рекламує поточний ідентифікатор політики id.
2. Файл політики по HTTPS за адресою https://mta-sts.<domain>/.well-known/mta-sts.txt, який описує прийнятні MX-хости і режим застосування.

Відправники, які підтримують MTA-STS, періодично завантажують вашу політику через HTTPS, кешують її і потім використовують для рішення про доставку, відкладення або відмову у разі, коли TLS не відповідає вимогам.

Від чого це захищає

• Атаки на пониження рівня захисту opportunistic TLS, коли мережевий атакувальник знімає STARTTLS і примушує відкритий SMTP.
• Деякі сценарії неправильного маршрутування, коли доставка опиняється на хості без валідного сертифіката для вашого домену.
• Поведение «ми спробували TLS, але приймаємо будь-що» з боку деяких відправників; MTA-STS штовхає їх до суворої валідації для вашого домену.

Чого це не захищає

• Скомпрометований відправник або одержувач. Якщо сервер пошти зламаний — MTA-STS не врятує; це як ремінь безпеки в горящому авто.
• Підміна DNS на рівні власника домену. Якщо ваш DNS скомпрометовано, ви можете публікувати політики, що завдадуть шкоди або перенаправлять трафік.
• Цілісність вмісту листа. Це зона DKIM/DMARC, а не транспорт.
• Усі MITM. MTA-STS покладається на HTTPS і довіру до CA; це не те саме, що DNSSEC-анкований автентифікатор типу DANE.

Одна операційна тонкість: MTA-STS не змушує вас щось робити на приймальній стороні; воно змушує відправників відмовлятися від доставки, якщо ваш TLS-постуре не відповідає заявленому. Тому невдачі MTA-STS часто виглядають як «вхідна пошта раптово припинилася з деяких провайдерів» — класична насолода для відповідальних на виклику.

Один вислів, який варто «татуювати» на кожному changerequest: «Надія — це не стратегія.» — Gene Kranz. Це не лише про пошту, але надзвичайно актуально, коли ви публікуєте «enforce» і сподіваєтесь, що всі кейси в порядку.

Чи варто його ввімкнути?

Так, якщо ви послідовно дотримуєтесь двох базових вимог:

• Ваші MX-хости надійно підтримують STARTTLS з сучасними шифрами і без зламаних проміжних ланок.
• Ваші сертифікати валідні, не прострочені, правильно зібрані в ланцюжок і відповідають іменам MX, які ви вказуєте в політиці.

Якщо це звучить тривіально — чудово. Так і має бути. Але «надійно» — це де кістки ховаються: балансувальники навантаження, що перехоплюють TLS, застарілі пристрої, резервний MX у третьої сторони, що не відповідає іменам, або «тимчасовий» DR-шлях, який лишився тимчасовим з 2019 року.

Кому це особливо корисно

• Доменам, що отримують чутливу пошту: зарплати, юридичні, охорона здоров’я, фінанси, потоки автентифікації користувачів.
• Організаціям з суворим комплаєнсом, які вже вимагають TLS скрізь і потребують вимірної позиції від відправників.
• Всім, хто втомився від того, що opportunistic TLS — «опційний, поки не стане критично».

Кому варто відкласти встановлення режиму «enforce»

• Доменам з різнорідними шляхами доставки (декілька MX-провайдерів, on-prem + хмарні, застарілі шлюзи).
• Всім, хто не має автоматизації сертифікатів і моніторингу.
• Командам, які не можуть відповісти на питання «Що трапиться, якщо наш хост політики недоступний?» без проведення наради.

Моя суб’єктивна рекомендація:

• Швидко ввімкніть MTA-STS у mode: testing (за декілька днів), бо це низький ризик і дає вам видимість.
• Залишайтеся в testing, поки не матимете доказів: TLS-з’єднання вдаються з різних мереж, сертифікати оновлюються коректно, і резервні MX-сьютації приведені до ладу.
• Перейдіть у mode: enforce лише після проведення практичної тренування з відмовостійкості, що включає тест реального маршруту пошти. Якщо ви ніколи не тестували відмову MX в реальних умовах — у вас не відмовостійкість, а казка на ніч.

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

Цікаві факти і історія (коротко, але корисно)

• MTA-STS — це RFC IETF з 2018 року (RFC 8461). Він відносно молодий порівняно з SMTP, тому розгортання дуже різняться.
• SMTP STARTTLS стандартизовано у 2002 році (RFC 3207). Протягом років більшість доставки була «опортуністичною»: використати TLS якщо запропоновано, інакше надіслати у відкритому вигляді.
• MTA-STS був розроблений частково через реальність STARTTLS-стрипінгу. Це не теоретична загроза; мережеві атакувальники можуть змінювати рекламовані можливості сервера.
• DANE для SMTP існував раніше і використовує DNSSEC для автентифікації TLS-ключів. MTA-STS обрав прагматичний шлях: HTTPS + публічні CA, бо впровадження DNSSEC для пошти залишається фрагментованим.
• Політика завантажується по фіксованому хосту (mta-sts.<domain>). Це зручно, але створює операційний залежний сервіс, який потрібно тримати живим.
• Відправники кешують політики, тому ваші помилки можуть зберігатися, а виправлення можуть розповсюджуватись із затримкою. «Ми виправили» ≠ «відправники перестали кешувати стару політику».
• DNS-запис містить поле «id», яке ви змінюєте, щоб позначити оновлення. Це фактично «скас-бастер» для кешів відправників.
• TLS-RPT існує як супутній механізм: механізм звітності, де відправники можуть надсилати вам звіти про помилки TLS. Це найближче до зовнішньої спостережливості, яку ви отримаєте.

Як MTA-STS порушує вхідну пошту

MTA-STS зазвичай не ламає пошту відразу після публікації. Неприємність у відкладених відмовах:

• Відправники завантажують вашу політику за своїм графіком.
• Вони кешують її на певний час.
• Вони застосовують її під час доставки до вас.

Отже, ви можете опублікувати «enforce» сьогодні і виявити наслідки завтра, коли великий відправник оновить політику і раптом відмовиться доставляти на ваш «резервний» MX, який насправді є стороннім спам-шлюзом із сертифікатом, що прострочено в травні.

Карта режимів відмов (звичайні підозрювані)

• Несумісність списку MX: у політиці вказано mx1.example.com і mx2.example.com, але в DNS також рекламуються mx-backup.vendor.net. Деякі відправники можуть спробувати його; політика каже «ні», і при режимі enforce доставка провалюється.
• Збої TLS-рукопотискання: непідтримувані шифри, несумісні версії TLS, зламане SNI або STARTTLS, який насправді не працює стабільно.
• Проблеми з сертифікатом: прострочений сертифікат, неправильне ім’я хоста, відсутній проміжний сертифікат або RSA-ключ занадто малий для сучасних клієнтів.
• Несправний балансувальник навантаження: TLS-офлоад, який не передає SNI правильно або показує дефолтний сертифікат деяким відправникам.
• Недоступний хост політики: mta-sts.example.com впав або заблокований. Деякі відправники збережуть кешовану політику; інші можуть інакше трактувати помилки завантаження. Ви не хочете, щоб це було несподіваним залежним сервісом.
• Несподіваний DR-шлях: ви перемикаєтеся на резервний шлях під час інциденту, але DR-MX не в політиці або його сертифікат не проходить валідацію. У режимі enforce відновлення стає самонанесеним простою.

Тема: MTA-STS змушує вас узгодити те, що ви кажете (політика) з тим, що ви робите (реальні MX і TLS). Технічна робота керована. Організаційна робота — інвентаризація всіх шляхів — ось де ви приносите цінність.

Швидкий план діагностики

Коли хтось каже «ми не отримуємо листи», ви можете витратити години на суперечки про DMARC, фільтрацію спаму і людський фактор. Відмови MTA-STS мають характерний запах: проблеми у конкретних відправників, помилки TLS у їхніх логах і недавні зміни в політиці/сертифікатах/DNS.

Перше: підтвердіть, чи задіяний MTA-STS

1. Перевірте, чи існує TXT запис _mta-sts і яке значення id.
2. Завантажте файл політики і підтвердьте mode і шаблони MX.
3. Шукайте нещодавню зміну id або зміну сертифіката.

Друге: перевірте MX + TLS ззовні

1. Резолвіть записи MX і перелічіть усі хости. Порівняйте з рядками mx: у політиці.
2. Протестуйте STARTTLS і валідацію сертифіката для кожного MX на порті 25.
3. Підтвердьте ланцюжок сертифікатів і відповідність імен хостів тому, що відправник буде перевіряти.

Третє: зіставте з реальними помилками доставки

1. Перегляньте ваші SMTP-логи на предмет спроб з’єднань, переговорів STARTTLS і відмов.
2. Шукайте TLS-коди тривог, збої рукопотискання або «no shared cipher».
3. Якщо ви публікуєте TLS-RPT — проаналізуйте звіти на предмет закономірностей: конкретний MX, конкретна версія TLS, конкретний відправник.

Якщо ви виконаєте ці три кроки, зазвичай ви з’ясуєте одне з: «політика надто сувора для реальності», «сертифікат зламаний» або «MX змінились без оновлення політики». Тоді виправлення просте.

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

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

Завдання 1: Перевірити, чи опубліковано MTA-STS у DNS

cr0x@server:~$ dig +short TXT _mta-sts.example.com
"v=STSv1; id=20260103T1200Z"

Що це означає: MTA-STS увімкнено для example.com, і відправники кешуватимуть політику, прив’язану до id.

Рішення: Якщо пошта не доходить і ви нещодавно змінили MX/TLS, розгляньте, чи збігається файл політики з реальністю. Якщо потрібно швидко оновити політику — змініть id після оновлення файлу.

Завдання 2: Резолв MX і інвентаризація всіх цілей входу

cr0x@server:~$ dig +short MX example.com
10 mx1.example.com.
20 mx2.example.com.
50 mx-backup.vendor.net.

Що це означає: Є три цілі доставки, включно з резервом від постачальника.

Рішення: Переконайтеся, що політика включає шаблони, які відповідають усім MX-ім’ям, які ви рекламуєте, або видаліть MX, який не можете привести у відповідність. У режимі enforce «забуті» MX стануть причиною простою.

Завдання 3: Завантажити файл політики MTA-STS через HTTPS

cr0x@server:~$ curl -fsS https://mta-sts.example.com/.well-known/mta-sts.txt
version: STSv1
mode: enforce
mx: mx1.example.com
mx: mx2.example.com
max_age: 604800

Що це означає: Активний режим enforce; дозволені лише mx1 і mx2.

Рішення: Якщо ви все ще публікуєте mx-backup.vendor.net в DNS, додайте його до політики (якщо він відповідає вимогам) або видаліть його з MX, щоб уникнути спроб відправників і помилок доставки.

Завдання 4: Перевірити сертифікат та ланцюжок хоста політики

cr0x@server:~$ echo | openssl s_client -connect mta-sts.example.com:443 -servername mta-sts.example.com -showcerts 2>/dev/null | openssl x509 -noout -subject -issuer -dates
subject=CN = mta-sts.example.com
issuer=C = US, O = Example CA, CN = Example Issuing CA 01
notBefore=Dec  1 00:00:00 2025 GMT
notAfter=Mar  1 23:59:59 2026 GMT

Що це означає: HTTPS-ендпоінт представляє сертифікат для правильного імені і він не протермінований.

Рішення: Якщо дати неправильні або CN/SAN не відповідають — виправте HTTPS першочергово. Відправники не зможуть надійно завантажувати політику, а деякі й надалі можуть застосовувати кешовану політику.

Завдання 5: Переконатися, що файл політики повертає HTTP 200 і нормальні заголовки

cr0x@server:~$ curl -sSI https://mta-sts.example.com/.well-known/mta-sts.txt | sed -n '1,8p'
HTTP/2 200
content-type: text/plain
cache-control: max-age=300
content-length: 104
date: Fri, 03 Jan 2026 12:15:11 GMT

Що це означає: Файл доступний і повертає plain text. Коротке кешування на HTTP-ребрі не зашкодить; відправники все одно кешують на основі max_age у політиці.

Рішення: Якщо ви бачите редиректи на інший хост, вимоги автентифікації або коди ≠200 — виправте. Тримайте це нудним: статичний текстовий файл, стабільний шлях, публічний доступ.

Завдання 6: Перевірити STARTTLS і валідацію сертифіката для кожного MX

cr0x@server:~$ echo | openssl s_client -starttls smtp -connect mx1.example.com:25 -servername mx1.example.com -verify_return_error 2>/dev/null | egrep -i "Verify return code|subject=|issuer="
subject=CN = mx1.example.com
issuer=C = US, O = Example CA, CN = Example Issuing CA 01
Verify return code: 0 (ok)

Що це означає: TLS домовлено і сертифікат валідований для mx1.

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

Завдання 7: Перевірити банер SMTP і підтримку STARTTLS

cr0x@server:~$ printf 'EHLO test.example\r\nQUIT\r\n' | nc -w 5 mx2.example.com 25
220 mx2.example.com ESMTP Postfix
250-mx2.example.com
250-PIPELINING
250-SIZE 52428800
250-STARTTLS
250-8BITMIME
250-ENHANCEDSTATUSCODES
250 CHUNKING

Що це означає: Сервер рекламує STARTTLS. Добре.

Рішення: Якщо STARTTLS не рекламується послідовно (періодично), у вас проблема з балансувальником або різницею бекендів. MTA-STS посилить це в жорсткі відмови.

Завдання 8: Виявити проблему «дефолтного сертифіката» за балансувальником (SNI)

cr0x@server:~$ echo | openssl s_client -starttls smtp -connect mx1.example.com:25 2>/dev/null | openssl x509 -noout -subject
subject=CN = lb-default.example.net

Що це означає: Без SNI сервер повертає дефолтний сертифікат, який не збігається з mx1.example.com.

Рішення: Багато MTAs не відправляють SNI на SMTP STARTTLS. Не покладайтеся на це. Виправте фронтенд, щоб він за замовчуванням презентував правильний сертифікат для цієї IP:порту, або виділіть слушні IP-слухачі під кожне ім’я хоста.

Завдання 9: Підтвердити версії TLS і шифри (виявити застаріле)

cr0x@server:~$ openssl s_client -starttls smtp -connect mx1.example.com:25 -tls1_2 -brief /dev/null | egrep -i "Protocol|Ciphersuite|Verification"
Protocol version: TLSv1.2
Ciphersuite: ECDHE-RSA-AES256-GCM-SHA384
Verification: OK

Що це означає: TLS 1.2 працює і верифікується.

Рішення: Якщо працює лише TLS 1.0, сучасні відправники можуть відмовити ще до MTA-STS. З MTA-STS в режимі enforce ви вимагаєте суворої валідації, тож оновіть TLS-стек до сучасних стандартів.

Завдання 10: Перевірити налаштування Postfix TLS (приймальна сторона)

cr0x@server:~$ postconf -n | egrep "smtpd_tls|smtpd_tls_security_level|smtpd_tls_cert_file|smtpd_tls_key_file"
smtpd_tls_security_level = may
smtpd_tls_cert_file = /etc/letsencrypt/live/mx1.example.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mx1.example.com/privkey.pem
smtpd_tls_loglevel = 1

Що це означає: Сервер пропонує TLS («may») і видно, який сертифікат він використовує.

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

Завдання 11: Швидко виявляти TLS-помилки в логах пошти

cr0x@server:~$ sudo grep -E "TLS|SSL|handshake|STARTTLS" /var/log/mail.log | tail -n 8
Jan  3 12:07:51 mx1 postfix/smtpd[18291]: warning: TLS library problem: error:0A000152:SSL routines::unsafe legacy renegotiation disabled
Jan  3 12:08:02 mx1 postfix/smtpd[18302]: warning: TLS library problem: error:0A0000C1:SSL routines::no shared cipher
Jan  3 12:08:15 mx1 postfix/smtpd[18310]: Anonymous TLS connection established from mail-oi1-f172.google.com[209.85.167.172]: TLSv1.3 with cipher TLS_AES_128_GCM_SHA256

Що це означає: Ви бачите проблеми з шифром/рукопотисканням з деякими клієнтами, але успіх з іншими. Це вказує на варіативність сумісності.

Рішення: Вирішіть, чи розширювати підтримку шифрів (обережно), або прийняти, що деякі застарілі відправники зазнають невдач у режимі enforce. Якщо ці відправники важливі — потрібен план сумісності.

Завдання 12: Підтвердити id політики і поведінку кешування (ви змінили id?)

cr0x@server:~$ dig +short TXT _mta-sts.example.com
"v=STSv1; id=20260103T1200Z"

Що це означає: Якщо ви змінили файл політики, але не id, багато відправників продовжать використовувати кешовану політику до її закінчення.

Рішення: При зміні mode або рядків mx — піднімайте id. Трактуйте його як версію конфігурації.

Завдання 13: Перевірити, чи опубліковано TLS-RPT (спостережливість ззовні)

cr0x@server:~$ dig +short TXT _smtp._tls.example.com
"v=TLSRPTv1; rua=mailto:tls-reports@example.com"

Що це означає: Відправники, що підтримують звітність TLS, можуть надсилати вам агреговані звіти про помилки.

Рішення: Якщо ви збираєтеся застосовувати enforce — опублікуйте TLS-RPT і стежте за поштовою скринькою. Інакше ви летите IFR з вимкненими приладами.

Завдання 14: Переконатися, що сертифікат містить ім’я MX у SAN

cr0x@server:~$ echo | openssl s_client -starttls smtp -connect mx2.example.com:25 -servername mx2.example.com 2>/dev/null | openssl x509 -noout -text | sed -n '/Subject Alternative Name/,+1p'
            X509v3 Subject Alternative Name:
                DNS:mx2.example.com, DNS:mx2.internal.example.com

Що це означає: Сертифікат покриває публічне ім’я MX. Добре.

Рішення: Якщо SAN не містить публічного MX-імені — випустіть сертифікат наново. CN-only не достатньо для багатьох сучасних валідаторів.

Завдання 15: Підтвердити, що резервний MX від вендора може зробити валідований TLS (або видалити його)

cr0x@server:~$ echo | openssl s_client -starttls smtp -connect mx-backup.vendor.net:25 -verify_return_error 2>/dev/null | egrep -i "subject=|Verify return code"
subject=CN = mx-backup.vendor.net
Verify return code: 0 (ok)

Що це означає: Вендорський MX підтримує валідований TLS для власного імені хоста. Це необхідна, але не завжди достатня умова.

Рішення: Вирішіть, чи включати mx-backup.vendor.net у вашу політику MTA-STS. Якщо ви лишаєте його в DNS, але виключаєте з політики у режимі enforce, деякі доставки впадуть, коли відправники спробують нижчий пріоритет MX.

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

1) Інцидент через хибне припущення: «Звісно, наш резервний MX у порядку»

Середня компанія мала чисту поштову архітектуру: два MX у active-active, автоматизацію сертифікатів і «резервний» MX, що вказував на шлюз стороннього постачальника з вищим пріоритетом. Резерв мав утримувати пошту, якщо первинний сайт ставав недоступним.

Вони ввімкнули MTA-STS у mode: enforce після огляду безпеки. У політиці були лише їхні два основні MX-хости. Припущення було простим: «Відправники спробують первинний MX першими; резерв — лише страховка».

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

У режимі MTA-STS enforce це вендорське ім’я не було дозволене. Відправник відмовився доставляти, замість того щоб «понизити» до не-політичного MX. З точки зору компанії, вхідна пошта з певних відправників не приходила для певних одержувачів у вікно, що не корелювало з їхнім моніторингом.

Виправлення не було героїчним. Потрібно було або видалити вендорський MX з DNS, або включити його в політику і перевірити його TLS-поставу. Урок болючий: поведінка failover у SMTP — це не теоретична функція; це те, що відбувається, коли інтернет «покашлює».

2) Оптимізація, яка повернулась проти: «Поставимо все за однією IP»

Команда пошти великої компанії вирішила спростити край: один anycast VIP перед кількома MX-іменами, один флот балансувальників, один бандл сертифікатів, менше правил фаєрвола. На папері — акуратно. У діаграмах — красиво.

У реальності SMTP STARTTLS не поводиться як сучасний HTTPS-трафік. Деякі відправні MTAs не відправляють SNI. Інші поводяться по-різному в залежності від версії. Балансувальник покладався на SNI, щоб вибрати правильний сертифікат для імені хоста. Коли SNI відсутній, він віддавав дефолтний сертифікат, що не відповідав ім’я MX.

До MTA-STS це викликало «деякі TLS-сесії падають, потім доставка переходить у відкритий режим». Потворно, але пошта доходила. Після включення MTA-STS в режимі enforce ті ж сесії стали жорсткими відмовами, бо відправник мав перевіряти сертифікати. Оптимізація не просто провалилась; вона провалилась голосно і вибірково.

Вони відкотили дизайн: виділили окремі IP-слухачі під публічні MX-імена, кожен з яких презентує сертифікат, що збігається без покладання на SNI. Це коштувало кількох додаткових IP і трохи більше конфігурації. Воно дало надійну доставку.

Жарт №2: Балансувальник пообіцяв «єдиний інтерфейс», а приніс «єдину точку суму».

3) Сумна, але правильна практика, яка врятувала день: «Поводьтесь з політикою як з конфігом у pipeline»

Фінансова компанія ввімкнула MTA-STS у testing-режимі рано і тримала його там довше, ніж хотіла команда безпеки. Поштова команда наполягала на нудному процесі: git-репозиторій для файлу політики, peer review і маленький CI-джеоб, що перевіряв синтаксис і порівнював записані MX з живим DNS.

Вони також автоматизували перевірки закінчення терміну дії сертифікатів для кожного MX-імені та хоста політики. Не «хтось отримає листа за 30 днів», а реальний моніторинг, підключений до пейджингу у робочі години з чіткими рукбуками.

Коли міграція дата-центру вимагала зміни MX-імен, вони зробили це поступово: опублікували новий MX поряд зі старим, оновили політику, щоб включити обидва, підняли id, чекали вікна кешування, а потім видалили старі записи. Повільно, свідомо і трохи нудно.

Під час міграції вендор спробував «допомогти», вставивши тимчасовий relay MX. CI-перевірка підняла прапорець, що новий MX не в політиці і зламає enforce пізніше. Зміна була відхилена до походження в DNS.

Нічого драматичного не сталося. Ось у чому суть. У операціях найвищий комплімент — «було буденно», а поруч — «ніхто не помітив».

Типові помилки: симптом → причина → виправлення

1) Симптом: Gmail/Microsoft відкладають доставку з TLS-помилками

Причина: Ваш MX рекламує STARTTLS, але презентує невірний сертифікат (неправильне ім’я хоста, прострочений, відсутній проміжний) або переговори періодично ламаються.

Виправлення: Перевірте за допомогою openssl s_client -starttls smtp кожен MX. Переконайтеся, що презентований сертифікат відповідає імені MX і ланцюжок повний. Виправте поведінку дефолтного сертифіката балансувальника.

2) Симптом: Лише деякі відправники не доставляють; інші доставляють нормально

Причина: Кешування політики і гетерогенність відправників. Деякі відправники завантажили і застосовують політику; інші ще ні або по-іншому трактують помилки. Або лише деякі відправники потрапляють на проблемний MX/IP через маршрутизацію.

Виправлення: Визначте, які відправники падають, потім відтворіть проблему з зовнішніх мереж. Перевірте TLS-RPT, якщо він є. Перевіряйте усі кінцеві точки MX, а не тільки ту, що зазвичай бачите у логах.

3) Симптом: Пошта падає під час failover/обслуговування, але зазвичай працює

Причина: Ваш DR/резервний MX не включений у політику або не проходить сувору TLS-валідацію.

Виправлення: Додайте DR-MX у політику і тримайте його TLS у відповідності, або не рекламуйте його в MX. Тестуйте відмову під час testing, перш ніж вона знадобиться у реальному інциденті.

4) Симптом: Ви оновили файл політики, але відправники все ще поводяться як до змін

Причина: Ви забули підняти DNS TXT id, тому відправники продовжують використовувати кешовану політику.

Виправлення: Оновіть файл політики, потім підніміть id в DNS. Плануйте затримки кешування з урахуванням max_age і поведінки відправників.

5) Симптом: Завантаження політики повертає помилку (404/редирект/авторизація) і застосування стає непередбачуваним

Причина: Ваш хост mta-sts за WAF-правилами, редиректить HTTP→HTTPS неправильно, вимагає автентифікації, блокує певні юзер-агенти або має періодичну недоступність.

Виправлення: Сервіруйте політику як простий статичний файл через HTTPS з валідним сертифікатом. Уникайте автентифікації, геоблокувань і хитрощів.

6) Симптом: Деякі MTAs скаржаться на «no shared cipher» або помилки версії TLS

Причина: Надмірно жорсткі TLS-настройки на ваших MX або старий TLS-стек у відправника. У режимі enforce деякі відправники віддадуть помилку замість пониження.

Виправлення: Визначте бізнес-прийнятні мінімальні вимоги. Підтримуйте TLS 1.2. Тримайте шифри сучасними, але не надмірно суворими. Моніторте, хто падає і чи вони важливі.

7) Симптом: Усе виглядає правильно, але вхідна пошта все ще не доходить для частини одержувачів

Причина: Записи MX відрізняються за регіонами через split-horizon DNS, CDN DNS steering або застарілі кеші резолверів, які повертають старі MX. Ваша політика може не охоплювати усі варіанти.

Виправлення: Запитайте публічні резолвери з різних регіонів (або через моніторинг). Переконайтеся, що політика охоплює усі публічні MX-імена, які можуть бути повернуті.

Чек-листи / покроковий план (безпечний rollout)

Крок 0: Інвентаризація реального шляху вхідної пошти

• Перелічіть усі записи MX (включно з «резервними» і шлюзами постачальників).
• Перелічіть будь-які вхідні SMTP-проксі/балансувальники і те, як вони презентують сертифікати.
• Перелічіть сценарії DR/відмов і які зміни в MX відбуваються під час інциденту.

Крок 1: Зробіть TLS нудним (перед публікацією enforce)

• Автоматизуйте видачу/оновлення сертифікатів для кожного публічного MX-імені.
• Переконайтеся, що подається повний ланцюжок (використовуйте fullchain.pem, де потрібно).
• Підтвердіть, що STARTTLS послідовно пропонується і працює на всіх бекендах.
• Не покладайтеся на SMTP SNI для вибору сертифікатів. За потреби віддавайте перевагу виділеним IP:порт слухачам під кожне ім’я хоста.

Крок 2: Розгорніть хост політики правильно

• Забезпечте наявність mta-sts.<domain> у DNS зі стабільним хостингом.
• Сервіруйте /.well-known/mta-sts.txt як статичний plaintext файл по HTTPS.
• Використовуйте валідний сертифікат і не блокуйте доступ WAF-правилами для світу (відправники — це світ).

Крок 3: Опублікуйте MTA-STS у testing режимі

Почніть з:

• mode: testing
• Шаблони MX, що відповідають усім вашим фактичним вхідним MX-хостам
• max_age встановлений помірно (тиждень—поширена практика; коротший період під час початкових ітерацій може бути виправданим)

Потім опублікуйте TXT-запис з чітким id.

Крок 4: Додайте TLS-RPT і справді читайте звіти

• Опублікуйте TXT _smtp._tls, який вказує звіти на моніторовану адресу.
• Налаштуйте правило для поштової скриньки або pipeline для інгесту, щоб звіти не гнили у скриньці.
• Шукайте: який MX падає, чому (сертифікат vs рукопотискання vs DNS), і чи це послідовно.

Крок 5: Проведіть тренування з відмови ще в testing

• Смоделюйте втрату первинного MX (або зміну маршруту) і спостерігайте, який MX обирають відправники далі.
• Підтвердьте, що альтернативний шлях дозволений політикою і проходить TLS-валідацію.
• Виправте відхилення зараз, не під час інциденту.

Крок 6: Перехід в enforce з вікном змін і планом відкату

• Оновіть файл політики до mode: enforce.
• Підвищіть id у DNS.
• Моніторте логи і TLS-RPT принаймні протягом одного вікна кешування.
• План відкату: повернути mode: testing і знову підняти id, якщо ви бачите суттєві проблеми з доставкою.

Крок 7: Підтримка (те, що всі забувають)

• Моніторте терміни дії сертифікатів для: кожного MX + хоста mta-sts.
• Моніторте доступність HTTPS файлу політики.
• Розглядайте зміни MX як пов’язану зміну: DNS + політика + сертифікати, відправлені разом.

FAQ

1) Чи MTA-STS зупинить спам?

Ні. MTA-STS — це безпека транспорту. Воно допомагає запобігти пониженню TLS та примушує валідувати сертифікати. Контроль спаму — це SPF/DKIM/DMARC та фільтрація.

2) Чи MTA-STS зайвий, якщо ми вже використовуємо STARTTLS?

Сам по собі STARTTLS зазвичай опортуністичний: якщо TLS не вдається — багато відправників переходять на відкритий текст. MTA-STS каже підтримуючим відправникам не понижувати для вашого домену.

3) Чи варто одразу переходити в enforce?

Не варто, якщо тільки ви не перевірили кожну кінцеву точку MX, включно з DR і шляхами постачальників, і не маєте автоматизації сертифікатів і моніторингу. Testing режим — недорога страховка.

4) Що фактично робить поле id в політиці?

Це сигнал версії. Відправники кешують політику; коли id змінюється, вони знають, що треба завантажити нову політику. Якщо ви змінюєте політику без зміни id, багато відправників не помітять змін швидко.

5) Чи можна вказувати IP-адреси у MTA-STS замість імен?

Ні. Політики MTA-STS співпадають з іменами MX (точні або wildcard-шаблони). Саме через це поведінка балансувальників і сертифікатів має таке вагоме значення.

6) Що робити, якщо імена MX управляються вендором і змінюються?

Потрібен операційний контракт: стабільні імена або процес оновлення політики і підняття id. Якщо вендор не може гарантувати стабільність — режим enforce стане джерелом регулярних інцидентів.

7) Чи MTA-STS вимагає DNSSEC?

Ні. Це основна відмінність від DANE. MTA-STS покладається на HTTPS і екосистему публічних CA для автентичності політики.

8) Якщо наш хост політики впаде, чи зупиниться пошта?

Зазвичай ні, бо відправники кешують політики. Але це створює невизначеність і відкладені відмови. Тримайте mta-sts.<domain> високодоступним; це невеликий сервіс з великим потенційним впливом.

9) Яке max_age слід використовувати?

Звичні значення — в межах днів до тижнів. Коротші віки зменшують час, протягом якого помилки зберігаються, але збільшують частоту завантажень. Оберіть те, що ви можете оперувати, і пам’ятайте, що кешування у відправників все одно варіюється.

10) Як відкотитися, якщо enforce ламає вхідну пошту?

Оновіть політику на mode: testing (або тимчасово послабте MX-шаблони), а потім підніміть DNS id. Очікуйте, що деякі відправники продовжуватимуть застосовувати кешовану політику, поки не оновлять її.

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

MTA-STS варто ввімкнути, бо опортуністичний TLS — не межа безпеки; це ввічлива порада. Але режим enforce — це обіцянка, і інтернет змусить вас її дотримуватися.

Практичні наступні кроки:

1. Інвентаризуйте всі цілі MX і порівняйте їх з реальністю (включно з постачальниками і DR-шляхами).
2. Розгорніть хост політики як статичний HTTPS-файл з валідним сертифікатом і нудною доступністю.
3. Опублікуйте MTA-STS у режимі testing з правильними MX-шаблонами і помірним max_age.
4. Перевірте STARTTLS + валідацію сертифікатів для кожного MX ззовні вашої мережі.
5. Опублікуйте TLS-RPT і спрямовуйте звіти на моніторовану адресу.
6. Проведіть одне тренування з відмови поки все ще в testing. Виправте те, що ламається. Потім перейдіть до enforce з планом відкату.

Якщо ви робите це як продакшн-зміну — версіонований конфіг, моніторовані кінцеві точки, відпрацьований відкат — MTA-STS стане одним із рідкісних виграшів у безпеці електронної пошти, що не каратиме вас пізніше. Якщо робити це як галочку в чек-листі — воно рано чи пізно розбудить вас опів на другу ночі і зажадає жертви.