MX, SPF, DKIM и DMARC: что это и почему письма не доходят

Что такое DNS и зачем почте несколько разных записей

DNS это система доменных имён. Она хранит сведения, по которым программы находят нужные службы домена и получают опубликованные владельцем правила. Домен компании может одновременно использоваться для сайта и почты. Наличие работающего сайта само по себе ничего не говорит о корректности почтовых настроек.

Словом «запись» называют отдельный элемент этих сведений. У записей бывают разные типы и задачи. MX описывает направление входящей почты. SPF и DMARC публикуются как текстовые сведения. Для DKIM в DNS размещают данные, позволяющие проверить подпись. Поэтому просьба «посмотреть DNS» требует уточнения: какое именно письмо и какую функцию проверяют.

Полезно разделять два направления. Входящие письма приходят в компанию от партнёров. Исходящие уходят из компании сотрудникам других организаций и клиентам. Проблема в приёме не доказывает проблему с подписью исходящего письма. Хорошая подпись, в свою очередь, не исправляет адрес, на который пытается писать контрагент.

Отдельно существует доступ к самому ящику. IMAP связан с чтением и синхронизацией почты в клиенте, SMTP используется при отправке. Если программа не может подключиться к почтовой службе, наличие правильных доменных записей не возвращает ей доступ.

Что такое MX-запись и за что она отвечает

MX-запись это указание, какие почтовые серверы принимают сообщения для домена. Когда партнёр пишет на корпоративный адрес, его почтовая система использует эти сведения для поиска принимающей стороны. При наличии нескольких MX у них есть приоритеты, которые участвуют в выборе сервера.

Представьте адрес компании в справочнике. Он помогает доставить корреспонденцию в нужное здание. При этом наличие адреса не подтверждает, что внутри существует нужный кабинет. Так же MX не создаёт ящик сотрудника, алиас или общий адрес отдела. Принимающая почтовая система должна знать, какие адреса она обслуживает.

Неверный сервер в MX может объяснять недоставку входящих писем или попадание корреспонденции в другую почтовую систему. Но отсутствие одного сообщения в папке «Входящие» ещё не доказывает ошибку MX. Сообщение могло оказаться в другой папке, быть отклонено принимающим сервером или адресовано с опечаткой.

Для разбора полезно знать полный адрес получателя и получить уведомление о недоставке, если оно есть. Формулировка «нам никто не пишет» слишком широкая. Уточните, затронуты ли все адреса компании, отдельный сотрудник или общий ящик. Это разные признаки, и они помогают специалисту оценить границы проблемы.

MX не разрешает серверу отправлять письма от имени компании. Входящая и исходящая почта могут обслуживаться разными системами. Поэтому вывод «MX правильный, значит отправитель подтверждён» неверен. Для исходящих сообщений есть другие механизмы.

SPF это проверка разрешённого источника отправки

SPF это механизм, который позволяет принимающей стороне проверить, разрешён ли IP-адрес отправляющего сервера правилами проверяемого домена. Владелец домена публикует такие правила в DNS. Получатель сопоставляет их с источником конкретного сообщения.

Важная деталь: SPF обычно проверяет домен технического адреса возврата, который используется при передаче письма. Это не обязательно тот адрес, который человек видит в строке «От кого». У SMTP есть служебная информация, а у письма есть собственные заголовки. Если смешать эти уровни, результат проверки легко истолковать неверно.

У компании может быть несколько источников исходящих сообщений. Сотрудники отвечают из почтового сервиса, сайт отправляет заявки, CRM сообщает о документах. Для каждого источника важно понимать, откуда реально выходит письмо. Успешная отправка сотрудника не подтверждает, что тот же результат будет у сайта.

Типичная ошибка возникает, когда разрешения не соответствуют действующим отправителям. Тогда законная система компании может не пройти SPF. Обратная крайность тоже нежелательна: слишком широкое разрешение делает проверку менее полезной. Правила должны описывать реальные источники, а их смысл должен быть понятен ответственному администратору.

SPF не подписывает содержимое письма и не доказывает, что пользователь прочитал сообщение. Он отвечает на ограниченный технический вопрос об источнике отправки. Поэтому его результат нужно читать рядом с другими сведениями, а не превращать в общий вердикт «почта работает правильно».

DKIM это подпись письма, а не список разрешённых IP

DKIM это механизм электронной подписи почтового сообщения. Отправляющая система добавляет подпись, а получатель проверяет её по открытому ключу, опубликованному для указанного домена. Подпись охватывает определённые заголовки и содержимое письма по правилам DKIM.

Корректная подпись помогает подтвердить, что подписанные части сообщения не изменились после подписания. Она также показывает связь подписи с указанным в ней доменом. Это техническое подтверждение. Оно не является оценкой честности текста, подлинности счёта или полномочий человека, который написал письмо.

В подписи указывается селектор. Это обозначение, по которому получатель находит подходящий открытый ключ в DNS. Если подпись ссылается на ключ, который недоступен или не соответствует ей, проверка не сможет завершиться успешно. Такое расхождение нужно объяснять на уровне подписывающей системы и опубликованных сведений.

Ещё одна возможная причина ошибки связана с изменением подписанных частей после подписания. Поэтому одного сообщения «DKIM не прошёл» мало. Важно видеть само письмо с техническими заголовками и понимать, через какие системы оно прошло. Пересказ текста сотрудником не сохраняет этих данных.

SPF и DKIM дополняют друг друга, но проверяют разное. SPF смотрит на разрешение источника. DKIM проверяет подпись. Из успешного SPF нельзя вывести наличие корректной DKIM-подписи, а из успешного DKIM нельзя сделать вывод, что SPF тоже прошёл. В заключении специалиста должны быть отдельные результаты.

