Александр Есин / блог

Почтальон Печкин у тебя дома. Часть 2

29 сентября 2026

Продолжаем о почте (первая часть — вот здесь). Самый тонкий момент — это настройки безопасности.

Если некорректно настроены записи SPF, DKIM, DMARC в DNS, то наши письма никуда не дойдут.

Разберём по порядку. Все три — обычные DNS-записи, ни одна не требует никакого софта на сервере. Возьму для примера свой домен esin48.ru, все записи живые.

SPF. TXT-запись в корне домена. Моя выглядит так:

esin48.ru.  TXT  "v=spf1 mx ip4:109.195.6.79 -all"

Читается вслух: «письмо от esin48.ru считается законным, если оно пришло с хоста, указанного в MX-записи, или с адреса 109.195.6.79; во всех остальных случаях — отвергнуть». v=spf1 — версия, обязательна и стоит первой. mx — сокращение для «наш MX-хост и его A-запись», чтобы не дублировать IP руками. ip4: — явный адрес. -all — жёсткий отказ всему, что не перечислено; встречается также ~all («мягкий отказ», помечать, но не блокировать) и ?all (разрешить всё — по сути отсутствующий SPF).

Два подводных камня. Первый: у SPF есть предел в 10 DNS-запросов на проверку. Каждый include: съедает запрос, и доменные имена с include:sendgrid.net include:mailgun.org include:_spf.google.com ... очень быстро упираются в лимит — сервер вернёт permerror, а принимающая сторона по стандарту обязана трактовать это как провал проверки. Второй камень: SPF проверяет только конверт, то есть адрес отправителя на этапе SMTP-сессии. Заголовок From:, который читает человек, SPF не видит вообще. Отсюда — поддельные письма «от вашего банка», которые SPF проходят: конверт принадлежит спамеру, а в глазах почтового клиента From может быть любым. Для этого нужны ещё две записи.

DKIM. Если SPF про конверт, то DKIM — про само письмо. Сервер при отправке подписывает письмо приватным ключом и добавляет заголовок DKIM-Signature; принимающая сторона берёт из DNS публичный ключ и проверяет, что письмо не менялось в дороге. Ключи в poste.io генерятся сами в админке, наружу уходит только публичная часть — TXT-запись вида:

s20260214494._domainkey.esin48.ru.  TXT  "k=rsa; p=MIIBIjANBgkq...IDAQAB"

Набор: s20260214494 — селектор (имя ключа; их бывает несколько одновременно, это нужно для плавной ротации ключей), k=rsa — тип ключа, p= — публичный ключ, тут RSA 2048. Приватный ключ при этом живёт только на сервере, в DNS его нет и быть не может.

DMARC. Третья запись, которая склеивает первые две. Публикуется как TXT на _dmarc.<домен>:

_dmarc.esin48.ru.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@esin48.ru"

Смысл: «письмо считается моим, только если SPF и/или DKIM прошли И домен в них совпадает с доменом из From (это и есть alignment — то, чего SPF по себе не гарантирует). Если не совпало — поступай по моей политике: p=none — только присылать мне отчёты, ничего не делать; p=quarantine — в спам; p=reject — не принимать вовсе». rua= — адрес, на который собираются агрегированные отчёты: кто, откуда и с каким результатом отправлял письма от имени твоего домена. У меня отчёты падают на dmarc@esin48.ru — отдельный ящик только под них, полезно завести сразу.

Политику не начинают с reject. Нормальный путь: месяц-другой на p=none, по отчётам убедиться, что все легитимные источники (дом, рабочий сервер, мобильный клиент, если он шлёт напрямую) в схеме, — и только потом quarantine, затем reject. Я со своим доменом живу на reject и не жалуюсь: ни одно реальное письмо не потерялось, зато подделать esin48.ru теперь нельзя в принципе.

И обещанный в первой части момент про провайдеров. Даже с идеальными записями домашний IP может оказаться в блокирующих списках (Spamhaus DUL и подобные) — динамические диапазоны заносятся туда по умолчанию. Пугаться не стоит: это не «черный список за грехи», а рутина. Лечится общением: у каждого списка есть процедура исключения (delist), пишешь, объясняешь, что сервер легитимный и стоит дома, ждёшь ответа. Требует времени и переписки, но работает.

Как всё проверить. SPF/DKIM/DMARC смотрятся любым DNS-lookup (mxtoolbox умеет по домену). Дальше — mail-tester.com: сайт даёт одноразовый адрес, отправляем ему письмо и получаем вердикт с разбором: SPF pass, DKIM pass, DMARC pass, PTR ok, позиция IP по базам. При правильно настроенном домене 10/10 и «не спам» — на моём esin48.ru, собственно, так и есть. Финальная проверка — отправить письмо на Gmail и в исходном тексте посмотреть заголовок Authentication-Results: там видно, что именно и как прошло.

Итого: SPF — про конверт, DKIM — про письмо, DMARC — про то, как это склеить и что делать при провале. Три TXT-записи в DNS и один ключ на сервере — и почта с домашнего сервера доезжает до Inbox, а подделки под твой домен не доезжают ни до чего. Это, собственно, всё, за что платят провайдерам.

Если подвести итог кратко, то так мы при помощи ниток, иголок смогли сделать из буханки хлеба троллейбус, который вполне себе будет ехать) Ничего страшного в настройке почты на локальном домашнем сервере нет. Главное знать общие принципы.