Назад | Перейти на главную страницу

Полезно ли настраивать SPF для домена виртуального хостинга

Я сейчас немного запутался:

Насколько я понимаю, SPF-записи должны подтверждать MAIL-FROM и, возможно, HELO от отправляющего почтового сервера. Если я нахожусь в среде общего хостинга, где у меня нет доступа к конфигурации почтовых серверов, зачем мне добавлять запись SPF в DNS моего домена?

Например, в doku 1 и 1 я нашел: https://help.1and1.com/domains-c36931/manage-domains-c79822/dns-c37586/explanation-of-an-spf-record-a792807.html что предполагает, я должен добавить 

 include:_spf.kundenserver.de

к записи SPF.

Но когда я смотрю на информацию MAIL FROM и EHLO, когда я отправляю электронное письмо с test@exampledomain.com, оно содержит только:

$receivingServer>> grep 'MAIL FROM' /var/log/mail.log
mout.kundenserver.de[212.227.126.133]: MAIL FROM:<cgi-mailer-bounces-373775065@kundenserver.de> SIZE=1534

$receivingServer>> grep 'EHLO' /var/log/mail.log
mout.kundenserver.de[212.227.126.133]: EHLO mout.kundenserver.de

$receivingServer>> grep 'exampledomain.com' /var/log/mail.log
[empty]

Итак, мой вопрос: действительно ли полезно добавлять в эту среду предлагаемую SPF-запись? Проверяет ли SPF-Validator когда-либо домен FROM в заголовках электронной почты?

Заранее спасибо.

EHLO / HELO не имеет значения, он только рекомендуется стандартом и часто игнорируется. С помощью SPF получатель проверяет, разрешено ли отправляющему серверу (который не обязательно совпадает с его именем хоста / адресом) отправлять электронные письма для домена MAIL FROM-адреса.

Итак, если кто-то получает письмо от user@exampledomain.com (как FROM / Return-Path конверта), его можно проверить, разрешено ли это делать отправляющему серверу. Если отправляющие серверы - это только те, которые предоставляет ваш провайдер, используйте include:_spf.kundenserver.de -all.

Если вы не отправляете электронные письма с вашим доменом как MAIL-FROM, вы можете установить его на -all.

В этом конкретном примере некоторые вещи перепутались: ваше сообщение было отправлено из веб-пространства общего хостинга, которое автоматически добавляет общий адрес MAIL FROM (cgi-mailer-bounces-${some_id}@kundenserver.de) всякий раз, когда ваша почта -сценарий отправки не указал один (с использованием "sendmail -f sender@domain.tld"). Итак, в этом примере ваш собственный домен вообще не используется. Используемый домен (kundenserver.de) действительно имеет запись SPF, включая используемый почтовый сервер 212.227.126.133, поэтому чистая проверка SPF отлично работает для примера сообщения, но, вероятно, это не та конфигурация, которую вы хотели бы использовать , так как вы можете столкнуться с дальнейшими проблемами.

В общем, записи SPF важны для любого типа почтового домена, независимо от того, где и как он размещен.

SPF сам по себе может защитить ваш домен от переполнения незаконными спам-сообщениями (используя ваше доменное имя в MAIL FROM).

Добавление записи SPF в ваш домен определяет, каким почтовым серверам разрешено доставлять почту от имени вашего домена. Это может защитить (до некоторой степени) ваш домен от злоупотребления спамерами, но также (в некоторой степени) гарантирует вашу пользу при отправке почты.

Упрощенный:

  • если присутствует запись SPF и отправляющий сервер находится в списке этой записи SPF, сообщение рассматривается как «подлинное» письмо от вашего домена. Это не гарантирует, что ваша почта будет доставлена ​​как "не спам"; однако, если отправляющий сервер отсутствует в списке записей SPF, сообщение с большей вероятностью будет отклонено или отправлено в папку «спам» получателя.
  • если для вашей почты / домена нет записи SPF (и ничего подобного DKIM), принимающий сервер не знает, было ли сообщение отправлено законно с вашего домена. Поскольку большинство законных писем отправляется с использованием SPF и / или DKIM, фильтр спама на принимающем почтовом сервере может с большей вероятностью направить ваше сообщение как «потенциальный спам» в папку «спама» получателя.
  • если MAIL FROM-адрес пуст, то нет адреса или домена, на который должны отправляться сообщения об ошибках / отказы; обычно это используется только для отправки отказов. В этом особом случае используется запись SPF для домена, используемого в HELO / EHLO.

