メールのSPFレコード設定と検証ガイド

メールがエラーで戻ってきました。迷惑メールに振り分けられたのではなく、受信を拒否されたのです。サーバーは 550 5.7.26 または 550 5.7.515 を返し、メッセージは届きませんでした。考えられる原因の一つは、ドメインに有効なメール用 SPF レコードがない、または既存のレコードに構造上の問題があることです。ただし、このコードだけで SPF のみが原因だとは断定できません。

2024 年二月以降、Google と Yahoo は送信者認証の要件を厳格化しています。具体的な要件は、送信者の区分や送信量などによって異なります。SPF の誤設定は受信拒否の原因になり得ますが、すべての業務用ドメインのメールが必ず拒否されるわけではありません。

Google：550 5.7.26 - 認証されていないメールは受け付けられません

Microsoft：550 5.7.515 - 送信者の身元が認証されていません

このガイドでは実際の設定に焦点を当てます。構成ごとのレコード、正しく見える設定に潜む落とし穴、実際の送信経路を確認するテストを紹介します。SPF は SPF、DKIM、DMARC による認証の一部です。役割の違いと連携については、業務用メールのセキュリティ基盤をご覧ください。

メール用 SPF レコードとは？

SPF レコードは、ドメインの DNS に公開する TXT レコードで、そのドメインについてメールを送信できるサーバーを定義します。Gmail や Outlook などの受信サーバーは DNS を参照し、送信元 IP をルールと照合します。許可されたルールに一致すれば Pass になり、一致しない場合の結果は末尾のルールによって変わります。メールを受け付けるかどうかは、受信側が他の検査や独自のポリシーも考慮して判断します。

SPF が検証するのは SMTP エンベロープの MAIL FROM ドメインであり、受信トレイに表示される「差出人」アドレスではありません。TXT レコードは検証対象のドメインに配置します。メインドメインならルート（@）、エンベロープ用サブドメインならそのサブドメインです。DNS 設定全体の流れは、自分のドメインでメールを設定する方法で説明しています。

SPF レコードは一つだけ

SPF の仕様である RFC 7208 では、検証対象の各ドメインに置ける v=spf1 で始まる TXT レコードは一つだけです。受信サーバーが二つの SPF レコードを見つけると、SPF の検証結果は PermError になります。単に迷惑メールの評価が悪くなるのではなく、認証処理のエラーです。実際に受信拒否になるかは受信側のポリシーによります。

Google Workspace などをすでに利用しているドメインに新しいサービスを追加する際によく起きる重大なミスです。既存のレコードを編集せず、二つ目を追加してしまいます。

変更する前に、現在のレコードを確認してください：

dig +short txt yourdomain.com

v=spf1 で始まる行を数えます。二つあれば SPF 検証は PermError になります。まずこの構造上の問題を直しましょう。

状態	結果
SPF レコードが一つで、構文も正しい	送信元 IP が許可されていれば Pass になり得る ✓
同じドメインに SPF レコードが二つある	SPF 検証が PermError になる ✗
ドメインに SPF レコードがない	SPF による確認ができず、要件によっては拒否される ✗

誤った例：レコードが二つあるため、このドメインの SPF 検証は PermError になります：

v=spf1 include:_spf.google.com -all
v=spf1 include:spf.trekmail.net -all

正しい例：一つの SPF レコードに統合します：

v=spf1 include:_spf.google.com include:spf.trekmail.net -all

メール用 SPF レコード：最小限の設定

レコードの内容は、実際にメールを送信するサーバーによって決まります。使っているサービスだけを許可してください。余分な include: はルックアップの上限を消費し、自分で管理していない IP 範囲を取り込みます。

構成 A：TrekMail のマネージド SMTP（Starter、Agency プラン）

契約中の TrekMail プランにマネージド送信が含まれ、ほかに送信元がなければ、次の一行でドメインをカバーできます。適用前にすべての送信サービスを洗い出してください：

v=spf1 include:spf.trekmail.net -all

