DMARCアライメントとは？SPF・DKIMの一致判定とメールが届かない原因【2026年版】

「片方のアラインで合格するから両方は不要」は誤り ― RFC 9989の要件と実際の受信の挙動

2026年10月13日作成
著者: 竹洞 陽一郎

DMARCの導入相談で、「DMARCはSPFかDKIMのどちらか一方がアラインすれば合格するので、両方は不要」という説明を受けたという話をよく聞きます。
この説明は、受信側がDMARCの合否を判定するルールとしては正しいのですが、送信側（ドメイン所有者）が満たすべき要件としては誤りです。
さらに、実際の受信では、片方のアラインだけではメールが届かないケースが確認されています。
ここでは、2026年5月に発行されたDMARCの新しい仕様（RFC 9989）に基づいてアライメントの一致判定を解説し、受信側の判定ルールと送信側の要件を分けて説明します。
そのうえで、MailDataの実測で確認している「届く・届かない」の条件と、その対策をまとめます。

GmailやOutlook.comが公開している大量送信者向けの要件については、GmailやOutlook.comが推奨するSPFとDKIM双方のDMARCアライメントで解説しています。

早見表 ― アライメントの状態と届く・届かない

最初に、この記事の結論を一覧にします。
「受信側のDMARCの判定」と「完全な参加の要件」は、DMARCの仕様（RFC 9989）に基づきます。
受信側の判定では、SPFかDKIMのどちらか一方がアラインすればpassになります。
一方、送信側（ドメイン所有者）がDMARCに完全に参加する（Full DMARC Participation）には、SPFとDKIMの両方でアライメントを満たすことが求められています。
詳しくは、3. RFC 9989の規定一覧で解説します。
「B2B宛て」「B2C宛て」の列は、MailDataの観測（2026年10月時点）です。

DMARCの判定がpassでも、完全な参加の要件を満たさない状態では、送信先によっては届きません。
SPFとDKIMの両方でアライメントを満たした状態だけが、完全な参加の要件と実際の受信の両方を満たします。

なお、仕様上、受信者は送信ドメインのポリシーがp=rejectであることだけを理由にメッセージを拒否してはなりません（MUST NOT、Section 7.4・Section 8）。
上の表の「届かない」は、受信側がDMARCの結果とほかの判断材料を合わせて判断した結果として観測しているものです。

なお、この表は受信者に直接届くメールの場合です。
受信側がGoogle Groupsなどのメーリングリストを部署メールに使っている場合は、結果が異なります。
メーリングリスト（Google Groups）経由の早見表をご覧ください。

送信者（ドメイン所有者）と受信者に求められる、SPFとDKIMのアライメントに関する要件は次のとおりです（RFC 9989のSection 8、Section 7.4、Section 5.3.5）。

メーリングリスト（Google Groups）経由の早見表

受信側がGoogle Groupsを部署メール（例：sales@やinfo@のような部署の共有アドレス）に使っている場合、メールはGoogle Groupsが受け取ってから各メンバーに配り直します。
この場合、届くかどうかはアライメントの状態ではなく、送信元ドメインのDMARCポリシー（p=の値）で分かれています。
以下はMailDataの観測（2026年10月時点）です。

GoogleのGmailヘルプによると、DMARCポリシーがp=quarantineまたはp=rejectのドメインからGoogle Groupsに送られたメールは、送信者が「送信者名 via グループ名」とグループのアドレスで表示されます。
これは、Google Groupsの配信が送信元ドメインのDMARCポリシーに引っかからず、正しく配信されるようにするための動作だと説明されています。
p=quarantineとp=rejectのドメインからのメールが届いているのは、この書き換えによるものと考えられます。
一方、p=noneのドメインからのメールはこの書き換えの対象ではなく、アライメントの状態にかかわらず届いていません。

なお、RFC 9989（Section 7.4）は、メーリングリストに投稿する可能性のあるユーザーを抱えるドメインについて、p=rejectを公開すべきではない（SHOULD NOT）としています。
受信側の部署メールとして使われているGoogle Groupsに送ることも、メーリングリストへの投稿にあたります。
ただし、MailDataの観測では、Google Groupsについてはp=quarantineとp=rejectのドメインからのメールが届き、p=noneのドメインからのメールが届いていません。

