DKIMドメインアライメント失敗の原因とRFC 5322ヘッダーの修正方法
著者: Yunes Tarada
翻訳: 古川 綾乃
この記事はPowerDMARCのブログ記事 DKIM Domain Alignment Failures – RFC 5322 Fixesの翻訳です。
Spelldataは、PowerDMARCの日本代理店です。
この記事は、PowerDMARCの許可を得て、翻訳しています。
DMARCの判定で「RFC 5322 From」のアライメントが失敗するのは、「From:」ヘッダーのドメインと、DKIM署名の 「d=」で指定されたドメインが一致しない場合です。
DMARCでは、「From:」ヘッダーのドメインが、SPFまたはDKIMのいずれかによって認証されたドメインと一致していることが求められます。
DKIMは、メールが送信途中で改竄されていないことを検証する仕組みです。
DMARCの仕組みでは、DKIMの 「d=」タグによって送信ドメインの正当性も確認されます。
DMARCは、「From:」ヘッダーのドメインが、SPFまたはDKIMで認証されたドメインと一致しているかどうかを検証します。
主なポイント
- RFC 5322のアライメントエラーは、「From:」ヘッダーのドメインがDKIM署名（d=タグ）で指定されたドメインと一致しない場合に発生します。
- SPFのアライメントが失敗している、または設定されていない場合、DMARCに合格するためにはDKIMドメインアライメントが必要です。
- DMARCには、strict（厳格）とrelaxed（緩和）の2つのアライメントモードがあります。
- メールマーケティングツールの利用やメール転送により、RFC 5322におけるDKIMアライメント不一致が発生することがあります。
- 対策としては、まずDKIMの 「d=」と 「From:」のドメインを一致させます。
そのうえで、運用に応じてアライメントモード（strict / relaxed）を選びます。
「From:」をサブドメインにする場合は、サブドメイン用のDKIMキー追加も検討してください。
RFC 5322とは何か
RFC 5322は、「From:」ヘッダーを含むインターネットメールヘッダーの書式を定めた標準仕様です。
DKIMおよびDMARCは、認証の仕組みにおいてこれらのヘッダー情報を利用します。
一方、SPFはRFC 5321に従い、エンベロープ送信者（MAIL FROM）を検証します。
RFC 5322は2008年10月に公開され、現在もインターネットメールのメッセージ形式を定める基本仕様として使われています。
アライメント要件がなければ、攻撃者はあるドメインの有効なSPFやDKIM設定を利用しつつ、別のドメインの「From:」アドレスを詐称することが可能でした。
アライメント要件の導入により、その結果、なりすましは大幅に抑止できるようになりました。
ドメインが一致しない場合、DMARC認証は失敗し、受信側で隔離されたり、拒否されたりする可能性があります。
DKIMドメインアライメントとは何か
DKIMドメインアライメントを説明する前に、まずDKIMの基本を整理します。
DKIMとは何か、そしてどのように機能するか
DKIM（DomainKeys Identified Mail）は、送信ドメインがメールに署名し、受信側が改竄の有無を検証できるようにする認証技術です。
送信時にデジタル署名を付与することで、受信側のメールサーバーが、メールが転送中に改ざんされていないことを確認できるようにします。
メール送信時、送信ドメインは秘密鍵を使ってメッセージにデジタル署名を付与します。
受信側は、DNSに公開されている公開鍵で署名を検証します。
DKIM署名の重要な要素である「d=」タグは、署名に責任を持つドメインを指定します。
このドメインはDKIM署名ヘッダー内に記載されており、受信サーバーはこの情報をもとに公開鍵を取得して署名を検証します。
DMARCにおけるrelaxedアライメントモードとstrictアライメントモードの違い
DMARCのアライメントは、「From:」ヘッダーのドメインが、SPFまたはDKIMで認証されたドメインと一致しているかどうかを確認するための仕組みです。
DMARCには、relaxed（緩和）とstrict（厳格）の2つのアライメントモードがあります。
- Relaxedアライメント（緩和）
- relaxedアライメントでは、「From:」ヘッダーのドメインが、SPFまたはDKIMで認証された組織ドメインと一致していれば合格となります。
このモードは、条件が比較的緩く、特にサブドメイン運用や外部のメール配信サービスを利用する場合に有用です。 - Strictアライメント（厳格）
- strictアライメントでは、「From:」ヘッダーのドメインが、SPFまたはDKIMで認証されたドメインと完全に一致している必要があります。（サブドメインも区別されます）。
| アライメントモード | 「From:」ヘッダー例 | DKIM d=例 | DMARC結果 |
|---|---|---|---|
| Strict | user@example.com | d=example.com | ✅ Pass |
| Strict | user@sub.example.com | d=example.com | ❌ Fail |
| Relaxed | user@sub.example.com | d=example.com | ✅ Pass |
| Relaxed | user@example.com | d=mail.example.com | ✅ Pass（Public Suffix Listに基づき、同一の組織ドメインと判定されるため） |
なぜDKIMおよびRFC 5322のアライメントが重要なのか
DKIMおよびRFC 5322のアライメント要件の主な目的は、送信元ドメインのなりすましを防止することです。
DMARCのアライメント要件
DMARCは、メールの「From:」ヘッダーのドメインが、少なくともDKIM署名のd=タグで指定されたドメインとアライメントしていることを求めます。
strictアライメントでは、ドメインはサブドメインを含めて完全に一致している必要があります。
relaxedアライメントでは、同一の組織ドメインであれば一致とみなされます。
よくある不一致の例
- マーケティングツールの利用
- マーケティングツールでは、user@sub.example.com のようなアドレスからメールを送信しながら、DKIMの d=example.com で署名するケースがあります。
この状態で adkim=s（strict）に設定されていると、DKIMアライメントは失敗します。 - メール転送
- 通常、メール転送はSPFに影響することが多いですが、メッセージ内容が変更された場合（例：メーリングリストによる件名の追記など）には、DKIM署名が無効になることがあります。
なお、「From:」ヘッダーは転送者によって変更されることはほとんどありません。 - 不一致の具体例
- From: support@sub.example.com（RFC 5322ヘッダー）
DKIM-Signature: d=example.com
この場合、strictアライメントではドメインが一致しないため、DMARCは失敗します。
アライメント問題の一般的な原因
アライメント失敗の最も一般的な原因には、以下が含まれます。
- 外部サービスの利用
- ドメインアライメントが適切に設定されていない外部メール配信サービス経由で送信すると、DKIMとRFC 5322のアライメント失敗が発生しやすくなります。
- DKIM設定の誤り
- DKIMレコードやセレクタの設定ミスにより、不一致が発生することがあります。
わずかな設定ミスでも、メール到達率に大きな影響を与える可能性があります。 - ドメインの不整合
- DKIM署名と「From:」ヘッダーで異なるドメインを使用すると、RFC 5322のFromヘッダー不一致が発生します。
この不整合が設定ミスによるものであっても、意図的な構成であっても、結果としてDMARC失敗やメール到達率の低下につながります。
RFC 5322アライメント失敗を診断する方法
RFC 5322（「From:」ヘッダー）とDKIMのアライメント問題を切り分けるための、基本の手順を2つ紹介します。
- RFC 5322アライメント失敗を診断したい場合、まずDMARCレポートを慎重に確認し、「dkim alignment failed」という理由が記載されたエントリを探してください。
- 次に、
DKIMチェッカーやdigコマンドなどのメール認証ツールを使用して、DNSレコードを確認します。
これにより、DKIM署名が正しく公開されており、送信ドメインと一致していることを確認できます。
DKIM–RFC 5322不一致を修正する方法
DKIM（d=）とRFC 5322（From:）の不一致を解消するために、実装しやすい対処をまとめます。
- 1) DKIMドメインとFromドメインを一致させる
- DKIM署名の 「d=」が、「From:」ヘッダーと同じドメインになるように設定します。
この方法は、自社ドメインから直接送信するメールで特に効果的です。 - 2) アライメントモードを設定する
- 要件に合わせてDMARCのアライメントモードを設定します。
DMARCポリシーで、厳密な一致が必要なら adkim=s（strict） サブドメインの運用を許容するなら adkim=r（relaxed） （必要に応じてSPF側の aspf も同様に検討します） - 3) サブドメイン用のDKIMキーを追加する
- 「From:」でサブドメイン（例：sub.example.com）を使う場合は、次のいずれかを行います。
そのサブドメインで署名（d=をサブドメインにする）できるよう、DKIM鍵と設定を用意する。
もしくは、DMARCのアライメントモード（relaxed/strict）を運用に合わせて調整する。 - 4) 元の「From:」ヘッダーを書き換えない
- メールサービスや中継の設定で、「From:」ヘッダーのドメインが意図せず変更されないようにします。
転送やメーリングリストなどでメッセージが変更されると、DKIM署名が壊れ、結果としてDMARCが失敗することがあります。
また、ARC（Authenticated Received Chain）を併用すると、中継時に変更が入った場合でも、受信側がメッセージの正当性を判断するための追加情報（検証材料）を得られることがあります。 - 5) テストと検証を行う
- テストと検証は見落とされがちですが、非常に重要です。
DKIM設定やドメインアライメント、DMARC判定を確認できるツールを使い、DMARCが合格し、意図した受信者に届くことを継続的に確認します。
実務上のポイント
アライメント不一致を防ぐための追加ポイントを紹介します。
- SPFとDKIMのアライメント
- DMARCは、RFC 5322の「From:」ヘッダーに含まれるドメインが、以下のいずれかで認証されたドメインと一致しているかを突き合わせて確認します。
- SPF（RFC 5321のMAIL FROM）
- DKIM（署名のd=タグ）
- ヘッダーを書き換えるタイプの外部メール配信サービスは避ける
- メールヘッダーを改変・書き換える外部のメール配信サービス（ESP）は、可能な限り避けるべきです。
本格導入の前に、そのESPがDMARC運用に適しているか（仕様に準拠しているか）をテストしておくことができます。
これにより、仕様準拠を確保しつつ、配信上のトラブルを防ぎやすくなります。
まとめ
RFC 5322のアライメントエラーは、メールマーケティングツールの利用時やメール転送を行う場合など、さまざまな状況で発生する可能性があります。
主な原因としては、外部サービスの利用、DKIMレコードの設定ミス、ドメインの不整合などが挙げられます。
DMARCレポート解析ツールを利用すると、RFC 5322アライメント失敗を比較的容易に診断できます。
視覚的に整理されたDMARCデータを確認することで、認証上の問題を迅速に特定し、原因を効率的に切り分けることができます。
DMARCレポートの解析や原因特定が難しい場合は、解析ツールの活用もご検討ください。
トライアルをご希望の際は、お気軽にお問い合わせください。