Ошибки настройки DNS: почему не доходит почта и как их решить

DNS для почты — это не декоративная часть домена, которую один раз заполнили и забыли. Это карта доверия: куда принимать письма, кому разрешено отправлять от имени домена, как проверить подпись, что делать с подозрительными сообщениями. Ошибки настройки DNS не всегда дают мгновенный отказ. Иногда они создают постоянный фоновый дискомфорт: часть писем проходит, часть теряется, администратор видит разные результаты в разных сервисах проверки, а у команды появляется тревожная привычка дублировать важные письма в чат.

Сначала отделяем DNS-проблему от почтовой суеты

Когда почта «не работает», легко уйти в визуальный шум: проверить пароль, перезапустить клиент, сменить порт SMTP, попросить получателя поискать письмо в спаме. Всё это иногда помогает, но для доменной почты полезнее начать с более спокойной последовательности.

Я обычно раскладываю проблему на три вопроса:

1. Письма не приходят на ваш домен — тогда в фокусе прежде всего MX-записи: куда внешние серверы должны доставлять входящую почту.

2. Письма с вашего домена не доходят наружу — тогда смотрим SPF, DKIM, DMARC, PTR и имя сервера в HELO/EHLO.

3. Письма доходят, но попадают в спам — чаще всего проблема не одна: DNS-аутентификация, обратная зона, репутация IP-адреса и содержание письма складываются в общий сигнал доверия.

Настройки DNS не гарантируют стопроцентную доставку. Это было бы слишком удобно, но почтовая реальность сложнее: антиспам-фильтры учитывают репутацию IP, историю домена, жалобы, контент письма, поведение получателей. Зато корректные DNS-записи убирают грубые технические причины, из-за которых письмо может быть отклонено ещё до того, как его вообще прочитает фильтр содержания.

Почтовый DNS — это не ускоритель доставки, а санитарный минимум доверия. Без него сервер получателя вправе относиться к письму настороженно.

MX-записи: почтовый адрес должен вести к имени, а не прямо к IP

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

Классическая неправильная настройка DNS записей выглядит так: в MX указывают IP-адрес сервера. На первый взгляд логика понятна — ведь сервер действительно находится по этому IP. Но по стандарту SMTP MX-запись должна указывать на доменное имя, у которого уже есть A- или AAAA-запись. Использование IP-адреса в MX — нарушение ожидаемой схемы, и разные почтовые системы могут реагировать на это неприятно.

Правильная цепочка выглядит спокойнее:

• у домена example.com есть MX-запись, например mail.example.com;
• у mail.example.com есть A-запись с IPv4-адресом или AAAA-запись с IPv6-адресом;
• почтовый сервер реально принимает соединения на этом адресе;
• имя сервера совпадает с тем, что вы используете в почтовой конфигурации.

Ещё один частый источник путаницы — приоритет MX. В DNS он задаётся числом, и чем меньше число, тем выше приоритет. То есть MX с приоритетом 10 будет выбран раньше, чем MX с приоритетом 20.

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

Как я проверяю MX без лишней драматизации

Моя рабочая рутина здесь простая. Сначала я смотрю, какие MX видны из публичного DNS. Потом проверяю, разрешаются ли имена MX в IP-адреса. Затем сравниваю эти IP с фактическим почтовым сервером или почтовым провайдером.

Если домен переезжал между сервисами — например, с хостинговой почты на Google Workspace, Microsoft 365 или собственный Postfix, — почти всегда стоит поискать старые MX. Они создают неровное поведение: часть серверов отправляет письма по старому маршруту, часть — по новому, а владелец домена видит хаос и думает, что «DNS ещё не обновился». Иногда это действительно кэширование и TTL, но иногда — просто оставленная лишняя запись.

SPF: разрешаем отправителей и не превышаем лимит DNS-запросов

SPF отвечает на практичный вопрос: какие серверы имеют право отправлять письма от имени домена. Если ваш домен отправляет почту через собственный сервер, CRM, сервис рассылок и, скажем, helpdesk-систему, всё это должно быть аккуратно отражено в SPF.

Но SPF легко превращается в длинную строку, где годами накапливаются include от старых сервисов. Визуально запись кажется рабочей: она есть, начинается с v=spf1, содержит знакомые домены. А затем при проверке возникает ошибка из-за лимита в 10 DNS-запросов. Это важное ограничение SPF: механизмы, которые требуют DNS-lookup, не должны суммарно превышать десять запросов.

