SPFとは?

どういうものか

SPFは、御社のドメインのDNSにある、v=spf1で始まる1件のTXTレコードです。メッセージが届くと、受信サーバーはエンベロープ送信者(メールサーバー間で使われる返信先アドレスで、読む人には見えません)を調べ、そのドメインのSPFレコードを取得します。送信元のサーバーが一覧にあれば、SPFは合格となります。

ほとんどの企業はプロバイダー経由で送信するため、レコードにはアドレスではなくプロバイダーを指定します。include:spf.protection.outlook.comのような記述は、Microsoft 365をカバーします。御社の名前で送信するメールマガジンツールや請求システムには、それぞれ専用のincludeが必要です。

レコードの終わり方

• -all(ハードフェイル):一覧にないサーバーからのメールは、不合格として扱うべきとします。
• ~all(ソフトフェイル):一覧にないサーバーからのメールは疑わしいものの受け入れられ、通常は迷惑メールに振り分けられます。送信元をすべて洗い出している途中では、こちらのほうが安全です。

つまずきやすいルール

• レコードは1件だけ:ドメインのSPFレコードは必ず1件でなければなりません。2件あると、すべてのメッセージでSPFが失敗するため、新しいサービスは既存のレコードに追加します。
• 10回のルックアップ:レコードの確認で行えるDNSルックアップは最大10回で、すべてのincludeと、その中に入れ子になったincludeも数えます。超えるとSPFは失敗します。
• 転送すると機能しません:メッセージが転送されると、転送元のサーバーから最終のサーバーに届きますが、そのサーバーは御社の一覧にありません。
• Fromアドレスはカバーしません:SPFが確認するのは、見えないエンベロープ送信者です。あるドメインでSPFに合格しながら、Fromの行には御社の名前を表示することもできます。この抜け穴を塞ぐのがDMARCです。

企業にとって重要な理由

SPFがない、またはレコードが壊れている、古い場合、本物の請求書や返信が迷惑メールに入りやすくなります。SPFは、当社のメール認証ガイドで説明しているとおり、DKIMとDMARCとあわせて使うと最も効果的です。全体像はビジネスメールのガイドにあります。

KawaConnectのSPFの扱い方

Microsoft 365を設定または移行する際には、ドメインのSPFレコードを作成し、事業が送信に使うその他のサービスも追加します。当社がホストするWebサイトでは、サイト自身のメールも同じレコードに入れます。Microsoft 365とWebサイトのページをご覧ください。

詳しく見る

• WikipediaのSender Policy FrameworkSPFの概要、構文、既知の限界を中立的にまとめています。
• Email authentication in Microsoft 365Microsoft 365を使うドメインのSPF、DKIM、DMARCに関するMicrosoftのガイダンスです。
• DMARC、DKIM、SPFに関するCloudflareの解説3つのレコードを、それぞれの例とともにわかりやすく説明しています。