GmailやOutlook.comが推奨するSPFとDKIM双方のDMARCアライメント

現時点の必須は「どちらか一方」、推奨は「双方」 ― 主要メールプロバイダーの送信者要件（2026年DMARCbis対応版）

2026年6月30日作成
著者: 竹洞 陽一郎

DMARC（Domain-based Message Authentication, Reporting, and Conformance）の仕様（RFC 9989）では、SPFまたはDKIMのいずれか一方がアライメントに合格すればDMARCは合格（pass）となります。
GmailやOutlook.comといった主要なメールプロバイダーも、現時点で必須としているのはどちらか一方のアライメントです。
しかし、両社ともSPFとDKIMの双方でDMARCアライメントに合格することを推奨しており、Googleは将来、双方のアライメントが送信者要件になる可能性が高いとしています。
ここでは、その背景と各プロバイダーの要件、そして具体的な対応方法について解説します。

1. DMARCアライメントとは

DMARCアライメントとは、メールのヘッダーFrom:ドメインと、SPFやDKIMで認証されたドメインが一致（アライメント）しているかを検証する仕組みです。

具体的には、以下の2つのチェックが行われます。

SPFアライメント

SMTP通信時のMAIL FROMアドレス（エンベロープFrom、RFC 5321のMailFromアドレス）のドメインと、ヘッダーFrom:（RFC 5322のFromアドレス）のドメインが一致しているかを検証します。
SPF認証自体が合格していても、MAIL FROMドメインとヘッダーFromドメインが異なればSPFアライメントは失敗します。

DKIMアライメント

DKIM署名ヘッダーのd=タグで指定されたドメインと、ヘッダーFrom:のドメインが一致しているかを検証します。
第三者署名（例えば、ESPが自社ドメインで署名している場合）では、DKIMアライメントは失敗します。

RFC 9989での規定（旧RFC 7489）

現行のDMARC仕様であるRFC 9989は、2026年5月にIETFが公開したもので、2015年公開のRFC 7489を正式に廃止して置き換えたものです。
RFC 9989でも、SPFまたはDKIMのいずれかがアライメントに合格すればDMARCはpassとなるという基本原則は維持されています。
つまり、DMARC標準としては引き続き「OR」条件です。
しかし、これはあくまで最低基準であり、メールプロバイダーがより厳しい条件を課すことを妨げるものではありません。
RFC 9989には、レベルの異なる2つの記述があります。
Section 4.5では、一般的なDMARC運用としてSPFとDKIM双方を認証メカニズムとして使うことがRECOMMENDED（推奨）とされています。
一方、Section 8「Conformance Requirements for Full DMARC Participation」では、Domain Ownerが「完全な参加」を満たすための条件として、SPFアライメントとDKIMアライメントの双方がMUST（必須）と明記されています。
つまり、DMARCの合否判定自体は引き続きOR条件ですが、標準仕様が定める「完全な参加」の水準では、双方のアライメントが必須とされています。

2. Googleの要件 ― Gmailの送信者ガイドライン

Googleはメール送信者ガイドラインにおいて、1日5,000通以上の大量送信者（Bulk Sender）に対して以下の要件を課しています。

• SPFとDKIMの双方による認証が必須
• DMARCレコードの公開（最低でもp=none）
• 直接送信メールについて、ヘッダーFrom:ドメインがSPFドメインまたはDKIMドメインとアライメントしていること

さらに、Googleの送信者ガイドラインFAQでは、以下のように明記されています。

To ensure reliable authentication, we recommend all senders fully align DMARC to both SPF and DKIM.
It's likely that DMARC alignment with both SPF and DKIM will eventually be a sender requirement.

（信頼性の高い認証を確保するため、すべての送信者がSPFとDKIMの双方でDMARCアライメントを完全に設定することを推奨します。SPFとDKIMの双方でのDMARCアライメントは、将来的に送信者要件となる可能性が高いです。）

2025年11月以降、Googleは非準拠メールに対する施行を強化し、一時的なエラー（4xx）および恒久的な拒否（5xx）を適用するようになっています。
Google公式のFAQ（support.google.com）では、どのチェックで失敗したかがエラーコードごとに明記されています。
このうち、ヘッダーFrom:のアライメント不一致に対応するのは一時エラーの4.7.32で、公式FAQ上には恒久エラー版の記載はありません。

3. Microsoftの要件 ― Outlook.comの送信者要件