1. DMARCアライメントとは

DMARCアライメントの仕組みは、DMARCの仕様解説の「DMARC Alignmentチェックとは？」で詳しく解説しています。
SPFアライメントで使うEnvelope FromとReturn-Pathの関係は、同ページの「Envelope FromとReturn-Pathの関係」をご覧ください。
ここでは、要点を表にまとめます。

DMARCアライメント（Identifier Alignment）とは、メールのヘッダーFrom:のドメイン（RFC 9989ではAuthor Domainと呼びます）と、SPFやDKIMで認証されたドメインが一致しているかどうかを確認する仕組みです。
SPFやDKIMの認証にpassしていても、認証されたドメインがヘッダーFrom:のドメインと一致していなければ、DMARCの判定には使われません。
そのため、「SPFはpass」「DKIMはpass」でも、DMARCはfailになることがあります。

RFC 9989では、DMARCが使うSPFの認証はMAIL FROMの検証だけであると明記されています（Section 4.4.2）。

DMARC relies solely on SPF validation of the MAIL FROM identity.

（DMARCは、MAIL FROMのアイデンティティに対するSPFの検証だけを使います。）

HELOのドメインでSPFがpassしていても、DMARCのSPFアライメントには使われません。

2. アライメントの一致判定 ― relaxedとstrict

relaxedとstrictの違いは、DMARCアライメント: Relaxed VS Strictアライメントモードで、aspfタグの書き方はDMARC aspfタグ 説明ガイドで詳しく解説しています。
ここでは、要点を表にまとめます。

アライメントの一致判定には、relaxed（緩和）とstrict（厳格）の2つのモードがあります（Section 3.2.10、Section 4.4、Section 4.7）。

タグを書かなければrelaxedになるので、意図せずaspf=sやadkim=sが設定されていないかを確認してください。

組織ドメインの判定方法も、RFC 9989で変わりました。
旧仕様のRFC 7489はPublic Suffix List（PSL）を使う方法を説明していましたが、RFC 9989では、DNSのツリーをたどってDMARCレコードを探すDNS Tree Walkという手法が定義されています（Section 4.10）。
一般的な企業ドメインでは、上の表の判定結果は変わりません。

3. RFC 9989の規定一覧 ― 受信側の判定と送信側の要件

RFC 9989のうち、アライメントに関係する規定を一覧にします。
規範用語（MUST、MUST NOT、RECOMMENDED）の意味はRFC 2119とRFC 8174の定義に従います。

受信側の判定 ― 片方のアラインでDMARCはpass

If one or more of the Authenticated Identifiers align with the Author Domain, the message is considered to pass the DMARC mechanism check.

（認証された識別子のうち1つ以上がAuthor Domainとアラインしていれば、そのメッセージはDMARCのメカニズムチェックにpassしたとみなされます。）

「片方のアラインで合格する」という説明は、この受信側の判定ルールを指しています。

送信側の要件 ― 両方のアラインがMUST

Section 8「Conformance Requirements for Full DMARC Participation」は冒頭で、ドメイン所有者と受信者がDMARCの仕組みのどの部分を実装するかについて、ある程度の裁量の余地（some leeway）があるとしています。
そのうえで、「DMARCに完全に参加するために（In order to fully participate in DMARC）」ドメイン所有者が満たすべき要件として、次の2つをMUST（必須）と定めています。

MUST send mail so it produces an SPF-Authenticated Identifier that has Identifier Alignment with the Author Domain.

MUST send mail that has a DKIM Signing Domain that will produce a DKIM-Authenticated Identifier that has Identifier Alignment with the Author Domain.

（Author DomainとアラインしたSPF認証済み識別子が得られるようにメールを送信しなければならない（MUST）。
Author DomainとアラインしたDKIM認証済み識別子が得られる署名ドメインでメールを送信しなければならない（MUST）。）

