Почему письма из WordPress попадают в спам?

Если Вам когда-нибудь приходилось настраивать WordPress с функцией отправки электронных писем, будь то онлайн магазин, где в письме клиенту приходят детали заказа, или регистрация на сайте с подтверждением по Email, то, наверняка, Вы сталкивались с тем, что письма, которые отсылает WordPress попадают в спам или вообще не доходят до адресата. Если у Вас есть возможность создать отдельного пользователя SMTP для отправки почты, то одним из самых простых решений будет настройка SMTP в WordPress. Но иногда такой возможности нет, или же просто не хочется идти по этому пути. В этой статье я расскажу с какими трудностями я столкнулся и как их решил, кратко расскажу о SPF, DKIM и DMARC и на примере DigitalOcean и Microsoft Office 365 покажу как настроить DNS, чтобы письма больше не попадали в спам. Сразу сделаю небольшое отступление — статья для новичков и я постараюсь максимально упростить понимание написанного, сократив технические термины и объяснения. Так что с технической точки зрения где-то могут быть недочеты, но для понимания так будет проще. И всегда можно погуглить о дополнительной информации.

Для начала нужно понять в чем суть проблемы. Как происходит отправка почты из WordPress и почему письма попадают в спам? Я попытался схематически изобразить что происходит с письмом при отправке.

Когда WordPress решает отправить письмо некому адресату, то он посылает его через SMTP веб-сервера (для примера, пусть сервер будет со следующим IP-адресом: 100.100.100.100), письмо доходит до адресата, заголовки письма парсятся и извлекается адрес Return-Path. Далее делается запрос к серверу Return-Path (в нашем примере сервер имеет IP-адрес: 200.200.200.200) и идет проверка на то может ли вообще веб-сервер отправлять письма от имени почтового сервера. Вот тут и кроется основная проблема — почтовый сервер не давал разрешения веб-серверу отправлять письма от имени отправителя. Но на помощь нам приходят SPF, DKIM и DMARC.

Sender Policy Framework, SPF (инфраструктура политики отправителя) — расширение для протокола отправки электронной почты через SMTP. SPF позволяет проверить, не подделан ли домен отправителя. Данные SPF можно получить из TXT записи в DNS. Она имеет следующий формат:

example.org. IN TXT "v=spf1 a mx -all"

v=spf1 Указывает на версию SPF
a Говорит о том, что если есть запись A для домена отправителя, то произойдет совпадение по данному правилу. И если IP адрес веб-сервер совпадает с IP адресом A записи, то проверка SPF будет пройдена.
mx Тоже самое, только проверяется запись MX.
-all Означает, что если сообщение не прошло проверку, то оно отвергается. Некоторые считают, что вместо -all стоит указывать ~all, когда сообщения не отклоняются, а к заголовку добавляется специальный тэг, говорящий о том, что сообщение стоит проверить более тщательно.

Наиболее распространенной ошибкой является создание нескольких TXT зон. В таком случае принимающий сервер может не понять какую из зон использовать для запроса, сообщение не пройдет проверку и попадет в спам или не будет доставлено вообще. Если необходимо добавить какие-то дополнительные параметры, например еще один адрес или include, то они добавляются в текущую TXT запись SPF, а не в новую.

Теперь на примере DigitalOcean и Office 365, как выглядит TXT зона у меня:

example.org. IN TXT "v=spf1 a mx include:spf.protection.outlook.com -all"

DKIM — это метод аутентификации Email сообщений, который позволяет предотвратить спуфинг адреса. Суть работы DKIM в том, что Ваш почтовый сервер подписывает отправленные сообщения закрытым ключом шифрования, а принимающая сторона пытается проверить подлинность подписи, используя открытый ключ. Если проверка пройдена, соответствующая пометка делается в заголовке письма и оно (письмо) передается дальше для принятия окончательного решения.

DKIM, как и SPF, настраивается через DNS запись. И весь процесс проверки очень схож со схемой SPF, разница лишь в том, что для SPF мы в DNS ищем разрешенные домены или адреса, а для DKIM через DNS мы получаем открытый ключ шифрования, который дальше используем для проверки целостности сообщения. Говоря простым языком — сервер шифрует заголовки письма (не само тело сообщения, это важно понимать!) и отсылает. А принимающая сторона пытается с помощью открытого ключа проверить — не было ли изменено сообщение.

Для DKIM нужно создать две зоны CNAME, на примере Office 365 записи следующие:

