DMARC アライメント検証と修正

DMARC アライメントは見落とされがちです。SPF、DKIM、DMARC を公開しても、メールが迷惑メール扱いや拒否になる場合があります。ビジネスメールのガイドで扱う全体設定に加え、実際の送信経路の検証が必要です。

認証成功だけでは足りません。SPF または DKIM の少なくとも一方が成功し、そのドメインが表示上の From とのアライメントを満たす必要があります。それがなければ DMARC は失敗しますが、なりすましの証拠とは限りません。配信基盤、CRM、サポート、転送、不完全な DNS などで不一致が起こります。

ここでは仕組み、SPF の限界、受信した重要なヘッダーの確認方法を説明します。転送には検証済みのアライメントを満たす DKIM が役立ちますが、どの中継でも保持される保証はありません。

DMARC アライメントとは

SPF または DKIM で認証したドメインが、見える From と対応するかを確認します。少なくとも一方が認証成功とアライメントを同時に満たせば DMARC は成功します。その経路がなければ失敗します。

これは RFC 7489 の規則です。DMARC は SPF と DKIM を使い、独立した認証を追加するのではなく、成功した認証と利用者に見える From の関係を確認します。

各検証の対象を整理します。

検証	受信側が確認する対象	DMARC で対応が必要なドメイン
SPF	エンベロープ送信者 / Return-Path ドメインによる送信 IP の許可	Return-Path が From とアライメントを満たす
DKIM	署名の有効性と d= ドメイン	d= が From とアライメントを満たす
DMARC	認証成功とアライメント	上記の少なくとも一方が同時に両条件を満たす

SPF pass や DKIM pass だけでは十分ではありません。成功した一方が From と対応する必要があります。本文の安全性や受信箱への配信を証明するものではありません。

DMARC pass = (SPF pass + SPF aligned) OR (DKIM pass + DKIM aligned)

SPF が成功してもアライメントを満たさない理由

Return-Path が提供元のドメインなら、SPF はそのドメインで成功しても自社の From に対応しない場合があります。ただし DKIM が成功しアライメントを満たせば、DMARC は成功します。

配信プラットフォームにはバウンス処理や送信イベント管理が必要なため、構成によっては自身の Return-Path ドメインを使います。

表示上の From：billing@example.com
Return-Path：bounces+123@sendgrid.net

SendGrid が sendgrid.net について送信 IP を許可していれば SPF は成功し得ます。しかし sendgrid.net は example.com に対応せず、この SPF 経路はアライメントを満たしません。別の成功した対応経路があれば DMARC は成功できます。

独自バウンスドメインや custom Return-Path は SPF アライメントに役立つ場合があります。リンクのブランド化やトラッキングドメインだけでエンベロープが変わるわけではなく、実際の機能を確認します。

bounces.example.com.   CNAME   u1234.wl.sendgrid.net.

提供元で設定し有効化すると、送信者が bounces.example.com をエンベロープに使える場合があります。緩和モードでは example.com に対応します。CNAME だけでは送信設定は自動的に有効にならず、実際のメールで確認します。

転送にも限界があります。受信側が確認するのは元の送信 IP ではなく転送サーバーの IP なので、SPF が失敗し得ます。ドメインメールの Gmail 転送とメールエイリアスの転送も参考になります。SPF は有用ですが、全転送経路を支えるものではありません。

アライメントを満たす DKIM が役立つ理由

転送後も DKIM が成功するには、署名が有効で From とのアライメントを満たし、署名対象のデータが正規化規則のもとで保持される必要があります。本文や署名したヘッダーの変更は検証に影響し得ます。

そのため、アライメントを満たす DKIM の設定とテストを推奨します。ただし SPF が成功してアライメントを満たせば、DMARC に DKIM は必須ではありません。提供元自身のドメインの署名では自社の対応関係は自動的に得られません。

表示上の From：newsletter@example.com
DKIM 署名：d=mailchimpapp.net

DKIM が成功しても From に対応しない場合があります。成功してアライメントを満たす SPF もなければ、DMARC は失敗します。

実際の送信プラットフォームでドメイン認証を設定します。提供された DKIM レコードを公開し、提供元でドメインを有効化して、実メールがそのドメインで署名されるか確認します。

s1._domainkey.example.com.   CNAME   s1.domainkey.u1234.vendor.net.
s2._domainkey.example.com.   CNAME   s2.domainkey.u1234.vendor.net.

適切に有効化されれば、d=example.com や緩和モードで対応する d=mail.example.com などを使います。有効でアライメントを満たす署名なら、転送で SPF が失敗しても DMARC の成功を支えます。

Google が説明する一括送信者の要件は、成功した SPF または DKIM による From アライメントを求めます。適用条件を確認してください。不一致は制限につながり得ますが、迷惑メール扱いや拒否の唯一の原因ではありません。

緩和アライメントと厳密アライメント

緩和モードでは組織ドメインが同じかを比較し、厳密モードでは完全一致が必要です。緩和が既定値ですが、実際の送信経路と要件に応じて選択します。全環境の唯一の正解ではありません。