Microsoftは2025年5月5日から、Outlook.com、Hotmail.com、Live.comへの大量送信者（1日5,000通以上）に対して、以下の認証要件を施行しています。
Microsoft Tech Community公式ブログにて発表されました。

• SPFの認証合格が必須
• DKIMの認証合格が必須
• DMARCレコードの公開（最低p=none）、SPFまたはDKIMとアライメント（できれば双方）

MicrosoftのDMARC設定ガイドでは、DMARCの仕組みとして以下の2つのチェックを行うと説明されています。

SPFによるチェック

メッセージがMAIL FROMアドレスのドメインの認可された送信元から送信されたこと（SPFの基本要件）を確認し、かつMAIL FROMとFrom:のドメインがアライメントしていることを確認する。

DKIMによるチェック

メッセージに署名したドメイン（DKIM-Signatureヘッダーのd=値）が、From:アドレスのドメインとアライメントしていることを確認する。

非準拠のメールは、エラーコード550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level.で拒否されます。

4. なぜ「双方」が推奨されるのか

SPFとDKIMの双方でのDMARCアライメントが推奨される背景には、以下の理由があります。

SPFだけでは不十分なケース

メール転送（forwarding）が行われると、転送サーバーのIPアドレスは元の送信ドメインのSPFレコードに含まれていないため、SPF認証が失敗します。
この場合、DKIMが合格していればDMARCアライメントを維持できます。

DKIMだけでは不十分なケース

一部のメーリングリストやセキュリティゲートウェイでは、メール本文やヘッダーが改変されることがあり、これによりDKIM署名の検証が失敗する場合があります。
この場合、SPFが合格していればDMARCアライメントを維持できます。

双方合格による堅牢性の向上

SPFとDKIMの双方でDMARCアライメントに合格していれば、メール転送時にSPFが壊れても、メール本文改変時にDKIMが壊れても、残りの一方でDMARCアライメントが維持されます。
これにより、メール配信の信頼性が大幅に向上します。
主要メールプロバイダーが双方を「推奨」するのは、この冗長性（redundancy）を確保するためと考えられます。

双方のアライメントを求めるセキュリティ上の理由（MailDataの見解）

冗長性は、双方のアライメントを「推奨」する理由にはなりますが、双方を「必須」とする理由にはなりません。
双方を必須にすると、転送でSPFが壊れたメールは不合格になり、かえって届きにくくなるためです。
それでも、MailDataの観測では、GmailやOutlook.comなどの個人向けメールサービス（B2C）宛てで、双方のアライメントが一致していないメールが拒否されています（DMARCアライメントとは？SPF・DKIMの一致判定とメールが届かない原因【2026年版】の「4. 実際の受信で起きていること」）。
GoogleとMicrosoftは、双方のアライメントを求める理由を公表していません。
MailDataでは、次の2つの攻撃への対策だと考えています。

DKIMリプレイ攻撃への対策として、SPFのアライメントを求める

DKIMリプレイ攻撃では、攻撃者は正規のDKIM署名が付いたメールを入手し、署名を壊さないまま自分のサーバーから大量に再送します。
DKIMのアライメントは一致したままですが、送信元のIPアドレスはドメインのSPFレコードで許可されていないため、SPFのアライメントは一致しません。
SPFのアライメントも求めることで、リプレイされたメールを拒否できます。
DKIMリプレイ攻撃の詳細は、DKIMリプレイ攻撃とは？その防御方法をご参照ください。

共有基盤を悪用したSPFの迂回への対策として、DKIMのアライメントを求める

クラウドサーバー、プロキシ、サーバーレス、CI/CD、CDNなどの共有基盤では、多くの利用者が同じIPアドレスの範囲を使います。
SPFレコードでこうした共有基盤のIPアドレスの範囲を許可していると、同じ基盤を使う第三者が、そのドメインをMAIL FROMとヘッダーFrom:に使ってSPFとDMARCに合格させられる場合があります。
NDSS 2024で発表された論文「BreakSPF: How Shared Infrastructures Magnify SPF Vulnerabilities Across the Internet」では、この攻撃をBreakSPFと名付け、なりすましが可能なドメインを23,916件確認したと報告しています。
同論文では、なりすましメールにはDKIM署名がないものの、受信トレイへの配信の妨げにはならなかったとしています。
攻撃者はそのドメインのDKIMの秘密鍵を持っていないため、DKIMのアライメントも求めれば、この攻撃を防げます。
なお、同論文が対策として挙げているのは、クラウドサービスでの送信ポートの制限、SPFレコードの検査、DMARCレポートの活用であり、DKIMのアライメントを求めることは、MailDataの見解です。

