SPFアライメントとは？DMARC認証でPassするための仕組みと失敗時の対処法

DMARCを導入したのに「なぜかSPFアライメントが失敗する」「SPF認証はPassしているのにDMARCがFailになる」こうした問い合わせが、ここ数年で急増しています。原因は明確です。SPF認証とSPFアライメントは別物だからです。

2024年2月にGoogleが「メール送信者ガイドライン」を施行して以降、Gmail宛に1日5,000通以上送信する事業者にはDMARC設定が事実上の必須要件となりました。DMARCポリシーをp=quarantineやp=rejectに引き上げる企業が増えるなか、SPFアライメントの失敗はそのまま到達率の悪化に直結します。

しかし、多くの解説記事は「SPFアライメントとは何か」の概念説明にとどまり、「なぜ失敗するのか」「どうすれば直せるのか」という現場のエンジニアが本当に知りたい部分が抜け落ちているのが実情です。

この記事では、SPFアライメントの基礎から、失敗する具体的なケース、Return-Pathの調整方法、relaxed/strictモードの実務的な使い分け、そしてメール配信サービスを利用する場合の対処法まで、現場で必要な知識を体系的に解説します。

SPFアライメントとは何か

SPFアライメントを理解するためには、まずSPF認証そのものとの違いを明確に押さえる必要があります。両者は名前が似ていますが、検証する対象も合否判定の基準もまったく異なる仕組みです。

SPFアライメントの定義

SPFアライメントとは、メールの「ヘッダFromドメイン」と、SPF認証に使用される「エンベロープFromドメイン（Return-Pathドメイン、Mail Fromドメインとも呼ばれる）」が一致しているかを検証する仕組みです。

英語の「Alignment」は「整合性」「一致」という意味で、日本語では「アライメント」「整合性」「調整」などと表記されます。技術文書ではアルファベット表記の「Alignment」がそのまま使われるケースも多く、用語の揺れに惑わされないことが重要です。SPFアライメントが照合するのは、以下の2つのドメインです。

• ヘッダFromドメイン
  メールソフトの「差出人」欄に表示される、受信者が目にするアドレスのドメイン部分
• エンベロープFromドメイン
  SMTP通信のMAIL FROMコマンドで指定される、バウンス処理に使われるアドレスのドメイン部分

この2つが「整合している」と判定されれば、SPFアライメントはPassします。

SPF認証との違い

混同されやすいのですが、SPF認証とSPFアライメントは検証する対象が異なります。

SPF認証は、メールを送信したサーバーのIPアドレスが、エンベロープFromドメインのSPFレコードに登録された「許可IP」に含まれているかを検証します。つまり「正しいサーバーから送られたメールか」を判定する仕組みです。

一方、SPFアライメントは「ヘッダFromドメインとエンベロープFromドメインが一致しているか」を検証します。SPF認証が通っていても、この2つのドメインがズレていればSPFアライメントは失敗します。

DMARC認証で合格するためには、「SPF認証＋SPFアライメント」または「DKIM認証＋DKIMアライメント」のどちらかのセットが揃う必要があります。片方だけ通っても意味がない点が、DMARC運用における最大の落とし穴です。

なぜSPFアライメントが必要なのか

そもそもなぜアライメントという概念が必要なのでしょうか。答えは、SPFやDKIM単体ではヘッダFromの偽装を防げないからです。メールには「ヘッダFrom」と「エンベロープFrom」という2種類の送信元アドレスが存在します。受信者がメールソフト上で目にするのはヘッダFromですが、SPF認証が検証するのはエンベロープFromです。

つまり、攻撃者は自分が管理するドメインのSPFレコードを正しく設定したうえで、ヘッダFromだけ有名企業のドメインに偽装することが可能でした。これでは「SPF認証はPassしたが、表示上は別人になりすましたメール」を防げません。

