「SPFやDKIMはPassしているのに、DMARCがFailになる」といった経験はないでしょうか。このような場合、原因の一つとして考えられるのが「アライメント」です。
DMARCでは、SPFやDKIMの認証に成功しているかだけでなく、メールのヘッダFromに使用されているドメインと、SPF・DKIMで認証されたドメインが整合しているかも確認します。このドメイン同士の整合性を確認する仕組みが、DMARCのアライメントです。
本記事では、DMARCのアライメントの基礎知識から、SPFアライメント・DKIMアライメントの仕組みと失敗する例、relaxed/strictの違い、アライメント状況の確認方法までわかりやすく解説します。
DMARCの仕組みや設定方法については、以下の記事で詳しく解説しています。
DMARCとは? 仕組み・導入メリット・設定方法・注意点を基礎から解説|ベアメールブログ

目次
DMARCのアライメントとは
DMARCのアライメントとは、メールのヘッダFromに使用されているドメインと、SPFまたはDKIMで認証されたドメインの整合性を確認するものです。
ここでは、アライメントの仕組みと、DMARCでアライメントが必要とされる理由について解説します。
アライメントの仕組み
DMARCでは、SPFとDKIMについて、それぞれ認証結果とアライメントの両方を確認します。
SPFアライメントはヘッダFromのドメインとSPFで認証されたドメインの整合性を、DKIMアライメントはヘッダFromのドメインとDKIMで認証されたドメインの整合性を確認するものです。
メールがDMARC認証にPassするには、以下のいずれかの条件を満たす必要があります。
- SPF認証がPassし、SPFアライメントもPassしている
- DKIM認証がPassし、DKIMアライメントもPassしている
SPFとDKIMのいずれかで認証とアライメントの両方がPassしていれば、もう一方が未導入あるいはFailとなっていても、DMARC認証はPassとなります。(※ただし、RFC9989では、安定したDMARC運用のためにはSPF・DKIMの両方を適切に設定することが推奨されています。)
一方で、SPFとDKIMの認証がどちらもPassしていても、SPFアライメントとDKIMアライメントの両方がFailとなった場合、DMARC認証はFailとなります。
以下の図は、SPF・DKIMの認証結果とアライメント結果によって、DMARCの判定がどのように変わるかを示したものです。

SPFアライメントとDKIMアライメントの仕組みについては、次章以降で詳しく解説します。
DMARCでアライメントが必要な理由
DMARCでアライメントが必要なのは、SPFやDKIMだけでは、受信者に表示される送信元ドメインが正当に使用されているかまで確認できないためです。
メールソフト上で送信元として表示されるメールアドレスは「ヘッダFrom」と呼ばれます。ヘッダFromはメールの送信者が設定できるため、第三者が自分とは無関係のドメインを指定して、正規の送信者になりすますことも可能です。
一方、SPFやDKIMが認証するドメインは、必ずしもヘッダFromのドメインと一致するとは限りません。SPFではMAIL FROM(エンベロープFrom)のドメインを、DKIMではDKIM署名の「d=」タグに指定されたドメインを認証します。
そのため、悪意のある第三者がヘッダFromのドメインに他社のドメインを設定し、自身が管理する別のドメインを使ってSPFやDKIMをPassさせることもできます。この場合、SPFやDKIMの認証結果だけでは、ヘッダFromのドメインが正当に使用されているかを判断できません。

