Налаштування MTA-STS і TLS-RPT

MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) — відкритий стандарт, який дозволяє власнику домену оголосити, що пошта на його домен має прийматися лише через TLS-з'єднання з дійсним сертифікатом. Це захищає вхідну пошту від атак пониження шифрування (downgrade) і підміни MX.

📘

Хто налаштовує

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

Політику MTA-STS виконують лише поштові сервери, які підтримують цей стандарт. Інші сервери продовжують доставляти пошту без додаткової перевірки MTA-STS.

MTA-STS і DMARC

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

MTA-STS не вимагає ані DMARC, ані певної політики DMARC. Автентифікація домену відправника (SPF, DKIM, DMARC) налаштовується окремо. Автентифікація email-домену >

Що потрібно для MTA-STS

MTA-STS складається з чотирьох частин:

1. Піддомен mta-sts.<ваш-домен> — робочий вебхост із дійсним TLS-сертифікатом.
2. Файл політики, доступний за HTTPS на цьому піддомені — містить перелік ваших MX-серверів і режим політики.
3. DNS-запис TXT на піддомені _mta-sts.<ваш-домен> — сигналізує відправникам, що політика існує, і зберігає її версію.
4. DNS-запис TXT на піддомені _smtp._tls.<ваш-домен> — просить відправників надсилати вам звіти TLS-RPT.

Відправник спершу читає DNS-запис, і якщо значення id змінилося — завантажує файл політики й кешує його на час max_age.

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

Порядок налаштування

Файл політики має бути доступний до того, як DNS оголосить про її наявність. Щойно з'явиться запис _mta-sts, відправники почнуть шукати політику, тому на цей момент файл має бути на місці й коректний. Наведений порядок відповідає рекомендаціям Google Workspace і Microsoft.

1. Налаштуйте TLS-RPT.
2. Створіть піддомен mta-sts і його хостинг.
3. Розмістіть файл політики в режимі testing і перевірте його.
4. Опублікуйте DNS-запис _mta-sts.
5. Проаналізуйте звіти й перейдіть на enforce.

Крок 1. Звіти TLS-RPT

TLS-RPT (RFC 8460) — окремий стандарт, який дозволяє отримувати від відправників щоденні звіти про успішні й невдалі TLS-з'єднання з вашими MX-серверами. Налаштуйте його першим, щоб звіти охоплювали весь період тестування.

Додайте в DNS запис:

Замість [email protected] вкажіть скриньку, яка прийматиме звіти, або сервіс, що їх розбирає. Звіти надходять у форматі JSON і показують, скільки з'єднань пройшло успішно, а скільки завершилося помилкою і з якої причини. Типові причини помилок:

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

📘

Адреса для звітів в іншому домені

Якщо адреса для звітів належить не тому домену, про який ці звіти, домен-одержувач має підтвердити свою згоду приймати їх додатковим DNS-записом. Ця вимога описана в RFC 8460; сервіс звітності підкаже точний запис.

Крок 2. Піддомен mta-sts

Файл політики віддається за HTTPS з окремого піддомену mta-sts, тому цей піддомен має існувати як робочий вебхост:

1. Створіть запис A, AAAA або CNAME для mta-sts.<ваш-домен>, який вказує на вебсервер або спеціалізований сервіс, що віддаватиме файл.
2. Налаштуйте на цьому сервері віддавання шляху /.well-known/.
3. Випустіть TLS-сертифікат, дійсний для mta-sts.<ваш-домен>.

Без цих трьох кроків адреса політики просто не існує, і всі наступні кроки не працюють.

Крок 3. Файл політики

Розмістіть текстовий файл за адресою:

https://mta-sts.<ваш-домен>/.well-known/mta-sts.txt

Вимоги стандарту:

• файл віддається лише за HTTPS з дійсним сертифікатом, виписаним на mta-sts.<ваш-домен>;
• тип вмісту — text/plain;
• переадресації не допускаються.

Приклад вмісту:

version: STSv1
mode: testing
mx: mx1.example.com
mx: mx2.example.com
max_age: 604800