受信側の判定は「どちらか一方」でも、送信側がDMARCに完全に準拠するには、SPFとDKIMの両方でアライメントを満たすことがMUST（必須）です。
「片方のアラインで合格するので、両方は不要」という説明は、受信側の判定ルールと送信側の要件を混同しています。

p=rejectのドメインはSPFだけに頼ってはならない

It is therefore critical that domains that publish "p=reject" MUST NOT rely solely on SPF to secure a DMARC pass and MUST apply valid DKIM signatures to their messages.

（したがって、"p=reject"を公開するドメインは、DMARCのpassを確保するためにSPFだけに頼ってはならず（MUST NOT）、メッセージに有効なDKIM署名を付けなければなりません（MUST）。）

Section 7.4のこの規定は、「完全な参加」の要件に限らず、p=rejectを公開するドメインに対して書かれています。
メール転送ではSPFが失敗しやすいので、p=rejectを目指すドメインにとってDKIMのアライメントは欠かせません。

RECOMMENDEDだけを根拠にしない

However, it is RECOMMENDED that Domain Owners use both DKIM and SPF as underlying authentication mechanisms for DMARC.

（ただし、ドメイン所有者は、DMARCの基盤となる認証の仕組みとしてDKIMとSPFの両方を使うことが推奨されます（RECOMMENDED）。）

Section 4.5は、SPFかDKIMの片方だけを使う選択肢にも触れたうえで、両方を使うことをRECOMMENDED（推奨）としています。
RECOMMENDEDは、正当な理由があれば従わないことも許される強さの規範用語です。
Section 4.5だけを根拠にすると「両方使うのは推奨にとどまる」と受け取られますが、DMARCへの完全な準拠の要件はSection 8のMUSTです。

アライメント以外のRFC 9989の変更点（np・t・psdタグの追加、pct・rf・riタグのhistoric（非推奨）化など）は、GmailやOutlook.comが推奨するSPFとDKIM双方のDMARCアライメントの「DMARCbis ― 2026年5月のDMARC仕様刷新」で解説しています。

4. 実際の受信で起きていること ― 届く・届かないの分かれ目

ここからは、仕様ではなく、MailDataがお客様のDMARCレポートや配信結果から確認している実測・観測（2026年10月時点）です。
GoogleやMicrosoftが公開している要件ではないので、今後変わる可能性があります。

添付ファイルの有無で結果が変わる理由は、GoogleやMicrosoftから公開されておらず、現時点では確認できていません。
添付ファイルはマルウェアの感染源になりうるため、添付ファイル付きのメールには、より厳しいフィルターが設定されていると推測されます。

Googleの公開要件と、上の観測を並べると次のようになります。

Googleは、SPFとDKIMの設定は両方を求めていますが、アライメントはどちらか一方で可としています。
観測の結果は、この公開要件よりも厳しくなっています。

5. アライメント不一致の主な原因と対策

アライメントが一致しない原因の多くは、外部のメール配信サービスやSaaSが、MAIL FROMやDKIM署名に自社（サービス側）のドメインを使っていることです。

MAIL FROMを自社ドメインに合わせる具体的な方法は、メール配信事業者向けEnvelope From一致の方法と、Amazon SESのSPFでのDMARC Alignmentチェックを一致させる方法で解説しています。

「DMARCはpassしているが、SPFのアライメントが一致していない」送信元は、DMARCの合否だけを見ていると見逃します。
しかし、上記のとおり、添付ファイル付きのメールやB2C宛てのメールでは届かない原因になります。
DMARCの集計レポート（RUA）で、送信元ごとにSPFとDKIMの両方のアライメントを確認してください。

6. まとめ ― 確認チェックリスト

受信側の判定ではSPFかDKIMのどちらか一方のアラインでDMARCはpassしますが、送信側の要件と実際の受信では、両方のアラインが求められます。
p=rejectを目指すのであれば、すべての送信元で、SPFとDKIMの両方のアライメントを満たしてください。

MailDataでは、DMARCレポートの分析を通じて、送信元ごとのSPF・DKIMのアライメント状況を洗い出し、p=rejectへの移行を支援しています。
アライメントが一致していない送信元の特定や対策でお困りの場合は、お問い合わせフォームからご相談ください。