К таким механизмам относятся, например, include, a, mx, ptr, exists, redirect. И особенно коварны вложенные include: вы добавили один внешний сервис, а внутри его SPF может быть ещё несколько обращений.

Вторая частая ошибка — несколько SPF-записей для одного домена. Например, одна TXT-запись осталась от старого хостинга, другая добавлена для рассылочного сервиса. Получается не «усиленная защита», а конфликт: принимающий сервер может считать SPF некорректным.

Хорошая SPF-запись обычно устроена сдержанно:

• начинается с v=spf1;
• перечисляет только актуальные источники отправки;
• содержит один финальный механизм all;
• не дублируется второй TXT-записью SPF для того же имени;
• не превышает лимит в 10 DNS-запросов.

Финальный механизм all тоже не стоит выбирать на автопилоте. -all означает жёсткое отрицание: всё, что не перечислено, не должно отправлять почту от имени домена. ~all — мягкий вариант, при котором письмо помечается как подозрительное, но не обязательно отклоняется. В период настройки и миграции я часто предпочитаю начинать осторожнее, особенно если у компании много источников отправки и не все они сразу очевидны.

SPF любит порядок. Не длинную героическую строку на пол-экрана, а честный список тех, кто действительно отправляет почту от имени домена.

Что делать, если SPF уже распух

Вместо того чтобы механически добавлять ещё один include, лучше спокойно разобрать отправителей. Я бы сделал так:

1. Соберите реальные источники отправки. Не только основной SMTP, но и бухгалтерию, CRM, сервис рассылок, трекер заявок, сайт с формами, платформу вебинаров.

2. Удалите следы старых сервисов. Если рассылочный сервис не используется полгода, его include в SPF только увеличивает шум и риск ошибки.

3. Проверьте вложенные lookup. Один внешний include может тянуть за собой несколько DNS-запросов.

4. Разделите потоки, если нужно. Для массовых рассылок иногда разумнее использовать поддомен, например news.example.com, чтобы не смешивать транзакционные письма и маркетинг в одном пространстве.

5. Не добавляйте несколько SPF-записей. Для одного имени должна быть одна TXT-запись SPF, собранная аккуратно.

Здесь особенно заметна разница между «почта вроде отправляется» и «почтовая инфраструктура обслуживается». Во втором случае DNS не растёт как кладовка, куда складывают всё подряд. Его периодически приводят в порядок.

DKIM: подпись письма и длина ключа

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

DKIM состоит из двух частей:

• приватный ключ хранится на стороне отправляющего почтового сервера или сервиса;
• публичный ключ публикуется в DNS как TXT-запись на специальном имени с селектором.

Имя записи обычно выглядит примерно так: selector._domainkey.example.com. Селектор может называться по-разному: default, google, mail, s1, dkim2024. Это не косметика, а способ иметь несколько ключей для разных сервисов или для ротации ключей.

Ошибка, которую я часто вижу при проверке DNS записей домена, — DKIM вроде бы включён в панели сервиса, но публичная TXT-запись не опубликована или опубликована не там. Бывает и мягче: запись есть, но строка ключа повреждена при копировании, разбита некорректно, содержит лишние кавычки или пробелы там, где DNS-панель их не ждёт.

Отдельный разговор — длина ключа. Ключи меньше 1024 бит считаются небезопасными. На практике лучше ориентироваться на 2048 бит, если почтовый сервис и DNS-провайдер нормально с ним работают. У старых панелей иногда были ограничения на длину TXT-записей, но современные DNS-сервисы обычно умеют корректно хранить длинные DKIM-ключи.

DKIM не заменяет SPF. Это другой тип проверки. SPF смотрит на сервер-отправитель, DKIM — на подпись письма. Поэтому ситуация «SPF проходит, DKIM нет» или наоборот вполне возможна. Для хорошей доставки лучше, чтобы оба механизма были настроены аккуратно, без лишнего напряжения и догадок.

PTR и HELO/EHLO: почему обратная DNS-зона влияет на доверие

