DMARCアライメントとは？SPF・DKIMとの関係や設定方法、失敗原因と対策を解説

メールのセキュリティ対策として「SPFを設定した」「DKIMも導入した」にもかかわらず、DMARC認証に失敗してメールが迷惑メールフォルダに入ってしまう。そんな経験はないでしょうか。実は、SPFやDKIMの認証が技術的にPassしていても、DMARCアライメントが成立していなければ、DMARC認証全体としてはFailと判定されてしまいます。アライメントとは、メールに表示される送信元アドレス（ヘッダFrom）と、SPF・DKIMで認証されたドメインの「一致性」を確認する仕組みです。

2024年2月にGoogleが施行した送信者ガイドラインの強化により、1日5,000通以上のメールを送信する企業にはDMARC対応が求められるようになりました。しかし、DMARCレコードを設定しただけでは不十分で、アライメントの仕組みを正しく理解していなければ、正当なメールまでブロックされるリスクがあります。

この記事では、DMARCアライメントの基本から、SPFアライメント・DKIMアライメントそれぞれの仕組み、relaxedモードとstrictモードの違い、よくある失敗パターンと具体的な対処法までを体系的に解説します。

DMARCアライメントとは？基本概念をわかりやすく解説

DMARCアライメントとは、メールの「ヘッダFrom」ドメインと、SPFやDKIMで認証されたドメインが一致しているかを確認するプロセスです。英語の「Alignment」は「整合性」や「一致」を意味し、日本語の翻訳では「調整」と表記されるケースもあります。

DMARCにおけるアライメントの役割

DMARCは、SPFとDKIMという2つの既存認証技術の上に構築されたフレームワークです。しかし、SPFやDKIM単体では、受信者がメールソフト上で確認する「送信元アドレス（ヘッダFrom）」の正当性を直接検証できないという弱点があります。

メールには、受信者に表示される「ヘッダFrom」と、メールサーバー間の通信で使用される「エンベロープFrom（Return-Path）」という2つの送信元情報があります。ヘッダFromは送信者が自由に設定できるため、悪意のある第三者が正規のドメインを詐称する「なりすまし」が可能です。SPF認証はエンベロープFromのドメインを検証し、DKIM認証は電子署名のドメイン（d=タグ）を検証しますが、いずれもヘッダFromとの照合は行いません。そのため、SPFやDKIMが技術的にPassしていても、ヘッダFromが正規のドメインと無関係なケースが起こり得ます。

DMARCアライメントは、この「抜け穴」を塞ぐ仕組みです。SPFまたはDKIMで認証されたドメインと、ヘッダFromのドメインが一致するかを確認することで、受信者に表示される送信元が偽装されていないかを検証します。

DMARC認証がPassする条件

DMARC認証がPassするためには、以下のいずれかの条件を満たす必要があります。

重要なのは、SPFとDKIMの両方がPassする必要はなく、どちらか一方の認証とアライメントがPassしていれば、DMARC認証全体としてPassとなる点です。ただし、認証だけがPassしてアライメントがFailの場合は、DMARC認証としてはFailになります。

たとえば、SPF認証がPass・DKIMも認証がPassしていても、SPFアライメントとDKIMアライメントの両方がFailであれば、DMARC認証はFailです。この点が見落とされがちな落とし穴となっています。

上記の表で特に注意すべきはパターン4です。SPF・DKIMともに認証自体はPassしているにもかかわらず、アライメントが両方ともFailのためDMARC認証が失敗しています。

SPFアライメントの仕組みと成立条件

SPFアライメントは、ヘッダFromのドメインと、SPF認証で検証されるエンベロープFrom（Return-Path）のドメインが一致するかを確認する仕組みです。

エンベロープFromとヘッダFromの関係

メールの仕組みを手紙に例えると、エンベロープFromは封筒に記載された差出人住所、ヘッダFromは便箋に記載された差出人名にあたります。封筒の差出人と便箋の差出人が一致していれば信頼できますが、一致していなければ不審に感じます。SPFアライメントは、まさにこの「一致」を確認する仕組みです。

具体的には、SPF認証はエンベロープFromのドメインに対して行われます。DNSのSPFレコードに記載されたIPアドレスから送信されているかを確認するのがSPF認証で、そのエンベロープFromのドメインとヘッダFromのドメインが一致するかをチェックするのがSPFアライメントです。

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