SPF は aspf、DKIM は adkim で指定します。

モード	対応するとみなす条件	運用への影響
緩和	`mail.example.com` は `example.com` に対応する	同じ組織ドメインの適切なサブドメインを利用できる
厳密	ドメインの完全一致のみ	異なる正規の送信ドメインは調整が必要になる

例です。

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

厳密モードは意図して検証します。アプリが mail.example.com で署名し、From が example.com なら、この DKIM 経路は厳密アライメントを満たしません。

明確な目的があり全送信元をテストできる場合に厳密モードを選びます。他の環境では緩和が合う場合がありますが、認証成功が自動的に得られるわけではありません。

DMARC アライメントの調査方法

信頼できる受信サーバー自身の結果を確認します。Authentication-Results、DKIM d=、SPF smtp.mailfrom、header.from に関係する dmarc が対象です。任意の添付ヘッダーは偽造され得るため、無条件に信用しません。

受信側の結果と実際の署名を合わせると、使ったドメインが分かります。送信側の画面だけでは個別メールの経路を確認できません。

Authentication-Results: mx.google.com;
  dkim=pass header.i=@sendgrid.net header.s=s1;
  spf=pass smtp.mailfrom=bounces+123@sendgrid.net;
  dmarc=fail header.from=example.com

次の順序で確認します。

header.from を確認します。DMARC が使う表示上のドメインです。
smtp.mailfrom の SPF ドメインを確認します。異なる組織ドメインでは SPF アライメントを満たしません。
header.i を決定的な署名ドメインとみなしません。DMARC の基準は検証に成功した DKIM 署名の d= です。
SPF と DKIM のどちらも認証成功と From アライメントを満たさなければ、他のドメインで成功しても DMARC は失敗します。

DNS も補助的に検索できます。

dig +short TXT _dmarc.example.com
dig +short TXT example.com
dig +short CNAME s1._domainkey.example.com

転送後だけの SPF 失敗は新しいサーバーによる場合があります。有効でアライメントを満たす DKIM が DMARC を成功させ得ますが、具体的な署名を調べます。ARC はローカルな例外を助ける場合があり、DMARC 失敗を本来の成功に変えるものではありません。

ドメインの構築には TrekMail のドメイン設定ガイドと独自ドメインメールの作成方法が参考になります。実際のエンベロープドメインの有効な SPF、稼働する DKIM、正しい DMARC が必要です。MX は検証した切り替え計画のもとで変更します。

よくあるアライメント失敗の原因

外部送信者、転送、異なるサブドメイン、重複や古い DNS は調査が必要な要因です。実際の送信で影響を確認します。

主なパターンは次のとおりです。

マーケティング基盤が自身のバウンスドメインを使う。SPF が成功しても対応しないが、DKIM で DMARC が成功し得る。
提供元が自身のドメインで署名する。DKIM は対応しないが、成功してアライメントを満たす SPF があれば足りる。
転送で SPF が失敗する。有効でアライメントを満たす DKIM が残る成功経路になり得る。
意図せず厳密モードにして異なるサブドメインを除外する。
古い DNS が現在の設定に合わない。ただし実際の署名プラットフォームは自動的に変わらないので、送信とルーティングを別に確認する。

4.7.32 が From と SPF または DKIM の不一致を明示する場合は、その認証関係を調べます。適用条件は Google の送信者 FAQにあります。他の配信問題には追加の原因もあり得ます。

TrekMail でアライメントを確認する

TrekMail はメールボックス、DNS 状態、送信設定を集約でき、五つの管理画面を行き来する手間を減らす助けになります。ただし適切なレコードと実メールの検証は必要です。

運用の例です。

分散した管理と共通の作業

分散した管理	TrekMail で可能な作業
メールボックス、送信、DNS を別々に管理する	ドメイン、メールボックス、SMTP 選択、DNS 検査をまとめる
提供元の SPF と DKIM を個別に照合する	ウィザードと DNS 検査を使い、その後にメールをテストする
転送と苦情を別々に調べる	対応する DKIM と記録した転送テストを組み合わせる

管理された SMTP は該当する有料プランで利用できます。独自 SMTP ではプランに応じて SES、SendGrid、Mailgun などを接続できる場合があります。最新条件と実送信を確認します。正常な DNS 表示だけでは全送信元のアライメントは証明できません。

参考になる TrekMail の資料です。

メールが迷惑メールに入る場合の FAQは転送も扱います。IMAP と SMTP の設定はクライアント接続を説明します。クライアントログインとドメイン認証は別の検証です。

Starter の価格目安は月額 $3.50 です。提供される有料プランの 14 日間試用にはクレジットカードが必要です。Nano には独自 SMTP の無料オプションがあり、最大 10 ドメインと 5 GB の共有容量を扱えます。現在の機能、上限、条件は TrekMail の料金で確認します。IMAP 移行はメールをコピーし、MX やアプリの全面的な切り替えは別に計画します。