このチェックでは、現在DNSに公開されているレコードを確認します。特定のメッセージがSPFに合格したかどうかは検証しません。それを確認するには、メッセージのヘッダーを開き、Authentication-Results行を読んでください。DNSのキャッシュにより、最近の変更が反映されるまでに時間がかかることがあります。
SPF(Sender Policy Framework)は、ドメインがメール送信を許可するサーバーの一覧をDNSで公開する仕組みです。メッセージが届くと、受信サーバーはエンベロープ送信者(Return-Path、MAIL FROMとも呼ばれます)のドメインを確認し、そのドメインのSPFレコードを読み取ります。接続元のIPアドレスが一覧に含まれていればSPFは合格です。含まれていなければ、レコードが受信側の対応を指示します。
SPFは、受信者に表示されるFromアドレスを確認しません。そのため、メッセージがSPFに合格してもDMARCに失敗することがあります。2つのドメインが一致している必要があり、SPFだけではそれを保証できないからです。
SPFレコードはv=spf1で始まる1行のテキストで、左から右へ読まれる項目で構成されます。送信元IPに最初に一致した項目が結果を決定します。
| 項目 | 意味 |
|---|---|
| ip4:203.0.113.0/24, ip6:... | 固定のアドレスまたは範囲を許可します。DNS照会は発生しません。 |
| include:example.net | example.net自身のSPFレコードが許可するものも許可します。照会が1回、さらにその中の照会も加算されます。 |
| a, mx | ドメインのAレコードまたはMXレコードのアドレスを許可します。それぞれ照会が発生します。 |
| redirect=example.net | このレコードを、example.netのレコードに置き換えます。別のドメインにすべてを判断させたい場合に使います。 |
| exists:, ptr | 必要になることはまれです。ptrは標準仕様で非推奨となっており、使用すべきではありません。 |
| -all, ~all, ?all, +all | 末尾の包括ルールです。拒否、ソフトフェイル、中立、すべて許可のいずれかを示します。+allは誰でもあなたになりすまして送信できてしまいます。 |
SPFの標準仕様(RFC 7208)では、受信側がレコードの評価に使えるDNS照会は最大10回です。include、a、mx、ptr、exists、redirectの各項目がそれぞれ数えられ、includeしたレコード内の照会もすべて加算されます。10回を超えると永続エラーとなり、受信側はこれを失敗として扱います。
原因として多いのは、複数のメールサービスを重ねて使うことです。マーケティングプラットフォーム、ヘルプデスク、CRM、メールプロバイダーを合わせると、上限の大半を使い切ることがあります。チェッカーは受信側と同じ方法ですべてのincludeをたどり、上限に対する照会数を表示するため、どの枝が負担になっているかがわかります。
標準仕様では、何も返さない名前への「ボイド」照会も2回までに制限されています。SPFレコードのないドメインを指すincludeは、そのため問題として数えられます。
有効な対処法:使っていないサービスを削除する、プロバイダーが安定した範囲を公開している場合はa、mx、includeをip4やip6の範囲に置き換える、メールの種類ごとに別のサブドメインから送信して、それぞれに独自のレコードを持たせる。
よく見かける問題は次のとおりです。チェッカーは、それぞれの問題を分かりやすい修正方法とともに報告します。
レコードが問題なしと表示されても、ポリシーの形式が正しいというだけです。特定のメッセージが通過した証明にはなりません。実際のメッセージを検証するには、ヘッダーを開いて Authentication-Results 行を読むか、メールヘッダーアナライザーに貼り付けてください。
メールが転送されると、転送サーバーのIPがお客様のレコードに含まれないため、SPFは失敗します。DMARCがSPFまたはDKIMのどちらかで認証を受け付けるのはこのためで、DKIMでもメールに署名すべき理由でもあります。
~all(ソフトフェイル)と -all(ハードフェイル)はどちらも、送信者が許可されていないことを受信側に伝えます。実際には、多くの受信側はSPFを複数のシグナルの1つとして扱い、独自に判断します。失敗したメールの扱いを決めるのはDMARCです。多くの組織は、すべての送信元を洗い出している間は ~all を公開し、一覧が完成した時点で -all に移行します。どちらでも問題ありませんが、+all や all の欠落は避けてください。
ドメインのルートにあるTXTレコードを読み取り、v=spf1 で始まるものを抽出します。レコードがない場合や、複数ある場合は警告します。
受信サーバーと同じように、すべての include と redirect をたどり、ルックアップ数を上限の10回と照らし合わせて合計します。
不明なメカニズム、無効なIPアドレスや範囲、どこにも通じない include、ループ、評価されない項目を調べます。
+all や ?all、非推奨の ptr メカニズム、all の欠落、DNSで問題になるほど長いレコードについて警告します。
SPFレコードは、ドメインに設定するDNSのTXTレコードで、そのドメインとしてメールを送信できるサーバーを一覧にしたものです。受信サーバーは、メッセージが届いたときに、送信元のIPアドレスをこの一覧と照合します。
SPFの評価で発生してよいDNSルックアップは最大10回です。include、a、mx、ptr、exists、redirect はすべてカウントされ、include したレコード内のルックアップも含まれます。10回を超えると、受信側は永続エラーを返し、そのドメインからのすべてのメッセージでSPFが失敗します。
各 include は別のレコードを指し、そのレコードにも独自の include が含まれることがあります。チェッカーは受信側と同じ方法で、それらをすべてたどって合計します。include が4つのレコードでも、ルックアップが8回以上になることは珍しくありません。
レコードを評価できなかったことを意味します。主な原因は、1つのドメインにSPFレコードが2つある、ルックアップが10回を超える、構文ミス、SPFレコードのないドメインを指す include のいずれかです。
いいえ。SPFはシグナルの1つにすぎません。受信側はDKIM、DMARCのアライメント、送信者の評判、苦情率、コンテンツも見ています。SPFへの合格は、高い到達率に必要な条件ですが、それだけでは十分ではありません。
照会は当社のサーバーで実行され、結果は約5分間保持されるため、同じチェックを繰り返してもDNS照会は繰り返されません。チェックはアカウントと紐づけられず、照会先のDNSサーバーを保護するため、ツールにはレート制限がかかっています。
手順ガイドに沿って進めるか、ジェネレーターでルックアップ制限内に収まるレコードを作成してください。