[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-10dd4654-89c0-41ac-908b-8a322c451871":3},{"id":4,"body":5,"uuid":6,"created_at":7,"updated_at":8,"brand":9,"header":10,"short_body":11,"image":12,"published":13,"published_at":14,"tags":15},39,"\u003Cp>\u003Cstrong>SPF говорит, каким серверам разрешено отправлять почту от домена. DKIM ставит на письмо криптографическую подпись домена. DMARC проверяет, что хотя бы одна из этих проверок прошла именно для домена из поля «От кого», и сообщает получателю, что делать с письмом, если нет.\u003C\u002Fstrong> Нужны все три: SPF и DKIM по отдельности проверяют домен, который может отличаться от того, что человек видит в адресе отправителя. Связать их с этим адресом умеет только DMARC.\u003C\u002Fp>\n\u003Cp>Ниже — что именно проверяет каждая запись и где она ломается, что такое выравнивание, как три проверки складываются в один вердикт и как проверить свой домен за пару минут.\u003C\u002Fp>\n\u003Ch2>Три проверки в одной таблице\u003C\u002Fh2>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>\u003C\u002Fth>\n\u003Cth>SPF\u003C\u002Fth>\n\u003Cth>DKIM\u003C\u002Fth>\n\u003Cth>DMARC\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>Что проверяет\u003C\u002Ftd>\n\u003Ctd>IP-адрес сервера, который передал письмо\u003C\u002Ftd>\n\u003Ctd>Подпись на заголовках и теле письма\u003C\u002Ftd>\n\u003Ctd>Совпадение домена из From с доменом, прошедшим SPF или DKIM\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Какой домен\u003C\u002Ftd>\n\u003Ctd>Домен адреса конверта (\u003Ccode>MAIL FROM\u003C\u002Fcode>, он же Return-Path)\u003C\u002Ftd>\n\u003Ctd>Домен из тега \u003Ccode>d=\u003C\u002Fcode> подписи\u003C\u002Ftd>\n\u003Ctd>Домен из заголовка \u003Ccode>From\u003C\u002Fcode>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Где запись\u003C\u002Ftd>\n\u003Ctd>TXT на домене конверта\u003C\u002Ftd>\n\u003Ctd>TXT на \u003Ccode>селектор._domainkey.домен\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>TXT на \u003Ccode>_dmarc.домен\u003C\u002Fcode>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Что ломает\u003C\u002Ftd>\n\u003Ctd>Пересылка: письмо приходит с чужого IP\u003C\u002Ftd>\n\u003Ctd>Изменение письма в пути: подвал от рассылки, переписанная тема\u003C\u002Ftd>\n\u003Ctd>Отсутствие выравнивания у обеих проверок\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Стандарт\u003C\u002Ftd>\n\u003Ctd>RFC 7208\u003C\u002Ftd>\n\u003Ctd>RFC 6376\u003C\u002Ftd>\n\u003Ctd>RFC 9989 (с мая 2026 года заменил RFC 7489)\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Cp>Главное в этой таблице — строка «Какой домен». У письма три домена, и они не обязаны совпадать.\u003C\u002Fp>\n\u003Ch2>SPF: кто имеет право отправлять\u003C\u002Fh2>\n\u003Cp>SPF-запись — список отправителей домена. Принимающий сервер смотрит, с какого IP пришло письмо, берёт домен из адреса конверта и спрашивает у DNS: этот IP входит в разрешённые?\u003C\u002Fp>\n\u003Cpre>\u003Ccode>example.ru.  TXT  "v=spf1 ip4:203.0.113.10 include:_spf.yandex.net ~all"\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Запись разрешает один адрес и все серверы Яндекса, а для остальных просит мягкий отказ (\u003Ccode>~all\u003C\u002Fcode>). Строгий вариант \u003Ccode>-all\u003C\u002Fcode> просит отклонять.\u003C\u002Fp>\n\u003Cp>У SPF две слабости, и обе встречаются каждый день.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Он проверяет конверт, которого человек не видит.\u003C\u002Fstrong> Адрес конверта задаёт отправляющий сервер, а почтовый клиент его обычно не показывает. Злоумышленник может поставить в конверт свой домен с правильным SPF, а в \u003Ccode>From\u003C\u002Fcode> — ваш. SPF пройдёт и подмены не заметит.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Он ломается при пересылке.\u003C\u002Fstrong> Если получатель переслал письмо со своего ящика на другой, следующий сервер видит IP пересылающего сервиса, а не ваш. SPF не проходит, хотя письмо настоящее.\u003C\u002Fp>\n\u003Cp>Есть и техническое ограничение: при проверке SPF разрешено не больше 10 DNS-запросов на механизмы вроде \u003Ccode>include\u003C\u002Fcode>, \u003Ccode>a\u003C\u002Fcode>, \u003Ccode>mx\u003C\u002Fcode> и \u003Ccode>redirect\u003C\u002Fcode> (RFC 7208, раздел 4.6.4). Каждый подключённый сервис со своим \u003Ccode>include\u003C\u002Fcode> тратит этот бюджет, и запись, которая его превысила, получает результат \u003Ccode>permerror\u003C\u002Fcode>, то есть не работает вовсе. \u003Ca href=\"https:\u002F\u002Ffmailer.ru\u002Ftools\u002Fspf-checker\">Проверка SPF\u003C\u002Fa> проходит всё дерево \u003Ccode>include\u003C\u002Fcode> и считает этот бюджет.\u003C\u002Fp>\n\u003Ch2>DKIM: подпись, которая едет вместе с письмом\u003C\u002Fh2>\n\u003Cp>Отправляющий сервер подписывает письмо закрытым ключом, а владелец домена публикует открытый ключ в DNS. Подпись лежит в заголовке \u003Ccode>DKIM-Signature\u003C\u002Fcode>:\u003C\u002Fp>\n\u003Cpre>\u003Ccode>DKIM-Signature: v=1; a=rsa-sha256; d=example.ru; s=mail2026;\n        h=from:to:subject:date:message-id; bh=…; b=…\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Получатель берёт селектор \u003Ccode>s=\u003C\u002Fcode> и домен \u003Ccode>d=\u003C\u002Fcode>, запрашивает ключ по адресу \u003Ccode>mail2026._domainkey.example.ru\u003C\u002Fcode> и проверяет, что подписанные заголовки и тело не изменились по пути.\u003C\u002Fp>\n\u003Cp>В отличие от SPF, подпись переживает пересылку: она привязана к содержимому, а не к IP. Ломают её изменения письма. Список рассылки дописывает подвал, шлюз переписывает тему или перекодирует тело, и подпись перестаёт сходиться.\u003C\u002Fp>\n\u003Cp>Два практических требования. Ключ RSA должен быть длиной не меньше 1024 бит, на практике используют 2048. Алгоритм — \u003Ccode>rsa-sha256\u003C\u002Fcode>: RFC 8301 запретил \u003Ccode>rsa-sha1\u003C\u002Fcode>, и проверяющий сервер, следующий этому RFC, считает такую подпись недействительной.\u003C\u002Fp>\n\u003Cp>Слабость DKIM — та же, что у SPF. Подпись доказывает, что письмо подписал домен из \u003Ccode>d=\u003C\u002Fcode>, но ничего не говорит о домене в \u003Ccode>From\u003C\u002Fcode>. Письмо от \u003Ccode>support@bank.ru\u003C\u002Fcode>, подписанное ключом \u003Ccode>d=random-domain.com\u003C\u002Fcode>, проходит DKIM без единой ошибки.\u003C\u002Fp>\n\u003Ch2>Выравнивание: то, без чего первые две проверки мало что значат\u003C\u002Fh2>\n\u003Cp>Выравнивание (alignment) — вопрос DMARC к результатам SPF и DKIM: прошла ли проверка \u003Cstrong>для того же домена, что стоит в \u003Ccode>From\u003C\u002Fcode>\u003C\u002Fstrong>?\u003C\u002Fp>\n\u003Cp>Возьмём письмо, отправленное через внешний сервис без настройки своего домена:\u003C\u002Fp>\n\u003Cpre>\u003Ccode>From: Магазин <shop@example.ru>\nReturn-Path: <bounce-7731@mailer-service.net>\nDKIM-Signature: … d=mailer-service.net …\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>SPF проходит: сервис отправил со своего IP, и в конверте его домен. DKIM проходит: подпись настоящая, ключ сервиса. Но обе проверки прошли для \u003Ccode>mailer-service.net\u003C\u002Fcode>, а человек видит \u003Ccode>example.ru\u003C\u002Fcode>. Выравнивания нет ни у одной проверки, и DMARC для \u003Ccode>example.ru\u003C\u002Fcode> не проходит.\u003C\u002Fp>\n\u003Cp>Теперь то же письмо после настройки домена:\u003C\u002Fp>\n\u003Cpre>\u003Ccode>From: Магазин <shop@example.ru>\nReturn-Path: <shop@example.ru>\nDKIM-Signature: … d=example.ru …\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Обе проверки прошли для \u003Ccode>example.ru\u003C\u002Fcode>, обе выровнены, DMARC проходит.\u003C\u002Fp>\n\u003Ch3>Мягкое и строгое выравнивание\u003C\u002Fh3>\n\u003Cp>По умолчанию выравнивание мягкое (\u003Ccode>adkim=r\u003C\u002Fcode>, \u003Ccode>aspf=r\u003C\u002Fcode>): домены считаются совпадающими, если у них общий организационный домен. Подпись \u003Ccode>d=mail.example.ru\u003C\u002Fcode> выровнена с \u003Ccode>From: shop@example.ru\u003C\u002Fcode>. Строгое выравнивание (\u003Ccode>adkim=s\u003C\u002Fcode>, \u003Ccode>aspf=s\u003C\u002Fcode>) требует точного совпадения имён. Строгий режим нужен редко, а мягкий позволяет отправлять с поддомена без потери выравнивания.\u003C\u002Fp>\n\u003Ch2>DMARC: правило и отчёты\u003C\u002Fh2>\n\u003Cp>DMARC-запись публикуется на \u003Ccode>_dmarc.<домен>\u003C\u002Fcode> и делает две вещи.\u003C\u002Fp>\n\u003Cpre>\u003Ccode>_dmarc.example.ru.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.ru; adkim=r; aspf=r"\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>\u003Cstrong>Задаёт правило.\u003C\u002Fstrong> DMARC проходит, если выровнена \u003Cstrong>хотя бы одна\u003C\u002Fstrong> проверка: SPF или DKIM. Если не выровнена ни одна, получатель смотрит на политику \u003Ccode>p=\u003C\u002Fcode>:\u003C\u002Fp>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Политика\u003C\u002Fth>\n\u003Cth>Что просит владелец домена\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>\u003Ccode>p=none\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>Ничего не менять, только присылать отчёты\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Ccode>p=quarantine\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>Считать письмо подозрительным, обычно это папка «Спам»\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Ccode>p=reject\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>Отклонить письмо на этапе SMTP\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Cp>Политика — просьба владельца домена. Окончательное решение остаётся за провайдером, но крупные почтовые сервисы её учитывают.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Собирает отчёты.\u003C\u002Fstrong> Тег \u003Ccode>rua=\u003C\u002Fcode> задаёт адрес для агрегированных отчётов. Провайдеры обычно раз в сутки присылают XML со сводкой: сколько писем от вашего домена пришло, с каких IP, сколько прошло SPF и DKIM и сколько выровнено. Это единственный способ узнать, что кто-то отправляет от вашего имени или что ваш собственный сервис давно подписывает письма чужим ключом.\u003C\u002Fp>\n\u003Cp>Если адрес в \u003Ccode>rua=\u003C\u002Fcode> находится на другом домене, этот домен должен разрешить приём отчётов отдельной записью: так требует стандарт DMARC. Без неё отчёты не придут, а по самой записи \u003Ccode>_dmarc\u003C\u002Fcode> этого не видно. \u003Ca href=\"https:\u002F\u002Ffmailer.ru\u002Ftools\u002Fdmarc-checker\">Проверка DMARC\u003C\u002Fa> проверяет и это разрешение.\u003C\u002Fp>\n\u003Ch2>Как три проверки складываются в вердикт\u003C\u002Fh2>\n\u003Cp>Последовательность у получателя такая:\u003C\u002Fp>\n\u003Col>\n\u003Cli>Проверить SPF по IP и домену конверта.\u003C\u002Fli>\n\u003Cli>Проверить каждую подпись DKIM по ключу из DNS.\u003C\u002Fli>\n\u003Cli>Сравнить домены прошедших проверок с доменом из \u003Ccode>From\u003C\u002Fcode>.\u003C\u002Fli>\n\u003Cli>Если хотя бы одна прошедшая проверка выровнена, DMARC пройден.\u003C\u002Fli>\n\u003Cli>Если нет, применить политику \u003Ccode>p=\u003C\u002Fcode> и записать результат в отчёт.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>Отсюда видно, зачем нужны обе первые проверки, если DMARC достаточно одной. Они страхуют друг друга в типичных ситуациях:\u003C\u002Fp>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Ситуация\u003C\u002Fth>\n\u003Cth>SPF\u003C\u002Fth>\n\u003Cth>DKIM\u003C\u002Fth>\n\u003Cth>DMARC\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>Обычная отправка с настроенного домена\u003C\u002Ftd>\n\u003Ctd>выровнен\u003C\u002Ftd>\n\u003Ctd>выровнен\u003C\u002Ftd>\n\u003Ctd>проходит\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Получатель переслал письмо на другой ящик\u003C\u002Ftd>\n\u003Ctd>не проходит\u003C\u002Ftd>\n\u003Ctd>выровнен\u003C\u002Ftd>\n\u003Ctd>проходит за счёт DKIM\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Список рассылки дописал подвал\u003C\u002Ftd>\n\u003Ctd>не выровнен\u003C\u002Ftd>\n\u003Ctd>подпись сломана\u003C\u002Ftd>\n\u003Ctd>не проходит\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Сервис отправил без настройки вашего домена\u003C\u002Ftd>\n\u003Ctd>не выровнен\u003C\u002Ftd>\n\u003Ctd>не выровнен\u003C\u002Ftd>\n\u003Ctd>не проходит\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Злоумышленник поставил ваш домен в From\u003C\u002Ftd>\n\u003Ctd>не выровнен\u003C\u002Ftd>\n\u003Ctd>нет подписи вашего домена\u003C\u002Ftd>\n\u003Ctd>не проходит, срабатывает политика\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Злоумышленник взял похожий домен, \u003Ccode>examp1e.ru\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd> —\u003C\u002Ftd>\n\u003Ctd> —\u003C\u002Ftd>\n\u003Ctd>DMARC тут ни при чём\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Cp>Последняя строка — граница всех трёх механизмов: они защищают точное имя вашего домена и не мешают регистрировать похожие.\u003C\u002Fp>\n\u003Ch2>Что требуют почтовые провайдеры\u003C\u002Fh2>\n\u003Cp>Gmail требует от всех отправителей SPF \u003Cstrong>или\u003C\u002Fstrong> DKIM на отправляющем домене. От тех, кто отправляет в Gmail больше 5 000 писем в день, требуются SPF \u003Cstrong>и\u003C\u002Fstrong> DKIM, DMARC-запись и выравнивание: домен в \u003Ccode>From\u003C\u002Fcode> должен совпадать с доменом SPF или DKIM. Письма, которые этим требованиям не отвечают, Gmail отклоняет с кодом \u003Ca href=\"https:\u002F\u002Ffmailer.ru\u002Ferrors\u002Fgmail\u002F5-7-26-authentication\">550 5.7.26\u003C\u002Fa>.\u003C\u002Fp>\n\u003Cp>На практике письмо с домена без подписи и без истории Яндекс и Mail.ru принимают неохотно, особенно при большом объёме.\u003C\u002Fp>\n\u003Ch2>Как проверить SPF, DKIM и DMARC\u003C\u002Fh2>\n\u003Cp>Быстрее всего — бесплатными инструментами FMailer, без регистрации:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Ca href=\"https:\u002F\u002Ffmailer.ru\u002Ftools\u002Femail-dns-checker\">Проверка DNS для почты\u003C\u002Fa> — сводный отчёт по SPF, DKIM, DMARC и MX домена.\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"https:\u002F\u002Ffmailer.ru\u002Ftools\u002Fspf-checker\">Проверка SPF\u003C\u002Fa> — дерево \u003Ccode>include\u003C\u002Fcode> и счётчик 10 DNS-запросов.\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"https:\u002F\u002Ffmailer.ru\u002Ftools\u002Fdkim-checker\">Проверка DKIM\u003C\u002Fa> — перебор распространённых селекторов и длина ключа.\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"https:\u002F\u002Ffmailer.ru\u002Ftools\u002Fdmarc-checker\">Проверка DMARC\u003C\u002Fa> — политика, теги и разрешение на внешний \u003Ccode>rua=\u003C\u002Fcode>.\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"https:\u002F\u002Ffmailer.ru\u002Ftools\u002Femail-header-analyzer\">Анализ заголовков письма\u003C\u002Fa> — вердикт принимающего сервера и выравнивание каждого домена с \u003Ccode>From\u003C\u002Fcode> по заголовкам полученного письма.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Последний инструмент отвечает на вопрос, который DNS-проверки не закрывают: записи на месте, но прошло ли конкретное письмо. В заголовках Gmail это строка \u003Ccode>Authentication-Results\u003C\u002Fcode>, например:\u003C\u002Fp>\n\u003Cpre>\u003Ccode>Authentication-Results: mx.google.com;\n       dkim=pass header.d=example.ru;\n       spf=pass smtp.mailfrom=example.ru;\n       dmarc=pass (p=QUARANTINE) header.from=example.ru\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Из консоли записи читаются так:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">dig +short TXT example.ru                     # SPF\ndig +short TXT mail2026._domainkey.example.ru # DKIM, нужен селектор из подписи\ndig +short TXT _dmarc.example.ru              # DMARC\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2>В каком порядке настраивать\u003C\u002Fh2>\n\u003Col>\n\u003Cli>\u003Cstrong>SPF и DKIM для каждого сервиса\u003C\u002Fstrong>, который отправляет от вашего домена: почта сотрудников, сайт, CRM, сервис рассылок.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>DMARC с \u003Ccode>p=none\u003C\u002Fcode> и адресом \u003Ccode>rua=\u003C\u002Fcode>.\u003C\u002Fstrong> Политика пока ничего не меняет, но отчёты начинают приходить.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Две-четыре недели читать отчёты.\u003C\u002Fstrong> В них всплывут источники, о которых вы забыли: старый сервер, бухгалтерия, форма на сайте.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Перейти на \u003Ccode>p=quarantine\u003C\u002Fcode>, затем на \u003Ccode>p=reject\u003C\u002Fcode>\u003C\u002Fstrong>, когда все законные источники выровнены.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>Сразу публиковать \u003Ccode>p=reject\u003C\u002Fcode> опасно: первый же забытый сервис начнёт терять письма, и вы узнаете об этом от клиентов.\u003C\u002Fp>\n\u003Ch2>Частые ошибки\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>Две SPF-записи на одном домене.\u003C\u002Fstrong> Запись должна быть одна. Две записи \u003Ccode>v=spf1\u003C\u002Fcode> дают \u003Ccode>permerror\u003C\u002Fcode>, и SPF не работает ни для одной. Новые сервисы добавляйте в существующую запись через \u003Ccode>include\u003C\u002Fcode>.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Превышен лимит в 10 DNS-запросов.\u003C\u002Fstrong> Пять сервисов со своими вложенными \u003Ccode>include\u003C\u002Fcode> легко выходят за лимит. Уберите неиспользуемые и замените часть \u003Ccode>include\u003C\u002Fcode> на \u003Ccode>ip4:\u003C\u002Fcode>, если адреса сервиса стабильны.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>DKIM-ключ обрезан в DNS.\u003C\u002Fstrong> Ключ на 2048 бит длиннее 255 символов, и часть панелей регистраторов молча обрезает значение. Проверка DKIM покажет, что ключ не разбирается.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Сервис рассылок подписывает своим доменом.\u003C\u002Fstrong> SPF и DKIM проходят, DMARC — нет. В настройках сервиса нужно подключить собственный домен, чтобы \u003Ccode>d=\u003C\u002Fcode> и конверт стали вашими.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Нет \u003Ccode>rua=\u003C\u002Fcode>.\u003C\u002Fstrong> Политика опубликована, но отчёты никуда не идут, и сломанную подпись вы заметите только по жалобам.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Забытые поддомены.\u003C\u002Fstrong> Если у поддомена нет своей записи \u003Ccode>_dmarc\u003C\u002Fcode> и в основной не задан тег \u003Ccode>sp=\u003C\u002Fcode>, на поддомен действует политика основного домена. Сервис, который шлёт с поддомена без выровненной подписи, при \u003Ccode>p=reject\u003C\u002Fcode> на основном домене начинает терять почту.\u003C\u002Fp>\n\u003Ch2>Как это устроено в FMailer\u003C\u002Fh2>\n\u003Cp>В FMailer вы делегируете поддомен через NS-записи, например \u003Ccode>mail.example.ru\u003C\u002Fcode>, и все три записи FMailer публикует и поддерживает сам. Порядок действий — в разделе \u003Ca href=\"https:\u002F\u002Ffmailer.ru\u002Fdocs\u002Fns-records\">«Настройка NS-записей»\u003C\u002Fa>.\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>DKIM\u003C\u002Fstrong>: отдельная пара ключей RSA на 2048 бит для каждого домена, подпись \u003Ccode>rsa-sha256\u003C\u002Fcode>.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>SPF\u003C\u002Fstrong>: адрес конверта по умолчанию совпадает с адресом в \u003Ccode>From\u003C\u002Fcode>, поэтому SPF проверяется по вашему домену и выравнивается для DMARC.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>DMARC\u003C\u002Fstrong>: запись с \u003Ccode>p=quarantine\u003C\u002Fcode> и адресом \u003Ccode>rua=\u003C\u002Fcode> на стороне FMailer. FMailer разбирает агрегированные отчёты и показывает их сводку в панели, а низкая доля выровненных писем ограничивает оценку \u003Ca href=\"https:\u002F\u002Ffmailer.ru\u002Fdocs\u002Freputation\">репутации домена\u003C\u002Fa>.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Корневой домен и его MX при этом не затрагиваются.\u003C\u002Fp>\n\u003Ch2>Частые вопросы\u003C\u002Fh2>\n\u003Ch3>Можно ли обойтись только SPF и DKIM?\u003C\u002Fh3>\n\u003Cp>Для небольшого объёма Gmail требует хотя бы одно из двух, но без DMARC ни SPF, ни DKIM не защищают адрес в \u003Ccode>From\u003C\u002Fcode>: обе проверки проходят и для чужого домена. Для отправителей больше 5 000 писем в день Gmail требует DMARC.\u003C\u002Fp>\n\u003Ch3>Что значит «DMARC fail», если SPF и DKIM — pass?\u003C\u002Fh3>\n\u003Cp>Проверки прошли, но для другого домена. Почти всегда это сервис, который отправляет с собственным адресом конверта и подписывает своим ключом. Подключите в нём свой домен.\u003C\u002Fp>\n\u003Ch3>Какую политику DMARC ставить сначала?\u003C\u002Fh3>\n\u003Cp>\u003Ccode>p=none\u003C\u002Fcode> с адресом \u003Ccode>rua=\u003C\u002Fcode>. Через несколько недель, когда отчёты покажут, что все ваши источники выровнены, переходите на \u003Ccode>p=quarantine\u003C\u002Fcode>, затем на \u003Ccode>p=reject\u003C\u002Fcode>.\u003C\u002Fp>\n\u003Ch3>Почему письмо прошло SPF у одного получателя и не прошло у другого?\u003C\u002Fh3>\n\u003Cp>Чаще всего второй получатель пересылает почту с другого ящика. После пересылки письмо приходит с IP пересылающего сервера, и SPF не проходит. Выровненная подпись DKIM в этом случае сохраняет DMARC.\u003C\u002Fp>\n\u003Ch3>Нужны ли SPF, DKIM и DMARC для домена, с которого не отправляют почту?\u003C\u002Fh3>\n\u003Cp>Да, чтобы от его имени не отправляли другие. Достаточно SPF \u003Ccode>v=spf1 -all\u003C\u002Fcode> и DMARC с \u003Ccode>p=reject\u003C\u002Fcode>: так получатели узнают, что законной почты с этого домена нет.\u003C\u002Fp>\n\u003Ch3>Как проверить SPF, DKIM и DMARC одновременно?\u003C\u002Fh3>\n\u003Cp>\u003Ca href=\"https:\u002F\u002Ffmailer.ru\u002Ftools\u002Femail-dns-checker\">Проверка DNS для почты\u003C\u002Fa> проверяет все три записи и MX в одном отчёте. Чтобы убедиться, что конкретное письмо прошло проверки, вставьте его заголовки в \u003Ca href=\"https:\u002F\u002Ffmailer.ru\u002Ftools\u002Femail-header-analyzer\">анализатор заголовков\u003C\u002Fa>.\u003C\u002Fp>\n\u003Ch2>Итог\u003C\u002Fh2>\n\u003Cp>SPF проверяет сервер, DKIM — подпись, и ни одна из них сама по себе не привязана к домену, который видит получатель. DMARC требует, чтобы хотя бы одна из них прошла для домена из \u003Ccode>From\u003C\u002Fcode>, задаёт правило для писем, где это не так, и присылает отчёты. Порядок настройки: SPF и DKIM, затем DMARC с \u003Ccode>p=none\u003C\u002Fcode>, затем ужесточение политики по отчётам.\u003C\u002Fp>\n\u003Ch2>Попробовать FMailer\u003C\u002Fh2>\n\u003Cp>Подключите поддомен на fmailer.ru: FMailer опубликует DKIM, SPF и DMARC сам, будет следить, чтобы записи не пропали, и примет отчёты DMARC на свой адрес. А проверить текущее состояние своего домена можно прямо сейчас и без регистрации — бесплатными инструментами в разделе «Инструменты».\u003C\u002Fp>\n\u003Cp>\u003Ca href=\"https:\u002F\u002Ffmailer.ru\">Подключить домен на fmailer.ru →\u003C\u002Fa>\u003C\u002Fp>","10dd4654-89c0-41ac-908b-8a322c451871","2026-10-07T20:59:50.877917+03:00","2026-10-07T20:59:50.881941+03:00","fmailer","SPF, DKIM и DMARC простыми словами: зачем нужны все три","SPF, DKIM и DMARC: что проверяет каждая запись, что такое выравнивание домена, почему без DMARC подпись не защищает From и как проверить все три записи.","https:\u002F\u002Fapi.fmailer.ru\u002Fmedia\u002Fblog\u002Frecord_10dd4654-89c0-41ac-908b-8a322c451871\u002F08-spf-dkim-dmarc-prostymi-slovami.jpg",true,"2026-10-18T09:00:00+03:00",[16,17,18,19,20,21],"spf dkim dmarc","dkim spf","dkim dmarc","dmarc spf","проверка spf dkim dmarc","проверить spf dkim dmarc"]