DKIM アライメント（DKIM Alignment）
概要
DKIM アライメント（DKIM Alignment） は、DKIM 署名の d= タグに記載されたドメインと、メールのヘッダー From（RFC5322.From）ドメインが一致するかを DMARC が検証するプロセスです。仕様は RFC 7489 の Section 3.1.1 で定義されています。
DKIM 単体の認証は「署名が有効かどうか」を確認しますが、署名ドメインがヘッダー From と一致するかは検証しません。攻撃者が自身のドメインで正規の DKIM 署名を付与しつつ、ヘッダー From に別組織のドメインを記載すれば、DKIM は pass します。DKIM アライメントはこの隙間を塞ぎます。DMARC レコードの adkim タグで strict（完全一致）または relaxed（組織ドメイン一致）を指定し、デフォルトは relaxed です。
メールに複数の DKIM 署名が付与されている場合、いずれか 1 つの署名がアライメント条件を満たせば DMARC の DKIM アライメントは pass と判定されます。SaaS のメール送信サービスを使う環境では、SPF アライメントが取りづらい構成が多いため、DKIM アライメントが DMARC pass の主要な経路になります。
仕組み
DKIM アライメントには relaxed（組織ドメイン一致）と strict（FQDN 完全一致）の 2 つのモードがあり、DMARC レコードの adkim タグで制御します。
relaxed モード（デフォルト）
adkim=r を指定するか、adkim タグを省略した場合に適用されます。DKIM 署名の d= ドメインとヘッダー From ドメインの組織ドメイン（Organizational Domain）が一致すれば pass です。
組織ドメインは Public Suffix List を基準に判定されます。d=mail.example.com でヘッダー From が @example.com の場合、どちらの組織ドメインも example.com なので pass します。d=example.com でヘッダー From が @news.example.com の場合も同様に pass します。
relaxed モードは、サブドメインごとに DKIM 署名を使い分ける運用に適しています。マーケティングメールを mail.example.com の DKIM 鍵で署名し、ヘッダー From を @example.com にする構成でもアライメントが成立します。
strict モード
adkim=s を指定した場合に適用されます。DKIM 署名の d= ドメインとヘッダー From ドメインの FQDN が完全に一致する必要があります。
d=example.com でヘッダー From が @example.com であれば pass です。d=mail.example.com でヘッダー From が @example.com であれば fail です。サブドメインと親ドメインの差異は許容されません。
strict モードは、送信インフラを自社で完全に管理しており、すべてのメールが同一ドメインの DKIM 鍵で署名される環境でのみ現実的です。
DKIM の正規化モードとの違い
DKIM 署名の c= タグで指定する正規化（canonicalization）にも simple と relaxed がありますが、DKIM アライメントの strict / relaxed とは無関係です。c=relaxed/relaxed はメール本文やヘッダーの空白処理に関する設定であり、ドメイン照合の挙動には影響しません。
複数の DKIM 署名がある場合
1 通のメールに複数の DKIM 署名が含まれることがあります。Amazon SES は独自の d=amazonses.com 署名を自動付与するため、カスタムドメインの署名と合わせて 2 つの DKIM-Signature ヘッダーが付きます。SendGrid も d=sendgrid.net の署名を追加します。
DMARC は全署名を評価し、1 つでもアライメント条件を満たして検証に pass すれば DKIM アライメント pass と判定します。サービス側の署名（d=amazonses.com など）はアライメントに失敗しますが、カスタムドメインの署名（d=example.com）が pass すれば問題ありません。
設定例
DMARC レコードで DKIM アライメントモードを指定します。
relaxed モード（デフォルト）の場合は adkim タグを省略できます。
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"明示的に relaxed を指定する場合は次のようになります。
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; adkim=r; rua=mailto:dmarc@example.com"strict モードに変更する場合は adkim=s を指定します。
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; adkim=s; rua=mailto:dmarc@example.com"strict に変更する前に、rua レポートで現在の DKIM 署名ドメインがヘッダー From ドメインと完全一致しているか確認します。サブドメインで署名しているメールが 1 通でもあれば、strict 移行でそのメールは DKIM アライメント fail になります。
SaaS 送信サービスとの組み合わせ
SendGrid でカスタムドメインの DKIM 署名を設定すると、d=example.com で署名されます。ヘッダー From が @example.com であれば、relaxed でも strict でもアライメントが成立します。
Amazon SES の Easy DKIM を使う場合、カスタムドメインを設定すると d=example.com で署名されます。SES が自動付与する d=amazonses.com の署名はアライメントに失敗しますが、カスタムドメインの署名が pass すれば DMARC は通過します。
確認方法
DMARC レコードの adkim タグを dig で確認します。
dig TXT _dmarc.example.com;; ANSWER SECTION:
_dmarc.example.com. 3600 IN TXT "v=DMARC1;p=reject;sp=reject;adkim=s;aspf=s"レスポンスに adkim=s が含まれていれば strict モード、adkim=r または adkim タグが存在しなければ relaxed モードです。
DKIM 署名の d= タグは、受信したメールのヘッダーで確認します。メールのソースを表示し、DKIM-Signature ヘッダーの d= の値を読み取ります。
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1;
c=relaxed/relaxed; q=dns/txt; h=from:to:subject:date;
bh=abc123...; b=xyz789...d=example.com がヘッダー From のドメインと一致するかを確認します。
外部の視点からも確認したい場合は、Labee Dev Toolbox の Mail Auth API を使うと、外部の視点から見た結果を取得できます。
curl "https://labee.dev/api/mail-auth?domain=example.com"{
"success": true,
"data": {
"spf": { "record": "v=spf1 include:_spf.google.com ~all", "exists": true },
"dkim": {
"record": "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...",
"exists": true,
"selector": "default"
},
"dmarc": {
"record": "v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:dmarc@example.com",
"exists": true
},
"bimi": { "record": null, "exists": false }
},
"error": null,
"meta": { "responseTime": 123 }
}data.dmarc.record フィールドで DMARC レコード全体を確認できます。レコード内の adkim= の有無と値で、現在のアライメントモードを把握できます。data.dkim.exists と data.dkim.record で DKIM レコードの存在と内容も同時に確認できます。
よくある問題
DKIM アライメントの失敗は SaaS 送信サービスの初期設定やモード変更時に集中して発生します。
SaaS サービスのデフォルト署名でアライメントが取れない
SaaS のメール送信サービスを導入した直後は、サービス側のドメイン（d=sendgrid.net、d=amazonses.com など）で DKIM 署名が行われます。この署名はヘッダー From のドメインとは異なるため、DKIM アライメントが fail します。
対処法は、各サービスのカスタムドメイン DKIM 設定を行うことです。SendGrid であれば Domain Authentication、Amazon SES であれば Easy DKIM のカスタムドメイン設定を有効にします。設定後、d=example.com で署名されるようになり、アライメントが成立します。
strict モードへの移行で正規メールが拒否される
relaxed モードで運用中にサブドメインの DKIM 署名（d=mail.example.com）を使っている送信経路がある場合、adkim=s に切り替えるとその経路の DKIM アライメントが fail します。SPF アライメントも同時に fail していると、DMARC 全体が fail になります。
移行前に rua レポートを最低 2 週間確認し、全送信経路の DKIM 署名ドメインがヘッダー From と完全一致しているかを検証します。一致しない経路がある場合は、署名ドメインをヘッダー From と揃えてから移行します。
転送メールで DKIM アライメントが崩れる
メーリングリストや転送サービスが本文にフッターを追加すると DKIM 署名が壊れ、DKIM 自体が fail します。アライメント以前に DKIM pass しないため、DKIM アライメントも成立しません。
この場合、SPF アライメントが通れば DMARC は pass します。ただし転送時にはエンベロープ From も書き換わることが多く、SPF アライメントも取れないケースがあります。転送メールの認証問題に対しては ARC（Authenticated Received Chain、RFC 8617）が策定されていますが、受信側のサポート状況に依存します。
adkim と aspf を混同する
adkim は DKIM アライメントモード、aspf は SPF アライメントモードです。片方だけ strict にして片方を relaxed のままにすることも可能です。意図しないアライメント fail を避けるため、変更時は rua レポートで SPF と DKIM の両方のアライメント状況を確認します。
p=none 運用中にアライメント fail を放置する
p=none ではアライメントが fail してもメール配信に影響しないため、問題が見えにくい状態です。アライメント fail を放置したまま p=quarantine や p=reject に移行すると、正規メールが迷惑メールフォルダ行きまたは拒否されます。p=none の段階で rua レポートを定期的に確認し、すべての正規送信経路で DKIM アライメントが pass しているかを把握しておきます。