外部のメール配信サービスを利用している場合、SPFアライメントが失敗するケースがよくあります。

たとえば、自社ドメインが「example.com」で、メール配信サービスのドメインが「mail-service.com」の場合を考えます。メール配信サービスのサーバーから送信するため、エンベロープFromは「bounce@mail-service.com」のようにサービス提供元のドメインが設定されます。一方、受信者に表示されるヘッダFromは「info@example.com」のまま。この場合、エンベロープFromのドメイン（mail-service.com）とヘッダFromのドメイン（example.com）が一致しないため、SPFアライメントはFailとなります。

この問題を解決するには、メール配信サービス側でカスタムReturn-Pathの設定を行い、エンベロープFromのドメインを自社ドメイン（またはサブドメイン）に変更する必要があります。多くのメール配信サービスでは、この設定をCNAMEレコードの追加で対応しています。

SPFアライメントの注意点：メール転送

メール転送は、SPFアライメントにとって大きなリスク要因です。メールが転送されると、転送サーバーのIPアドレスが元のSPFレコードに含まれていないため、SPF認証自体がFailする場合があります。このため、SPFアライメントのみに依存するのではなく、DKIMアライメントと併用することが推奨されています。

DKIMアライメントの仕組みと成立条件

DKIMアライメントは、ヘッダFromのドメインと、DKIM署名のドメイン（d=タグの値）が一致するかを確認する仕組みです。

DKIM署名ドメインとは

DKIMは、送信メールに電子署名を付与し、受信側がその署名をDNSの公開鍵で検証することで、送信元の正当性とメッセージの改ざん有無を確認する技術です。DKIM署名には「d=」タグでドメインが指定されており、DKIMアライメントではこのd=タグのドメインとヘッダFromのドメインの一致を検証します。

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

SPFアライメントと同様に、外部のメール配信サービスを使用している場合にDKIMアライメントが失敗するケースがあります。

メール配信サービスがデフォルトで自社（サービス提供元）のドメインでDKIM署名を行っている場合、d=タグには「mail-service.com」のようなドメインが設定されます。しかし、ヘッダFromが「example.com」であれば、ドメインが不一致となりDKIMアライメントはFailです。

この問題を解決するには、メール配信サービス側でカスタムDKIM署名の設定を行い、自社ドメインの秘密鍵・公開鍵ペアを使ったDKIM署名を有効にする必要があります。具体的には、自社ドメインのDNSにDKIM公開鍵レコード（TXTレコード）を追加し、配信サービス側で自社ドメインのd=タグを使用するよう設定します。

DKIMアライメントが推奨される理由

一般的に、DMARCの認証においてはDKIMアライメントの方が推奨されています。理由は以下の通りです。

SPFは送信元IPアドレスに依存するため、メール転送やメーリングリストなど、途中で送信元IPが変わるシナリオではSPF認証自体が壊れてしまいます。一方、DKIMはメッセージヘッダに付与された電子署名に基づくため、メールが転送されても署名が維持されている限り認証が有効です。

もちろん、メーリングリストなどでメッセージ内容が変更される場合はDKIM署名も無効化される可能性がありますが、一般的なメール転送ではDKIMの方が堅牢に機能します。そのため、SPFとDKIM両方のアライメントを正しく設定しておくことが、確実なDMARC認証のための鉄則です。

relaxedモードとstrictモードの違い

DMARCアライメントには、ドメインの一致度合いを判定する「モード」が2種類あります。relaxed（緩和）モードとstrict（厳格）モードです。

relaxedモード（aspf=r / adkim=r）

relaxedモードは、ヘッダFromと認証ドメインの「組織ドメイン（Apex Domain）」が一致していれば、アライメント成立と判定します。つまり、サブドメインを使用していても一致とみなされるのが特徴です。

例：relaxedモードの判定

ヘッダFromが「news@example.com」、エンベロープFromが「bounce@mail.example.com」の場合、組織ドメインはどちらも「example.com」なので、SPFアライメントはPassとなります。

DMARCレコードでモードを指定しない場合、デフォルトではrelaxedモードが適用されます。

strictモード（aspf=s / adkim=s）

