Без правильно настроенных DKIM, SPF и DMARC почта с вашего домена массово улетает в спам или отклоняется серверами Gmail и Outlook. Все три записи решают одну задачу — подтверждают получателю, что письмо действительно отправлено от имени вашего домена, а не подделано мошенником.

Зачем нужны DKIM, SPF, DMARC

Запись	Что делает
SPF	Указывает, какие серверы могут отправлять почту от имени домена
DKIM	Цифровая подпись каждого письма
DMARC	Политика действий при несоответствии SPF/DKIM

Записи работают вместе, а не по отдельности: SPF без DMARC легко обходится подделкой заголовка From, DKIM без SPF не защищает от подмены конверта письма, а DMARC без обеих предыдущих записей просто не имеет смысла проверять.

Включение DKIM в cPanel

cPanel → Email → Email Deliverability → нажмите Repair напротив домена. cPanel автоматически создаст DKIM-запись в DNS и покажет статус «Valid», если запись успешно опубликована и прошла проверку. Если статус остаётся «Not Valid» после Repair дольше суток, скорее всего домен использует внешние NS-серверы (например, Cloudflare), а не встроенный DNS хостинга — тогда cPanel не может сам прописать TXT-запись, и её нужно скопировать из cPanel → Email Deliverability вручную в панель управления DNS-провайдера.

SPF запись

# Добавьте TXT запись для домена:
v=spf1 +a +mx +ip4:YOUR_SERVER_IP include:spf.protection.outlook.com ~all

# Если отправляете только через свой сервер:
v=spf1 +a +mx ~all

Типичная ошибка: две SPF-записи одновременно

Если добавить новую SPF-запись, не удалив старую (например, оставшуюся от прошлого email-провайдера), проверка почтового сервера покажет ошибку:

$ dig TXT example.com +short
"v=spf1 +a +mx ~all"
"v=spf1 include:_spf.google.com ~all"

# Результат проверки:
permerror: Two or more SPF records found

Стандарт SPF прямо запрещает несколько TXT-записей типа v=spf1 для одного домена — при обнаружении второй записи почтовые серверы получателя считают проверку неуспешной (permerror) и часто отправляют письмо в спам именно из-за этого, а не из-за содержимого письма. Решение — объединить все нужные источники отправки в одну строку через include: и удалить дублирующие TXT-записи в Zone Editor.

DMARC запись

# TXT запись для _dmarc.yourdomain.com
# Начните с мониторинга (p=none):
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

# После анализа отчётов перейдите на quarantine:
v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@yourdomain.com

# Финальная строгая политика:
v=DMARC1; p=reject; pct=100; rua=mailto:dmarc@yourdomain.com

Переход сразу на p=reject без периода мониторинга — частая причина того, что легитимные письма (например, отправленные через стороннюю CRM или рассылку) начинают отклоняться: если их SPF/DKIM не выровнены с доменом в поле From, DMARC с жёсткой политикой блокирует их наравне с поддельными.

Как читать результаты проверки

Результат	Что означает
SPF: pass	IP отправителя есть в разрешённом списке домена
SPF: softfail	IP не в списке, но политика мягкая (~all) — письмо помечается, не блокируется
DKIM: pass	Подпись письма совпадает с публичным ключом в DNS
DMARC: pass	Хотя бы одна из SPF/DKIM прошла И совпадает с доменом в From

Когда записи не спасут от спам-фильтра

IP сервера уже в чёрном списке (Spamhaus, Barracuda) — идеальные SPF/DKIM/DMARC не помогут, пока IP не будет исключён из блэклиста
Письма отправляются через сторонний сервис рассылок (Mailchimp, SendGrid) без добавления его в SPF — нужно прописать конкретный include: провайдера, иначе его письма от вашего имени провалят проверку
Содержимое письма похоже на спам по формальным признакам — избыток заглавных букв, ссылки на подозрительные домены, вложения с макросами — это оценивается отдельно от подлинности отправителя
Получатель использует агрессивный корпоративный фильтр (например, требует полное совпадение DMARC alignment в strict-режиме) — тогда даже валидные, но не идеально выровненные записи могут блокироваться

Проверка

# Через командную строку
dig TXT yourdomain.com
dig TXT _dmarc.yourdomain.com
# Через онлайн-сервис:
# mxtoolbox.com → SuperTool → DKIM Lookup

Проверять стоит после каждого изменения записей, а не только один раз при первой настройке — DNS-кэш у разных резолверов обновляется не мгновенно, и результат может отличаться в зависимости от того, откуда идёт проверка. Самый надёжный способ проверить всё сразу — отправить письмо на тестовый адрес сервиса mail-tester.com: он пришлёт отчёт с оценкой от 0 до 10 и укажет, какая именно из трёх записей не прошла проверку. Подробнее о защите почты от спама на входящей стороне — в статье SpamAssassin в cPanel.