Причин три группы: путь доставки (MX-записи и состояние самого домена), аутентификация отправителя (SPF, DKIM, DMARC) и репутация. Различать их надо по симптому: «не приходят вообще», «приходят только на часть сервисов» и «уходят в спам у всех» — это разные диагнозы, и лечатся они по-разному.

Три симптома проблем с почтой и три разные причины

Диагноз определяется симптомом: письма не приходят никуда, приходят не всем или у всех попадают в спам — это три разные причины.

Сначала определите, какой у вас симптом

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

Письма не доходят вообще: проверьте MX-записи

Без MX-записи по RFC 5321 письма формально могут доставляться на A-запись домена — это так называемая неявная MX. На практике это часто не срабатывает: типовой ответ при отсутствии MX — 550 «account or domain may not exist». Поэтому если у домена нет ни одной MX-записи, а почта должна работать, её нужно добавить. Проверить, что реально видно в DNS, поможет проверка домена в whois.

Обратная ситуация опаснее: MX есть, но ни одна из них не отвечает. По RFC 5321 доставка в этом случае завершается ошибкой, а не поиском A-записи. То есть «битая» MX полностью ломает почту, даже если сайт на домене открывается. Если домен не должен принимать почту вообще, для него по RFC 7505 публикуют NULL MX — запись с target «точка».

Письма доходят, но у всех в спаме: SPF, DKIM, DMARC

Это проверка аутентификации, и смотреть её надо в этом порядке.

SPF — TXT-запись со списком серверов, которым разрешено отправлять почту от вашего домена. Частая ловушка — лимит в 10 DNS-запросов на одну проверку: include, a, mx, ptr, exists и redirect считаются, а all, ip4, ip6 — нет. При превышении SPF возвращает permerror; для DMARC это провал аутентификации, и это не то же самое, что «SPF нет вовсе».

DKIM — подпись писем. Ключ короче 1024 бит использовать нельзя (RFC 6376), 2048 бит — рекомендованный стандарт, на который перешёл и Google. Типичная ошибка после «улучшения» ключа: публичный ключ 2048 бит в base64 занимает около 392 символов, а одна строка TXT в DNS — максимум 255 байт. Ключ нужно публиковать несколькими кавычёнными строками внутри одной TXT-записи; при обрезке подпись перестаёт проверяться. Часть панелей управления (в том числе cPanel в ряде конфигураций) по умолчанию выпускает 1024-битные ключи.

DMARC — запись _dmarc, которая говорит получателю, что делать при провале SPF или DKIM. Здесь важно: при p=none провал аутентификации не влияет на попадание в спам. Доставку ломают только p=quarantine и p=reject — они отправляют письмо в карантин или отклоняют его. Если вы включили rua на внешний адрес отчётов, отчётов не будет без подтверждающей TXT-записи <домен>._report._dmarc.<хост>: без неё адрес просто игнорируется. И не рассчитывайте на ruf — Gmail и часть крупных сервисов failure-отчёты не присылают.

Письма отклоняются или уходят в спам у всех: дело в репутации

Симптом тот же, что и у неверной аутентификации, но SPF, DKIM и DMARC при этом настроены. Тогда стоит проверить отправляющий IP по публичным спам-листам и, если адрес там есть, подать заявку на исключение по инструкции конкретного списка. Универсальных сроков рассмотрения и автоматического де-листинга не существует, поэтому начинать надо с проверки самого IP на листинги.

Изменил DNS, а почта не заработала: сколько ждать

Изменения вступают в силу не позже, чем истечёт TTL записи — другого норматива по времени пропагации нет. Отчёты DMARC тоже зависят от кеширования DNS. Поэтому на время правок имеет смысл держать TTL коротким (5–15 минут), а после стабилизации вернуть к обычному значению (1–4 часа), чтобы не перегружать DNS-запросы.

Ничего не менял, а почта внезапно отвалилась: проверьте срок домена

По политике ICANN ERRP регистратор обязан гасить DNS для неоплаченного домена. Если домен удаляют в течение 8 дней после истечения срока, разрешение имён не работает от самой даты истечения. Это ровно тот случай, когда «почта перестала ходить», а срок регистрации формально ещё не вышел. Напоминания регистратор шлёт за 26–35 и за 4–10 дней до окончания, поэтому письмо легко пропустить. Первым делом посмотрите дату expiry и статус домена (clientHold, autoRenewPeriod) — это видно в проверке домена в whois.

Дальше цикл такой: около 45 дней Auto-Renew Grace Period, 30 дней Redemption Grace Period на восстановление, затем 5 дней Pending Delete — и домен освобождается.

Проверьте, отвечает ли почтовый сервер

Прежде чем править DNS, убедитесь, что сам сервер жив и принимает соединения — это делается через проверку ответа сервера. Если сервер не отвечает, ни SPF, ни DKIM не помогут: проблема на уровне доступности, а не в записях.