strictモードは、ヘッダFromと認証ドメインのFQDN（完全修飾ドメイン名）が完全に一致する必要があります。サブドメインの使用は許容されません。

例：strictモードの判定

ヘッダFromが「news@example.com」、エンベロープFromが「bounce@mail.example.com」の場合、FQDNが「example.com」と「mail.example.com」で異なるため、SPFアライメントはFailとなります。

どちらのモードを選ぶべきか

導入初期や複数の外部メール配信サービスを利用している環境では、まずrelaxedモードで運用を開始し、DMARCレポートを通じてアライメントの状況を確認するのが一般的な手順です。すべての正当な送信元でアライメントが安定的にPassするようになった段階で、strictモードへの移行を検討するのが実務的なアプローチです。

金融機関や官公庁など、高いセキュリティが求められる組織では、strictモードの導入が推奨されます。ただし、strictモードに移行する際は、すべてのメール送信経路（自社サーバー、メール配信サービス、CRM、MAツールなど）でアライメントが確実にPassすることを事前に確認する必要があります。

DMARCレコードの設定方法とアライメントモードの指定

DMARCレコードは、DNSのTXTレコードとして設定します。アライメントモードの指定は、DMARCレコード内のタグで行います。

DMARCレコードの基本構文

DMARCレコードは、対象ドメインのDNSに「_dmarc.ドメイン名」というサブドメインのTXTレコードとして追加します。

基本的なDMARCレコードの例（監視モード）

v=DMARC1; p=none; rua=mailto:dmarc-report@example.com

アライメントモードを指定したDMARCレコードの例

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

主要タグの解説

v=DMARC1：DMARCのバージョンを示す必須タグです。

p=（ポリシー）：DMARC認証に失敗したメールの処理方法を指定します。none（何もしない・監視のみ）、quarantine（隔離・迷惑メールフォルダ行き）、reject（拒否・配信ブロック）の3段階があります。

aspf=：SPFアライメントモードの指定です。「r」はrelaxed、「s」はstrictです。省略時のデフォルトは「r」（relaxed）です。

adkim=：DKIMアライメントモードの指定です。「r」はrelaxed、「s」はstrictです。省略時のデフォルトは「r」（relaxed）です。

rua=：DMARC集計レポート（Aggregateレポート）の送信先メールアドレスです。アライメントの成功・失敗状況を把握するために必ず設定しましょう。

ruf=：DMARCフォレンジックレポート（Failureレポート）の送信先メールアドレスです。認証失敗の詳細情報を取得できますが、対応しているメールプロバイダは限られています。

pct=：DMARCポリシーを適用するメールの割合（パーセンテージ）です。段階的に導入する場合に使用します。

設定の推奨手順

DMARC導入からポリシー強化までの推奨手順は以下の通りです。まず、SPFとDKIMの設定が正しく完了していることを確認します。DMARCはSPFとDKIMの認証結果を基にした技術であるため、前提となるSPF・DKIMの設定が適切でなければ機能しません。

次に、DMARCレコードを「p=none」で設定し、DMARCレポートの受信を開始します。この段階ではメールの配信には影響を与えず、認証状況の可視化のみを行います。レポートを分析し、自社ドメインからの正当なメール送信経路をすべて把握することが重要です。

レポートの分析結果をもとに、すべての正当な送信元でSPF・DKIMのアライメントがPassしている状態を確認できたら、ポリシーを「p=quarantine」に引き上げます。さらに安定運用が確認できたら「p=reject」へ移行するのが理想的なステップです。

DMARCアライメントが失敗するよくある原因と対処法

DMARC認証の失敗原因の多くは、実はアライメントの不一致によるものです。SPFやDKIMの設定ミスだけでなく、運用上の盲点がアライメント失敗を引き起こしているケースが少なくありません。

原因1：外部メール配信サービスのデフォルト設定

多くのメール配信サービスやMAツールは、デフォルトではサービス提供元のドメインでSPF認証やDKIM署名を行っています。この場合、ヘッダFromに自社ドメインを設定していても、エンベロープFromやDKIM署名のドメインがサービス提供元のドメインになるため、アライメントが失敗します。

対処法

