Наша компания владеет доменом somecompany.com и использует внешнего провайдера электронной почты emailemailprovider.com для отправки электронных писем. Провайдер электронной почты рекомендует делегировать им поддомен для автоматической обработки механизмов аутентификации электронной почты SPF / DKIM и т. Д. Итак, мы добавили это в нашу зону DNS:
em.somecompany.com NS ns1.emailemailprovider.com
em.somecompany.com NS ns2.emailemailprovider.com
С тех пор мы можем отправлять электронные письма через их API, не попадая в папку СПАМ получателей, и установить From заголовок на любой адрес, например user@em.somecompany.com, user@somecompany.com или user@other.somecompany.com. Обратите внимание, что Return-Path домен заголовка все еще em.somecompany.com во всех 3 случаях.
Я понимаю, как можно аутентифицировать user@em.somecompany.com с нашей настройкой, но я не понимаю, почему 2 других адреса FROM считаются действительными получателями.
Смутно понимаю разницу между Return-Path заголовок и From заголовок, но если бы поддомены компании не принадлежали и не управлялись одним и тем же лицом, не могло ли это привести к серьезным ошибкам аутентификации?
Ключ вашего вопроса находится в этой части вашего вопроса:
СПФ, ДКИМ, и т.д. механизмы аутентификации электронной почты.
В и т.п. на самом деле называется DMARC. Подробнее об этом позже.
SPF
Как вы упомянули, SPF аутентифицирует только адрес возврата, также известный как обратный путь. Сохраняя один и тот же адрес возврата для всех отправленных писем, письмо всегда проходит SPF. Этот адрес возврата используется вашим провайдером электронной почты для обработки отказов. Кроме того, теперь они могут управлять вашей записью SPF для этого поддомена, который вы делегировали.
DKIM
Поскольку вы делегировали субдомен с помощью записи NS, поставщик электронной почты теперь может также создавать записи селектора DKIM в зоне _domainkey.em.somecompany.com. Теперь они могут подписывать для вас сообщения из домена em.somecompany.com используется в d= в подписи DKIM.
DMARC
На самом деле является стандартный способ аутентификации адресного домена FROM, включающий как SPF, так и DKIM. Требуется, чтобы один из этих механизмов прошел проверку. И совпадает с доменом, используемым в адресе FROM. Есть два возможных способа выравнивания. Либо
Эти режимы выравнивания для SPF и DKIM контролируются aspf и adkim теги соответственно. Если эти теги опущены в записи политики DMARC, они по умолчанию работают в расслабленном режиме.
Запись DMARC должна быть настроена для каждого домена, который необходимо защитить от подделки. Как минимум, DNS TXT запись должна включать версию и тег политики, например "v = DMARC1; p = отклонить;"
В RFC для DMARC объясняет все теги в разделе 6.3..
Помните, что при отсутствии записи DMARC в поддомене принимающий сервер будет искать запись DMARC для домена организации, используемую в адресе FROM.
Вы можете проверить, есть ли запись DMARC для конкретного субдомена, по адресу _dmarc.em.somecompany.com (TXT запись) и настройте свои собственные записи на основе того, что там настроено.
Получатели не считают их действительными или недействительными. Они просто рассматриваются как «возможно / возможно не спам», поскольку нет связанной записи SPF, чтобы сказать иначе. Содержание электронного письма, скорее всего, будет оценено и не будет считаться спамом, поэтому будет доставлено.
Я думаю, что суть вопроса может заключаться в неправильном предположении, что для электронной почты требуется SPF / DKIM. Это не так - хотя наличие этого может ускорить доставку.