Як перевірити записи MX, SPF, DKIM і DMARC?

Як перевірити запис MX?

Виконайте dig MX з вашим доменом і +short, і порівняйте пріоритети та імена хостів зі значеннями, які дав ваш провайдер. Відповідь друкує по одному рядку на запис: пріоритет, пробіл і хост. Для Proton Mail очікуйте 10 mail.protonmail.ch. і 20 mailsec.protonmail.ch.; для Fastmail 10 in1-smtp.messagingengine.com. і 20 in2-smtp.messagingengine.com.; для Mailbox.org чотири хости mxext.

Тут видно дві проблеми. Запис попереднього провайдера, що лишився в списку, робить доставку непередбачуваною, тож його треба видалити. А порожня відповідь означає відсутність MX: відправники тоді повертаються до адресного запису домену, як описує RFC 5321. Що означає кожен рядок, пояснено в що таке запис MX.

Як перевірити запис SPF?

Запросіть записи TXT у корені домену і переконайтеся, що рівно один рядок починається з v=spf1. У корені також лежать інші записи TXT, наприклад підтвердження власності від вашого поштового провайдера, тож прочитайте весь список. Два рядки, що починаються з v=spf1, — помилка: RFC 7208 повертає постійну помилку, коли в домену більше одного запису SPF.

Потім порахуйте запити. Кожне include, a, mx, ptr і exists, а також модифікатор redirect рахуються в ліміті 10, і include також рахує те, що вкладено всередині нього. Запис понад ліміт не проходить для кожного відправника. Як створити запис, детально описано в як створити запис SPF.

Як перевірити DKIM, якщо я не знаю селектора?

Використайте селектор свого провайдера: селектори з DNS не перелічити, тож візьміть їх з екрана DKIM провайдера. DNS не дозволяє переліку імен під _domainkey. Селектори у Proton Mail — protonmail, protonmail2 і protonmail3, у Fastmail — fm1, fm2 і fm3, а у Mailbox.org — від MBO0001 до MBO0004.

Ім'я для запиту — selector._domainkey.yourdomain. Провайдер, що використовує записи CNAME, як ці три, відповідає CNAME на свій хост. Провайдер, який публікує ключ напряму, відповідає записом TXT, що містить v=DKIM1 і p=, а далі відкритий ключ. Порожнє p= означає, що ключ відкликано. Найсильніший тест — справжній лист, бо запис, що існує, може бути невикористаним: надішліть лист до іншого провайдера і прочитайте dkim=pass у повних заголовках.

Як перевірити запис DMARC?

Запросіть запис TXT на _dmarc.yourdomain і переконайтеся, що є один рядок, який починається з v=DMARC1 і містить політику p=. Якщо p немає, одержувачі вважають політику none. Якщо в рядку немає rua, сукупні звіти не створюються, і етап моніторингу з розгортання DMARC нічого вам не скаже. Записи у старому стилі можуть досі мати тег pct, який RFC 9989 прибрав.

Піддомен без власного запису підпорядковується політиці батьківського домену через обхід дерева DNS, не більше ніж вісім запитів. Запит імені, для якого немає запису, нічого не повертає, що те саме, що відсутність DMARC.

Чому мій запит досі показує старе значення?

Кеш тримає стару відповідь доти, доки не закінчиться її TTL, і відсутній запис також може бути в кеші. Час поширення зміни приблизно дорівнює старому TTL запису в момент зміни. Рекомендації постачальників дають звичний час зміни MX від однієї до чотирьох годин і до 24–48 годин у найгіршому разі. RFC 2308 додає, що негативні відповіді кешуються з TTL із запису SOA зони, тож щойно створений запис може здаватися відсутнім у деяких резолверах.

Щоб обійти кеші, запитайте авторитетний сервер імен: знайдіть його через dig NS, потім повторіть запит з @ і його іменем, як у блоці коду вище. Якщо авторитетний сервер показує нове значення, а ваш резолвер — ні, зачекайте. Якщо не показує ні той, ні інший, запис не збережено або ім'я хоста неправильне, найчастіше тому, що редактор DNS додав домен удруге.

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

Які онлайн-інструменти можуть перевірити записи пошти?

Будь-яка онлайн-перевірка DNS або перевірка автентифікації пошти, що запитує публічний DNS, дає ту саму відповідь, що й dig, але з зручнішим відображенням. Користуйтеся тим, що показує сирий текст запису, щоб порівняти його посимвольно зі значенням вашого провайдера. Не вставляйте туди приватних даних: їй потрібна лише назва домену.

За підрахунком Postelva від 12 листопада 2026, повне налаштування Proton Mail займає 8 записів (1 TXT для підтвердження, 2 MX, 1 SPF, 3 DKIM, 1 DMARC) і 6 запитів, бо два записи MX ділять один запит, а записи підтвердження і SPF — спільний запит TXT для кореня. Збережіть шість команд один раз і повторюйте їх після кожної зміни. Ті самі записи порівнює SPF проти DKIM проти DMARC.

Правило, яке можна цитувати: після кожної зміни DNS запитуйте чотири типи записів і надсилайте тестовий лист; запис правильний лише тоді, коли запит і лист погоджуються.