Почта вида info@yourcompany.com вместо yourcompany@gmail.com — базовый признак серьёзного бизнеса. Для её настройки нужно правильно указать DNS-записи домена.
Минимальный набор DNS-записей для почты
| Запись | Назначение | Пример |
|---|---|---|
| MX | Адрес почтового сервера | mail.example.com (приоритет 10) |
| A | IP почтового сервера | mail IN A 192.168.1.1 |
| TXT (SPF) | Авторизованные отправители | v=spf1 mx ~all |
| TXT (DKIM) | Цифровая подпись писем | Генерирует почтовый сервер |
| TXT (DMARC) | Политика обработки | v=DMARC1; p=quarantine |
Настройка для Google Workspace
# MX-записи Google Workspace
@ IN MX 1 aspmx.l.google.com.
@ IN MX 5 alt1.aspmx.l.google.com.
@ IN MX 5 alt2.aspmx.l.google.com.
@ IN MX 10 alt3.aspmx.l.google.com.
@ IN MX 10 alt4.aspmx.l.google.com.
# SPF для Google Workspace
@ IN TXT "v=spf1 include:_spf.google.com ~all"Настройка для Zoho Mail (бесплатный план)
# MX-записи Zoho Mail
@ IN MX 10 mx.zoho.eu.
@ IN MX 20 mx2.zoho.eu.
@ IN MX 50 mx3.zoho.eu.
# SPF для Zoho Mail
@ IN TXT "v=spf1 include:zoho.eu ~all"Настройка для собственного сервера (cPanel/Exim)
# MX-запись
@ IN MX 10 mail.example.com.
# A-запись почтового сервера
mail IN A YOUR.SERVER.IP
# SPF (разрешить собственный IP и MX)
@ IN TXT "v=spf1 ip4:YOUR.SERVER.IP mx ~all"nslookup -type=MX example.comЧастые ошибки доставки почты
| Сообщение или симптом | Причина | Решение |
|---|---|---|
| 550 5.7.1 SPF check failed | IP отправляющего сервера не указан в SPF-записи домена, либо SPF содержит опечатку в include-механизме | Добавить IP или include нужного сервиса в SPF, проверить синтаксис через онлайн-валидатор SPF |
| 550 5.7.26 The message could not be authenticated over IPv6 without DKIM | Google требует DKIM для отправки по IPv6, наличия только SPF недостаточно | Включить и опубликовать DKIM-запись на отправляющем сервере |
| Письмо доставлено, но помечено как Spam с пометкой dmarc=fail | DMARC-политика настроена на p=reject или p=quarantine, а SPF/DKIM не проходят alignment (домен From не совпадает с доменом подписи) | Проверить, что домен в заголовке From совпадает с доменом DKIM d= и доменом SPF-проверки |
| Temporary failure in name resolution при отправке | MX-запись указывает на имя, которое само не резолвится (нет A-записи) или резолвится с задержкой | Убедиться, что имя из MX имеет действующую A-запись и не является CNAME (RFC запрещает CNAME для целей MX) |
| SPF Permerror: too many DNS lookups | Превышен лимит в 10 DNS-запросов на резолвинг SPF (RFC 7208) — обычно из-за цепочки вложенных include | Сократить число include, заменить часть механизмов на прямые ip4/ip6 |
DKIM: как проверить подпись
DKIM добавляет криптографическую подпись в заголовок письма. Публичный ключ публикуется в TXT-записи вида selector._domainkey.example.com, где selector — произвольное имя, которое задаёт почтовый сервер (например, google или default).
# Проверить публичный ключ DKIM для селектора google
dig TXT google._domainkey.example.com +short
# Проверить заголовок Authentication-Results в полученном письме
# (показывает результат SPF, DKIM и DMARC на стороне получателя)Если селектор неизвестен — его можно узнать в заголовках любого письма, отправленного с домена: строка DKIM-Signature: ... s=selector1 содержит нужное значение.
DMARC: разбор политики
| Значение p= | Действие получателя | Когда использовать |
|---|---|---|
| none | Только отчёты, письма доставляются как обычно | Первый этап внедрения — сбор данных без риска потерять письма |
| quarantine | Письма, не прошедшие проверку, помещаются в спам | После недели-двух чистых отчётов none без ложных срабатываний |
| reject | Письма, не прошедшие проверку, отклоняются полностью | Финальный этап, когда все легитимные источники отправки учтены в SPF/DKIM |
Переход сразу на p=reject без промежуточного none — частая причина потери легитимной почты: любой забытый сервис рассылок или CRM, отправляющий письма от имени домена, начнёт получать отказы без предупреждения.
Когда нужен отдельный поддомен для рассылок
- Транзакционные и маркетинговые письма идут через внешний сервис (SendGrid, Mailgun) — репутация рассылок не должна влиять на репутацию основного домена
- Объём рассылок превышает несколько тысяч писем в день — резкий рост объёма с основного домена может восприниматься спам-фильтрами как аномалия
- Разные отправители (поддержка, биллинг, маркетинг) используют разные DKIM-селекторы и политики DMARC для независимого мониторинга репутации
- Нужно протестировать нового провайдера рассылок без риска для доставляемости писем с основного домена
Если письма всё равно попадают в спам после настройки SPF и DKIM, проверьте обратный DNS сервера — см. настройку PTR-записи.
Частые вопросы
Что произойдёт с существующей почтой, если изменить MX-записи без предварительной подготовки?
Смена MX-записей переключает приём новой входящей почты на другой сервер, но письма, уже лежащие в почтовых ящиках старого сервиса, никуда не переносятся автоматически. Перед переключением стоит экспортировать существующую переписку или настроить параллельный приём на обоих серверах на переходный период, иначе часть писем, отправленных во время смены записей, может затеряться.
Нужно ли удалять старую SPF-запись при переходе с одного почтового провайдера на другой?
Да, старую SPF-запись нужно заменить новой или объединить оба include-механизма в одной записи, а не оставлять две отдельные TXT-записи SPF одновременно — почтовые серверы при получении нескольких SPF-записей для одного домена считают такую конфигурацию ошибкой и могут отклонять письма. Правильный способ — один TXT-запись с перечислением всех разрешённых отправителей через include.
Как долго применяются изменения DNS-записей для почты после их сохранения?
Время применения зависит от значения TTL у конкретной записи и от кэширования на стороне провайдеров доступа и почтовых серверов — обычно изменения видны в течение нескольких часов, но полное распространение по всем узлам интернета может занять дольше. Перед важным переключением стоит заранее снизить TTL записи, чтобы сократить время ожидания при следующем изменении.
Можно ли использовать несколько сервисов рассылки одновременно с одним SPF без превышения лимита запросов?
Использовать несколько сервисов рассылки одновременно можно, но каждый добавленный include в SPF-записи увеличивает число DNS-запросов при проверке, и превышение лимита приводит к ошибке Permerror, после которой почта от домена может не проходить проверку вовсе. Чтобы оставаться в пределах лимита, часть сервисов стоит подключать через прямые IP-адреса вместо вложенных include-механизмов.