構成 B：TrekMail 無料プラン（外部 SMTP を持ち込む）

Nano プランの現行条件で外部 SMTP が利用できる場合、Amazon SES、SendGrid、Mailgun などを接続できます。許可するのは TrekMail ではなく、そのプロバイダーの送信サーバーです：

v=spf1 include:amazonses.com -all

include:amazonses.com は、実際に使うエンベロープドメインについてプロバイダーの資料が指定する値に置き換えてください。使っていない IP 範囲は許可しないでください。

構成 C：併用 - TrekMail + Google Workspace

Google から移行中、または移行期間中に両方の送信経路を使う場合は、一つのレコードにまとめます：

v=spf1 include:spf.trekmail.net include:_spf.google.com -all

レコードの各要素

要素	役割
`v=spf1`	バージョン識別子。必ず先頭に置きます。
`include:`	外部プロバイダーの SPF ルールを参照します。
`-all`	許可されていない送信元に Hard Fail を返します。送信元をすべて確認してから使用します。`~all` とは結果が異なりますが、受信拒否を保証するものではありません。

~all（Soft Fail）は、未登録の送信元がおそらく未許可であることを示します。配信も拒否も保証しません。-all は Fail を返すため、正当な送信経路をすべて把握した後に適しています。~all は導入や調査の段階で役立つ場合があります。確認済みの送信構成に合わせて選んでください。

DNS ルックアップを伴う項目は最大 10

SPF 仕様（RFC 7208）では、一回の検証で評価する DNS ルックアップを伴うメカニズムと修飾子を 10 個までに制限しています。個々の DNS クエリすべての合計ではありません。include:、a、mx、redirect が対象で、参照先のレコード内にある該当項目も数えます。ip4: と ip6: は対象外です。評価数が 10 を超えると、結果は PermError になります。

これは気づきにくい問題です。構文に問題がなければ、構文検証ツールは正常と判定します。しかし受信サーバーが参照をたどり、include の先にさらに include があり、その先にも参照が続くと、合計が 10 を超えて SPF 検証に失敗することがあります。

上限に数えるもの：

include:（その内部の入れ子の include も含む）
a、mx、redirect

上限に数えないもの：

ip4: と ip6: - IP を直接指定するため、このルックアップの連鎖が不要です
all

公開前にレコードと参照先のルールを確認します：

dig +short txt yourdomain.com

include の連鎖が長い場合は、include: を直接の ip4: 指定に置き換えるフラット化を検討できます。ただし、その後はプロバイダーの IP 範囲の変更を確実に反映する必要があります。別の方法として、送信経路を適切なエンベロープ用サブドメインに分け、それぞれに SPF レコードとルックアップ枠を持たせることもできます。

メール用 SPF レコードを検証する

DNS 管理画面の緑のチェックだけを信用しないでください。構文検証では配信を確認できません。実際に SMTP でメールを送り、その具体的な送信経路を Gmail がどう評価するかを確認しましょう。

自分のドメインから、自分で管理する Gmail アカウントへメールを送ります。
Gmail でメールを開きます。
三点メニュー → メッセージのソースを表示を選びます。
Authentication-Results を探します。

SPF が成功した場合の例：

spf=pass (google.com: domain of team@yourdomain.com designates 192.0.2.1 as permitted sender)

結果	意味	対処
`spf=softfail`	送信元 IP が未許可で、`~all` などのルールに一致	正当な送信元を追加。すべて確認した後で `-all` を検討
`spf=fail`	IP が未許可で、`-all` が Fail を返した	正当な送信元 IP をレコードに追加
`spf=permerror`	構文エラー、二つのレコード、またはルックアップを伴う項目が 10 を超過	先に構造を修正
`spf=none`	検証対象のドメインに SPF レコードがない	エンベロープドメインに TXT を公開。メインドメインなら `@`

permerror は、単に送信元 IP が未登録なのではなく、SPF の評価に問題があることを示します。まず重複レコード、ルックアップ枠、構文を確認してください。