PTR-запись — это обратная DNS-запись: она связывает IP-адрес с доменным именем. Если A-запись отвечает на вопрос «какой IP у mail.example.com», то PTR отвечает наоборот: «какое имя у этого IP».

Для обычного сайта PTR часто не попадает в фокус владельца домена. Для почтового сервера — попадает. Многие почтовые системы относятся к отсутствию или несоответствию PTR настороженно. Особенно если сервер отправляет почту напрямую с собственного IP, а не через крупного почтового провайдера.

Важный нюанс: PTR обычно настраивается не у регистратора домена, а у владельца IP-адреса — хостинг-провайдера, VPS-провайдера, дата-центра. Поэтому человек может долго искать нужное поле в DNS-зоне домена и не находить его. Это нормальная ситуация: обратная зона управляется со стороны IP.

Связка должна быть логичной:

• почтовый сервер представляется в SMTP-команде HELO/EHLO как mail.example.com;
• mail.example.com через A-запись указывает на IP сервера;
• PTR для этого IP указывает обратно на mail.example.com;
• имя не выглядит как случайный технический хост провайдера вроде vps-123-45.provider.local.

Если PTR указывает на одно имя, HELO/EHLO сообщает другое, а MX — третье, почтовый сервер получателя видит не катастрофу, но беспорядок. Для антиспам-фильтра это один из сигналов: возможно, письмо отправляет плохо настроенный сервер, временная машина или ботнет. Наша задача — убрать этот лишний повод для недоверия.

Собственный сервер или почтовый провайдер

Здесь стоит честно выбрать уровень контроля. Собственный Postfix, Exim или другой MTA даёт гибкость, но требует дисциплины: PTR, HELO, TLS, очереди, логи, репутация IP, обработка отказов. Почтовый провайдер забирает часть рутины на себя, но просит правильно добавить MX, SPF, DKIM и DMARC.

Я не считаю один путь «правильным для всех». Для небольшой команды комфортнее бывает использовать готовую бизнес-почту на домене: меньше технического шума, проще поддерживать стабильность. Для инфраструктурной команды с понятными требованиями собственный сервер может быть оправдан. Но если собственный сервер поднимается только потому, что «так дешевле», а потом письма не доходят в Gmail и Outlook, экономия быстро превращается в скрытую нагрузку.

DMARC: политика для писем, которые не прошли проверку

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

Для домена example.com имя записи будет таким: _dmarc.example.com.

Минимальная DMARC-запись может выглядеть очень просто: политика наблюдения, без жёстких санкций. Но даже она уже создаёт пространство для анализа: вы начинаете видеть, кто отправляет письма от имени домена и какие потоки проходят аутентификацию.

Основные политики DMARC:

Типичная ошибка — сразу поставить p=reject, не разобрав все источники отправки. В результате под удар попадают вполне легитимные письма: уведомления сайта, счета из CRM, ответы из helpdesk-системы. Поэтому я обычно отношусь к DMARC как к постепенной настройке, а не к кнопке «защитить домен».

У DMARC есть ещё один тонкий момент: выравнивание доменов, или alignment. Проверка должна не просто увидеть успешный SPF или DKIM, а связать их с доменом в заголовке From, который видит пользователь. Именно это помогает бороться с подменой отправителя, когда письмо внешне выглядит как сообщение от вашего домена, но технически отправлено чужой системой.

Как внедрять DMARC без лишнего стресса

Спокойная последовательность выглядит так:

1. Сначала настройте SPF и DKIM. DMARC опирается на них, поэтому начинать с политики без базовой аутентификации неудобно.

2. Опубликуйте запись в _dmarc. Не в корне домена, не в dmarc.example.com, а именно в поддомене _dmarc.

3. Начните с p=none. Это режим наблюдения, который помогает увидеть реальную картину.

4. Разберите отчёты. Найдите легитимные сервисы, которые отправляют письма от вашего имени, но пока не проходят проверку.

5. Постепенно усиливайте политику. Переход к quarantine и затем к reject лучше делать после того, как основные потоки стали понятны.

6. Не забывайте про поддомены. Если рассылки идут с отдельного поддомена, для него тоже нужна ясная политика.

DMARC особенно полезен там, где домен уже узнаваем: компания общается с клиентами, выставляет счета, отправляет ссылки на вход, подтверждения заказов. В такой среде подмена отправителя — не абстрактная угроза, а вполне практичный риск для доверия.

