Это демонстрационный отчет: он показывает формат платного аудита MailAudit, структуру выводов, доказательства и план исправлений. Данные ниже примерные и не относятся к реальному клиенту.
В рабочем аудите каждая проблема хранится отдельно: что найдено, почему это важно, чем подтверждается и кто должен исправить. Такой формат удобно превращать в задачи.
Получатели могут считать письмо поддельным, усиливать spam score или отклонять доставку.
Envelope sender: mail@example-company.ru, IP: 203.0.113.18, SPF: v=spf1 include:crm.example -all.
Добавить отправляющий IP или корректный include сервиса отправки, затем повторить проверку письма.
Почтовые системы хуже доверяют SMTP-серверу, особенно при B2B-доставке.
PTR указывает на mail.example.net, но hostname не резолвится обратно в 203.0.113.18.
Настроить PTR у провайдера IP и A-запись hostname так, чтобы проверка совпадала в обе стороны.
Домен собирает отчеты, но не защищает получателей от spoofing на уровне политики.
_dmarc.example-company.ru TXT: v=DMARC1; p=none; rua=mailto:dmarc@example-company.ru.
После стабилизации SPF/DKIM перейти к quarantine, затем к reject, контролируя отчеты DMARC.
Часть фильтров и клиентов воспринимает такое письмо хуже, чем multipart/alternative.
Content-Type: text/html, plain text fallback не найден.
Настроить CRM или рассылочный сервис на отправку multipart/alternative: text/plain + text/html.
Это чаще security hardening, но лишние детали могут раскрывать инфраструктуру отправителя.
Received и X-* headers содержат внутренние имена серверов и версии ПО.
Настроить header cleanup на MTA или шлюзе, не удаляя заголовки, нужные для DKIM/DMARC.
Начать можно с бесплатной проверки письма. Если проблема сложнее одного письма, платный аудит связывает DNS, сервер, репутацию, логи и реальные симптомы в единый план исправлений.