Как не перепутать From, envelope sender, HELO и PTR, определить фактический исходящий IP, проверить прямое подтверждение reverse DNS и понять, кто может изменить PTR, прежде чем править SPF или почтовый домен.
Сначала найдите реальный исходящий IP
Возьмите один свежий bounce или заголовки тестового письма и определите IP сервера, который непосредственно подключался к принимающей стороне. Не публикуйте полный заголовок: в нём могут быть адреса, внутренние имена и идентификаторы. Запишите код SMTP, hostname из ответа и исходящий IP. Если почту отправляет Microsoft 365, Google Workspace или другой relay, проверять нужно инфраструктуру этого relay, а не IP сайта или домашнего роутера.
Разведите пять похожих имён
В одном письме участвуют видимый From, envelope MAIL FROM, домен DKIM, имя HELO или EHLO и hostname из PTR исходящего IP. Они выполняют разные функции и не обязаны быть одной строкой. Формулировка «PTR не совпадает с доменом отправителя» недостаточна, пока не указано, с каким именно полем сравнивают. Составьте таблицу этих значений для одного сообщения. Не меняйте From или MX только ради косметического совпадения с именем узла relay.
Проверьте прямую и обратную цепочку
Для исходящего IP выполните reverse lookup и получите PTR hostname, затем сделайте A или AAAA lookup этого hostname. В корректной forward-confirmed схеме прямой ответ возвращает исходный IP. Требования Gmail для отправителей прямо требуют действительных прямых и обратных DNS-записей. Если PTR отсутствует или hostname не возвращает IP, сохраните оба результата и TTL. Не добавляйте PTR в обычную прямую DNS-зону: это запись зоны владельца адресного пространства.
Определите владельца изменения
Microsoft отмечает, что reverse zones обычно обслуживает провайдер или владелец IP. Для арендованного сервера PTR меняется в панели хостинга или через его поддержку; для управляемого почтового сервиса пользователь часто не контролирует исходящие адреса. Перед запросом сформулируйте желаемый FQDN и убедитесь, что его A или AAAA уже указывает на тот же IP. Не создавайте несколько противоречивых PTR и не обещайте мгновенную доставку после одной DNS-правки.
Проверьте аутентификацию отдельно
Даже корректный PTR не заменяет SPF, DKIM, DMARC, TLS и приемлемую репутацию. Google перечисляет эти требования отдельно, а Microsoft показывает, что крупная почтовая система может иметь различающиеся, но согласованные имена PTR и HELO. После изменения повторите тест на одном адресате и сохраните новый SMTP-ответ. Эскалируйте владельцу relay, если исходящий IP меняется или недоступен для управления; приложите время UTC, IP, PTR и прямой ответ без адресов получателей.
Материал подготовлен самостоятельно с автоматизацией и редакционно проверен 30 июля 2026 года по обезличенному сигналу Microsoft Q&A, официальным требованиям Gmail и документации Microsoft по PTR.
Источники и проверка
- Gmail Help — требования к отправителям электронной почты проверено 2026-07-30
- Microsoft Learn — отсутствие PTR у исходящего IP проверено 2026-07-30
- Microsoft Learn — различие PTR и HELO в Exchange Online проверено 2026-07-30
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.