この弱点を補うために生まれたのが、DMARCのアライメント検証です。ヘッダFromとSPF認証ドメインを照合することで、なりすましメールを構造的に検知できるようになりました。SPFアライメントとあわせてDKIMアライメントも含めたDMARC全体のアライメント設計を知りたい方は、こちらの記事もあわせてご覧ください。

関連記事

DMARCアライメントとは？必要性や種類、仕組みを徹底解説

SPFアライメントの2つのモード

SPFアライメントには「relaxed（緩和）」と「strict（厳格）」の2つのモードがあります。どちらを選ぶかで合否判定の厳しさが変わるため、運用上の理解が欠かせません。

relaxed（緩和）モードの仕組み

relaxedモードは、ヘッダFromドメインとエンベロープFromドメインの「組織ドメイン」が一致していれば合格と判定するモードです。

組織ドメインとは、いわゆるルートドメイン（example.com）のことを指します。サブドメインの有無は問われません。具体例で見てみます。

• ヘッダFrom：info@example.com
• エンベロープFrom：bounce@mail.example.com

このケースでは、ヘッダFromの組織ドメインは「example.com」、エンベロープFromの組織ドメインも「example.com」です。サブドメイン「mail.」が付いていますが、組織ドメインが同じなのでrelaxedモードではPassします。

DMARCレコードでaspfタグを省略した場合や、明示的にaspf=rと指定した場合は、このrelaxedモードが適用されます。RFC 7489（DMARCの仕様）でもデフォルトはrelaxedと定められています。

strict（厳格）モードの仕組み

strictモードは、ヘッダFromドメインとエンベロープFromドメインが完全一致しなければ合格と判定しません。サブドメインの違いも許容されません。先ほどと同じ例で考えてみます。

• ヘッダFrom：info@example.com
• エンベロープFrom：bounce@mail.example.com

このケースでは、example.com と mail.example.com は完全一致しないため、strictモードではFailとなります。DMARCレコードにaspf=sを指定するとstrictモードが有効になります。strictは厳格さと引き換えに設定難易度が一気に上がるため、なりすまし対策の精度と運用負荷のバランスをどう取るかの判断が問われます。

relaxedとstrictの使い分け基準

実務上、どちらを選ぶべきかは、組織の運用体制によって決まります。

一般的な企業のメール運用では、サブドメインを使い分けるケースが多いため、まずはrelaxedモードで運用を始めるのが現実的です。金融機関や政府機関など、なりすましメールが致命的なリスクとなる組織では、strictモードを採用してドメインを完全にコントロールする運用も選択肢に入ります。

ただし、strictモードに切り替える前に、必ずDMARCレポートを数週間モニタリングし、自社が使うすべての配信経路がstrictでもPassすることを確認してください。何のテストもなくstrictに変更すると、正当なメールまでDMARCがFailするリスクがあります。

SPF以外の原因でDMARCがFailするケースも含めて確認したい場合は、こちらの記事を参照してください。

関連記事

DMARC認証が失敗する原因と簡単にできる解決方法を詳しく解説

SPFアライメントが失敗する典型的なケース

SPFアライメントが失敗するパターンは、実はほぼ決まっています。代表的な5つのケースを押さえておくと、トラブル発生時の原因特定が一気に早くなります。

ケース1：外部メール配信サービス利用時

最も頻繁に発生するのが、外部のメール配信サービスを利用するケースです。

メール配信サービスを利用すると、エンベロープFromには配信サービス側のドメイン（例：bounce.service-provider.com）が自動で設定されることが多くあります。一方、ヘッダFromには自社ドメイン（例：info@your-company.com）を設定するのが通常です。この結果、エンベロープFromの組織ドメインとヘッダFromの組織ドメインが別物になり、SPFアライメントは失敗します。

このパターンを解消するには、メール配信サービス側で「エンベロープFrom持ち込み機能」（サービスによっては「カスタムReturn-Path」とも呼ばれる）に対応している必要があります。自社ドメインのサブドメイン（例：bounce.your-company.com）を配信サービスにCNAME登録することで、エンベロープFromを自社ドメイン配下に揃えられます。

