CRMのプロが書くマーケティングBLOG
<この記事でわかること>
自社から配信したメールが、顧客に届かず迷惑メールフォルダに振り分けられてしまう問題は、深刻な機会損失につながります。原因はメールの送信元ドメイン認証、特に「SPFレコード」の設定不備にあるかもしれません。
SPFレコードとは、送信元サーバが正当なものであることを証明し、なりすましを防ぐためにドメインに設定する「許可リスト」のような情報です。本記事では、SPFレコードの基本的な仕組みから、なぜ設定が必要なのか、そして具体的な書き方、設定手順、確認時の注意点までを解説します。
SPFレコードとは、メールの送信ドメイン認証を実現するために、ドメイン所有者がDNSに登録する情報です。具体的には、「このドメインからメールを送ってもよいサーバ」をあらかじめ定義しておき、受信メールサーバにそれを参照させる仕組みです。
通常、SPFレコードはDNSのTXTレコードとして記述され、”v=spf1”で始まる文字列で構成されます。このレコードにより、受信側は送信サーバのIPアドレスがそのドメインで許可されているものか否かを判断できるようになり、なりすましメールや迷惑メールの判定補助に役立てられます。
送信ドメイン認証を含めた全体のセキュリティ対策は、次の記事で整理しています。
関連記事：メール配信システムにセキュリティが必要な理由は？リスクと対策を解説
SPFは、メールが本当にそのドメインから送られたものかを確認する仕組みです。メールを受け取った側のサーバが、送信ドメインの情報を調べて「このサーバから送っていい」と許可されているかどうかを確かめます。
仕組みとしては、送信されたメールを受け取るときに、受信側がそのドメインに設定されたSPFレコードを参照し、「このサーバ（IPアドレス）は許可されているか？」を順番に確認していきます。もしリストに含まれていれば「正しい送信」と判断され、含まれていなければ「不正な送信」とみなされることがあります。
ただし、SPFだけで完全に見分けられるわけではありません。メールの転送などでは誤って判定されることもあるため、他の仕組み（DKIMやDMARCなど）と組み合わせて使うのが一般的です。
メールの信頼性や到達率を維持するうえで、SPFレコードの設定は欠かせません。ここでは、SPFレコードがなぜ必要なのか、その主な役割と効果について解説します。
法規制と実務の関係をまとめて把握したい場合は、運用現場の知見をまとめた資料が参考になります。
参考資料：失敗しないメール配信とコンプライアンス対策の関係 -運用実績20年のメール配信現場のリアル入門編1
SPFレコードは、なりすましや詐称された送信元アドレスを用いた迷惑メールを検出・防止する基本的な仕組みです。迷惑メール送信者は、しばしば正規のドメインを偽装してメールを送り、受け取った側に信頼を持たせようとします。
しかしSPFレコードを設定しておけば、受信側メールサーバは送信元IPを参照し、そのアドレスがそのドメインで許可されたものかどうかをチェックできます。許可されていないIPから送信されていれば「拒否」「警告」「隔離」などの処理が可能で、迷惑メールとして判定されやすくなります。
SPFレコードを正しく設定することで、受信側での迷惑メール判定が抑えられ、正当なメールが受信者の受信トレイに届きやすくなります。多くのメール配信プロバイダーやメールサービスは、SPFなどの認証情報を評価要素に含めており、認証が不十分なドメインからの配信を制限したり、評価を落としたりすることがあります。
さらに、Gmailをはじめとする主要なメール受信サービスでは、2024年以降、SPFやDKIMを設定していないと配信拒否や迷惑メール振り分けの可能性が高くなるガイドライン強化が行われています。よってSPFを導入・最適化することは、ビジネスメールが「正しく届けられること」を確保するための信頼基盤になるのです。
SPFを導入することで、第三者によるなりすまし送信など、正規ドメインの不正使用を防ぐ抑止力となります。もしSPFレコードが未設定であれば、他者があなたのドメインを使ってなりすましメールを送信しても、受け手はそれを識別できず、信頼性が損なわれるリスクがあります。
また、不正送信によりドメインがスパム送信源とみなされ、ブラックリストに登録されると、正規メールの配信にも悪影響が出ます。したがって、SPFを設定し、許可された送信元を明示することは、ドメイン自身の評判と信用を守るうえで不可欠な対策です。
SPFレコードは「バージョン指定」「メカニズム」「限定子」「修飾子」という4つの要素から構成され、それぞれが送信ドメイン認証の精度に影響します。ここでは、それぞれの役割と記述のポイントについて解説します。
SPFレコードには必ず最初にバージョン指定が置かれ、「v=spf1」という形式で現在のSPFのバージョンを宣言します。これは受信側がそれ以降の文字列をSPFレコードとして解釈するための識別子であり、「v=spf2」など非対応の表記にするとレコードが無視される可能性があります。
この「v=spf1」に続いて、メカニズムや限定子、修飾子が順次並ぶのが基本構造です。バージョン指定だけでは認証機能はなく、以降の要素で具体的な許可／不許可ルールを記述しますが、バージョン指定が欠けていたり誤っていたりすると、全体が無効扱いとなるため、必ず正確に記載することが前提条件になります。
メカニズムは、送信元IPやドメイン情報に基づいて「この送信元は許可かどうか」を判定するためのルール群です。主なメカニズムにはa、mx、ip4、ip6、include、exists、ptr、allなどがあります。
たとえばip4:203.0.113.0/24はそのIPv4範囲内からの送信を許可、mxはそのドメインのMXレコードのAレコードに含まれるIPを許可、include:example.comは別ドメインのSPFレコードを参照して追加許可、allはあらゆる送信元を対象とする最終的なキャッチオールルールです。メカニズムは記述された順に評価され、最初に一致したルールの限定子（例：「-all」の「-（Fail）」）が、そのメールの最終的な評価結果として適用されます。
また、DNSルックアップを伴うメカニズムにはルックアップ回数の上限があるため、設計時には制限に注意が必要です。
限定子は、各メカニズムに付加できる記号で、マッチした際にどう判定するかを指示するものです。限定子には「+（Pass）」「-（Fail）」「~（SoftFail）」「?（Neutral）」の4種類があります。
メカニズムに限定子を付けない場合、デフォルトで“+”が適用されます。たとえば–allは一致しない送信元を明示的に拒否、~allはソフトフェイルで受け入れるが警告扱い、?allは中立扱いという指示になります。
また、各メカニズムに対し異なる限定子を付けることで、柔軟に許可や除外ポリシーを制御できます。ただし、最初に一致するメカニズムの限定子が採用され、それ以降は評価が停止します。
修飾子は、メカニズムによるルールとは別に追加の制御や説明を与えるname=value形式の要素で、SPFレコードの末尾に一度だけ記述できます。代表的なものに、ポリシーを別ドメインに委任する「redirect=<ドメイン名>」や、認証失敗時の説明文を指定する「exp=<ドメイン名>」などがあります。
redirectは現在のドメインのSPFポリシーを別ドメインのSPFレコードに転送して適用させる指示で、複数ドメイン間で同一ポリシーを使いたい場合に便利です。
一方、expはSPF判定でFail（–）が適用された際に、なぜ拒否されたかを受信側や送信側に説明する文言を持つTXTレコードを指し示す用途です。未知の修飾子は無視され、またredirectとallメカニズムを同時に使うとredirectが無視されるという仕様もあります。
SPFレコードは、どのサーバやサービスからのメール送信を許可するかを宣言する設定です。正しく記述することで、迷惑メール判定を避けつつ、なりすまし送信によるブランド毀損を防ぐことができます。
一方で、書き方を誤ると正当なメールまで届かなくなるリスクもあるため、構成とルールの理解が重要です。ここでは、代表的な3つのケースを例に、実際のSPFレコード記述方法について解説します。
もし、特定のIPアドレスを持つ自社のメールサーバからしかメールを送信しない場合、SPFレコードは非常にシンプルです。このIPアドレスからの送信のみを許可し、他はすべて拒否するという、最も基本的な記述です。
＜記述例＞
“v=spf1 ip4:203.0.113.1 -all”
マーケティング担当者が最もよく目にするのがこのケースです。自社のメールに加え、メルマガ配信用に外部のメール配信サービスも利用している場合、「include」メカニズムを使って両方を許可リストに加えます。
＜記述例＞
“v=spf1 include:_spf.google.com include:spf.service.com ~all”
この場合、予期せぬメール不達を避けるため、限定子を「-all（Fail）」ではなく「~all（SoftFail）」にすることが推奨される場合があります。
コーポレートサイトのためだけに取得したドメインなど、メールを一切送信する予定がないドメインもSPFレコードを設定すべきです。なぜなら、設定がないと、そのドメインをなりすましに悪用される可能性があるからです。
「いかなるサーバからの送信も許可しない」と明確に宣言することで、不正利用を強力に防ぎます。
＜記述例＞
“v=spf1 -all”
SPFレコードの設定は、一度登録すれば終わりというものではなく、自社のメール送信環境を正確に把握し、誤りなく反映する必要があります。ここでは、SPFレコードを設定する基本的な3つのステップについて解説します。
まず、マーケティング担当者が主体となり、自社のドメインを使ってメールを送信しているすべてのサービス・システムを洗い出します。
これには、日常的に使うメールソフト、メルマガ配信システム、MAツール、Webサイトの問い合わせフォームからの自動返信、SFA／CRMからの通知メールなど、考えられるすべてが含まれます。
Step1で洗い出した全サービスのリストをもとに、それぞれに必要なSPFレコードの記述を、各サービスのヘルプページやサポート窓口で確認します。
そして、それらを1つの文字列にまとめ、最後に「-all」または「~all」を追記して、完全なSPFレコードを作成します。構文に自信がない場合は、Web上にある無料の「SPFレコード生成ツール」などを活用するとよいでしょう。
設定や配信前に確認したい項目は、チェックリストにまとめています。
参考資料：誤配信をふせぐメール制作・配信チェックリスト
完成したSPFレコードの文字列を、情報システム部門やドメイン管理業者に渡し、「この内容で、自社ドメインのDNSにTXTレコードとして登録してください」と依頼します。この依頼の際に、Step1で作成した「なぜこの記述が必要なのか」というサーバの棚卸しリストも併せて共有すると、担当者が内容を理解しやすくなり、ミスなく作業を進められます。
課題解決のために導入すべきツールは？CRM・MA・SFAそれぞれの違いをわかりやすく説明した資料です。
SPFレコードは、正しい書式で設定されていても、構成の仕方によっては思わぬトラブルを引き起こすことがあります。ここでは、SPFレコードを確認・修正する前に押さえておくべき2つの重要なポイントについて解説します。
SPFレコードは、1つのドメインにつき1つのTXTレコードしか設定できません。もし同じドメインに複数の「v=spf1」レコードが存在すると、受信側のサーバはどちらを評価すべきか判断できず、結果的に「PermError」として扱われ、SPF認証は必ず失敗します。
したがって、複数の送信元を利用する場合は、それぞれの許可設定を1つのレコードに統合しなければなりません。たとえば、自社サーバと外部サービスを併用する場合、以下のように記述します。
＜記述例＞
“v=spf1 ip4:203.0.113.1 include:spf.service.com ~all”
このように、すべての許可対象を1つのレコード内に収めることで、認証エラーを防ぎ、安定したメール到達を実現できます。
SPFレコードでは、メカニズムの中でDNSルックアップを伴う要素を利用できますが、これらの参照には「10回まで」という上限が設けられています。
この制限を超えると、受信側サーバはSPFレコードの検証を中断し、「PermError」として扱います。つまり、記述ミスではなく「構造上の制限」により、認証に失敗してしまうのです。
特に、複数のメール配信サービスを併用している場合、それぞれのサービスで指定された「include」を1つのレコードにまとめていくと、意図せず10回を超えるケースが発生します。
このような場合は、不要なincludeを削除したり、サブドメインを分けて管理することで対処します。
SPFレコードの設定が完了しても、それが正しく反映されているかを確認しなければ意味がありません。ここでは、SPFレコードを確認する3つの代表的な方法について解説します。
DNSのTXTレコードを直接参照するには、コマンドラインツールが有効です。Windowsなら「nslookup -q=txt ドメイン名」、LinuxやmacOSなどでは「dig ドメイン名 TXT」といったコマンドを使ってSPFレコードを取得できます。たとえばdig example.com TXT | grep “v=spf1″のように絞り込む方法もあります。
複数のネームサーバを指定して照会することも可能で、DNSの応答差異を比較する際にも役立ちます。この手法はリアルタイムで“現在公開されているレコード”を把握できるため、DNSの設定変更後や伝播確認時に特に有効です。
コマンド操作に不慣れな場合は、オンラインで利用できるSPFチェックツールを使うのが便利です。これらのツールは、ドメインを入力するだけでDNSへの問い合わせを自動実行し、SPFレコードの構文エラーやDNSルックアップ回数の超過、認証結果の想定などを可視化してくれます。
一部のツールでは、設定内容の安全性や改善点をスコア化して提示してくれるものもあり、専門知識がなくても誤設定を見つけやすいのが特長です。特に複数の配信サービスを利用している場合、includeの入れ子やルックアップ制限超過などを事前に検出できるため、運用前のチェックとしても効果的です。
設定とDNSの状態だけでなく、実際に送信したメールが受信側でどのように評価されたかを確認することも重要です。テスト送信を行い、受信したメールのヘッダー情報を確認すると、「Authentication-Results」という項目にSPFの判定結果が表示されます。
たとえば「spf=Pass」であれば認証成功、「spf=Fail」や「spf=softFail」であれば認証が失敗または警告扱いになっています。特にGmailやOutlookなどでは、迷惑メールフォルダへの振り分け要因がSPFの評価結果に直結するため、実運用環境での動作確認を怠らないことが、信頼性の高い配信の第一歩です。
SPFレコードは、メール送信ドメインの正当性を証明し、なりすましや迷惑メールを防ぐための重要な仕組みです。DNS上に「どのサーバから送信を許可するか」を明示することで、受信側が正規の送信元かどうかを判断できるようになります。
SPFレコードを正しく設定しておくことは、メールの到達率向上とドメインの信頼維持に直結します。設定ミスや複数レコードの重複、DNSルックアップ回数の超過などは認証失敗の原因となるため、構文と構成を慎重に確認することが大切です。また、メール送信環境が増えたり変更された場合には、常に最新の状態に保つ運用体制が求められます。
当社が提供する「Synergy!」では、SPFやDKIMなどの送信ドメイン認証を前提とした設計で、高い到達率と安定したメール運用を実現しています。自社ドメインの信頼性を守り、確実に届くメール運用を実現したい企業様は、ぜひ当社までお問い合わせください。
「Synergy!」の具体的な製品機能については、ぜひ以下のフォームから資料をダウンロードしてご確認ください。
クラウド事業本部CX部 本部付部長
前職までは開発／プロジェクト管理などエンジニアとして従事。シナジーマーケティングに入社後はSynergy!の導入対応やフロント支援を経てカスタマーサポートに携わる。お客様のお困り事を解消することに喜びを感じ、より多くのお客様に自社製品をご利用いただける活動に注力。