B2C宛てで観測している「DKIMのアライメントが一致していても、SPFのアライメントが一致していないと拒否される」挙動は、DKIMリプレイ攻撃への対策という見方と合っています。
ただし、これはMailDataの観測と分析に基づく見解であり、GoogleやMicrosoftが公表した理由ではありません。

5. 具体的な対応方法

SPFアライメントの確保

SPFアライメントを確保するためには、SMTP通信のMAIL FROMアドレスのドメインと、ヘッダーFrom:のドメインを一致させる必要があります。

• ESPや外部メール送信サービスを利用している場合は、カスタムReturn-Path（カスタムバウンスドメイン）を設定し、自社ドメインまたはそのサブドメインをMAIL FROMに使用するようにします。
• SPFレコードには、実際に使用するすべての送信元IPアドレスやinclude先を正確に記載します。

DKIMアライメントの確保

DKIMアライメントを確保するためには、DKIM署名のd=タグのドメインと、ヘッダーFrom:のドメインを一致させる必要があります。

• ESPや外部メール送信サービスを利用している場合は、カスタムDKIM署名を有効にし、自社ドメインのd=値でメールに署名するようにします。
• ESPが第三者署名（ESP自身のドメイン）のみを提供している場合、DKIMアライメントは失敗します。自社ドメインでの署名に対応しているESPを選定することが重要です。

DMARCレコードの設定

DMARCレコードは、最低でもp=noneで公開し、RUAレポートの受信先を設定します。
SPFとDKIMの双方のアライメントが確認できた段階で、p=rejectへポリシーを引き上げます。

2026年5月公開のRFC 9989（Section 7.4）は、メーリングリストに投稿する可能性のあるユーザーを抱えるドメインについて、p=rejectを公開すべきではない（SHOULD NOT）としています。
そのうえで、そうしたドメインがp=rejectを公開する場合は、DMARCの集計レポートを活用し、まずp=noneを少なくとも1か月、続いてp=quarantineを同じ期間公開して、結果を比較すべきである（SHOULD）としています。
受信者に対しては、ほかの知識や分析がない場合、こうした経路でDMARCに失敗したメールを、p=rejectではなくp=quarantineであるかのように扱わなければならない（MUST）としています。

MailDataでは、p=noneで送信元を洗い出して是正を終えた時点で、p=quarantineを経由せずに直接p=rejectへ移行することをお勧めしています。
理由は、問題をすぐに検知できること、p=rejectへの移行後2〜3週間でなりすましメールが1%未満に減ること（当社の観測）、送信頻度の低い正規の送信元を洗い出せることの3点です。
具体的な手順は、DMARCでp=rejectにするためのプロセスで解説しています。

v=DMARC1; p=reject; rua=mailto:rua@example.com; ruf=mailto:ruf@example.com; adkim=r; aspf=r;

ARC（Authenticated Received Chain）への対応

メール転送やメーリングリストを経由するメールでは、SPFやDKIMが壊れる場合があります。
Googleは、これらの間接的なメールについてはARCヘッダーの付与を求めています。
ARCはRFC 8617で定義されており、転送経路での認証結果を保持する仕組みです。

6. DMARCbis ― 2026年5月のDMARC仕様刷新

2026年5月21日、IETF（Internet Engineering Task Force）は、2015年に公開されたRFC 7489に代わる新しいDMARC仕様として、RFC 9989、RFC 9990、RFC 9991の3本を正式に公開しました。
これらは総称して「DMARCbis」と呼ばれています。

最大の変化は、DMARCが従来のInformational（参考情報）扱いから、IETFのStandards Track（標準化過程）へと格上げされた点です。
これにより、DMARCは正式なインターネット標準としての位置付けを得ることになりました。

3本のRFCへの分割

RFC 9989

DMARCのコアプロトコル。ポリシー評価、アライメント規定、レコード処理を規定します。

RFC 9990

集計レポート（Aggregate Report）の仕様です。

RFC 9991

失敗レポート（Failure Report）の仕様です。

既存のDMARCレコードへの影響

v=DMARC1で始まる既存のDMARCレコードは、そのまま有効です。
DNSレコードを緊急に書き換える必要はありませんが、以下の変更点は把握しておく必要があります。

Organizational Domainの判定方式変更