ケース2：メーリングリスト・フォワーディング経由の配信

メーリングリストや転送サービス（フォワーディング）を経由したメールも、SPFアライメントが失敗しやすい典型例です。

転送時、エンベロープFromは転送元サーバーのアドレスに書き換えられることが多く、結果としてヘッダFromとは異なるドメインになります。これは「SRS（Sender Rewriting Scheme）」と呼ばれる仕組みでも完全には解決されない構造的な問題です。

この場合の対策は、SPFアライメントに頼らず、DKIMアライメントを確実にPassさせることです。DKIM署名は転送経路で書き換えられないため、フォワーディング環境でも認証情報が保持されます。

ケース3：MAツール・CRMからの送信

マーケティングオートメーション（MA）ツールやCRMの送信機能を使う場合も、SPFアライメントが失敗するケースが頻発します。

ツール側のサーバーから自社ドメインのアドレスでメールを送る際、エンベロープFromがツールベンダーのドメインに固定されている仕様だと、構造上アライメントが取れません。

対策としては、ツール側がエンベロープFrom持ち込み機能に対応しているかを契約前に必ず確認することです。対応していない場合は、DKIM署名の独自ドメイン化（作成者署名）で代替する判断が必要になります。

ケース4：sendmail・Postfixの設定ミス

自社サーバーから直接送信する場合でも、メールサーバー（sendmailやPostfixなど）の設定でエンベロープFromとヘッダFromが食い違うことがあります。

特に、Webアプリケーションのメール送信関数でFromヘッダだけを指定し、SMTPのMAIL FROMをデフォルト（OSユーザー名@ホスト名）のままにしているケースがよく見られます。このような構成では、エンベロープFromがapache@server01.example.comのような自動生成アドレスになり、ヘッダFromのinfo@example.comとドメインが揃いません。

対策は、Webアプリケーションのメール送信処理で-fオプションやReturn-Pathヘッダを明示的に指定し、ヘッダFromと同じ組織ドメインに揃えることです。

ケース5：strictモードでサブドメインを使用

strictモードを設定しているのに、サブドメインを含むアドレスから送信しているケースです。例えばaspf=sに設定したうえで、ヘッダFromにnews@mail.example.com、エンベロープFromにbounce@example.comを使うと、サブドメインのレベルが違うため失敗します。

対策は、relaxedモードに変更するか、ヘッダFromとエンベロープFromのドメインを完全一致させることです。strictモードを採用する場合は、配信経路を絞り込んだ運用設計が不可欠です。

SPFアライメントの確認方法

SPFアライメントが現状どうなっているかを確認する方法は、大きく2つあります。

メールヘッダから直接確認する

最も基本的な方法は、実際に届いたメールのヘッダ情報を確認することです。

Gmailの場合、対象のメールを開き、右上の「︙」メニューから「メッセージのソースを表示」を選択すると、ヘッダの全文が表示されます。確認すべき項目は以下のとおりです。

• From: ヘッダの値（ヘッダFrom）
• Return-Path: の値（エンベロープFromに相当）
• Received-SPF: の判定結果
• Authentication-Results: の spf= dmarc= の値

Authentication-Resultsヘッダには、Gmailなどの受信側がSPF・DKIM・DMARCをどう判定したかが記録されています。dmarc=passとなっていれば認証成功、dmarc=failであれば失敗です。

加えて、より詳細な判定情報を見るにはReceived-SPFのidentity=mailfromや、Authentication-Results内のspf.heloの項目を確認します。

DMARCレポートで全体傾向を把握する

個別メールではなく、ドメイン全体の認証状況を把握するにはDMARCレポートを活用します。DMARCレコードにrua=mailto:dmarc-reports@your-company.comのように指定すると、各受信メールサーバーから集計レポート（aggregateレポート）がXML形式で届きます。レポートには以下のような情報が含まれます。