メール配信サービスの管理画面から、カスタムReturn-Path（エンベロープFrom）やカスタムDKIM署名の設定を行います。具体的には、自社ドメインのDNSにCNAMEレコードやTXTレコードを追加し、サービス側でドメインの検証を完了させます。

原因2：メール転送による認証の破損

メールが別のアドレスに転送されると、転送サーバーのIPアドレスが送信元SPFレコードに含まれていないため、SPF認証がFailします。また、転送時にメッセージ内容（ヘッダの追加・変更など）が行われると、DKIM署名も無効になる場合があります。

対処法

メール転送によるアライメント失敗を完全に防ぐことは困難ですが、ARC（Authenticated Received Chain）という技術が中継時の認証情報を保持する手段として注目されています。現時点では、DKIMアライメントをしっかり設定しておくことが最も効果的な対策です。

原因3：サブドメインの取り扱いミス

strictモードを使用している環境で、サブドメインからメールを送信した場合にアライメントが失敗するケースがあります。たとえば、ヘッダFromが「news@campaign.example.com」、DKIM署名のd=タグが「example.com」の場合、relaxedモードではPassしますが、strictモードではFailとなります。

対処法

サブドメインからのメール送信がある場合は、relaxedモードの使用を検討するか、サブドメインごとにDKIM署名を設定してFQDNを完全一致させる必要があります。

原因4：複数の送信経路の管理不備

企業では、社内メールサーバー、メール配信サービス、CRM、MAツール、問い合わせフォームの自動返信など、複数のシステムからメールが送信されているケースが一般的です。一部のシステムでSPF・DKIMのアライメント設定が漏れていると、そのシステムから送信されるメールのDMARC認証がFailします。

対処法

DMARCレポート（ruaレポート）を分析し、自社ドメインからメールを送信しているすべての送信元IPアドレスとサービスを特定します。漏れなくSPFレコードへの追加とDKIM署名の設定を行うことが重要です。

原因5：DMARCレコードの構文ミス

DMARCレコード自体に誤った記述があると、正しく評価されない場合があります。よくあるミスとして、タグ間のセミコロンの不足、スペースの不正、無効なタグ値の使用などがあります。

対処法

オンラインのDMARCレコード検証ツール（MXToolbox、DMARC Analyzerなど）を使用して、レコードの構文エラーがないか確認します。

DMARCレポートを活用したアライメント状況の監視

DMARCレポートは、自社ドメインのメール認証状況を把握するための重要な情報源です。アライメントの成功・失敗を継続的に監視することで、問題の早期発見と対処が可能になります。

DMARCレポートの種類

DMARCレポートには、集計レポート（RUAレポート）とフォレンジックレポート（RUFレポート）の2種類があります。

集計レポートは、受信側のメールプロバイダから日次で送信されるXML形式のレポートです。送信元IPアドレスごとの認証結果（SPF・DKIMの認証およびアライメントの成否）、送信通数、DMARCポリシーの適用結果が記載されています。

フォレンジックレポートは、認証に失敗した個別のメールに関する詳細情報です。ただし、プライバシーの観点から対応しているメールプロバイダが限られており、すべてのケースで取得できるわけではありません。

レポートの分析ポイント

DMARCレポートをXML形式のまま読み解くのは現実的ではありません。無料のDMARCレポート分析ツール（DMARC Analyzer、Postmark DMARC、dmarcianなど）を活用して、視覚的に確認できる環境を整えましょう。

分析時に注目すべき主なポイントは、アライメントがFailになっている送信元IPの特定です。不明なIPアドレスからの送信がある場合、なりすましの可能性があります。一方、自社で利用しているメール配信サービスやシステムのIPアドレスでアライメントがFailしている場合は、設定の見直しが必要です。

段階的なポリシー強化のロードマップ

DMARCのポリシーを段階的に強化するロードマップとして、以下のような流れが一般的です。

DMARCアライメントとGmail送信者ガイドラインの関係

2024年2月にGoogleが施行した「メール送信者ガイドライン」は、DMARC対応の重要性を一気に高めました。このガイドラインとアライメントの関係を整理します。

Gmailガイドラインが求めるDMARC対応

Googleは、Gmail宛に1日5,000通以上のメールを送信する送信者に対して、SPF・DKIM・DMARCのすべてを設定することを要件としています。DMARC認証がPassしないメールは、Gmailへの到達率が大幅に低下するリスクがあります。

