Інструменти мережевої діагностики
Перевірте свій запис Sender Policy Framework
DNS та записи
Пошук DNS Усі записи DNS для будь-якого домену Пошук запису A IPv4-адреси домену Пошук запису AAAA IPv6-адреси домену Пошук MX Поштові сервери домену Пошук NS Авторитетні сервери імен Пошук TXT Записи TXT, SPF, верифікація Пошук CNAME Записи канонічного імені (псевдонім) Пошук SOA Запис Start of Authority Пошук SRV Записи розташування сервісів Пошук CAA Які CA можуть видавати сертифікати Зворотний DNS (PTR) IP-адреса до імені хоста Перевірка DNSSEC Чи підписаний і валідований домен? Перевірка стану DNS Повний звіт про делегування та стан DNSДоставлюваність пошти
Перевірка SPF Перевірте свій запис Sender Policy Framework Перевірка DMARC Перевірте та оцініть свою політику DMARC Перевірка DKIM Знайдіть і перевірте свій відкритий ключ DKIM Перевірка чорних списків Перевірте IP за поштовими чорними списками (DNSBL) Тест SMTP Підключіться до поштового сервера та перевірте STARTTLS Перевірка MTA-STS Примусова політика TLS для вхідної пошти Перевірка BIMI Запис логотипа бренду для пошти Перевірка TLS-RPT Політика звітності SMTP TLSМережа та веб
Перевірка SSL-сертифіката Перевірте TLS-сертифікат сайту та термін дії Перевірка заголовків HTTP Перевірте заголовки відповіді, перенаправлення та безпеку Ping (TCP) Доступність і затримка через TCP Перевірка портів Які поширені порти відкритіДомен
Пошук WHOIS Реєстраційні дані для доменів, IP та ASNSPF (Sender Policy Framework) повідомляє поштовим серверам-отримувачам, яким хостам дозволено надсилати листи від імені вашого домену. Зламаний запис SPF — з дублюванням, надмірною кількістю DNS-запитів або без механізму «all» — призводить до того, що легітимні листи потрапляють у спам. IPeek знаходить ваш запис SPF, розбирає кожен механізм і позначає проблеми, що шкодять доставлюваності.
SPF зберігається як TXT-запис на кореневому домені та починається з v=spf1. Коли сервер отримує лист, що нібито надійшов від вас, він шукає цей запис і перевіряє, чи авторизована IP-адреса відправника. Запис на кшталт v=spf1 include:_spf.google.com ip4:198.51.100.10 -all означає: «дозволити хости Google і цю одну IP-адресу, відхилити решту». Механізми оцінюються зліва направо; виграє перший збіг. Кінцевий механізм all є загальним правилом, що визначає типовий результат для будь-якого хоста, не вказаного явно.
Механізм all задає вашу політику: -all — це hardfail (відхиляти невказаних відправників), ~all — softfail (приймати, але позначати як підозрілі), а +all дозволяє будь-кого — ніколи не використовуйте його. SPF також обмежує механізми, що роблять DNS-запити (include, a, mx, ptr, exists, redirect), 10 запитами загалом; перевищення цього ліміту дає permerror, який трактується як збій. Вкладені include теж рахуються, тож додавання кількох постачальників непомітно вичерпує ліміт. IPeek рахує кожен запит і попереджає, перш ніж ви досягнете межі.
Самого SPF недостатньо. Він автентифікує відправника на рівні конверта (return-path), а не видиму адресу From, яку бачать користувачі, тож шахраї можуть пройти SPF, підробивши ваш бренд. DMARC усуває цю прогалину, вимагаючи відповідності (alignment) між доменом SPF і доменом From, та поєднуючи SPF із DKIM, щоб будь-який із них міг автентифікувати лист. Сприймайте SPF як один із трьох рівнів: SPF авторизує хости, DKIM підписує вміст, а DMARC прив’язує їх до вашого домену From і застосовує політику.
SPF дозволяє максимум 10 механізмів із DNS-запитами на одну перевірку. Механізми include, a, mx, ptr, exists і redirect кожен витрачає запити, а вкладені include враховуються в тому самому ліміті. Перевищення 10 дає permerror, який отримувачі трактують як збій автентифікації. Згорніть або об’єднайте include, щоб не виходити за межу.
Різниця в застосуванні. -all — це hardfail, що вказує отримувачам відхиляти листи від будь-якого хоста, не зазначеного у вашому записі, тоді як ~all — це softfail, що вказує приймати їх, але вважати підозрілими. Використовуйте ~all під час тестування, а потім переходьте на -all, щойно переконаєтеся, що всі легітимні відправники авторизовані. Уникайте +all, який авторизує будь-кого.
Самого запису SPF недостатньо, щоб гарантувати потрапляння у вхідні. Поширені причини: перевищення ліміту у 10 запитів (permerror), відсутній або надто дозвільний механізм all, хост-відправник, який насправді не авторизований, або дублікати записів SPF на одному домені. SPF також не захищає вашу видиму адресу From — для надійної доставлюваності вам потрібні DKIM і DMARC поряд із ним.
Ні. Домен має публікувати рівно один TXT-запис SPF (v=spf1). Два чи більше записи SPF спричиняють permerror, і отримувачі можуть відхиляти ваші листи або не проходити автентифікацію. Якщо потрібно авторизувати кількох відправників, об’єднайте їх в один запис за допомогою додаткових механізмів include чи ip4/ip6, а не додавайте другий запис.
Ні. SPF автентифікує відправника на рівні конверта (return-path або MAIL FROM), а не заголовок From, який насправді бачать ваші отримувачі. Саме тому одного SPF недостатньо, щоб зупинити підробку вашого бренду. DMARC додає вирівнювання SPF, вимагаючи, щоб домен SPF збігався з видимим доменом From, що й усуває розрив між перевірками на рівні протоколу і тим, що читають користувачі.