• 送信元IPアドレスごとの配信通数
• SPF認証・DKIM認証の合格率
• SPFアライメント・DKIMアライメントの合格率
• DMARCポリシーの適用結果

XML形式のままでは読みにくいため、DMARCレポート解析ツール（dmarcian、Postmark、Valimailなど）を利用するのが現実的です。これらのツールを使うと、SPFアライメントがどの送信経路で失敗しているかを可視化できます。

DMARC導入直後は必ずp=none（モニタリングのみ）でレポートを数週間収集し、すべての正当な配信経路でアライメントがPassすることを確認してから、p=quarantineやp=rejectに引き上げてください。DMARCレポートの具体的な読み方や、初期設定手順については以下の記事で詳しく解説しています。

関連記事

DMARCとは？メリットや設定方法、DMARCレポートの読み方について徹底解説

SPFアライメントを通過させる実践的な設定方法

実際の設定手順を、自社サーバー運用と外部配信サービス利用の2パターンに分けて解説します。

自社サーバーから配信する場合の設定

自社のメールサーバーから直接送信する場合、SPFアライメントを通すためにやるべきことは、エンベロープFromドメインをヘッダFromドメインと揃えることです。

• 送信時にMAIL FROM（エンベロープFrom）を明示的に指定する
• WebアプリケーションのSMTPライブラリでReturn-Pathを設定する
• メールサーバー側で送信元ドメインの正規化処理を行う

PHPのmail()関数を例に挙げると、第5引数の-fオプションでエンベロープFromを指定できます。Pythonのsmtplibでは、sendmail()メソッドの第1引数（from_addr）がそのままエンベロープFromになります。

これらの設定で、ヘッダFromと同じ組織ドメインのアドレスをエンベロープFromに指定すれば、relaxedモードでアライメントはPassします。

外部メール配信サービスを利用する場合の設定

外部のメール配信サービスやSMTPリレーサービスを利用する場合、SPFアライメントの設定は配信サービスの仕様に大きく依存します。確認すべきポイントは以下のとおりです。

• エンベロープFrom（Return-Path）を自社ドメインに変更できるか
• DKIM署名を自社ドメインで行う「作成者署名」に対応しているか

これらに対応している配信サービスであれば、自社ドメインで完結したDMARC認証を構築できます。逆に、これらに対応していないサービスを使うと、SPFアライメントは構造的にFailし、DKIMアライメントだけが頼りになります。

DMARCレコードの記述例

実際のDNS設定で使うDMARCレコードの記述例を示します。relaxedモードを採用するケースが一般的です。

v=DMARC1; p=quarantine; pct=100; aspf=r; adkim=r; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensic@example.com

各タグの意味は以下のとおりです。

• v=DMARC1：DMARCのバージョン（固定値）
• p=quarantine：認証失敗時の処理（隔離）
• pct=100：ポリシー適用率（100%）
• aspf=r：SPFアライメントモード（relaxed）
• adkim=r：DKIMアライメントモード（relaxed）
• rua=mailto:...：集計レポートの送信先
• ruf=mailto:...：個別失敗レポートの送信先

最初はp=noneで運用を始め、レポートで問題がないことを確認してからp=quarantine、最終的にp=rejectへと段階的に引き上げる「DMARC段階的導入」が推奨されています。

SPFアライメントが失敗しても問題ないケース

ここまで「SPFアライメントを通す」ことを前提に解説してきましたが、実はSPFアライメントが失敗していてもDMARCがPassすれば問題ありません。

DMARC認証は「SPFアライメント＋SPF認証」または「DKIMアライメント＋DKIM認証」のどちらか一方が通れば合格と判定されます。つまり、DKIM側の認証とアライメントがしっかり通っていれば、SPFアライメントが失敗していてもDMARCは合格します。

外部のメール配信サービスを利用する企業の多くは、構造的にSPFアライメントを通すのが困難です。この場合、DKIMアライメントを確実にPassさせる設計のほうが現実的かつ堅牢です。

