Какая задача решается настройкой почтового домена
Услуга нужна, когда появились новые отправители, письма стали получать ошибки проверки или домен используется для подделки отправителя. Начинать с копирования универсальной TXT-записи рискованно: реальный отправитель может быть не учтен. Сначала выясняем, какие системы разрешены владельцем, какие адреса видит получатель и кто может изменить настройки в каждой системе.
SPF проверяет полномочия отправляющего узла для определенной SMTP-идентичности, DKIM связывает подпись с доменом подписанта, а DMARC сопоставляет прошедший SPF или DKIM с доменом в видимом From. По RFC 9989 достаточно одного успешного согласованного механизма для DMARC pass. Два независимых статуса pass без такого согласования сами по себе не доказывают прохождение DMARC.
Практическая задача CyberFixCrew шире проверки наличия записей: определить владельцев отправки, согласовать изменения и сохранить понятный порядок добавления новых систем. Наши израильские знания в области защиты цифровой инфраструктуры применяются к конкретному домену заказчика. Для международного проекта отдельно согласуем часовой пояс, полномочия и взаимодействие с вашим почтовым провайдером.
Составляем карту отправителей до изменения DNS
Для каждого потока нужны назначение, техническая система, владелец и возможность проверить тестовое сообщение. Корпоративный ящик и уведомление интернет-магазина могут идти через разные сервисы. Поэтому проверка одного письма не заменяет проверку всех потоков. Неизвестный источник в отчете нельзя автоматически разрешать: сначала нужно подтвердить, связан ли он с бизнесом и кто отвечает за него.
| Поток | Что уточнить | Условие приемки |
|---|---|---|
| Корпоративная почта | Провайдер, домен From, подпись | Контрольное письмо и согласованный механизм |
| CRM и счета | Отправляющий сервис и владелец | Письмо из настоящего рабочего маршрута |
| Уведомления сайта | SMTP или почтовый сервис, шаблон From | Отправка без раскрытия данных клиентов |
| Маркетинговая рассылка | Домен подписи и возвратный адрес | Проверка согласования и правил провайдера |
| Неизвестный источник | Разрешение бизнеса и техническая история | Решение владельца до включения в разрешенные |
Проверяем записи и реальные заголовки сообщений
DNS показывает опубликованную конфигурацию, но не то, каким маршрутом ушло конкретное письмо. Для проверки нужны исходные заголовки сообщения у контролируемого получателя и контекст отправляющей системы. Заголовок Authentication-Results интерпретируют с учетом того, какой доверенный принимающий узел его добавил. Пересланный скриншот имени отправителя не заменяет эти данные.
Для SPF учитываем действующую запись и ограничения вычисления, а не создаем вторую независимую политику. Для DKIM проверяем домен подписи и нужный селектор, а не случайное имя в DNS. Доступ к секретному ключу не требуется передавать в заявку. При изменениях сохраняем исходное состояние, согласованный порядок публикации и способ возврата, если рабочая отправка нарушится.
- Подтвердить владельца домена и разрешенных отправителей.
- Согласовать доступ к DNS и настройкам каждого сервиса.
- Подготовить изменения с учетом существующих записей.
- Проверить сообщения из согласованных рабочих потоков.
- Записать результат, ограничения и план дальнейшего наблюдения.
Как выбирать политику DMARC без слепого ужесточения
Решение о политике принимается после проверки отправителей и оставшихся исключений. Наблюдение с p=none не просит получателя применять quarantine или reject к сообщениям, не прошедшим DMARC. Более строгая политика тоже не заменяет решение принимающей стороны. Нельзя обещать, что публикация p=reject остановит все мошеннические письма или обеспечит доставку каждого законного сообщения.
RFC 9989 опубликован в мае 2026 года и заменил RFC 7489 и RFC 9091. Старый параметр pct не используем как обещание постепенного применения текущей политики. Готовность к изменениям оцениваем по известным потокам, отчетам и проверенным исключениям. Условия Gmail относятся к его получателям и категориям отправителей; их нельзя автоматически объявлять одинаковыми требованиями всех почтовых систем.
Какие угрозы остаются после настройки
DMARC не защищает от письма с похожего, но другого домена, обманного отображаемого имени или уже захваченного законного ящика. При изменении платежных реквизитов требуется независимая проверка известным способом связи. Успешная аутентификация показывает определенные свойства домена и сообщения, а не добросовестность человека и не полномочие менять условия оплаты.
Проблема доставки может также зависеть от репутации, содержания, согласия адресата и правил получателя. Поэтому отчет об успешной настройке не должен превращаться в гарантию попадания во входящие. Если есть признаки компрометации учетной записи, отдельно проверяем доступ, сеансы и правила пересылки в согласованном объеме. Подмена домена и взлом ящика требуют разных действий.
Что входит в передачу результата и как подготовиться
В передаваемом результате нужны карта отправителей, согласованные изменения, проверенные маршруты, исключения и владельцы дальнейших действий. Уточняем, кто получает агрегированные отчеты и кто добавляет новые сервисы. Отчеты могут содержать технические сведения о почтовом потоке; доступ и хранение выбираются под условия бизнеса. Постоянный анализ отчетов не включается автоматически в разовую настройку.
Для заявки укажите домен, почтового провайдера, известные CRM и сервисы рассылок, а также наблюдаемую проблему. Не отправляйте пароли, полный почтовый архив или клиентские письма с лишними персональными данными. Стоимость зависит от числа доменов, потоков и ограничений доступа; после обсуждения согласуем объем работ. Лицензии сторонних сервисов и последующее сопровождение нужно оговорить отдельно.