SPF-実装する必要がありますか？

SPF TXTレコードを含めるために、ドメインのDNSレコードがWeb開発者からリクエストされました。私はこれについて異なる意見を見つけました...

あなたが提供できるコメントや洞察は高く評価されます。これは経験的な質問自体ではないことは承知していますが、それでも主観的な提供に感謝します...特に、ウェブポストやオンラインドキュメントなど、参考資料が含まれている場合は調べてみます。

はい。明確なコンセンサスがあるため、私はこれを主観的とは呼びません。SPFを使用します。

実装は非常に簡単で、インターネット全体としては良いことです。

日付の付いた参照が表示されている可能性があります。私のサーバーがSPFを使用するサーバーから受信する有効な電子メールの割合に基づいて、コンセンサスはSPFを使用することです。

SPFをセットアップすることを強くお勧めします。MXがメールを送信できるようにするためのレコードと、メールアドレスで使用するドメインのレコードを設定します。電子メールセットアップSPFを送信しないドメインの場合、それを示します。

電子メールサーバーのSPFレコードは、送信者の電子メールアドレスのSPFレコードよりも、スパムをブロックするのに役立ち、信頼できると思います。

サーバーがSPFレコードをサポートしている場合は、TXTレコードに加えてそれらを構成します。構成を変更すると、レコードの同期を維持するのに多少のオーバーヘッドが生じる可能性がありますが、多くのシステムは、SPFを構成してMXとアドレスの変更に自動的に調整することができます。

SPFによるメールの評判の保護に関する私の投稿を確認してください。SPFの最初の実装は、電子メールサービスを提供するドメインを偽造していたスパマーをブロックすることでした。比較的低いSPF浸透にもかかわらず、それらをシャットダウンするのに非常に効果的でした。ただし、作成した偽造アドレスには引き続きスパムが送信されます。（スパマーのみがそのアドレスを使用するため、スパマーを検証するための優れた方法です。）

受信側でのSPFの浸透は、発行側よりも大きいと思われます。

編集：SPFレコードを使用する場合は、自動メールを配信するユーザーがサーバーを追加するための要件を認識していることを確認してください。（自動化システムは設定が不十分で、スパムボットに似たプロファイルを持っている可能性があるため、サーバーは完全に吟味されている必要があります。サーバーを正しく設定することはそれほど難しくありません。）

間違いなくSPFをセットアップします-（適切にセットアップされ、テストされている限り）欠点はありませんが、他のサイトがあなたになりすましてあなたの名前でスパムを送信するのを防ぎます。それが良い理由は、ドメインにメールを送信できる特定のサーバー/ IPを明示的にホワイトリストに登録しているためです。

それが良いことであるという最良の証拠は、いくつかの主要な電子メールサービスを見ることです。元のメールで「Received-SPF」ヘッダーを探して、SPFがチェックされているかどうかを確認してください。例えば：

ヤフーメール：

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が否認防止の基礎であることを意味するわけではありません）。このようなイベントの直接的な影響が非常に低い場合でも、後方散乱を減らすのに役立ちます。

ただし、もう1つの非常に重要な理由は、プロバイダーがSPFを実装する受信者への配信可能性を向上させることです。

SPFのマイナス面について、ぜひ聞いてみてください。現在、私が認識しているのは次のとおりです。

1. ユーザーは、指定されたサーバーを経由して送信メールをルーティングする必要があります-送信メールを制御することには明らかな利点がありますが、リモートユーザーがいる場合、これにより複雑さが増す可能性があります。SMTP認証またはVPNをセットアップする必要があります。

2. 転送に関する問題-IMEは非常にまれです

私がSPFで目にする大きな問題は、転送の中断です。これは本日現在、SPFのウィキペディアエントリでごくわずかに言及されています。また、メールサーバーにSPFを設定しない理由でもあります。

Aのアドレスa@a.org（MXがSPFを実装している）が、メールをb@b.orgに転送するようにこのアドレスを設定したアドレスのBにメールを送信するとしますb@reallyb.org。のMXはreallyb.org、b.orgのMX から送信されたAのメールを確認するため、メッセージを破棄できます。

したがって、SPFが登場する数十年前まで機能していた転送を使用するユーザーに引き続きメールを送信できるようにしたい場合は、少なくともを使用しないでください-all。

これは、SRSのMXがb.org使用されている場合、またはから受信したメールをホワイトリストのMXが使用している場合は修正できます。しかし私の現実的な見方によれば、ほとんどのフォワーダーはこれら2つを実行しません。サーバーにSPFを実装することを考えれば、Aの立場にいるので、これは一般的に制御できないことです。reallyb.orgb.org