【注意点】
DKIMアライメントを通すためのポイントは、配信サービス側で「作成者署名（自社ドメインでのDKIM署名）」に対応していることです。第三者署名（配信サービスのドメインで署名する方式）ではDKIMアライメントは通りません。

ただし、DKIMアライメントだけに依存する運用にはリスクもあります。DKIM署名がメール本文の改変で無効化されたり、署名鍵のローテーションミスで一時的にDKIM認証が失敗したりすると、DMARC全体がFailに転落します。

本来の理想は、SPFアライメントとDKIMアライメントの両方を満たすことです。両方を通しておけば、片方が一時的に失敗してもDMARCはPassし続けられます。「片方でOK」はあくまでも最低ラインの担保であり、堅牢なメール運用を目指すなら、SPFアライメント・DKIMアライメントの両輪を整えることを目標にしてください。実務的なアドバイスとしては、以下のようになります。

• 理想は、SPFアライメントとDKIMアライメントの両方を通すこと
• 自社サーバー運用なら両方を通せるよう設定する
• 外部配信サービス利用時はDKIMアライメントを最優先で確実に通す
• 並行してエンベロープFrom持ち込み機能を活用し、SPFアライメントも通せるサービスを選ぶ
• DMARCレポートでSPF・DKIM両方の合格率を毎月モニタリングする

SPF・DKIM・DMARCの関係性

ここまでの内容を、3つの認証技術の関係性として整理しておきます。

認証技術ごとの役割分担

メールセキュリティを支える3つの技術は、それぞれ異なる役割を担っています。

SPFアライメントは、DMARCの判定基準の一部です。DMARC認証をPassするためには、単にアライメントを通すだけでなく、ベースとなるSPFまたはDKIMのどちらかにおいて、認証そのものとアライメントの両方が成功している必要があります。

関連記事

送信ドメイン認証とは？SPF・DKIM・DMARCの仕組みと設定方法を解説

認証の全体像

メール受信時、受信サーバーはSPFとDKIMの認証結果、そしてそれぞれのアライメントをDMARCの判定材料として統合的に評価します。厳密な順番で逐次処理されるわけではなく、以下の要素を組み合わせてDMARCの合否が決まります。

• SPF認証：送信元IPがエンベロープFromドメインのSPFレコードに合致するか
• SPFアライメント：エンベロープFromとヘッダFromのドメインが整合するか
• DKIM認証：DKIM署名が公開鍵で検証可能か
• DKIMアライメント：DKIM署名ドメインとヘッダFromのドメインが整合するか

受信サーバーはこれらの結果をもとに、DMARCポリシーに従って最終的な処理（通常配信／隔離／拒否）を決定します。SPFアライメントは、SPF認証の結果に意味を持たせるための重要なチェック要素として機能します。

Gmail送信者ガイドラインとSPFアライメント

2024年2月にGoogleが施行した「メール送信者ガイドライン」は、SPFアライメントを含むDMARC設定の重要性を一気に高めました。このガイドラインの影響を最後に整理します。

ガイドラインの要点

Gmailのメール送信者ガイドラインでは、Gmail宛に1日5,000通以上のメールを送信する送信者に対し、以下を要件として課しています。

• SPF・DKIMの両方の設定
• DMARCの設定（最低でもp=none）
• ヘッダFromドメインとSPF/DKIMのドメインのアライメント
• ワンクリック登録解除（List-Unsubscribe-Postヘッダ）の実装
• 迷惑メール報告率を0.3%未満に維持

このうち「ヘッダFromドメインとSPF/DKIMのドメインのアライメント」は、まさにSPFアライメントまたはDKIMアライメントを通すことを意味します。どちらか一方が通っていればOKですが、両方とも失敗していればGmailへの到達率は大きく低下します。

実務上の影響

