【ITニュース解説】DMARC fails even though SPF and DKIM pass: how alignment actually works

メールの送受信において、その信頼性を保証するための技術がDMARC、SPF、DKIMである。これらの技術は、送信元が偽装されていないかを確認し、スパムやフィッシングメールからユーザーを守る役割を果たす。SPF (Sender Policy Framework) は、メールの送信元IPアドレスがそのドメインの正規の送信サーバーのものであるかを確認する。DKIM (DomainKeys Identified Mail) は、メールに電子署名を付与し、送信中に内容が改ざんされていないか、そしてその署名が正しいドメインから発行されたものであるかを確認する。そして、DMARC (Domain-based Message Authentication, Reporting & Conformance) は、SPFとDKIMの認証結果に基づき、メールの処理方法（受信拒否、隔離、許可など）を指示し、認証結果のレポートを送信者に送る仕組みである。

しかし、SPFとDKIMの両方が「認証を通過（pass）」しているにもかかわらず、DMARCが「認証失敗（fail）」となるケースが存在する。これは、一見するとシステムのバグのように思えるかもしれないが、実はDMARCの重要な仕組みである「アライメント」の理解が鍵となる。DMARCは単にSPFやDKIMが通過したかどうかだけをチェックしているわけではない。DMARCが本当に確認しているのは、「SPFまたはDKIMの認証が、ユーザーがメールソフトで確認する『From:』ヘッダーに表示されるドメインと同じドメインに対して通過したかどうか」という点である。この「同じドメインに対して通過した」状態を「アライメントが取れている」と表現する。

具体的に、アライメントはSPFとDKIMそれぞれに適用される。SPFアライメントでは、メールを実際に送ったサーバーのドメインを示す「エンベロープセンダー（smtp.mailfromまたはReturn-Pathと呼ばれる部分）」のドメインが、メールの「From:」ヘッダーに表示されるドメインと一致する必要がある。例えば、メールのFrom:が「yourdomain.com」である場合、エンベロープセンダーも「yourdomain.com」である必要がある。一方、DKIMアライメントでは、DKIM署名に含まれる「d=ドメイン（署名を行ったドメイン）」が、From:ヘッダーのドメインと一致する必要がある。これらのうち、SPFアライメントかDKIMアライメントのどちらか一方が取れていれば、DMARCは認証を通過（pass）すると判断する。

記事の冒頭で示された例では、spf=pass smtp.mailfrom=bounce.vendor.com、dkim=pass header.d=vendor.com、dmarc=fail header.from=yourdomain.com となっている。ここで注目すべきは、SPFとDKIMは確かに通過しているが、どちらも「vendor.com」というドメインに対するものであり、From:ヘッダーの「yourdomain.com」とは一致していない点である。つまり、SPFアライメントもDKIMアライメントも取れていないため、DMARCは失敗と判断されるのである。

アライメントには「Relaxed（ゆるやか）」と「Strict（厳格）」という二つのモードがある。デフォルトでは「Relaxed」モードが設定されていることが多い（aspf=r; adkim=r）。このモードでは、組織ドメインが一致していればアライメントが取れていると見なされる。例えば、「mail.yourdomain.com」というサブドメインと「yourdomain.com」というルートドメインは、Relaxedモードでは一致すると判断される。しかし、「Strict」モード（aspf=sまたはadkim=s）を設定すると、ドメインが完全に一致している必要がある。このため、Strictモードに設定した場合、サブドメインを使用してメールを送信しているサービスがDMARC認証に失敗し始める可能性がある。

DMARCが失敗する一般的な原因はいくつか考えられる。第一に、サードパーティのメール送信サービス（請求ツール、顧客管理システム、ヘルプデスク、ニュースレター配信プラットフォームなど）を使用している場合である。これらのサービスはデフォルトで、自社のリターンパスとDKIMドメインを使用してメールを送信することが多い。この問題を解決するには、利用しているサービスの管理画面で「カスタムドメイン」や「ドメイン認証」といった設定を有効にし、CNAMEレコードやTXTレコードの追加指示に従って、メールが「d=yourdomain.com」のように自社のドメインで署名されるように設定する必要がある。また、可能であればカスタムリターンパスも自社のドメインに設定すると良い。

第二の原因は、メールが転送されたり、メーリングリストを経由したりする場合である。SPFは、メールが別のサーバーを経由して転送されると、その転送サーバーのIPアドレスが元のドメインのSPFレコードに登録されていないため、認証に失敗してしまう。DKIMも、転送中にメールの本文や件名が変更されると、署名が無効化され認証に失敗する可能性がある。この問題は、特に元のDKIMがアライメントされていた場合に顕著である。このため、SPFだけでなく、アライメントされたDKIMを設定しておくことがより重要となる。

第三の原因として、DKIMセレクタの欠落や鍵のローテーションが挙げられる。DKIM署名は、セレクタという特定の識別子に基づいてドメインのDNSレコードに公開された公開鍵と対になって検証される。もし、この「selector._domainkey.yourdomain.com」という形式の公開鍵レコードが見つからない、あるいは鍵のローテーション後に古いレコードが残っていたり、新しいレコードが正しく公開されていなかったりすると、DKIM認証自体が失敗してしまう。

DMARC認証が失敗している送信元を特定するには、憶測ではなく、DMARC集計レポートを定期的に確認することが最も確実な方法である。DMARCレコードに設定した「rua=アドレス」宛に送られてくるこのレポートには、各送信元IPアドレス、送信メール数、そしてSPF/DKIMの認証結果とアライメント情報が詳細に記載されている。このレポートを分析し、「fail」と表示されており、かつ送信数が多い送信元を特定することで、どのサービスがDMARCの問題を引き起こしているのかを明確に把握し、適切な対策を講じることができる。

DMARCポリシーを導入する際には、全ての正当なメール送信元がアライメントされたDKIMを持っていることを確認するまで、「p=none」（認証失敗時の強制アクションなし）に設定しておくことが推奨される。これにより、正当なメールが誤って拒否されたり隔離されたりするのを防ぐことができる。その後、集計レポートで問題がないことを確認しながら、「pct=」パラメータを用いて、段階的に強制を強化していくのが安全な運用方法である。例えば、「p=quarantine; pct=10」として、まずは10%のメールだけを隔離対象とし、徐々に割合を上げて最終的に100%にする。

DMARCのアライメント設定は、一度行えば終わりというものではない。企業活動において、新しいツールやサービスが導入されるたびに、それがDMARCのアライメントに影響を与える可能性がある。そのため、メールの配信に問題が発生した時だけでなく、定期的にDMARC集計レポートを確認し、アライメントの状態を監視することが重要である。継続的な管理と調整によって、メールの信頼性を維持し、セキュリティを強化することができる。