SPFレコードは問題なさそうで、使っている送信元もすべて載っているのに、ある日、DMARCレポートやバウンスにpermerrorと表示される。原因として最も多いのが、DNSルックアップ10回の上限です。SPFは、評価の間に発生させてよいDNSクエリの数が決まっており、include:で追加したツールは、そのたびにこの予算を消費します。このガイドでは、ルックアップの数え方、1回として数えられる項目と数えられない項目、そして、うっかり忘れていた送信元からのメールを止めることなく、上限を超えたレコードを直す順番を説明します。
結論#
SPFはRFC 7208で定義されており、評価中にDNSクエリを発生させる項目を10個までに制限しなければならないと定めています。数えられるのは、include、a、mx、ptr、exists、そしてredirect修飾子です。ルックアップが不要なip4、ip6、allは数えられません。数え方は再帰的で、include:は1回に加え、参照先のレコードの中身もすべて数えます。10を超えるとチェックはpermerrorを返し、そのドメインからのどのメールでもSPFが成功しなくなります。修正は使わなくなったツールのincludeの削除、続いて固定のサーバーのip4/ip6への置き換え、さらに一括送信の送信元のサブドメインへの移行の順で行います。フラット化は最後の手段です。無料のSPF、DKIM、DMARCチェッカーとドメイン診断は、公開されているレコードを表示しますが、includeをたどってルックアップを数えることはしないため、後述のとおり手で数えるか、再帰的にたどるツールを使ってください。
上限に数えられるもの#
| 項目 | ルックアップを消費する？ | 補足 |
|---|---|---|
include:domain | はい、1回とその中身 | 参照先のレコードも評価されるため、その中のincludeも数えられます |
aまたはa:domain | はい、1回 | 返されるアドレスがいくつあっても、1項目として数えます |
mxまたはmx:domain | はい、1回 | 忘れやすい項目で、不要なこともあります |
ptr | はい、1回 | RFCでは非推奨です。削除してください |
exists:domain | はい、1回 | まれで、マクロを使った構成でよく使われます |
redirect=domain | はい、1回とその中身 | レコードにallも含まれている場合は無視されます |
ip4:とip6: | いいえ | 数えられませんが、最新の状態に保つのはご自身の責任です |
all | いいえ | 必ず最後に置きます。その後ろの項目は評価されません |
具体例を見ると、どれだけ早く積み上がるかがわかります。
example.com. TXT "v=spf1 include:_spf.google.com include:sendgrid.net include:mail.zendesk.com include:servers.mcsv.net mx a ~all"
このレコードには、トップレベルだけでルックアップを消費する項目が6つあり、各include:の中にさらに項目が含まれていることもあります。見た目の数は6ですが、実際の数は、入れ子のレコードが加える分だけ増えます。短く見えるレコードでも上限を超えることがあるのは、そのためです。また、DNSに手を加えていなくても数が変わるのも、同じ理由です。プロバイダーが自社のSPFレコードを編集すると、あなたの合計が動くのです。
RFCは、「void lookup」（何も返さないクエリ）も2回までに制限すべきだとしています。これは必須要件ではなく推奨ですが、すでに存在しない名前を指すinclude:、a、mxの項目は、まさにその種のルックアップにあたります。使われていないincludeを最初に削除すべき理由が、もう1つ増えます。
手順1：数の問題であることを確認する#
何かを変更する前に、SPFエラーを引き起こすほかの原因を除外してください。
- SPFレコードが複数ある。 同じ名前に
v=spf1のTXTレコードが2つあるのも恒久的なエラーで、ツールのセットアップ画面にレコードを追加するよう書かれていると、うっかり起こしがちです。dig +short TXT example.comを実行し、v=spf1で始まる行の数を数えてください。2つあれば、統合します。これと、ほかのよくある原因は、SPF、DKIM、DMARCが機能しなくなったときで説明しています。 - 構文エラー。 ドメインのない
include、不正なip4の範囲、スペースの欠落といった誤字で、レコードが壊れます。 - includeのループ。 2つのドメインが互いにincludeしていると、評価が永遠に終わりません。
- どこも指していないinclude。 参照先のドメインが、SPFレコードをまったく公開していません。
これらのいずれにも当てはまらなければ、ルックアップを数えます。仕組みを理解するために、一度は手で数えてみてください。トップレベルのレコードを問い合わせ、数えられる項目を書き出し、次にすべてのinclude:とredirect=の参照先を問い合わせて、同じことを繰り返します。includeをたどるツールなら再帰処理を代わりにやってくれるので、使う価値があります。入れ子になったプロバイダーのレコードは、何階層にもなることがあるからです。このサイトの無料チェッカーはレコードを読み取りますが、数えることはしません。
手順2：使っていないものを削除する#
最も手軽な対処で、通常、いくつかのルックアップを取り戻せます。すべてのinclude:を見直して、いまもそこを経由して送信しているものがあるかを確認してください。
- 試用したツール。 1か月試して、そのまま削除していないサービス。
- 廃止したプラットフォーム。 2年前に置き換えたマーケティングツールや、古いヘルプデスク。
- includeからしか名前がわからないプロバイダー。 それが何かわからないなら、削除する前に調べてください。DMARC集計レポートを見れば、実際にあなたのドメインを名乗って送信した送信元がわかるので、1か月分のレポートに一度も現れないincludeは、削除の有力な候補です。
1つずつ削除して数え直し、元に戻せるよう、古いレコードのテキストを保管しておいてください。また、本当にそのホストから送信していない限り、単独のmxとaの項目も削除し、ptrは完全に削除します。
手順3：includeをIP範囲に置き換える（慎重に）#
自社のメールサーバーのように、アドレスが少数で安定している送信元であれば、include:やmxをip4:のエントリに置き換えて、ルックアップを節約できます。
v=spf1 ip4:203.0.113.10 ip4:203.0.113.11 include:_spf.google.com ~all
トレードオフは、保守です。ip4:のエントリは、アドレスが変わったときに自分で気づくという約束です。これは、自分で管理しているインフラに限ってください。大手ESPのIPリストを自分のレコードにコピーするのは絶対にやめましょう。プロバイダーはアドレスを予告なく追加したり廃止したりするため、手元のコピーは気づかないうちに古くなります。
手順4：一括送信やマーケティングの送信元をサブドメインに移す#
送信ドメインごとに、独自のSPFレコードと独自の予算があります。マーケティングプラットフォーム、トランザクションメール用サービス、サポートデスクがすべてexample.comの名義で送信していると、10回という1つの予算を共有することになります。ニュースレターにはnews.example.comのようなサブドメインを割り当て、そこに短いSPFレコードを公開し、プラットフォームがリターンパスとFromアドレスにそれを使うよう設定します。これにより、レピュテーションも分離できます。詳しくは、送信用サブドメインのガイドで説明しています。
この際、DMARCにも注意してください。アライメントでは、Fromドメインと、SPFまたはDKIMに成功したドメインを比較します。緩やかなアライメントなら、news.example.comはexample.comとアライメントが一致しますが、送信元は、そのどちらかのドメインで認証されている必要があります。アライメントについては、DMARCの設定手順で説明しています。
手順5：フラット化と、古くなる理由#
フラット化とは、include:の項目を、それが解決する具体的なIPアドレスに置き換えて、レコードがルックアップを必要としないようにすることです。確かに効果はありますが、最もリスクの高い対処でもあります。includeは、あなたがDNSを編集しなくても、プロバイダーがアドレスを変更できるようにするために存在するからです。フラット化されたレコードは、作った時点のアドレスで固定されます。プロバイダーがサーバーを追加すると、誰かがレコードを更新するまで、そのサーバーからのメールはSPFで失敗します。
さらに2つの制約があります。フラット化したレコードは、1つのTXTレコードが無理なく保持できるサイズを超えることがあり、またDNSはUDP応答のサイズを制限しているため、大きなレコードは分割するか、慎重に配信する必要があります。そして、更新作業をあなたが担うことになります。フラット化するなら、スケジュールに従って再解決し、失敗したときに通知してくれるサービスやスクリプトを使ってください。1回限りのコピー&ペーストにしてはいけません。
ほとんどのドメインでは、上の順序で十分です。まず削除、次にサブドメイン、3番目にip4、最後にフラット化です。
ルックアップ数を管理下に置く#
ルックアップ数は固定ではありません。ツールを追加したときや、プロバイダーが自社のレコードを編集したときに動くため、3月には通っていたレコードが、あなたが何も変えていなくても9月には失敗することがあります。先手を打つための習慣が3つあります。
- 追加する前に数える。 includeを追加する前に合計を確認し、新しい送信元が収まるかを把握します。
- スケジュールに沿って再チェックする。 ドメイン診断では、毎回、再帰的な数を計算し直します。
- 11ではなく、9でアラートを出す。 数が10を超えた時点では、すでに失敗しています。
ドメイン診断の監視は、後半の2つを担います。対象のすべてのドメインで、includeとredirectをたどり、RFC 7208のセクション4.6.4に沿ってルックアップを数える、毎日のSPFチェックを行います。ルックアップが9回または10回で警告、10回を超えると重大度badの問題として報告し、メールでお知らせします。手順1にあるほかのSPFの問題も検出します。複数のレコード、構文エラー、レコードを公開していないinclude、末尾が+allや?allになっているもの、そしてptrメカニズムです。知っておくべき制限が1つあります。各レポートには、ドメインあたり40回のDNSクエリという予算があるため、非常に大きなレコードでは、一部の項目が未チェックとして表示され、数は下限値になります。SPF以外もチェックすることの意義は、メールドメイン診断の監視で、各送信元があなたの数に何を加えるかは、プロバイダー別のSPFガイドで説明しています。
よくある質問
01SPFのDNSルックアップ10回の上限とは何ですか？
RFC 7208では、SPFのチェックはDNSクエリを発生させる項目を10個までに制限しなければならないとされています。include、a、mx、ptr、exists、redirectが数えられ、入れ子になったincludeも数えられます。超えるとpermerrorが返され、受信側はこれをSPFの失敗として扱います。
02ip4とip6のメカニズムは、上限に数えられますか？
いいえ。ip4、ip6、allはDNSクエリを必要としないため、数えられません。代償は保守で、送信元がアドレスを変更するたびに、ご自身で更新する必要があります。
03SPFレコードのフラット化は、良い解決策ですか？
効果はありますが、プロバイダーの現在のアドレスで固定されるため、プロバイダーがサーバーを追加したときにレコードを更新しないと、メールが失敗します。まず使っていないincludeを削除し、一括送信の送信元をサブドメインに移してください。フラット化は、自動更新を伴う場合に限って行いましょう。
04何も変更していないのに、SPFが壊れたのはなぜですか？
includeは再帰的に評価されるため、プロバイダーが自社のSPFレコードを編集すると、合計が変わります。ルックアップが9回や10回のレコードは、あなたが何も編集しなくても超えてしまうことがあります。10回に達する前にアラートを出すことが有効なのは、そのためです。
SPFが示すのは、どのサーバーがあなたの名義で送信してよいかだけです。リストの相手があなたからのメールを望んでいるか、あるいは実在するかどうかはわかりません。料金ページにある100クレジットの無料枠なら、リストに対してフル検証を実行でき、バウンスしそうなアドレスの数を確認できます。SPFを通るレコードでも、受信箱にたどり着くには、健全なリストが必要です。