ガイドライン施行後、Gmail宛のメール到達率が急落した企業の多くは、SPFアライメントまたはDKIMアライメントが失敗していました。外部メール配信サービスを利用している企業では、サービス側がガイドラインに対応していなかったケースも報告されています。対応する具体策は以下のとおりです。

• 利用中の配信サービスがガイドライン対応を完了しているか確認
• エンベロープFrom（Return-Path）を自社ドメインに変更する設定を完了する
• DKIM署名を自社ドメインで行う設定に切り替える
• DMARCレポートで実際の認証状況を継続的にモニタリング

これらをきちんと運用できている企業と、そうでない企業の到達率には、すでに大きな差が生まれ始めています。

SPFアライメントを確実に運用するならメール配信システムを活用する

ここまでSPFアライメントの仕組みと設定方法を解説してきました。しかし、現実問題として自社のサーバーで完璧なSPF/DKIM/DMARC運用を構築・維持するのは、専任のメールエンジニアがいないと困難です。

メール配信システムを使うメリット

DMARC・SPFアライメント対応を確実に進めたいなら、最初から認証技術に対応したメール配信システムを利用するのが最短ルートです。

• 独自ドメインでの送信ドメイン認証：SPF・DKIM・DMARC・SPFアライメント・DKIMアライメントすべてを自社ドメインで構築できる
• DMARCレポート対応：認証失敗の原因をすぐに特定でき、運用負荷を最小化
• 高い到達率：IPレピュテーション管理を配信サービス側が行うため、ガイドラインに自動的に追従

特に大量配信を行う企業では、自社運用とのコスト・運用負荷の差が大きく、配信サービスの利用が現実的な選択肢になります。

おすすめのメール配信システム「blastengine」

blastengine（ブラストエンジン）は、SMTPリレーやAPIで連携することで、SPFアライメント・DKIMアライメントを含む送信ドメイン認証を確実に運用できるメール配信サービスです。お客様のシステムとAPIで連携することで、既存システムを変えずに高い到達率と認証対応を両立できます。

• エンベロープFrom持ち込み機能：SPFアライメントをPassすることが可能
• SPF/DKIM/DMARC対応：送信ドメイン認証に標準対応し、なりすまし・迷惑メール判定を回避
• 99%以上の高いメール到達率：国内キャリア・ISPへの個別送信ロジックで確実にメールを届ける
• API連携・SMTPリレー：既存システムへの組み込みが容易で、最短当日から利用開始可能
• IPレピュテーション管理：blastengine側で運用・管理するため、常に高い送信者評価を維持
• バウンスメール自動対応：エラーメール管理を自動化し、運用負荷を大幅に削減

Gmail送信者ガイドラインへの対応や、DMARC強化を進めたいエンジニア・システム担当者にとって、認証対応を一気にクリアできる選択肢となります。初期費用無料・月額3,000円から利用でき、メールアドレス入力のみで無料トライアルが可能です。

ブラストエンジン公式サイト：https://blastengine.jp/

まとめ

SPFアライメントは、ヘッダFromドメインとエンベロープFromドメインの一致を検証する仕組みです。SPF認証とは別物であり、DMARC認証で合格するために不可欠な要素となります。押さえておきたいポイントは以下のとおりです。

• SPFアライメントは「ヘッダFrom」と「エンベロープFrom」のドメイン一致を検証
• relaxedモード（デフォルト）は組織ドメインの一致、strictモードは完全一致を要求
• 外部メール配信サービス利用時はSPFアライメントが失敗しやすい
• DMARC合格には「SPFアライメントまたはDKIMアライメント」のどちらか一方が通ればよい
• Gmail送信者ガイドラインで、SPF/DKIMどちらかのアライメント通過が事実上の必須要件に

自社運用でSPFアライメントを完全に管理するのは技術的にハードルが高いため、対応済みのメール配信サービスを活用するのが現実的な選択肢です。送信ドメイン認証への対応は、もはや「やる/やらない」ではなく「いつまでに完了させるか」のフェーズに入っています。