Веб-разработчик сделал запрос на включение в записи 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:
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. В настоящее время мне известно только следующее:
пользователи должны направлять свою исходящую почту через назначенные серверы - хотя контроль исходящей почты имеет очевидные преимущества, это может добавить некоторые сложности, если у вас есть удаленные пользователи - вам необходимо настроить SMTP-аутентификацию или VPN.
проблема с пересылкой - такой IME очень редко
Я вижу большую проблему с SPF в том, что пересылка прерывается. На сегодняшний день это лишь кратко упоминается в Запись в википедии SPF. И это также причина, по которой я не устанавливаю SPF на своем почтовом сервере.
Рассмотрим A с адресом a@a.org (кто MX реализует SPF) отправляет письмо B с адресом b@b.org кто настроил этот адрес для пересылки писем на b@reallyb.org. MX для reallyb.org затем видит почту A, исходящую от b.orgMX и поэтому разрешено выбросить сообщение.
Поэтому, если вы хотите и дальше отправлять письма людям, которые используют пересылку, как это работало за десятилетия до появления SPF, по крайней мере, не используйте -all.
Это можно было бы исправить, если бы MX для b.org используемый SRS или если MX для reallyb.org белые списки писем, приходящих от b.org. Однако, по моему мнению, большинство экспедиторов не используют ни одно из этих двух. И поскольку вы находитесь в положении A, если вы думаете о внедрении SPF на своем сервере, это то, что вы не можете контролировать в целом.