SPF - я должен реализовать?

Веб-разработчик сделал запрос на запись DNS нашего домена, чтобы включить записи SPF TXT. Я нашел разные мнения по этому поводу там ...

Любые комментарии или идеи, которые вы можете предложить, будут высоко оценены. Я знаю, что это не эмпирический вопрос сам по себе - но я был бы признателен за ваши субъективные предложения, тем не менее ... Особенно, если бы они приходили со ссылками, на которые я мог бы посмотреть, такими как веб-сообщения или онлайн-документы и т. Д.

Да. Я бы не назвал это субъективным, потому что есть четкое согласие; использовать SPF .

Реализация очень проста, и это хорошая вещь для Интернета в целом.

Вы, вероятно, видите датированные ссылки. Основываясь на проценте действительной электронной почты, которую мой сервер получает от серверов, использующих SPF, единодушным является использование SPF.

От всей души рекомендую настроить SPF. Настройте записи для своего MX, позволяющего отправлять электронную почту, а также для домена, который вы используете в адресах электронной почты. Для доменов, которые не отправляют электронную почту, установите SPF, чтобы указать это.

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

Если ваш сервер поддерживает записи SPF, настройте их в дополнение к записям TXT. Если вы измените свою конфигурацию, может быть небольшая нагрузка на синхронизацию записей, но многие системы могут настроить свой SPF, чтобы он автоматически настраивался на MX и изменения адреса.

Возможно, вы захотите просмотреть мой пост о защите репутации вашей электронной почты с помощью SPF . Моя первая реализация SPF состояла в том, чтобы заблокировать спамера, который подделывал домен, для которого я предоставляю услуги электронной почты. Несмотря на относительно низкое проникновение SPF, он был очень эффективен при их отключении. Однако мы все равно получаем спам по поддельному адресу, который они создали. (Это отличный способ проверить спаммеров, так как только спаммеры будут использовать этот адрес.)

Я считаю, что проникновение SPF на принимающей стороне, вероятно, больше, чем на издательской стороне.

РЕДАКТИРОВАТЬ: Если вы используете записи SPF, убедитесь, что люди, доставляющие автоматические почтовые сообщения, знают о необходимости добавления своих серверов. (Сервер должен быть полностью проверен, поскольку автоматизированные системы часто плохо настроены и могут иметь профиль, похожий на спамбот. Не так уж сложно правильно настроить сервер.)

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

Я думаю, что лучшим доказательством того, что это хорошо, является рассмотрение нескольких крупных почтовых сервисов. Просто найдите заголовки «Received-SPF» в исходном письме, чтобы проверить, установлен ли флажок «SPF». Например:

Yahoo Mail:

Received-SPF: pass (domain of example.com designates xxx.xxx.xxx.xxx as permitted sender)

Gmail:

Received-SPF: pass (google.com: domain of user@example.com designates xxx.xx.xx.xx as permitted sender) client-ip=xxx.xx.xx.xx;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of user@example.com designates xxx.xx.xx.xx as permitted sender) smtp.mail=user@example.com

Hotmail также проверяет SPF (хотя, я думаю, они называют его Sender-ID). В целом, это простое дополнение, которое может принести много пользы - как для вашего домена, так и для Интернета в целом.

Как и другие респонденты (пока), я рекомендую внедрить SPF.

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

Однако другая, очень важная причина заключается в том, что она улучшает возможности доставки получателям, чьи поставщики внедряют SPF.

Мне, конечно, было бы очень интересно узнать, каковы недостатки SPF. В настоящее время все, что я знаю, это:

1. пользователи должны направлять свою исходящую почту через назначенные серверы - хотя контроль исходящей почты имеет очевидные преимущества, это может добавить некоторые сложности, если у вас есть удаленные пользователи - вам нужно настроить SMTP-аутентификацию или VPN

2. проблема с некоторым переадресацией - какой IME очень редкий

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

Рассмотрим A с адресом a@a.org(кто в MX реализует SPF) отправляет письмо B с адресом, b@b.orgкоторый настроил этот адрес для пересылки почты b@reallyb.org. Затем MX for reallyb.orgвидит почту A, исходящую из b.orgMX, и поэтому ему разрешено выбрасывать сообщение.

Поэтому, если вы хотите продолжать иметь возможность отправлять письма людям, которые используют переадресацию, как это было раньше, за десятилетия до появления SPF, по крайней мере, не используйте -all.

Это можно исправить, если MX для b.orgиспользованного SRS или MX для reallyb.orgписем из белого списка b.org. Однако, согласно моему взгляду на реальность, большинство экспедиторов не делают ни одного из этих двух. И поскольку вы находитесь в положении A, если вы думаете о реализации SPF на своем сервере, это то, что вы не можете контролировать в целом.