SPF, DKIM и DMARC: настройка почты для интернет‑магазина в Беларуси

Это краткое руководство о том, что такое SPF, DKIM и DMARC и зачем они нужны: правильные записи в DNS снижают попадание писем в спам, защищают бренд от подмены и повышают доверие клиентов. Подойдёт владельцу малого интернет‑магазина в Минске, Гомеле или небольшого города, который отправляет уведомления и рассылки через хостинг или сторонние сервисы.

SPF: прописать, кто имеет право отправлять письма от вашего домена

Сценарий: интернет‑магазин одежды в Гомеле отправляет рассылки через почтовый сервис и уведомления через хостинг. Если в DNS нет SPF или он неправильный, письма часто попадают в спам.

Как сделать:

  1. Соберите список отправляющих сервисов: ваш хостинг, SMTP провайдер, платёжный сервис (если он шлёт письма). Для каждого провайдера найдите рекомендованную строку include в их документации.
  2. Создайте или обновите TXT‑запись в DNS для домена example.by:

    v=spf1 mx include:spf.mailprovider.by include:spf.otherprovider.by -all

  3. Если не уверены, начните с ~soft‑fail~: замените -all на ~all и проверьте логи, затем переключите на -all.
  4. Проверьте: в консоли сервера используйте dig или nslookup для TXT‑записи, результат должен включать ваш SPF.

Практический совет: не создавайте две SPF‑записи для одного домена. Если провайдер требует нескольких include, объедините их в одну строку.

DKIM: как подписывать письма и где размещать ключ

Сценарий: небольшой магазин электроники в Бресте переводит уведомления на новый почтовый сервис. Без DKIM письма часто помечают как подозрительные.

Как сделать:

  1. Сгенерируйте ключ либо в панели почтового сервиса, либо на своём сервере (рекомендуемый размер 2048 бит для долгосрочных задач).
  2. В DNS добавьте TXT‑запись для селектора. Пример записи (селектор mail, домен example.by):

    mail._domainkey.example.by — "v=DKIM1; k=rsa; p=PUBLIC_KEY_БЕЗ_РАЗРЫВОВ"

  3. В панели почтового сервиса укажите селектор и включите подпись. Отправьте тестовое письмо и проверьте заголовки: должна быть DKIM‑подпись с pass.
  4. Периодически ротируйте ключи: создайте новый селектор, опубликуйте ключ, переключите подпись, затем удалите старый.

Практический совет: если запись выглядит очень длинной и провайдер просит разбить на части, используйте кавычки в TXT и следуйте правилам вашего DNS‑панели.

DMARC: политика и отчёты без резких ограничений

Сценарий: салон красоты в Гродно хочет видеть отчёты о доставляемости и защититься от подмены, но боится потерять легальные письма при строгой политике.

Как сделать:

  1. Запустите DMARC с мягкой политикой: в DNS добавьте TXT для _dmarc.example.by со значением:

    v=DMARC1; p=none; rua=mailto:dmarc@example.by; pct=10

    Это позволит получать агрегированные отчёты и применять политику только к 10% писем.

  2. Через 2–4 недели анализируйте отчёты и исправляйте проблемы SPF/DKIM. После стабилизации увеличьте pct и смените p на quarantine или reject.
  3. Если не хотите настраивать собственный приём отчётов, используйте сторонний сервис для агрегации и визуализации rua‑отчётов.

Практический совет: начинайте с p=none и pct=10–20, повышайте по мере уверенности в настройках SPF и DKIM.

Проверка и мониторинг: что контролировать и как тестировать

Сценарий: магазин подарков в Могилёве хочет еженедельный чек, чтобы не терять клиентов из‑за плохой доставляемости.

Как сделать:

  • Отправьте тестовое письмо на несколько почтовых ящиков (включая popular mailbox) и проверьте заголовки: строки SPF=pass, DKIM=pass, DMARC=pass/none.
  • Проверяйте DNS‑записи инструментами типа dig или nslookup: dig TXT example.by; dig TXT _dmarc.example.by; dig TXT mail._domainkey.example.by.
  • Ведите простую таблицу: дата, провайдер отправки, результаты SPF/DKIM/DMARC, заметки. Это поможет отследить изменения после смены провайдера или конфигурации DNS.

Практический совет: после смены хостинга или SMTP провайдера пересмотрите SPF и DKIM в первую очередь; задержка приводит к потере писем.

Типичные ошибки

  • Две отдельных SPF‑записи вместо одной объединённой.
  • Жёсткая политика DMARC (p=reject) без предварительного мониторинга.
  • Неправильный селектор DKIM или обрезанный ключ при вставке в DNS.
  • Забытые include для сторонних сервисов (платёжных систем, CRM), которые отправляют письма от имени домена.
  • Долгий TTL при тестировании изменений — обновления приходят с задержкой.

Полезные ссылки: практическая инструкция по настройке SPF, DKIM и DMARC на белорусском хостинге для малого бизнеса.

3 шага, которые можно сделать сегодня: 1) проверить текущие TXT‑записи домена командой dig/nslookup; 2) добавить DMARC с p=none и rua на реальный почтовый ящик для сбора отчётов; 3) проверить у почтового/SMTP провайдера рекомендуемую строку include для SPF и объединить её в одну запись. После этого отслеживайте отчёты и постепенно усиливайте политику.


🗓️

Вернуться на главную →