TTL и ожидание: почему изменения не всегда видны сразу

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

TTL в 3600 секунд — удобная рабочая величина для стабильных почтовых записей: не слишком нервная, не слишком вязкая. Перед крупной миграцией я обычно снижаю TTL заранее, чтобы потом быстрее переключить MX или связанные записи. После стабилизации можно вернуть более спокойное значение.

Здесь важно не попасть в ловушку постоянных правок. Если каждые десять минут менять MX, SPF и DKIM, а затем проверять их из разных сетей, картина будет только тревожнее. Лучше вести изменения как небольшую операцию:

• зафиксировать текущее состояние записей;
• внести одно логическое изменение;
• подождать с учётом TTL;
• проверить результат несколькими независимыми способами;
• только потом двигаться дальше.

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

Типовые симптомы и где искать причину

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

В моей практике особенно часто встречается сочетание «почти всё настроено». MX корректный, SPF есть, но DKIM забыли включить. Или DKIM есть, но PTR остался провайдерским. Такие недоделки неприятны именно тем, что не выглядят как очевидная авария. Почта может работать неделями, пока важное письмо не встретит более строгий фильтр на стороне получателя.

Практичная последовательность исправления

Если сейчас перед вами домен, у которого почта ведёт себя нестабильно, я бы не начинал с полного переписывания DNS-зоны. Лучше двигаться по слоям: от маршрутизации к доверию.

1. Проверьте MX. Убедитесь, что записи указывают на доменные имена, а не на IP-адреса, и что приоритеты расставлены осознанно.

2. Проверьте A/AAAA для MX-хостов. Само имя почтового сервера должно разрешаться в актуальный IP.

3. Сравните MX с реальным провайдером почты. Если вы используете Google Workspace, Microsoft 365, Zoho, Яндекс 360 или собственный сервер, в DNS не должно быть случайной смеси старых и новых маршрутов.

4. Приведите SPF к одной записи. Уберите дубликаты, старые include и проверьте лимит в 10 DNS-запросов.

5. Включите и проверьте DKIM. Опубликуйте TXT-запись с публичным ключом, используйте ключ не короче 1024 бит, лучше 2048 бит.

6. Настройте PTR у владельца IP. Если отправляете почту со своего сервера, обратная DNS-запись должна соответствовать имени сервера.

7. Согласуйте HELO/EHLO. Имя, которым представляется сервер, не должно конфликтовать с PTR и A-записью.

8. Добавьте DMARC в _dmarc. Начните с наблюдения, затем переходите к более строгой политике, когда увидите реальные потоки.

9. Дайте DNS время. Не ждите мгновенной синхронизации по всему интернету и не меняйте всё повторно до истечения разумного окна TTL.

10. Сохраните финальную схему. Короткая внутренняя заметка о том, какие сервисы отправляют почту и какие записи за что отвечают, через полгода сэкономит много сил.

Эта последовательность хороша тем, что возвращает ощущение контроля. Вы не «чините почту вообще», а проходите понятные узлы: куда доставлять, кому разрешено отправлять, чем подписывать, как получателю проверить доверие.

Финальная позиция: порядок в DNS снижает почтовую тревожность

Ошибки настройки DNS редко выглядят эффектно. Это не всегда красная авария в панели и не всегда полный отказ. Чаще это тихая нестабильность: один получатель видит письмо, другой нет; один сервис принимает, другой кладёт в спам; администратор добавляет новую запись, не убрав старую, и DNS-зона постепенно превращается в шумное пространство.

Хорошая новость в том, что почтовый DNS можно привести в порядок без героизма. MX должен вести к правильному имени сервера. SPF — описывать реальных отправителей и не превышать лимит. DKIM — подписывать письма нормальным ключом. PTR и HELO/EHLO — показывать аккуратную, согласованную идентичность сервера. DMARC — задавать понятную политику и помогать увидеть, кто действительно пишет от имени домена.

Я бы относился к этим записям как к спокойной инфраструктурной рутине. Не как к разовой магической настройке, после которой письма обязаны всегда доходить, а как к базовой гигиене домена. Когда она сделана аккуратно, в почте становится меньше случайности, меньше визуального шума и больше пространства для нормальной рабочей коммуникации.