Помимо SPF, также необходимо упомянуть DKIM и DMARC.

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

В SPF есть некоторая путаница в том, как следует использовать политику по умолчанию. Проверки SPF могут выполняться на уровне SMTP до того, как фактическое сообщение будет прочитано для доставки, поэтому «жесткая» политика SPF (-all) может иметь серьезные побочные эффекты и может применяться до того, как это сделают любые другие проверки или фильтры спама. Таким образом, для SPF рекомендуется использовать нейтральную (? Все) или мягкую (~ все) политику по умолчанию. Затем SPF фактически становится ваучером в пользу ваших законных почтовых серверов.

DKIM решает некоторые проблемы с SPF, но его сложнее реализовать, чем SPF. DKIM требует добавления криптографических закрытых ключей к вашему почтовому серверу и специальной записи TXT для вашего домена (соответствующий открытый ключ). Каждый раз, когда ваш почтовый сервер (законно) отправляет почту с использованием вашего домена и поддерживает DKIM, он добавляет цифровую подпись к ряду других заголовков сообщений (включая From-Header), чтобы доказать, что сообщение было законно отправлено с использованием вашего домена. . Затем принимающий сервер может проверить эту подпись (специальный заголовок), используя специфичную для DKIM запись TXT. У DKIM нет политики по умолчанию: действительная подпись - это просто ваучер в пользу этого сообщения, недействительные подписи следует игнорировать (они могут случайно сломаться при пересылке через какую-либо службу списков рассылки).

Важно, чтобы ваш домен / почтовый сервер поддерживал SPF, DKIM или, в лучшем случае, оба стандарта.

DMARC сочетает SPF и DKIM вместе со своей собственной политикой:

  • Домен, используемый в MAIL FROM, должен быть либо точно таким же, либо поддоменом домена, используемого в заголовке From сообщения, либо пустым (для сообщений о недоставке). Добавленный по умолчанию cgi-mailer-bounces-${some_id}@kundenserver.de, скорее всего, нарушит работу DMARC), поэтому при отправке почты вам следует указать свой домен.
  • если какой-либо заголовок-подписи DKIM действительно соответствует домену, используемому в заголовке From сообщения, DMARC принимает сообщение.
  • если запись SPF присутствует и проверка SPF проверяет домен, используемый в заголовке «От» (а не в домене MAIL FROM), DMARC принимает сообщение.
  • DMARC четко определяет, как следует обрабатывать нарушения DMARC: игнорировать («режим мониторинга»), отклонять или направлять в папку со спамом. DMARC также указывает, следует ли и как сообщать о таких нарушениях.

Поддержка DMARC в отрасли растет.

И это полный ответ на ваш вопрос: - когда вы используете DMARC, принимающие почтовые серверы оценивают вашу запись SPF с помощью заголовка From сообщения. - вам следует как минимум добавить запись SPF в свой домен, используя как рекомендованную вашим веб-хостом политику "include: _spf.kundenserver.de", так и нейтральную ("? all") или мягкую ("~ all") политику по умолчанию. . - Если ваш хост поддерживает DKIM, используйте и его (в противном случае: попросите их поддержать его…). - И SPF, и DKIM увеличивают (или: их отсутствие может уменьшать) ваши шансы на успешную доставку ваших сообщений. Вы должны поддержать хотя бы одного из них. - возможно, вы захотите изучить использование DMARC, поскольку он использует SPF и DKIM, исправляя при этом несколько проблем с обоими стандартами. Использование DMARC без DKIM (поэтому полагаться только на SPF) не рекомендуется, если вы действительно не знаете, что именно делаете.