ガイドラインでは、DMARCポリシーを最低でも「p=none」に設定することが求められていますが、これはあくまで最低要件です。なりすまし対策として本格的にDMARCを活用するには、「p=quarantine」以上のポリシーへの移行が推奨されます。

BIMI対応の前提条件としてのアライメント

BIMI（Brand Indicators for Message Identification）は、DMARC認証に成功したメールに対して、受信トレイに企業のブランドロゴを表示する仕組みです。Gmailでは、BIMIに対応したメールの送信者名の横に青い認証チェックマーク（Verifiedバッジ）が表示されます。

BIMIの導入には、DMARCポリシーが「p=quarantine」以上であることが前提条件です。つまり、BIMIを活用してブランドの信頼性を高めるためには、DMARCアライメントを確実にPassさせた上で、ポリシーを強化する必要があります。

今後、メールを活用したマーケティングにおいて、BIMIによるブランドロゴ表示は受信者の信頼獲得に大きく貢献する要素となるでしょう。そのためにも、DMARCアライメントの正しい設定は不可欠です。

メールの到達率を高めるならメール配信システムを活用する

DMARCアライメントの設定や送信ドメイン認証を適切に行うことは、メールの到達率を向上させるための重要なステップです。しかし、認証技術の設定・管理を自社のリソースだけで行うのは容易ではありません。メール配信システムを活用することで、SPF・DKIM・DMARCの認証に対応した環境を効率的に整備できます。

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

メール配信システムは、送信ドメイン認証の対応だけでなく、メール配信の品質全体を向上させるための基盤として機能します。

これらの機能を自社で一から構築・運用するのは技術的にもコスト的にも大きな負担です。メール配信に特化したシステムを活用することで、本来注力すべきメールコンテンツの質や配信戦略に集中できます。

おすすめのメール配信システム「ブラストメール」

ブラストメール（blastmail）は、15年連続で導入社数シェアNo.1を獲得している国内最大級のメール配信システムです。27,000社以上の導入実績に裏打ちされた高い到達率と、専門知識がなくても直感的に操作できるシンプルな管理画面が最大の特長です。

DMARCアライメントを含む送信ドメイン認証への対応はもちろん、高い配信速度と到達率を両立しており、初めてメール配信を始める企業から大規模配信を行う企業まで幅広く対応しています。まずは無料トライアルで使い勝手を確認してみてください。

公式サイト：シェア1位のメール配信システム「ブラストメール」

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

ブラストエンジン（blastengine）は、SMTPリレーやAPIで既存システムと連携することで、一斉配信やトランザクションメールを簡単に行えるメール配信サービスです。運用・メンテナンスはブラストエンジン側で行うため、常に高いIPレピュテーションを維持し、エンジニアをメールサーバー管理業務から解放します。

DMARCアライメントをはじめとする送信ドメイン認証に標準対応しており、自社システムとの連携によるメール配信基盤の強化を検討しているエンジニアに最適なサービスです。メールアドレス入力のみで無料トライアルが可能ですので、まずは気軽にお試しください。

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

まとめ

DMARCアライメントは、SPF・DKIMの認証結果とヘッダFromドメインの一致性を確認する仕組みであり、DMARC認証をPassするための核心的な要素です。

SPFやDKIMの認証が技術的にPassしていても、アライメントが成立していなければDMARC認証はFailとなります。特に外部メール配信サービスを利用している場合は、カスタムReturn-PathやカスタムDKIM署名の設定が必須です。relaxedモードとstrictモードの違いを理解した上で、自社の環境に適したモードを選択し、DMARCレポートを活用して認証状況を継続的に監視しましょう。

次にやるべき具体的なアクションは以下の3つです。

1. 現状確認： 自社ドメインのDMARCレコードを確認し、レポート受信先（rua）が設定されているか確認する。

2. 送信元の棚卸し： 自社ドメインからメールを送信しているすべてのシステム・サービスをリストアップし、各送信元のSPF・DKIMアライメント状況を確認する。

3. 修正と強化： アライメントがFailしている送信元の設定を修正し、すべてのメールでDMARC認証がPassする状態を確認した上で、ポリシーを段階的に強化する。