selector1._domainkey.example.org.  3600  IN  CNAME  selector1-example-org._domainkey.example.onmicrosoft.com
selector2._domainkey.example.org.  3600  IN  CNAME  selector2-example-org._domainkey.example.onmicrosoft.com

То что выделено жирным шрифтом — это initialDomain, которые дается при регистрации в Office 365. Не обязательно, что он будет производным от домена. После публикации записей CNAME в DNS нужно активировать DKIM в панели администрирования Office 365 в разделе Амдинистратор — Exchange, пункт меню Защита > dkim.

Хорошо, мы настроили SPF и DKIM, но письма все равно попадают в спам! Ну, во-первых, письма отправленные с веб-сервера не будут подписываться DKIM, и в рамках этой статьи у меня нет цели показать как это сделать. Не стоит забывать, что SPF и DKIM — это хорошие идеи, но они не является неким обязательным критерием, позволяющим со 100% вероятностью верифицировать отправителя письма. Они лишь помогают системе фильтрации спама принять правильное решение. И теперь нам на помощь приходит DMARC.

Если обратиться к Wikipedia, то определение DMARC выглядит следующим образом:

Domain-based Message Authentication, Reporting and Conformance (идентификация сообщений, создание отчётов и определение соответствия по доменному имени) или DMARC — это техническая спецификация, созданная группой организаций, предназначенная для снижения количества спамовых и фишинговых электронных писем, основанная на идентификации почтовых доменов отправителя на основании правил и признаков, заданных на почтовом сервере получателя.

DMARC устанавливает стандарт для идентификации электронных сообщений принимающими узлами с использованием механизмов Sender Policy Framework (структуры политики отправителя, SPF) и DomainKeys Identified Mail (почты, идентифицируемой при помощи доменных ключей, DKIM). Это означает, что будут выдаваться единые результаты идентификации сообщений отправителей на принимающих узлах Gmail, Yahoo!, Mail.ru, Яндекс.Почта и любых других принимающих узлах, использующих DMARC. Создатели спецификации надеются, что со временем стандарт будет поддержан большинством почтовых серверов, что позволит электронной почте стать более надёжным способом общения.

Если, опять же, попытаться все объяснить понятным языком, то можно представить DMARC — инструментом, позволяющим Вам сообщить провайдеру что делать с письмами, если они не прошли проверки SFP или DKIM или если такой проверки не было вообще. Например, можно настроить DMARC так, что письма не прошедшие проверку SFP и DKIM всегда отвергались.

Для DMARC нужно сделать следующую запись в DNS:

_dmarc.example.org. IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:<email для отчетов>; sp=none; aspf=r;"

v=DMARC1 Указывает на версию DMARC.
p=none Указывает на то, что делать с письмами ничего не надо. Используется лишь для настройки DMARC. Дальше стоит менять на p=reject.
pct=100 Какой процент письма отвергать. Если задаете p=reject, то стоит начать с более низких значений, таких как pct=10. Эти письма будут попадать в спам. И если со временем результаты Вас удовлетворят, то значение можно постепенно увеличивать.
rua=mailto:<email для отчетов> Куда отсылать отчеты.

Провайдеры, которые поддерживают DMARC будут отсылать отчеты в формате XML на адрес, указанный выше в TXT зоне. В отчете указывается IP-адрес отправителя и статус пройденной проверки SPF и DKIM. Но т.к. отчеты XML очень неудобны с точки зрения «чтения и изучения», можно воспользоваться сторонними сервисами, которые будут генерировать отчеты, удобные для восприятия. Я рекомендую обратить внимание на сервис Postmark.

Ваша задача будет заключаться в том, чтобы просматривать отчеты и определять являются ли отправители «нормальными» или это все же спам. Для крупных сервисов отправки почты есть инструкции как настраивать SPF и DKIM для прохождения необходимых проверок. Но вот для Вашего сервера — необходимы будут дополнительные настройки.

Наверное, на этом я остановлюсь, т.к. я рассказал основные моменты, на которые стоит обратить внимание. У меня достаточно было добавить запись SPF, и письма перестали попадать в спам. Настроив DKIM и DMARC позволило мне значительно сократить количество спама, особенно вирусного. Ну и каждую неделю я получаю отчеты по тем адресатам, которые так или иначе не проходят проверки SPF и DKIM. Вы удивитесь какие отправители там иногда отмечаются как не прошедшие проверки.

Очень хорошая статья о SPF, DKIM и DMARC — здесь. Но она на английском.

Проверить правильность настройки можно тут или отправив письмо вот сюда,