よくある SPF のミス

SPF の問題の多くは、次の五つのミスに由来します。原因が分かれば 10 分以内で調査や修正ができることもありますが、DNS の反映や再検証には時間がかかる場合があります。

ミス	影響
`+all` を使う	インターネット全体を検証対象ドメインの送信元として許可します。使わないでください。
`ptr` メカニズムを使う	SPF 仕様で非推奨。遅く、信頼性にも問題があります。
include ドメインの入力ミス	`include:google.com` は Workspace の指定レコードではありません。`include:_spf.google.com` を使います。
コロンの後に空白がある	`ip4: 1.2.3.4` は無効です。空白なしの `ip4:1.2.3.4` にします。
明確な方針なく本番で `~all` を使う	Soft Fail はなりすましメールの拒否を保証しません。正当な送信元をすべて確認した後で `-all` を検討します。

include の入力ミスは厄介です。構文だけを調べるツールでは、参照先の SPF レコードが有効かどうかまで分からない場合があります。必要な include の文字列は、必ずプロバイダーの資料で正確に確認してください。

複数ドメインの SPF レコードを管理する

一つのドメインの簡単な SPF 設定なら、10 分で済む場合もあります。しかし顧客の 50 ドメインを管理するなら、継続的な保守が必要です。顧客がマーケティングツールを追加するたびに、認証設定が気づかないうちに崩れる可能性があります。メールが戻ってくる理由を顧客から尋ねられて、初めて気づくこともあります。

代理店や MSP には標準化が役立ちます。選択したプランで利用できる場合、TrekMail の複数ドメイン管理画面と SPF/DKIM/DMARC ウィザードで設定をそろえられます。有料プランは月額 $3.50 から案内されていますが、実際の価格やマネージド SMTP の有無は現行条件によります。Nano プランで外部 SMTP が利用可能なら、自分のプロバイダーを接続できます。IP レピュテーションの管理範囲は、プロバイダーや共有 IP・専用 IP の割り当てにも左右されます。既存の SES や Mailgun アカウントが役立つ場合があります。

顧客に TrekMail の送信経路が適していれば、共通のテンプレートを利用し、ドメインごとに異なるプロバイダー構成を維持する手間を減らせます。ただし、正当な送信元は各ドメインで確認が必要です。大規模な運用については代理店向けの顧客メール管理を、新規設定の全体像については自分のドメインでメールを作成する方法をご覧ください。

メール用 SPF レコード：公開前のチェックリスト

公開前に、次の項目を順番に確認してください：

既存レコードを確認：dig +short txt yourdomain.com - v=spf1 の行は一つだけ。
トランザクションメール、マーケティング、サポートツールなど、そのドメインから送る全サービスを把握。
必要な送信元を一つのレコードにまとめる。別々の SPF レコードを重ねない。
送信元をすべて確認してから -all を使用。~all は方針を検討し、+all は避ける。
入れ子も含めて DNS ルックアップを伴う項目を数え、余裕を持って 10 未満にする。
検証対象のエンベロープドメインに TXT レコードを公開。メインドメインなら @。
Gmail にテストメールを送り、メッセージのソースを表示で spf=pass を確認。

Google のメール送信者のガイドラインでは、送信者の区分によって要件が異なります。一括送信者には SPF、DKIM、DMARC のすべてが必要ですが、その他の送信者の最低要件は異なります。正しい SPF 設定は大切な第一歩です。DKIM と DMARC が認証を補完しますが、すべてに成功しても受信や受信トレイへの振り分けは保証されません。

SPF を丁寧に設定しておけば、後の調査を減らせます。プロバイダーや IP 範囲が変わった際には再確認してください。誤設定は業務用メールの送信に支障を来すことがあります。TrekMail を無料で試す：Nano のカード不要条件、月額 $3.50 からの有料プラン、14 日間の無料試用の提供は、現行のプラン条件をご確認ください。