Demo
Demo
База знаний PMTA›Блок <domain>›Директива§ 3.3.10.2

check-spf-outbound

<domain>

Проверять ли SPF своей почты перед отправкой этому получателю
в конфигурации это строкаcheck-spf-outbound falseвнутри блока <domain>
Отбить у себя, чтобы не испортить репутацию у получателя

Включает проверку SPF своей исходящей почты для писем этому получателю. Узел сверяет адрес, с которого собирается отправлять, с записью SPF домена обратного адреса — ровно так, как это сделает приёмник.

Исходы жёсткие. Pass — доставка продолжается. TempError — письмо возвращается в очередь и повторяется. Любой другой результат — отказ, письмо не уходит.

Работает только при явно заданном адресе отправки. Нужен smtp-source-host или smtp-proxy-source-host — на уровне узла или потока. Без них проверять нечего, и узел ведёт себя как при временной ошибке: письма копятся в очереди.

Главная ловушка — включают на всё сразу, включая домен отказов. Ошибка в его записи SPF превращает входящие отказы в исходящие, которые тоже отбиваются, — руководство называет это двойным отказом. Вы перестаёте получать обратную связь и узнаёте об этом позже всех.
Что делает Хаб. Не пишет. Кандидат на включение: адреса отправки Хаб задаёт сам, записи SPF публикует сам — обе половины механизма у него есть. Включать надо с явным исключением для домена отказов.
Рекомендуемые значения

Домену отказов — no, остальным yes. Это прямая рекомендация руководства, а не осторожность.

Сначала адрес отправки, потом проверка. Без явно заданного адреса включение приводит не к отказам, а к застрявшей очереди.

Проверьте вручную до включения. Команда pmta check spf отвечает тем же результатом, но ничего не отбивает.

Порядок «сначала адрес, потом проверка» — наш. Из руководства здесь умолчание, все три исхода, требование заданного адреса отправки и рекомендация исключить домен отказов.
Пример в конфигурации
# домену отказов — нет, остальным — да
<domain yourbouncedomain.com>
    check-spf-outbound no
</domain>

<domain *>
    check-spf-outbound yes</domain>
Без первого блока ошибка в записи SPF домена отказов отберёт у вас обратную связь целиком.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

Типичные ошибки и проблемы

что делают не так и чем это кончается3 ошибки▶

Включают для домена отказов

§ 10.2

Чем чреватоОтказы, приходящие на этот домен, при ошибке в его записи SPF отбиваются сами. Обратная связь пропадает целиком, и об этом узнаёшь позже всего остального.
Как заметитьПоток отказов упал почти до нуля без изменений в отправке.
Как правильноОтдельным блоком выключить проверку для домена отказов.

Включают без заданного адреса отправки

§ 10.2

Чем чреватоПроверку выполнить нечем. Узел пишет ошибку в журнал и держит письма в очереди как при временной неудаче — до истечения срока жизни.
Как заметитьОчередь растёт, доставок нет, в журнале ошибки проверки.
Как правильноЗадать smtp-source-host и убедиться, что он виден в настройках.

Включают, не проверив запись SPF вручную

наш опыт

Чем чреватоОшибка в собственной записи превращается в отказы своей же почты. Приёмник её не увидит вовсе — письма не доедут.
Как заметитьРезкий рост отказов сразу после правки конфигурации.
Как правильноПрогнать pmta check spf по каждому адресу отправки до включения.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
check-spf-outbound <boolean>
Значения
yes или no; true и false принимаются наравне с ними
Умолчание
false § 3.3.10.2
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<domain>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Значение сливается по блокам <domain> от общего к частному: побеждает наиболее подходящий блок, а не последний по файлу. Блок <domain> можно вложить в <virtual-mta>. Подхватывается по pmta reload; на письма в очереди действует со следующей попытки — проверка выполняется при отправке.
⇄

Связанные директивы

3 связи

Без чего не работает

smtp-source-hostGlobalАдрес отправки, без которого проверку выполнить нечем. § 3.3.10.2smtp-proxy-source-hostGlobalВторой способ задать адрес отправки — при работе через прокси. § 3.3.10.2

То же имя в других блоках

check-spf-inbound<source>Та же проверка с другой стороны: та смотрит чужую входящую почту, эта — свою исходящую. § 3.3.7.22

Сюда ссылаются

mail-from<rewrite-list>Проверять SPF надо по переписанному адресу: именно его увидит приёмник. § 3.3.10.2Не отправлять то, что не пройдёт проверку у получателяСтрока, которая включает механизм для конкретного получателя. § 10.2

Как проверить на узле
Действующее значение печатает команда настроек очереди; тот же результат можно получить вручную, ничего не отбивая:
pmta show settings gmail.com/vmta1 | grep -i check-spf-outbound
pmta check spf 203.0.113.10 mail.example.com sender@example.com
Вторая команда даёт тот же вердикт, что и включённая проверка, но без последствий для почты. Хаб этой строки пока не пишет.
◇

Что ещё почитать

3 статьи

◇Не отправлять то, что не пройдёт проверку у получателяУзел сам проверяет SPF своей почты перед отправкой: не прошло — отбивает, не дожидаясь чужого отказа.◇Что узел рассказывает о себе и по каким каналамСемь поверхностей наблюдения: веб-монитор, консоль в четырёх форматах, журнал, учёт, поиск по учёту, метрики и выгрузка во внешнюю аналитику.◇Сторож, который перезапускает MTAПрисматривает за MTA и после падения поднимает его сам, отправляя отчёт о падении на адрес ответственного.

В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Разобраться с доставляемостью · Подпись и аутентификация писем
Соседние настройки блока <domain>:dkim-signdkim-identityarc-signdkim-headersdkim-disallow-adding-headersВсе 135 директив блока →