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

dkim-identity

<domain>

От чьего имени поставлена подпись
в конфигурации это строкаdkim-identity sender-or-fromвнутри блока <domain>
Чьё имя стоит в подписи, когда отправляют за другого

В подписи два поля про имя. d= — домен ключа, он берётся из объявления domain-key. i= — имя подписи, и его задаёт эта строка. По умолчанию узел берёт его из заголовка Sender, а если того нет — из From.

Ради чего её трогают. Отправка за клиента: в From стоит его домен, а ключа на этот домен у вас нет — управляет им клиент. Задав своим именем подписи собственный домен, вы подписываете письмо своим ключом и своей записью в DNS, а From остаётся клиентским.

Ограничение одно, и оно жёсткое. Имя подписи должно совпадать с доменом ключа или быть его поддоменом. Своим доменом подписать можно, чужим — нет.

Отдельное значение strict-from требует точного совпадения домена из From: ни поддомен, ни заголовок Sender в поиске ключа больше не участвуют.

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

Умолчание почти всегда верно. Имя подписи из заголовков — то, чего приёмник и ждёт.

Свой домен — только когда чужого ключа нет. И понимая цену: несовпадение d= с From заметно получателю.

strict-from сужает поиск ключа. Он полезен там, где поддомены не должны подписываться родительским ключом, — но и молча оставит без подписи всё, что не совпало точно.

Оценка «подпись от своего имени снижает доверие» — наша. Из руководства здесь все значения, связь имени подписи с доменом ключа, ограничение на их совпадение и поведение строгого режима.
Пример в конфигурации
# отправляем за клиента: в From его домен, подпись наша
domain-key key1, esp456.com, /etc/pmta/key1.esp456.com.pem

<domain yahoo.com>
    dkim-sign yes
    dkim-identity @esp456.com</domain>
Имя подписи совпадает с доменом ключа — иначе объявление не подойдёт. В письме получатель увидит клиентский From и ваш домен в поле d=.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Задают имя подписи, не совпадающее с доменом ключа

§ 3.3.10.27

Чем чреватоОбъявление не подходит, и письмо уходит без подписи — молча. Имя подписи обязано совпадать с доменом ключа или быть его поддоменом.
Как заметитьПодпись включена, ключ есть, заголовка в письмах нет.
Как правильноПривести имя подписи к домену объявления domain-key либо завести ключ на нужный домен.

Подписывают своим именем всю почту за клиентов

наш опыт

Чем чреватоВ каждом письме d= вашего домена при клиентском From. Крупные приёмники это сверяют, и доверие к письмам падает — притом что подпись формально верна.
Как заметитьДоставляемость по клиентским доменам ниже, чем по своим, при верной подписи.
Как правильноДоговариваться о ключе на домене клиента; эту строку держать запасным вариантом.

Ставят strict-from, не проверив поддомены

§ 3.3.10.27

Чем чреватоПоиск ключа сужается до точного домена из From. Всё, что уходит с поддоменов, остаётся без подписи, хотя родительский ключ есть.
Как заметитьПисьма с основного домена подписаны, с поддоменов — нет.
Как правильноЛибо завести ключи поддоменам, либо вернуть обычное значение.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
dkim-identity <enumeration-or-address>
Значения
домен или адрес электронной почты; sender-or-from — брать из заголовков; strict-from — только точный домен из From
Умолчание
sender-or-from § 3.3.10.27
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<domain>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Значение сливается по блокам <domain> от общего к частному: побеждает наиболее подходящий блок, а не последний по файлу. Задаёт поле i= подписи, но не d=: тот берётся из домена объявления domain-key, и имя подписи обязано совпадать с ним или быть его поддоменом. Подхватывается по pmta reload.
⇄

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

2 связи

Зависит от

domain-keyGlobalДомен объявления и есть домен подписи; имя подписи обязано совпадать с ним или быть его поддоменом. § 3.3.10.27

Работают в паре

dkim-identity-fallback<domain>Запасное имя подписи на случай, когда по основному ключа не нашлось; без этой строки оно не работает. § 3.3.10.28

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

dkim-sign<domain>Решает, от чьего имени поставлена подпись, — и по этому же имени выбирается ключ. § 3.3.10.27arc-identity<domain>Та же настройка для обычной подписи — но там имя дополняет домен ключа, а здесь заменяет его. § 3.3.10.36

Как проверить на узле
Действующее значение печатает команда настроек очереди; что вышло — видно в полях i= и d= самой подписи:
pmta show settings yahoo.com/vmta1 | grep -i dkim-identity
grep -i 'DKIM-Signature' /var/log/pmta/pmta.log | tail -3
Расхождение d= с доменом из From — то самое, что видит и сверяет приёмник. Хаб этой строки не пишет.
◇

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

3 статьи

◇Лицензия на парк, а не на серверЛицензия не привязана к серверу: её ставят на столько машин, сколько разрешает предел экземпляров, а узлы раз в час отправляют вендору статистику объёма.◇Как узел выбирает источник и складывает его настройкиСоединение попадает под все блоки источника, чьи адреса его накрывают, и действуют они слитно — узкий перекрывает широкий; именованные блоки подключаются только по прямой ссылке.◇Списки адресов — именованные и безымянныеСписок адресов, доменов, образцов или хешей; именованный подключается директивами вроде подавления, безымянный живёт внутри процессора входящей почты.

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