ヘッダー From（Header From）
概要
ヘッダー From（Header From） は、RFC 5322 で定義されるメッセージヘッダーの From: フィールドで、メールクライアント（Gmail、Outlook 等）に「送信者」として表示されるアドレスです。DMARC はこのヘッダー From のドメインを基準として、SPF と DKIM のアライメントを検証します。
SPF が検証するのは SMTP の MAIL FROM（Envelope From）であり、ヘッダー From は検証しません。このため、Envelope From と Header From を異なるドメインに設定するだけで SPF を pass しながらヘッダー From をなりすませるという問題が、DMARC 導入前は存在しました。DMARC がアライメントを要件化することで、ヘッダー From ドメインを実質的になりすまし防止の基準にしています。
仕組み
SMTP 通信では、DATA コマンドで送信するメッセージヘッダーの一部として From: が含まれます。
From: "Sender Name" <sender@example.com>
To: recipient@example.net
Subject: Test Emailこの From: フィールドがヘッダー From です。SMTP 通信自体（MAIL FROM コマンド）とは独立しており、受信サーバーは SMTP レベルでヘッダー From の内容を検証しません。
DMARC によるアライメント検証
DMARC はヘッダー From のドメインと、SPF または DKIM の認証ドメインを照合します。
SPF アライメント
MAIL FROM（Envelope From）のドメインとヘッダー From のドメインを比較します。relaxed モード（デフォルト）では組織ドメインレベルで一致していれば pass です。strict モード（aspf=s）では完全一致が必要です。
DKIM アライメント
DKIM-Signature ヘッダーの d= タグのドメインとヘッダー From のドメインを比較します。relaxed モード（デフォルト）では組織ドメインレベルで一致していれば pass です。strict モード（adkim=s）では完全一致が必要です。
SPF アライメントまたは DKIM アライメントのどちらかが pass し、かつその認証自体も pass であれば DMARC は pass です。
Display Name なりすましとの違い
Header From とは別に、Display Name（表示名）のなりすましがあります。
From: "Amazon.co.jp" <attacker@evil.example>この場合、ヘッダー From のドメインは evil.example なので DMARC 検証には evil.example のポリシーが参照されます。evil.example が DMARC を設定していなければ（または p=none であれば）、ポリシーによる拒否は行われません。Display Name なりすましはメールクライアントが視覚的に判断する問題であり、DMARC だけでは防げません。BIMI はヘッダー From のドメインが DMARC p=quarantine 以上のときにロゴを表示することで、視覚的な正当性の補強を行います。
設定例
ヘッダー From に自社ドメインを設定し、DKIM 署名の d= タグと組織ドメインを一致させることで DMARC アライメントを成立させます。
ヘッダー From の指定
正規のメール送信であれば、ヘッダー From は自社ドメインを使います。
From: "Company Name" <info@example.com>
To: customer@example.net
Subject: NewsletterDKIM 署名との整合
DMARC アライメントのために、DKIM 署名の d= タグもヘッダー From と同じ組織ドメインにします。
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; ...メール配信サービスを使う場合、サービス側のドメインで DKIM 署名されることがあります。その場合はカスタムドメインの DKIM 設定を行い、d=example.com のように自社ドメインで署名します。
確認方法
受信したメールのヘッダー From を確認するには、メールのヘッダー情報を表示します。Gmail では「その他のオプション」→「メッセージのソースを表示」から確認できます。
From: "Company Name" <info@example.com>自社ドメインに 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"p= タグでポリシー、aspf= や adkim= タグでアライメントモードを確認します。
外部の視点からも確認したい場合は、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 レコードの内容が返ります。data.dmarc.exists が true であれば外部から DMARC レコードが確認できる状態です。
よくある問題
ヘッダー From に関するトラブルは、Envelope From とのドメイン不一致やアライメントモードの設定ミスに集中しています。
ヘッダー From と Envelope From のドメインを無意識に分けてしまう
SaaS のメール送信サービス（SendGrid、Mailchimp 等）を導入すると、デフォルト設定では Envelope From がサービス側のドメインになり、ヘッダー From だけ自社ドメインになることがあります。この状態では SPF アライメントが fail です。DKIM アライメントが pass していれば DMARC は通過しますが、DKIM を設定していない場合は DMARC fail になります。
各サービスのカスタムドメイン設定ドキュメントに従い、DKIM 署名を自社ドメインで行うか、Envelope From を自社ドメイン配下にします。
p=reject の環境でヘッダー From のドメインを変更する
ヘッダー From のドメインを新しいドメインに変更する際、新ドメインに SPF / DKIM / DMARC が設定されていないと、メールが拒否または迷惑メール扱いになります。ドメイン変更前に新ドメインでの認証設定を完了し、DMARC を p=none でモニタリングしてから p=reject に移行します。
アライメントモードを strict に設定してサブドメインを見落とす
aspf=s または adkim=s で strict モードを指定すると、mail.example.com で送信した場合に example.com とのアライメントが fail します。サブドメインから送信するサービスがある場合は relaxed（デフォルト）のままにするか、送信サブドメインそれぞれに DMARC を設定します。strict モードは、フィッシング対策として厳格な管理が必要な場合に限定します。
DMARC レポートでヘッダー From のなりすましを検知しない
rua で集計レポートを受け取ると、自社ドメインをヘッダー From に使ったメールの認証結果が確認できます。認証 pass の中に見覚えのない送信元 IP が含まれている場合、正規でない送信者が自社ドメインを Envelope From に使っている可能性があります。定期的なレポート確認と送信元 IP の棚卸しを行います。