そこでDMARCでは、SPFまたはDKIMで認証されたドメインとヘッダFromのドメインが整合しているかを確認し、ヘッダFromのドメインが正当に使用されているかを検証しています。
エンベロープFromとヘッダFromの違いについては、以下の記事で詳しく解説しています。
エンベロープFromとは? ヘッダFromとの違いや確認方法を解説|ベアメールブログ
SPFアライメントとは
SPFアライメントとは、ヘッダFromのドメインと、SPFで認証されたMAIL FROM(エンベロープFrom)のドメインが整合しているかを確認する仕組みです。
例えば、以下のようなメールの場合を考えてみます。
- ヘッダFrom:user@example.com
- MAIL FROM:bounce@example.com
ヘッダFromとMAIL FROMにはどちらもexample.comが使用されているため、SPF認証がPassしていればSPFアライメントもPassとなります。
SPFアライメントが失敗する例
外部のメール配信サービスなどを利用している場合、ヘッダFromには自社ドメイン、MAIL FROMには配信サービス側のドメインが使用されることがあります。
例えば、以下のようなケースです。
- ヘッダFrom:user@example.com
- MAIL FROM:bounce@mail-service.com
この場合、mail-service.comのSPF認証がPassしていても、ヘッダFromのexample.comとはドメインが整合していないため、SPFアライメントはFailとなります。
SPFアライメントを成立させるには、ヘッダFromのドメインとアライメントするドメインをMAIL FROMに使用します。外部のメール配信サービスを利用している場合は、自社ドメインを使用したMAIL FROMの設定に対応しているかを確認し、必要な設定を行います。
DKIMアライメントとは
DKIMアライメントとは、ヘッダFromのドメインと、DKIM署名の「d=」タグに指定されたドメインが整合しているかを確認する仕組みです。
例えば、以下のようなメールの場合を考えてみます。
- ヘッダFrom:user@example.com
- DKIM署名:d=example.com
ヘッダFromとDKIM署名の「d=」タグにはどちらもexample.comが使用されているため、example.comによるDKIM認証がPassしていれば、DKIMアライメントもPassとなります。
DKIMアライメントが失敗する例
外部のメール配信サービスなどを利用している場合、ヘッダFromには自社ドメイン、DKIM署名には配信サービス側のドメインが使用されることがあります。
例えば、以下のようなケースです。
- ヘッダFrom:user@example.com
- DKIM署名:d=mail-service.com
この場合、mail-service.comによるDKIM認証がPassしていても、ヘッダFromのexample.comとはドメインが整合していないため、DKIMアライメントはFailとなります。
DKIMアライメントを成立させるには、ヘッダFromのドメインとアライメントするドメインを「d=」タグに指定してDKIM署名を行います。外部のメール配信サービスを利用している場合は、自社ドメインを使用したDKIM署名に対応しているかを確認し、必要なDKIM設定を行います。
DMARCのアライメントモード
DMARCのアライメントには、「relaxed(緩和)」と「strict(厳格)」の2つのモードがあります。モードによって、アライメントの判定をどの程度まで厳密に行うかが異なります。
SPFアライメントのモードはDMARCレコードのaspfタグ、DKIMアライメントのモードはadkimタグでそれぞれ指定します。なお、これらのタグを省略した場合は、いずれもrelaxedモードが適用されます。
DMARCのタグの種類やレコードの設定方法については、以下の記事で詳しく解説しています。
DMARCの設定方法は? DMARCレコードの書き方や失敗例も解説|ベアメールブログ
relaxed(緩和)モード
relaxed(緩和)モードは、ヘッダFromのドメインと、SPF・DKIMで認証されたドメインが完全に一致していなくても、同じ組織ドメイン(Organizational Domain)※ に属していればアライメントをPassとするモードです。
例えば、ヘッダFromのドメインがexample.comの場合、SPF・DKIMの認証に使用されたドメインがmail.example.comであっても、同じ組織ドメインに属しているため、relaxedモードではアライメントが成立します。
relaxedモードを指定する場合は、DMARCレコードのaspfとadkimにrを設定します。
v=DMARC1; p=none; aspf=r; adkim=r;
※組織ドメイン(Organizational Domain):サブドメインを含め、同じ管理権限のもとで管理されるドメイン階層のうち、最上位のドメイン。
strict(厳格)モード
strict(厳格)モードは、ヘッダFromのドメインと、SPF・DKIMで認証されたドメインが完全に一致している場合にのみ、アライメントをPassとするモードです。
例えば、ヘッダFromのドメインがexample.comの場合、SPF・DKIMの認証に使用されたドメインもexample.comであれば、strictモードでアライメントが成立します。一方、mail.example.comのようなサブドメインが使用されている場合は、同じ組織ドメインに属していてもアライメントはFailとなります。
strictモードを指定する場合は、DMARCレコードのaspfとadkimにsを設定します。
v=DMARC1; p=none; aspf=s; adkim=s;
relaxedとstrictのどちらを設定すべき?
RFC 9989では、relaxedとstrictのどちらを使用するかはドメイン所有者が選択するものとしたうえで、実際にはほとんどのドメイン所有者にとってrelaxedモードで十分だったと述べられています。
そのため、特別な要件がなければ、まずはデフォルトのrelaxedモードを利用するのが一般的です。relaxedモードでは、ヘッダFromのドメインとSPF・DKIMで認証されたドメインが完全に一致していなくても、同じ組織ドメインに属していればアライメントが成立するため、サブドメインを利用したメール配信にも対応しやすくなります。
一方で、サブドメインの管理を第三者に委任している場合など、意図しないサブドメインから送信されたメールでもrelaxedアライメントが成立する可能性があります。RFC 9989では、このようなケースでは、サブドメインの管理に注意し、必要に応じてstrictモードの利用を検討すべきとされています。
strictモードでは、ヘッダFromのドメインとSPF・DKIMで認証されたドメインの完全一致が求められます。そのため、設定する場合は、自社で利用しているメール配信サービスや送信システムを確認し、正規のメールがアライメントに失敗しないかを事前に確認することが重要です。
参考:RFC Editor「RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) 」
https://www.rfc-editor.org/info/rfc9989/(2026/10/6確認)
DMARCのアライメント状況を確認する方法
DMARCのアライメント状況は、DMARCレポートや専用の分析ツールを利用することで確認できます。
DMARCレポートで確認する
DMARCのアライメント状況は、受信側のメールサーバーから送信されるDMARCレポート(集約レポート)で確認できます。レポートには、送信元ごとのSPF・DKIMの認証結果や、SPF・DKIMのアライメント結果、DMARCの判定結果などが記録されています。
ただし、DMARCレポートはXML形式で提供されるため、そのままでは内容を把握しにくく、複数の送信元について継続的に確認・分析するには手間がかかります。そのため、DMARCレポートを可視化・分析できるツールを利用すると、アライメントの状況を確認しやすくなります。
DMARCレポートの読み方については、以下の記事で詳しく解説しています。
DMARCレポートとは? 設定方法や集計レポートの読み方、分析手順を解説|ベアメールブログ
ベアメール 迷惑メールスコアリングの「DMARC分析機能」で簡単にチェック
ベアメールが提供するメールの正常性診断&モニタリングサービス「迷惑メールスコアリング」では、DMARCレポートを受信・集計し、わかりやすく可視化する「DMARC分析機能」を提供しています。
SPF・DKIMの認証結果やアライメントの状況を集計レポートで確認できるほか、送信元IPアドレスへのタグ付けや、DMARC認証がNGとなる原因をパターン別に確認できる「エラーパターン分析」なども利用可能です。
XML形式のDMARCレポートを一つひとつ確認することなく、どの送信元で認証やアライメントに問題が発生しているのかを把握しやすくなります。
DMARCレポートの可視化・分析を効率的に進めたい方は、ぜひお気軽にお問い合わせください。

