GmailやOutlook.comが求めるSPFとDKIM双方のDMARCアライメント
本記事は2026年7月に、2026年5月公開のDMARCbis（RFC 9989/9990/9991）の内容を反映して更新しています。
DMARC（Domain-based Message Authentication, Reporting, and Conformance）の仕様（RFC 9989）では、SPFまたはDKIMのいずれか一方がアライメントに合格すればDMARCは合格（pass）となります。
しかし、GmailやOutlook.comといった主要なメールプロバイダは、この最低基準を超えて、SPFとDKIMの双方でDMARCアライメントに合格することを強く求めるようになっています。
ここでは、その背景と各プロバイダの要件、そして具体的な対応方法について解説します。
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上には恒久エラー版の記載はありません。
| エラーコード | 対象チェック | 内容 |
|---|---|---|
| 4.7.23 | PTR | 送信元IPにPTRレコードがない、または逆引きが一致しない（一時エラー） |
| 4.7.27 / 5.7.27 | SPF | SPF認証が合格しなかった |
| 4.7.29 / 5.7.29 | TLS | TLS接続が使用されていない |
| 4.7.30 / 5.7.30 | DKIM | DKIM認証が合格しなかった |
| 4.7.31 | DMARC | DMARCレコードの欠如、またはポリシー未指定（一時エラーのみ確認） |
| 4.7.32 | アライメント | ヘッダFrom:がSPFまたはDKIMのアライメント済みドメインと一致しない（一時エラーのみ確認） |
| 5.7.25 | PTR | 送信元IPにPTRレコードがない、または逆引きが一致しない（恒久エラー） |
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）を確保するためです。
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=quarantineからp=rejectへと段階的にポリシーを引き上げていきます。
ただし、2026年5月公開のRFC 9989では、メール転送やメーリングリストを経由するトラフィックが多いドメインに対して、p=rejectを一律に適用することは推奨されていません。
レシーバー側もそうした間接的なメールフローについては、p=rejectをp=quarantine相当として扱うべきとされています。
自社ドメインの利用実態（転送の有無、メーリングリスト経由の送信の有無）を踏まえたうえで、最終的なポリシーを判断することが重要です。
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の判定方式変更
- 従来のPublic Suffix List（PSL）参照から、DNS Tree Walkアルゴリズムに変更されました。
- pctタグの廃止
- テストモードの指定は、
pct=に代わりt=yを使用します。 - npタグの新設
- 存在しないサブドメイン向けのポリシーを個別に指定できるようになりました。
- Full DMARC Participationの明文化
- Section 8「Conformance Requirements for Full DMARC Participation」では、Domain OwnerがSPFアライメントとDKIMアライメントの双方を満たすメールを送ることをMUST（必須）と規定しています。ただし、これは「完全な参加」の基準であり、DMARCの合否判定自体はSection 4.5の通り引き続きOR条件です。
p=rejectに関するガイダンスの変更
DMARCbisでは、メール転送やメーリングリストを経由するトラフィックが多いドメインに対して、p=rejectを一律に適用することを推奨していません。
レシーバー側に対しても、そうした間接的なメールフローについてはp=rejectをp=quarantine相当として扱うことが求められています。
自社の送信実態を踏まえたうえで、ポリシーの引き上げ方針を判断することが重要です。
DMARCbisの登場は、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ポリシーを引き上げる
「どちらか一方で合格すれば良い」という時代は終わりつつあります。
今すぐ、すべての送信元でSPFとDKIMの双方のDMARCアライメントが合格しているか確認しましょう。