--- updatedAt: 2026-09-28T11:18:36.000Z agentTools: projectIndex: https://docs-ua.esputnik.com/llms.txt --- # Налаштування 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-домену >](https://docs-ua.esputnik.com/docs/nalashtuvannya-elektronnogo-pidpisu-dkim-spf-dmarc-ta-mx) ## Що потрібно для 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 запис: | Тип | Ім'я (Host) | Значення | | --- | ------------ | ------------------------------------------------ | | TXT | `_smtp._tls` | `v=TLSRPTv1; rua=mailto:tls-reports@example.com` | Замість `tls-reports@example.com` вкажіть скриньку, яка прийматиме звіти, або сервіс, що їх розбирає. Звіти надходять у форматі 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. Файл політики Розмістіть текстовий файл за адресою: ```text https://mta-sts.<ваш-домен>/.well-known/mta-sts.txt ``` Вимоги стандарту: * файл віддається **лише за HTTPS** з дійсним сертифікатом, виписаним на `mta-sts.<ваш-домен>`; * тип вмісту — `text/plain`; * переадресації не допускаються. Приклад вмісту: ```text 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-записом: | Тип | Ім'я (Host) | Значення | | --- | ----------- | ---------------------------- | | TXT | `_mta-sts` | `v=STSv1; id=20260813120000` | * `v=STSv1` — версія стандарту, значення фіксоване. * `id` — ідентифікатор поточної версії політики. Змінюйте його щоразу, коли редагуєте файл політики, — інакше відправники продовжать використовувати закешовану версію. Згідно з RFC 8461, значення `id` містить від 1 до 32 символів — лише латинські літери й цифри. Це не обов'язково має бути дата: позначка часу — лише зручний спосіб створювати унікальні значення. ## Крок 5. Режими політики | Режим | Що робить відправник | | --------- | ---------------------------------------------------------------------------------------------------------- | | `none` | Політика не діє. Використовується, щоб коректно вивести MTA-STS з експлуатації. | | `testing` | Відправник не блокує доставку при помилці TLS, але надсилає звіт TLS-RPT. Режим для перевірки налаштувань. | | `enforce` | Відправник не доставляє лист, якщо TLS-з'єднання або сертифікат не відповідають політиці. | Починайте з `testing`. Переходьте на `enforce` лише після того, як переконаєтеся зі звітів TLS-RPT, що помилок немає, і що перелік `mx` у політиці відповідає фактичним MX-записам домену. Після зміни файлу політики не забудьте оновити `id` у TXT-записі. > ❗️ Важливо > > У режимі `enforce` помилки в переліку MX-серверів або в їхніх TLS-сертифікатах можуть призвести до затримки чи недоставлення вхідних email. Недоступність файла політики також заважає відправникам отримувати її нові версії. Точну логіку кешування й отримання політики визначає RFC 8461. Змінюйте MX-записи й політику узгоджено. ## Перевірка Перевірте файл політики: ```bash curl -I https://mta-sts.example.com/.well-known/mta-sts.txt ``` Відповідь має бути `200`, із заголовком `Content-Type: text/plain` і без переадресації. Далі прочитайте сам файл і переконайтеся, що синтаксис правильний, а рядки `mx` збігаються з фактичними MX-записами: ```bash curl https://mta-sts.example.com/.well-known/mta-sts.txt dig +short MX example.com ``` Перевірте обидва TXT-записи й повторіть запит через інший резолвер, щоб переконатися, що записи поширилися: ```bash 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-домену](https://docs-ua.esputnik.com/docs/nalashtuvannya-elektronnogo-pidpisu-dkim-spf-dmarc-ta-mx) * [Поширені питання про email-автентифікацію та репутацію домену](https://docs-ua.esputnik.com/docs/poshireni-pitannya-nalashtuvannya-cifrovih-pidpisiv) * [Усунення проблем із верифікацією домену](https://docs-ua.esputnik.com/docs/domain-verification-troubleshooting)