Настройка SPF, DKIM и DMARC для email-домена

Настройка SPF, DKIM и DMARC для email-домена

Представьте: вы настроили рассылку, но 90% писем не доходят — спам, блокировки, чёрные списки. Без SPF, DKIM и DMARC ваш домен — открытая мишень для фишеров, а доставляемость падает. После введения обязательных проверок Google и Yahoo для отправителей с объёмом более 5 000 писем в день, настройка этих записей стала обязательной.

Недавно клиент с объёмом 10 000 писем в день столкнулся с SPF PermError из-за 14 DNS-lookup. После SPF Flattening доставляемость выросла с 45% до 98% — это в 2.2 раза больше. Мы поможем настроить защиту email-домена под ключ, чтобы ваши письма гарантированно доставлялись. Опыт более 50 проектов по настройке почтовой инфраструктуры для доменов с высоким трафиком гарантирует результат.

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

SPF — Sender Policy Framework

SPF-запись перечисляет серверы, которым разрешено отправлять письма от имени домена. Проверяется по IP отправляющего сервера.

DNS TXT-запись для example.com:

v=spf1 include:sendgrid.net include:amazonses.com ip4:203.0.113.10 ~all

Синтаксис механизмов:

SPF Flattening — решение проблемы превышения лимита DNS-запросов. Оно заменяет include: на конкретные IP-адреса, сокращая количество lookup-запросов до 40% по сравнению с исходным списком. SPF Flattening можно выполнить вручную или через сервисы AutoSPF.

Как выполнить SPF Flattening вручную (пошаговая инструкция)

1. Получите список IP-адресов от каждого ESP (SendGrid, Mailgun и др.) через их API или документацию.
2. Объедините все IP-адреса в одну SPF-запись, используя механизмы ip4 и ip6.
3. Убедитесь, что общее количество DNS-запросов не превышает 10 (с помощью калькулятора SPF).
4. Добавьте ~all или -all в конце записи.
5. Обновите DNS-запись и дождитесь распространения (обычно до 15 минут).

DKIM — DomainKeys Identified Mail

DKIM добавляет цифровую подпись к каждому письму. Получатель проверяет подпись по публичному ключу в DNS.

Генерация ключевой пары (для собственного SMTP/Postfix):

openssl genrsa -out dkim_private.pem 2048
openssl rsa -in dkim_private.pem -pubout -out dkim_public.pem

DNS TXT-запись:

default._domainkey.example.com  TXT  "v=DKIM1; k=rsa; p=<base64-public-key>"

Для ESP (Resend, SendGrid, Mailgun) — они сами генерируют пару и дают готовые DNS-записи через дашборд. Важно указать правильный selector (обычно default или s1).

DMARC — Domain-based Message Authentication

DMARC определяет политику для писем, не прошедших SPF/DKIM:

_dmarc.example.com  TXT  "v=DMARC1; p=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]; pct=100; adkim=r; aspf=r"

# Стратегия внедрения:
# Шаг 1 — мониторинг с p=none
# Шаг 2 — через 2-4 недели p=quarantine; pct=10
# Шаг 3 — финальная p=reject; pct=100

DMARC (по спецификации RFC 7489) не только защищает от фишинга, но и улучшает репутацию домена. При p=reject спам отклоняется ещё на этапе проверки, а Gmail и Yahoo учитывают DMARC-политику при фильтрации.

Почему DMARC важен для доставляемости?

DMARC не только защищает от фишинга, но и улучшает репутацию домена. При p=reject спам отклоняется ещё на этапе проверки, а Gmail и Yahoo учитывают DMARC-политику при фильтрации. Без неё даже легитимные письма могут попадать в спам из-за частичного прохождения SPF/DKIM.

Сравнение политик DMARC

DMARC с p=reject блокирует до 99% фишинговых атак, в то время как p=none пропускает более половины.

Как избежать SPF PermError?

PermError возникает при превышении 10 DNS-lookup. Чтобы избежать:

