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