識別子アライメント（Identifier Alignment）

概要

識別子アライメント（Identifier Alignment） は、SPF または DKIM が認証したドメインと、メールクライアントに表示されるヘッダー From のドメインが一致するかを DMARC が確認するプロセスです。仕様は RFC 7489（2015年）で定義されています。

SPF はエンベロープ From（SMTP の MAIL FROM）を検証し、DKIM は署名の d= タグのドメインを検証します。しかしどちらも、受信者が実際に目にするヘッダー From との一致は保証しません。攻撃者は SPF が pass するドメインからメールを送りながら、ヘッダー From に正規ドメインを偽装することができます。DMARC はこのギャップをアライメント検証で塞ぎます。

アライメントが成立する条件は「SPF pass かつ SPF アライメント pass」または「DKIM pass かつ DKIM アライメント pass」のどちらか一方を満たすことです。どちらか一方が成立すれば DMARC pass になります。

仕組み

アライメントには SPF アライメントと DKIM アライメントの 2 種類があり、それぞれ relaxed モードと strict モードを選択できます。

SPF アライメント

SPF アライメントは、SPF が pass したドメイン（エンベロープ From のドメイン）と、ヘッダー From のドメインを照合します。

relaxed モード（デフォルト）では、組織ドメインレベルの一致を許容します。エンベロープ From が bounce.example.com、ヘッダー From が news@example.com であれば、どちらも example.com の配下なので SPF アライメントは pass します。

strict モードでは完全一致が必要です。エンベロープ From が bounce.example.com でヘッダー From が example.com であれば、サブドメインと親ドメインで異なるため fail します。DMARC レコードの aspf=s タグで strict を指定します。

DKIM アライメント

DKIM アライメントは、DKIM 署名の d= タグのドメインと、ヘッダー From のドメインを照合します。

relaxed モードでは、d=mail.example.com でヘッダー From が @example.com であれば pass します。strict モードでは d=example.com とヘッダー From のドメインが完全一致する必要があります。DMARC レコードの adkim=s タグで strict を指定します。

なぜ DKIM アライメントが重要か

メール送信サービス（SendGrid、Amazon SES など）を使う場合、SPF が検証するエンベロープ From は送信サービスのドメインになることが多く、SPF アライメントが取れません。この場合、カスタムドメインで DKIM 署名を設定して DKIM アライメントを成立させることが現実的な対応です。SPF と DKIM のいずれか一方のアライメントが成立すれば DMARC pass になるため、DKIM アライメントが実質的なメインの検証経路になります。

設定例

DMARC レコードの aspf タグと adkim タグでアライメントモードを relaxed または strict に指定します。

relaxed モード（デフォルト）

DMARC レコードでアライメントモードを指定します。

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; aspf=r; adkim=r; rua=mailto:dmarc@example.com"

aspf=r は SPF アライメントを relaxed、adkim=r は DKIM アライメントを relaxed に設定します。どちらも省略するとデフォルトで relaxed になります。

strict モード

strict モードで運用する場合は次のようになります。

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; aspf=s; adkim=s; rua=mailto:dmarc@example.com"

strict モードは送信インフラを完全に自社管理している環境でのみ推奨します。SaaS のメール送信サービスを使っている場合、サブドメインが一致しないためにアライメントが fail するリスクがあります。

確認方法

DMARC レコードのアライメント設定は dig で確認できます。

dig TXT _dmarc.example.com

;; ANSWER SECTION:
_dmarc.example.com.	3600	IN	TXT	"v=DMARC1;p=reject;sp=reject;adkim=s;aspf=s"

aspf= と adkim= タグの値を確認します。タグが存在しない場合はデフォルトの relaxed が適用されます。

実際にアライメントが成立しているかは、DMARC の集計レポート（rua で受信する XML）を確認するのが確実です。<spf> および <dkim> の <result> フィールドに加えて、<policy_evaluated> の <spf> と <dkim> フィールドでアライメントの結果を読み取れます。

外部の視点からも確認したい場合は、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; aspf=r; adkim=r; rua=mailto:dmarc@example.com",
      "exists": true
    },
    "bimi": { "record": null, "exists": false }
  },
  "error": null,
  "meta": { "responseTime": 123 }
}

data.dmarc.record フィールドでレコード全体を確認できます。aspf= と adkim= の値でアライメントモードを把握できます。

よくある問題

アライメントのトラブルは、SaaS 送信サービス利用時の SPF 不一致や strict モードの過剰適用、p=none 運用中の見落としに集中しています。

SPF アライメントが取れない

SaaS のメール送信サービス（SendGrid、Mailchimp など）を使う場合、エンベロープ From はサービス側のドメイン（例: em.sendgrid.net）になります。この場合、SPF は pass してもアライメントが取れません。対処法は2通りあります。

1つ目は、送信サービスの指示に従いカスタムドメインのサブドメインを CNAME でサービス側に向ける設定（Custom Return Path / Custom Bounce Domain）です。例えば bounce.example.com をエンベロープ From に設定することで、relaxed モードであれば example.com との組織ドメイン一致が成立します。

2つ目は、DKIM アライメントで代替する方法です。多くの送信サービスはカスタムドメインでの DKIM 署名をサポートしており、d=example.com で署名できます。DMARC は SPF と DKIM のどちらか一方のアライメントが pass すれば全体として pass になります。

strict モードで意図せず fail する

aspf=s を設定すると、メーリングリストや転送サービス経由のメールがアライメント fail になりやすくなります。転送時にエンベロープ From が転送サーバーのドメインに書き換わるためです。アライメントモードを変更する前に、rua レポートで現在の認証状況を十分確認します。

アライメント fail を見落とす

p=none 運用中はアライメントが fail していてもメール配信に影響しないため、問題を発見しにくい状態です。rua に指定したアドレスで集計レポートを定期確認し、<policy_evaluated> の <spf> と <dkim> が pass になっているかを確認します。アライメント fail が続いたまま p=quarantine や p=reject に移行すると、正規メールが拒否されます。