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). В целом, это простое дополнение, которое может принести много пользы как вашему домену, так и Интернету в целом.

As the other respondents (so far) I recommend implementing SPF.

Some of the other posts have mentioned that this makes it more difficult for other people to masquerade as you (but that does not mean that SPF is basis for non-repudiation). Even if the direct impact of such an event is very low, it helps to reduce back-scatter.

However another, very important reason is that it improves deliverability to recipients whose providers implement SPF.

I'd certainly be very interested to hear what the downsides to SPF are. Currently all I'm aware of are:

1. users must route their outgoing mail through nominated servers - although controlling your outgoing mail has obvious benefits, this can add some complications if you've got remote users - you'll need to setup SMTP authentication or a VPN

2. problem with some forwarding - which IME is very rare

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

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

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

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

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

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

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

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

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

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

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

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

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