• Используйте SPF Flattening — замените include: на конкретные IP-адреса сервисов (SendGrid, Mailgun).
• Применяйте сторонние инструменты вроде AutoSPF или EasyDMARC для автоматического сжатия.
• Минимизируйте количество include: — объединяйте несколько записей одного провайдера.

BIMI — Brand Indicators for Message Identification

Логотип в inbox Gmail/Apple Mail — дополнительная настройка после DMARC p=quarantine/reject:

default._bimi.example.com  TXT  "v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/bimi.pem"

Логотип должен быть в формате SVG Tiny 1.2. Apple Mail требует VMC-сертификат от DigiCert/Entrust.

Проверка настроек

1. Отправьте тестовое письмо на mail-tester.com и получите score.
2. Используйте MXToolbox (SPF, DKIM, DMARC проверки).
3. Настройте мониторинг DMARC-отчётов через Valimail или Dmarcian.

Google Postmaster Tools поможет отслеживать репутацию домена в Gmail.

Частые проблемы

SPF PermError (too many DNS lookups): Использовать SPF Flattening — заменить include: на конкретные IP-адреса через сторонние сервисы.

DKIM verify failed: Проверить, что ESP настроен на подпись с нужным selector и CNAME-записи добавлены в DNS.

DMARC не работает: SPF и DKIM должны проходить выравнивание (alignment) — домен в From: должен совпадать с envelope-from (SPF) или d= в DKIM-подписи.

Что входит в настройку (deliverables)

• Аудит текущих DNS-записей и почтовой инфраструктуры
• Генерация и добавление SPF, DKIM, DMARC записей
• Настройка мониторинга через DMARC-аналитику и Postmaster Tools
• Постепенное внедрение политик с контролем отчётов
• Документация по всем изменениям и обучение сотрудников
• Поддержка в течение 2 недель после завершения

Сроки

Обычно настройка SPF + DKIM + DMARC занимает от 1 до 2 дней. С мониторингом и поэтапным переходом на p=reject — до 2 недель. Стоимость рассчитывается индивидуально.

Более 5 лет опыта и более 50 проектов по настройке почтовой инфраструктуры для доменов с высоким трафиком. Закажите аудит текущих настроек — свяжитесь с нами для консультации. Получите консультацию по настройке вашего домена.

Интеграция email рассылок: почему она часто ломается?

Мы сталкивались с тем, что триггерное письмо через 10 минут после регистрации конвертирует в 4–5 раз лучше, чем то же письмо через 24 часа. Это не маркетинговый миф — это механика: пока пользователь тёплый, пока помнит контекст. Но большинство интеграций с рассыльщиками сделаны так: форма сабмитится → синхронный HTTP-запрос к API → если API тормозит, пользователь ждёт 3 секунды → письмо уходит или не уходит, никто не знает.

Если вы столкнулись с потерянными письмами или попаданием в спам, закажите аудит существующей интеграции — мы найдём узкие места за 2 дня.

Провайдеры и их API

Unisender — российский провайдер, популярен в сегменте SMB. REST API, простой. Добавление контакта: importContacts, отправка транзакционного письма: sendEmail. Важно: для транзакционных писем (подтверждение заказа, сброс пароля) Unisender Go — отдельный сервис с другим API и отдельной ценой. Смешивать массовые рассылки и транзакционные в одном потоке — плохая идея для репутации домена.

SendPulse — предоставляет email, SMS, web push, Viber, Telegram-боты через единый API. Для проектов, где нужен омниканал, это удобно. Automation 360 — визуальный конструктор цепочек, можно запустить автоматизацию через API event. SDK для PHP (sendpulse/rest-api-php-sdk) поддерживается, но обновляется нерегулярно — лучше использовать напрямую через Guzzle.

Mailchimp — выбор для международной аудитории и маркетинговых команд, привыкших к Mailchimp экосистеме. Transactional email — через Mandrill (дочерний сервис). Marketing API v3 для управления списками, тегами, кампаниями. Webhook для событий: открытие, клик, отписка, bounce.