• mode — режим політики, див. нижче. Починайте з testing.
• mx — по одному рядку на кожен MX-хост вашого поштового провайдера. Значення мають збігатися з MX-записами домену; підтримуються шаблони на кшталт *.example.com.
• max_age — час кешування політики відправниками в секундах. Для періоду тестування беріть невелике значення (наприклад, 86400 — доба), для робочої політики — до 31557600.

Перевірте файл, як описано в розділі Перевірка, і лише тоді переходьте далі.

Крок 4. DNS-запис _mta-sts

Коли файл політики доступний і коректний, оголосіть його TXT-записом:

• v=STSv1 — версія стандарту, значення фіксоване.
• id — ідентифікатор поточної версії політики. Змінюйте його щоразу, коли редагуєте файл політики, — інакше відправники продовжать використовувати закешовану версію.

Згідно з RFC 8461, значення id містить від 1 до 32 символів — лише латинські літери й цифри. Це не обов'язково має бути дата: позначка часу — лише зручний спосіб створювати унікальні значення.

Крок 5. Режими політики

Починайте з testing. Переходьте на enforce лише після того, як переконаєтеся зі звітів TLS-RPT, що помилок немає, і що перелік mx у політиці відповідає фактичним MX-записам домену. Після зміни файлу політики не забудьте оновити id у TXT-записі.

❗️

Важливо

У режимі enforce помилки в переліку MX-серверів або в їхніх TLS-сертифікатах можуть призвести до затримки чи недоставлення вхідних email. Недоступність файла політики також заважає відправникам отримувати її нові версії. Точну логіку кешування й отримання політики визначає RFC 8461. Змінюйте MX-записи й політику узгоджено.

Перевірка

Перевірте файл політики:

curl -I https://mta-sts.example.com/.well-known/mta-sts.txt

Відповідь має бути 200, із заголовком Content-Type: text/plain і без переадресації. Далі прочитайте сам файл і переконайтеся, що синтаксис правильний, а рядки mx збігаються з фактичними MX-записами:

curl https://mta-sts.example.com/.well-known/mta-sts.txt
dig +short MX example.com

Перевірте обидва TXT-записи й повторіть запит через інший резолвер, щоб переконатися, що записи поширилися:

dig +short TXT _mta-sts.example.com
dig +short TXT _smtp._tls.example.com
dig +short TXT _mta-sts.example.com @1.1.1.1

Переконайтеся, що кожен хост із переліку mx приймає STARTTLS з дійсним сертифікатом. Зовнішній валідатор MTA-STS корисний як додаткова перевірка, але не як єдиний доказ коректності налаштування.

Залишайте політику в режимі testing щонайменше кілька днів, а для доменів із невеликим або нерегулярним поштовим трафіком — кілька тижнів. Переходьте на enforce лише після того, як звіти охоплять усі основні джерела вхідної пошти й не показуватимуть системних помилок.

Якщо після ввімкнення enforce виникли проблеми

1. Змініть у файлі політики mode: enforce на mode: testing.
2. Опублікуйте оновлений файл.
3. Змініть id у DNS-записі _mta-sts, щоб відправники завантажили нову версію.
4. Перевіряйте TLS-RPT і виправте проблеми з MX-серверами або сертифікатами.

Через кешування зміна може застосуватися не миттєво. Не видаляйте DNS-запис: відправники можуть продовжувати використовувати закешовану політику до завершення max_age.

Зміна MX-серверів

Змінюйте MX-записи й політику узгоджено:

1. Переведіть політику в режим testing і змініть її id.
2. Додайте нові MX-хости до файла політики до зміни DNS.
3. Перевірте їхні TLS-сертифікати та STARTTLS.
4. Змініть MX-записи домену.
5. Проаналізуйте TLS-RPT.
6. Поверніться до enforce і знову оновіть id.

Враховуйте попереднє значення max_age: закешована політика може діяти в частини відправників до завершення цього періоду.

Пов'язані статті

• Автентифікація email-домену
• Поширені питання про email-автентифікацію та репутацію домену
• Усунення проблем із верифікацією домену