DMARC и SPF настроены для моего домена без www, но не работают для www.

Мой веб-сайт работает на www.example.com, и я отправляю автоматические электронные письма с моего адреса [email protected]. DMARC и SPF, похоже, настроены соответствующим образом:

_dmarc : v=DMARC1;p=none;pct=100;rua=mailto:[email protected];ruf=mailto:[email protected]

spf : v=spf1 a mx include:_spf.elasticemail.com ~all

Однако я постоянно получаю отчеты по электронной почте от Google и Yahoo, в которых говорится, что мой адрес электронной почты не подвержен аутентификации. Когда я использую бесплатные анализаторы DMARC, они выдают сообщение (в качестве предупреждения):

Запись DMARC не найдена для подсети. Организационный домен этой подсети: example.com. Получатели во входящих будут применять запись DMARC example.com к почте, отправленной с www.example.com

Другой говорит (в качестве предупреждения):

Запись DMARC определена, но есть некоторые проблемы с конфигурацией, которые могут повлиять на безопасность, видимость и доставляемость электронной почты, отправленной с этого домена.

DMARC не действует для example.com. Любой может отправлять сообщения, выдавая себя за адреса на этом домене или его подсетях.

Что бы я ни делал, я не мог преодолеть эту проблему. Что я делаю не так? Все ли дело в том, что мой домен — www.example.com, и я использую [email protected] как подсеть для отправки email?

“Мой веб-сайт работает на www.example.com, и я отправляю автоматические электронные письма с моего адреса [email protected].”

Когда эти автоматические письма отправляются с вашего веб-сайта или приложения, кажется, что они отправляются с использованием собственного почтового сервера без какой-либо SMTP-аутентификации. Например, веб-сайт может отправлять сообщения для подтверждения регистрации пользователей, используя программное обеспечение почтового сервера sendmail или postfix, которые обычно устанавливаются на веб-серверах для этой цели, однако те, кто отправляет спам или поддельные сообщения, используют те же техники и также могут заявить, что отправляют электронную почту с [email protected]. С некоторой настройкой ваш веб-сайт мог бы отправлять аутентифицированные электронные письма, т.е. вместо использования встроенного программного обеспечения почтового сервера, сайт подключается к основному SMTP-серверу вашего домена (это может быть Exchange или Office365 или Google и т.д.; существуют и другие бренды почтовых серверов), аутентифицируется с помощью имени пользователя и пароля, так же, как вы бы это сделали, если бы использовали клиентское приложение электронной почты на своем телефоне или веб-почте, а затем отправляет электронное письмо.

“Запись DMARC не найдена для подсети. Организационный домен этой подсети: example.com. Получатели во входящих будут применять запись DMARC example.com к почте, отправленной с www.example.com”

В отсутствие записи DMARC для подсети будет применяться основная запись домена. Если вы не используете адреса электронной почты, такие как [email protected], это вряд ли будет проблемой. Вы можете гарантировать, что в этом случае произойдет сбой SPF, создав wildcard SPF запись, чтобы покрыть любые подсети, о которых могут подумать спуферы, например: v=spf1 -all и введя * как имя хоста для этой записи. Это не помешает записи SPF, которую вы создали для @, которая охватывает ваше обычное использование электронной почты для домена, например, адреса электронной почты, такие как [email protected].

“Запись DMARC определена, но есть некоторые проблемы с конфигурацией, которые могут повлиять на безопасность, видимость и доставляемость электронной почты, отправленной с этого домена.”

Без более тщательного расследования будет сложно точно сказать, на какую проблему это может указывать, однако это может быть так же просто, как указание адреса электронной почты с тем же доменным именем для отправки отчетов. Если есть проблемы с доставкой электронной почты для домена example.com, ваши отчеты об этом могут не быть получены по адресу [email protected]! Возможно, стоит настроить [email protected] или другой домен для обработки ваших отчетов DMARC.

“DMARC не действует для example.com. Любой может отправлять сообщения, выдавая себя за адреса на этом домене или его подсетях.”

Это просто означает, что у вас p=none или p=quarantine в данный момент. Первое идеально подходит для тех случаев, когда вы только начинаете и хотите получить представление о том, что происходит, не желая создавать проблемы без необходимости. Второе является хорошей промежуточной точкой, чтобы начать видеть, как сообщения помещаются в карантин (перемещаются в папки спама), когда вы тестируете, какие из них блокируются, а какие нет. В конечном итоге цель большинства организаций будет заключаться в том, чтобы установить это на p=reject, чтобы гарантировать, что сообщения просто отбрасываются и никогда не получаются. Поскольку форенсические отчеты DMARC в настоящее время редко внедряются, вы можете быть на самом деле в безопасности, выбрав карантин, пока не убедитесь, что те, кто помещается в карантин, не содержат никаких подлинных сообщений. Придется немного поработать над настройками, прежде чем перейти на p=reject. Сообщение, которое вы видите, не означает, что вы сделали что-то неправильно; это просто значит, что ваша реализация находится на ранних стадиях.