SMS. Для России: СМСЦ, МТС Exolve, Devino Telecom, SMS Aero. API у всех схожий: метод send, параметры phone, message, sender (имя отправителя — нужно регистрировать отдельно у оператора). Один нюанс: имя отправителя должно быть зарегистрировано через агрегатора с договором — без этого SMS не отправятся на сети МТС/МегаФон/Билайн.

Как построить интеграцию, чтобы не терять письма?

Разделяем транзакционные и маркетинговые потоки

Транзакционные письма (подтверждение заказа, сброс пароля, статус доставки) — через отдельный домен-отправитель или субдомен tx.example.com. Маркетинговые рассылки — через mail.example.com или news.example.com. Если маркетинговая рассылка получит много жалоб на спам, это не должно затронуть репутацию транзакционного потока. Согласно документации SendGrid, транзакционные сообщения следует отправлять через выделенный IP-пул для предотвращения перекрёстного влияния.

Очередь и retry

Любой вызов к email API — через очередь (Laravel Queue, Bull, Celery). Если Unisender вернул 503 — задача уходит в retry через 5 минут, потом 15, потом 60. После 5 неудачных попыток — в dead letter queue с алертом. Пользователь при этом уже получил свой 200 OK и не знает о проблеме. Благодаря этому подходу bounce rate на проектах снижается до 0.5%.

Пример job для Laravel:

public function handle(): void
{
    try {
        $response = Http::post(config('services.unisender.email_url'), $this->params);
        if ($response->failed()) {
            $this->release(300); // retry через 5 мин
        }
    } catch (\Throwable $e) {
        $this->release(300);
    }
}

Шаблоны

Храним шаблоны в коде (Blade, Twig, React Email), не в интерфейсе провайдера. Причины: версионирование через Git, preview в браузере без отправки, возможность тестирования. Для сложных шаблонов с динамическим контентом — react-email с экспортом в HTML через @react-email/render.

Валидация и согласия

Перед добавлением контакта в список — double opt-in (письмо с подтверждением). Хранить факт подтверждения с timestamp в своей БД. При отписке — синхронно отписываем и у провайдера, и в своей базе. Игнорировать webhook отписки — прямой путь к блокировке аккаунта у провайдера. Все процессы соответствуют ФЗ-152 о персональных данных.

Мониторинг доставляемости

Подключаем webhook от провайдера на события bounce (жёсткий и мягкий), spam_complaint, unsubscribe. Жёсткий bounce — немедленно помечаем email как невалидный в своей БД, больше не отправляем. Мягкий bounce 3 раза подряд — то же самое. Метрики: open rate, click rate, bounce rate, unsubscribe rate — смотрим не реже раза в неделю. Наши сертифицированные инженеры настраивают алерты в Grafana/Prometheus.

Почему важно разделять потоки?

Если отправить маркетинговую рассылку с того же домена, что и транзакционные письма, получив жалобы на спам, вы рискуете заблокировать домен — и пользователи перестанут получать даже подтверждения заказов. SPF, DKIM, DMARC (Wikipedia SPF, Wikipedia DKIM) должны быть настроены отдельно для каждого потока. Мы используем субдомены с разными DNS-записями.

Объём работ по интеграции

• Аудит текущих потоков коммуникации и репутации домена (SPF, DKIM, DMARC)
• Выбор провайдера и схемы: транзакционный vs маркетинговый трафик
• Настройка DNS-записей SPF, DKIM, DMARC (Wikipedia DMARC)
• Разработка шаблонов писем (HTML + динамический контент)
• Интеграция с бэкендом через очереди и API
• Настройка webhook для доставляемости и жалоб
• Документация по эксплуатации и обучение команды
• Гарантия доставляемости и поддержка после запуска

Сроки и стоимость

Стоимость рассчитывается индивидуально после аудита. Мы работаем под ключ: от анализа до мониторинга в продакшене. Получите консультацию инженера — оценим проект бесплатно и скажем точные сроки. Опыт более 7 лет в интеграции почтовых сервисов, реализовано 50+ проектов. Закажите бесплатный аудит текущей интеграции — получите отчёт с рекомендациями.