RFC 7489ではPublic Suffix List（PSL）を使う方法が説明されていましたが、RFC 9989では、PSLだけに頼るのではなく、DNSのツリーをたどってDMARCレコードを探すDNS Tree Walkという手法が定義されました（Section 4.10）。

pctタグの非推奨化

pctタグは、RFC 9989のIANA登録（Section 9.3）でhistoric（非推奨）とされ、現在の実装では使われないものと位置付けられました（rf・riタグも同様です）。テストモードの指定には、pct=に代わりt=yを使用します。

npタグの新設

存在しないサブドメイン向けのポリシーを個別に指定できるようになりました。

Full DMARC Participationの明文化

Section 8「Conformance Requirements for Full DMARC Participation」では、Domain OwnerがSPFアライメントとDKIMアライメントの双方を満たすメールを送ることをMUST（必須）と規定しています。ただし、これは「完全な参加」の基準であり、DMARCの合否判定自体はSection 5.3.5の通り引き続きOR条件です。

p=rejectに関するガイダンスの変更

DMARCbis（RFC 9989 Section 7.4）では、メーリングリストに投稿する可能性のあるユーザーを抱えるドメインは、p=rejectを公開すべきではない（SHOULD NOT）とされました。
受信者は、ほかの知識や分析がない場合、こうした経路でDMARCに失敗したメールを、p=rejectではなくp=quarantineであるかのように扱わなければなりません（MUST）。
MailDataの方針を含め、詳しくは「5. 具体的な対応方法」の「DMARCレコードの設定」をご覧ください。

DMARCbisは、DMARCの合否判定（どちらか一方のアライメントでpass）を変えていません。
一方で、Section 8で「完全な参加」の要件として双方のアライメントをMUSTと明文化したことは、GmailやOutlook.comが推奨する「SPFとDKIM双方のアライメント」と同じ方向を示しています。
今後は、DMARCレコードの有無だけでなく、SPFとDKIMの双方のアライメントを満たしているかどうかが、メール到達性を左右する基準になっていくと考えられます。

7. PowerDMARCでの対応確認

PowerDMARCのダッシュボードを活用することで、自社ドメインから送信されたメールのSPFアライメント状況、DKIMアライメント状況、そしてDMARC合否をリアルタイムで監視できます。

具体的には、以下の確認が可能です。

RUAレポートの分析

各送信元ごとに、SPF認証結果、DKIM認証結果、SPFアライメント、DKIMアライメントの状態を確認できます。「SPFは合格だがアライメント失敗」「DKIMは合格だがアライメント失敗」といったケースを特定し、修正対象の送信元を把握できます。

送信元ごとのアライメント状況

ESPやSaaSサービスなど、外部から送信されるメールについて、カスタムReturn-PathやカスタムDKIM署名が正しく設定されているかを確認できます。

アラート機能

アライメント失敗の急増や、新たな未認証送信元の検出時にアラートを受け取ることができます。

まとめ

DMARCの標準仕様ではSPFまたはDKIMのいずれか一方のアライメント合格で十分ですが、GmailやOutlook.comといった主要メールプロバイダーは、現時点ではどちらか一方のアライメントを必須とし、SPFとDKIMの双方でのアライメント合格を推奨しています。
2026年5月に公開されたDMARCbis（RFC 9989/9990/9991）でも、Section 8「Full DMARC Participation」の要件として、SPFとDKIM双方のアライメントがMUST（必須）と明文化されました。
Googleは将来的にこれを必須要件とする可能性を示唆しており、Microsoftも「できれば双方（preferably both）」と推奨しています。

メールの到達率を維持し、なりすましメールから自社ブランドを守るためには、以下のアクションが必要です。

• すべての送信元について、SPFとDKIMの双方を正しく設定する
• SPFアライメントのために、カスタムReturn-Path（カスタムバウンスドメイン）を設定する
• DKIMアライメントのために、自社ドメインでのカスタムDKIM署名を有効にする
• DMARCレポート（RUA/RUF）を活用して、アライメント状況を継続的に監視する
• 転送やメーリングリスト経由の送信実態を踏まえたうえで、段階的にDMARCポリシーを引き上げる

現時点の必須要件はどちらか一方のアライメントですが、メール転送への耐性、将来の要件化、MailDataが観測しているB2C宛ての受信の挙動を考えると、双方のアライメントを満たしておくことをお勧めします。
すべての送信元で、SPFとDKIMの双方のDMARCアライメントが合格しているか確認しましょう。