Что такое DMARC и почему важен домен в строке «От кого»

DMARC это механизм проверки домена видимого отправителя на основе SPF и DKIM. Он помогает принимающей системе оценить, согласуются ли технические подтверждения с доменом, который человек видит в поле «От кого». Такое согласование называют выравниванием доменов.

Для успешного DMARC достаточно успешного SPF с подходящим выравниванием или успешного DKIM с подходящим выравниванием. Само слово «успешно» в строке SPF ещё не означает успешный DMARC. Проверка могла пройти для другого домена, который не согласуется с доменом видимого отправителя.

Политика DMARC сообщает получателям пожелание владельца домена о работе с сообщениями, которые не проходят проверку. Также предусмотрены отчёты. Они помогают увидеть использование домена и результаты проверок. Получение отчёта само по себе не исправляет обнаруженную ошибку и не объясняет деловую цель каждого отправителя.

Основная задача этого механизма связана с защитой от подделки домена отправителя. При этом DMARC не проверяет, правдив ли текст письма, и не закрывает все способы обмана. Злоумышленник может использовать похожее имя, другой домен или чужую скомпрометированную учётную запись. Сотрудникам всё равно нужны понятные правила проверки необычных запросов.

Для компании полезен вопрос: совпадает ли представление получателя об отправителе с технически подтверждённым доменом? Его стоит задавать отдельно для переписки сотрудников, сайта и деловых программ. У разных источников могут быть разные технические адреса и подписи, хотя внешне они используют имя одной организации.

Почему письмо всё равно может попасть в спам

Успешные SPF, DKIM и DMARC подтверждают определённые технические свойства сообщения. Они не обязывают принимающий сервис положить его во входящие. На решение могут влиять репутация источника, содержание, вложения, жалобы получателей и внутренние правила принимающей системы.

Полезно различать три результата. Письмо может быть отклонено с сообщением об ошибке. Оно может быть принято, но оказаться в нежелательной почте. Наконец, оно может находиться в ящике, однако пользователь его не видит из-за папки или правил обработки. Для каждого случая нужны свои подтверждения.

Статус «отправлено» в программе часто означает, что сообщение принято ближайшей отправляющей системой. Он не подтверждает прочтение адресатом и не всегда говорит о конечной папке. Просите точное описание статуса и доступное уведомление о результате, а не делайте вывод по одной зелёной отметке.

Вымышленный пример. У условной компании из Алматы письма сотрудников приходят партнёрам, а уведомления сайта оказываются в спаме. Это не противоречие: источники отправки различаются. Для разбора нужны отдельные образцы обоих писем. Проверять только ящик сотрудника и распространять результат на сайт недостаточно.

Другой вымышленный случай: партнёр сообщает, что не получает письмо, хотя соседний адресат его видит. Это повод сравнить конкретные адреса и ответы принимающих систем. Делать вывод о поломке всей корпоративной почты по одному получателю рано. Так же рано обещать решение заменой одной записи.

Что подготовить для предметного разбора

Соберите сведения о проблемном сообщении: адрес отправителя, адрес получателя, тему, время отправки и название программы. Сохраните текст уведомления о недоставке полностью. Если сообщение пришло в спам, попросите получателя сохранить его с техническими заголовками. Перед передачей согласуйте защиту конфиденциальной переписки.

Укажите все известные источники: сотрудники, сайт, CRM, 1С, принтеры и сканеры. Отметьте, кто отвечает за каждую систему и где хранится её описание. Не передавайте пароли в открытой переписке. Для обсуждения проблемы обычно важнее понять состав систем и характер сбоя, чем получить бессистемный набор доступов.

Отдельно уточните, кто управляет доменом и корпоративной почтой. Эти роли могут находиться у разных людей или подрядчиков. Руководителю нужен понятный ответ о владельце настроек и ответственном за обращения. При выборе между размещением у провайдера и собственной инфраструктурой используйте разбор своего почтового сервера и облака.

Для бизнеса в Казахстане вопросы обработки переписки и персональных данных проверьте с юристом с учётом отрасли и договоров. Техническая корректность записей не заменяет такую оценку. Вопросы доступности и условий конкретного сервиса уточняйте у его поставщика.

Частые вопросы

MX и SPF это одна настройка?

У них разные задачи. MX указывает принимающие серверы домена. SPF помогает проверить разрешённый источник исходящего сообщения. Работа входящих писем не доказывает корректность исходящей отправки, поэтому результаты оценивают отдельно для конкретной ситуации.

Если DKIM прошёл, письмо точно настоящее?

Успешная проверка подтверждает подпись и целостность подписанных частей. Она не доказывает правдивость текста и право автора просить оплату. Необычные запросы проверяйте по принятым в компании правилам, даже если технические проверки сообщения успешны.

Почему DMARC не проходит при успешном SPF?

Для DMARC важно выравнивание с доменом видимого отправителя. SPF может успешно подтвердить другой технический домен. Нужны сведения о конкретном сообщении и результатах DKIM, чтобы понять итог DMARC и причину расхождения.

Правильные записи гарантируют попадание во входящие?

Нет. Получатель применяет собственные правила и учитывает другие признаки сообщения. Технические проверки являются частью оценки. Если письмо оказалось в спаме, сохраните его и разберите результаты вместе с данными об источнике отправки.

Поможет ли DNS, если почтовый клиент не подключается?

Причина может быть в доступе к службе, авторизации или условиях провайдера. MX, SPF, DKIM и DMARC не дают программе право входа в ящик. Опишите ошибку подключения отдельно от ошибок доставки, чтобы не смешивать два разных вопроса.