domain-key

<virtual-mta>критичноХаб задаёт сам

Тот же ключ подписи, но объявленный внутри потока отправки
в конфигурации это строкаdomain-keyвнутри блока <virtual-mta>
То же имя ещё 3:<domain-key-list>Global<virtual-mta><virtual-mta-pool>— часть из них другие настройки, часть та же самая
Ключ, который действует только в этом потоке

Та же строка, что и на уровне узла, — селектор, домен, ключ, — но объявленная внутри <virtual-mta>. Механизм выбора описан на общей странице; здесь важно другое: что меняет объявление именно в этом месте.

Меняет две вещи. Ключ становится доступен только письмам этого потока — всё, что уходит другими, его не увидит. И он сильнее общих: если подходящие объявления есть и на уровне узла, и здесь, выигрывают здешние.

Отсюда обычное применение: разные отправители подписываются разными ключами, а разделяются они по потокам.

Главная ловушка — почта не доходит до нужного потока. Руководство отдельно предупреждает: объявив ключ внутри потока, надо позаботиться, чтобы письма с этого домена отправки в него действительно попадали — обычно правилом отбора по MAIL FROM. Иначе ключ есть, подпись включена, а письма уходят другим потоком, где ключа нет, и остаются неподписанными.
Что делает Хаб. Раскладывает ключи по узлам и потокам сам: у каждого адреса отправки свой поток, и ключ ложится в него. Правило отбора при этом Хаб пишет тоже — почта попадает в тот поток, для которого ключ и заведён.
Рекомендуемые значения

Звёздочка внутри потока безопаснее, чем на уровне узла. Здесь она перехватит только письма этого потока, а не всю почту. Пример руководства именно такой.

Проверьте маршрут прежде значения. Ключ в потоке имеет смысл только вместе с правилом, которое направляет туда нужную почту.

Общие объявления не исчезают. Они остаются запасным вариантом для писем, которым здешние не подошли.

Замечание про безопасность звёздочки внутри потока — наше. Из руководства здесь пример с этим значением, приоритет ключей потока и предупреждение о маршруте.
Пример в конфигурации
# ключ действует только для писем этого потока
<virtual-mta mta1>
    domain-key s1, *, /etc/pmta/key.pem</virtual-mta>

# и правило, которое направляет сюда нужную почту
<pattern-list L>
    mail-from /[@\.]example\.com$/ virtual-mta=mta1
</pattern-list>
Второй блок не менее важен первого: без правила отбора письма уйдут другим потоком, где ключа нет, и останутся неподписанными.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Объявляют ключ в потоке и не направляют в него почту

§ 10.3.2

Чем чреватоКлюч есть, подпись включена, письма уходят другим потоком. Узел их не подписывает — молча, без записи в журнале.
Как заметитьПодпись включена, заголовка в письмах нет, а поток пустой.
Как правильноДобавить правило отбора по MAIL FROM либо перенести объявление на уровень узла.

Дублируют общий ключ в каждом потоке

наш опыт

Чем чреватоРотация превращается в правку во многих местах, и рано или поздно один поток остаётся со старым ключом. Приоритет при этом у него — то есть побеждает как раз устаревшее объявление.
Как заметитьПосле ротации часть писем подписана старым селектором.
Как правильноОбщий ключ держать на уровне узла, в потоках объявлять только то, что действительно относится к ним одним.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
domain-key <see-global>
Значения
три значения через запятую — селектор, домен или звёздочка, путь к файлу либо ссылка на хранилище секретов
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<virtual-mta>
Сколько раз
можно повторять
Всё здесь — из руководства, с разделом.
Наследование
Объявление действует внутри своего <virtual-mta> и перекрывает одноимённые объявления уровня узла. Общие при этом не исчезают: они остаются запасным вариантом для писем, которым здешние не подошли. Подхватывается по pmta reload.
Как проверить на узле
Каким ключом подписано письмо, видно по заголовку подписи; в какой поток оно ушло — по списку очередей:
grep -i 'DKIM-Signature' /var/log/pmta/pmta.log | tail -5
pmta show queues | grep -i mta1
Пустой второй вывод при заданном ключе означает, что почта в этот поток не попадает — правило отбора не сработало. Хаб раскладывает ключи по потокам сам.
В Хабе
Управляется
DNS → Ключи подписи
Значение
Хаб подбирает сам — темп, стадия прогрева, метрики
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Ротация адресов отправки
Важность
критично