まとめ
DMARCでは、SPFやDKIMの認証結果だけでなく、ヘッダFromのドメインと、SPF・DKIMで認証されたドメインが整合しているかを確認します。SPFまたはDKIMのいずれかで、認証とアライメントの両方がPassしていれば、DMARC認証はPassとなります。
SPFやDKIMはPassしているのにDMARCがFailになる場合は、アライメントに問題がないかを確認してみましょう。ベアメールの「迷惑メールスコアリング」では、DMARCレポートを集計・可視化し、SPF・DKIMの認証結果やアライメントの状況を確認できる「DMARC分析機能」を提供しています。DMARCの設定状況や認証結果の確認・分析に、ぜひご活用ください。

記事を探す
- 2026年06月
- 2026年05月
- 2026年04月
- 2026年03月
- 2026年01月
- 2025年12月
- 2025年11月
- 2025年10月
- 2025年09月
- 2025年08月
- 2025年07月
- 2025年06月
- 2025年05月
- 2025年04月
- 2025年03月
- 2025年02月
- 2025年01月
- 2024年12月
- 2024年11月
- 2024年10月
- 2024年09月
- 2024年08月
- 2024年07月
- 2024年06月
- 2024年05月
- 2024年03月
- 2024年02月
- 2024年01月
- 2023年12月
- 2023年11月
- 2023年10月
- 2023年09月
- 2023年06月
- 2023年05月
- 2023年01月
- 2022年12月
- 2022年11月
- 2022年10月
- 2022年09月
- 2022年08月
- 2022年07月
- 2022年06月
- 2022年05月
- 2022年04月
- 2022年03月
- 2022年01月
- 2021年12月
- 2021年11月
- 2021年10月
- 2021年09月
- 2021年08月
- 2021年07月
- 2021年06月
- 2021年05月
- 2021年04月
- 2021年03月
- 2021年02月
- 2021年01月
- 2020年12月
- 2020年11月
- 2020年09月
- 2020年08月
- 2020年06月
- 2020年05月
- 2020年04月
- 2020年02月
- 2020年01月
- 2019年12月
- 2019年11月
- 2019年10月
- 2019年09月
- 2019年08月
- 2019年07月
- 2019年06月
- 2019年05月
- 2019年02月
タグ一覧
- 用語解説 (66)
- HowToガイド (56)
- トラブルシューティング (34)
- メール到達率 (29)
- DMARC (21)
- SMTP (18)
- プロに学ぶ (14)
- Techブログ (13)
- メルマガ (13)
- 迷惑メール/スパム (13)
- DNS設定 (12)
- SPF (12)
- メールサーバー (12)
- メールリレー (11)
- DKIM (10)
- ツール・サービス比較 (9)
- BIMI (8)
- Gmail (8)
- IPレピュテーション (6)
- Postfix (6)
- メールエラー/バウンス (6)
- メールヘッダ (6)
- メール開封率 (6)
- ブラックリスト (3)
- メール配信サービス (3)
- API (2)
- ARC (2)
- Exchange Online (2)
- Outlook (2)
- RFC (2)
- iCloud (1)
- メールマーケティング (1)
- 調査 (1)
