メール送信ドメイン認証 入門 - SPF / DKIM / DMARC でなりすましを止める仕組み

「請求書のご確認をお願いします」という件名で、取引先そっくりのアドレスからメールが届く。差出人欄には確かに見慣れたドメインが表示されている。しかし本文のリンクをクリックすると、偽のログイン画面に飛ばされる。こうしたフィッシングが成立してしまう根本原因は、メールの差出人表示には、もともと本人確認の仕組みがなかったことにあります。

この記事では、メール配送の仕組みと、それを補うために後から積み上げられた送信ドメイン認証（SPF / DKIM / DMARC）を、RFC などの一次ソースを軸に整理します。設定を書き写すだけでは分からない「何を検証しているのか」「なぜ転送で壊れるのか」まで踏み込みます。

メールが届くまでの配送経路

まず、メールがどう運ばれるかを押さえます。登場人物は次のとおりです。

流れにするとこうなります。

宛先サーバーの探し方は DNS の MX レコードです。user@example.jp 宛のメールは、example.jp の MX レコードを引いて得たホストへ届けられます。この解決の仕組みそのものは DNS の仕組み入門で扱っています。送信ドメイン認証はすべて DNS の上に成り立っているので、DNS の理解がそのまま土台になります。

サーバー間の配送プロトコルが SMTP（Simple Mail Transfer Protocol）で、現行の仕様は RFC 5321（2008年10月、Standards Track）です。RFC 821 などを廃止した改訂版にあたります。

エンベロープ From とヘッダ From は別物

送信ドメイン認証を理解するうえで、いちばん重要な前提がこれです。メールには「封筒」と「便箋」に相当する2つの差出人が存在します。

RFC 5321 は、メッセージをエンベロープ（封筒）とコンテンツ（中身）に分けて扱うと定義しています。エンベロープは「エラー通知の宛先となる発信者アドレス」と「1つ以上の受信者アドレス」から構成される、と RFC 5321 は述べています。一方、RFC 5322（Internet Message Format、2008年10月）は本文側のフォーマットを定義しており、「本仕様はメッセージのコンテンツの形式と意味のみを対象とする」「エンベロープ内の情報については規定しない」と明記しています。

実際の SMTP のやり取りを見ると、その二重構造がはっきりします。

S: 220 mx.example.jp ESMTP ready
C: EHLO mail.example.com
S: 250-mx.example.jp
S: 250 STARTTLS
C: MAIL FROM:<bounce-12345@example.com>
S: 250 2.1.0 Ok
C: RCPT TO:<user@example.jp>
S: 250 2.1.5 Ok
C: DATA
S: 354 End data with <CRLF>.<CRLF>
C: From: "サポート窓口" <support@example.com>
C: To: user@example.jp
C: Subject: ご登録ありがとうございます
C:
C: 本文...
C: .
S: 250 2.0.0 Ok: queued

ここで2つの「From」が出てきました。

• エンベロープ From: MAIL FROM コマンドの引数（上の例では bounce-12345@example.com）。RFC 5321 の用語では reverse-path で、配送エラー（バウンス）の返送先です。一般的な用語として RFC5321.MailFrom と呼ばれます
• ヘッダ From: DATA の中の From: ヘッダ（上の例では support@example.com）。RFC 5322 が定義する「メッセージの著者」で、RFC5322.From と呼ばれます

そして受信者のメールソフトが画面に表示するのは、ほぼ常にヘッダ From のほうです。エンベロープ From は普段ユーザーの目に触れません。両者は一致していなくてもよく、メールマガジンなどでは意図的に別ドメインにすることも珍しくありません。

なお RFC 5322 は Sender: ヘッダも定義しており、From に複数のメールボックスが並ぶ場合に「実際に送信した主体」を示すために必須になります。RFC 5322 は、秘書が他人に代わって送るなら秘書のアドレスが Sender、実際の著者が From に入る、という例を挙げています。

なりすましがなぜ成立するのか

RFC 5321 の SMTP には、差出人が本人であることを検証する仕組みが組み込まれていません。RFC 5321 自身、リターンパスの検証は本仕様の対象外であると述べています。つまりプロトコル上は、誰でも任意の MAIL FROM と任意の From: ヘッダを名乗れます。

さらに厄介なのは、攻撃者が最も偽装したいのは「表示されるヘッダ From」のほうだという点です。ここが後述の DMARC の設計動機に直結します。

攻撃者のサーバー (203.0.113.99)
  MAIL FROM: <attacker@evil.example>    <- 攻撃者のドメイン。ユーザーには見えない
  From: "銀行サポート" <support@example.com>  <- 見えるのはこちら。完全に偽装
 
受信者の画面には support@example.com と表示される

この構造上の穴を、あとから DNS を使って塞ごうとしたのが送信ドメイン認証です。3つの技術はそれぞれ別のものを検証します。

SPF も DKIM も、単体ではヘッダ From を守りません。ここを結びつけるのが DMARC の役割です。この順で理解するのが近道です。

SPF: 送信元 IP を認可する

SPF（Sender Policy Framework）の現行仕様は RFC 7208（2014年4月、Standards Track）です。「このドメインの名前でメールを送ってよい IP アドレスはこれだけです」という宣言を DNS に置き、受信側が送信元 IP と突き合わせます。

RFC 7208 は「SPF レコードは DNS の TXT レコード（type 16）としてのみ公開しなければならない（MUST）」と定めています。かつて存在した専用の SPF リソースレコード（type 99）は廃止済みで、本バージョンではサポートされません。

レコードの書き方

example.com.   IN  TXT  "v=spf1 ip4:198.51.100.10 ip4:198.51.100.11 include:_spf.example.net mx -all"

先頭の v=spf1 は必須です。以降は左から順に評価され、最初にマッチしたメカニズムの修飾子（qualifier）が結果になります。

修飾子は4種類で、RFC 7208 は次のように定義しています。省略時は + です。

したがって末尾の書き分けはこう読みます。

• -all: リストにない IP はすべて不正。送信元を完全に把握できているなら、これが最も強い宣言です
• ~all: リストにない IP はおそらく不正。導入初期や、把握しきれていない送信経路が残る場合の安全側の選択です
• ?all: 何も表明しない。実質的に SPF を機能させていない状態です

10ルックアップ制限という落とし穴

SPF で最も事故が多いのがこれです。RFC 7208 のセクション4.6.4は、DNS 問い合わせを発生させる項（include、a、mx、ptr、exists、および redirect 修飾子）について「SPF 実装は SPF 評価中のこれらの項の総数を10に制限しなければならない（MUST）」と定めています。この上限を超えると結果は permerror になり、SPF は事実上機能しません。

厄介なのは、include の先が再帰的にカウントされる点です。SaaS を複数併用していると、自分のレコードには include が3個しか書いていなくても、その先で簡単に10を超えます。

example.com.  IN  TXT  "v=spf1 include:_spf.a-saas.example include:_spf.b-saas.example include:_spf.c-saas.example include:_spf.d-saas.example mx a -all"

さらに RFC 7208 は、応答が0件または NXDOMAIN となるvoid lookup を2回までに制限すべき（SHOULD）とも述べています。使わなくなった SaaS の include を消さずに残しておくと、これに引っかかることがあります。

制限を回避するには、不要な include を削る、a や mx を具体的な ip4 に展開する、といった対応を取ります。設定変更のたびに実際のルックアップ数を数える運用が必要です。

SPF が検証するのはエンベロープ From

RFC 7208 は、SPF が検証する識別子として HELO/EHLO 識別子と MAIL FROM 識別子の2つを挙げています。HELO のチェックを先に行うことが推奨され、結論が出ない場合に MAIL FROM をチェックします。バウンスメールのように MAIL FROM が空（null）の場合は、postmaster と HELO 識別子を組み合わせて評価します。

繰り返しになりますが、SPF はヘッダ From を一切見ていません。SPF が pass でも、ヘッダ From はまったく別のドメインを名乗れます。SPF 単体ではなりすましを止められない理由がここにあります。

DKIM: 電子署名で改ざんと発信元を示す

DKIM（DomainKeys Identified Mail）の現行仕様は RFC 6376（2011年9月、Standards Track。RFC 4871 / 5672 を廃止）です。送信側が秘密鍵でメッセージに署名し、公開鍵を DNS に置いて受信側に検証させます。仕組みそのものは 公開鍵暗号とデジタル署名の応用です。

セレクタと鍵レコード

公開鍵は DNS の TXT レコードとして セレクタ._domainkey.ドメイン という名前に公開します。セレクタ（selector）は、同じドメインで複数の鍵を並行運用するための名前空間の分割です。RFC 6376 は、ドメイン example.com、セレクタ foo なら foo._domainkey.example.com を引く、と定めています。

selector1._domainkey.example.com.  IN  TXT  ( "v=DKIM1; k=rsa; "
  "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...IDAQAB" )

鍵レコードのタグは次のとおりです。

セレクタを使い分けられるおかげで、鍵のローテーションを無停止で行えます。新しいセレクタで鍵を公開し、署名をそちらへ切り替え、旧セレクタで署名したメールが配送されきったころに旧鍵の p= を空にする、という手順です。

DKIM-Signature ヘッダ

署名は DKIM-Signature ヘッダとしてメッセージに付きます。

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=example.com; s=selector1; t=1786000000;
  h=from:to:subject:date:message-id;
  bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
  b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR

主なタグの意味です。

RFC 6376 は「署名者は rsa-sha256 を実装しなければならず（MUST）、これで署名すべき（SHOULD）」としています。正規化（canonicalization）には simple と relaxed があり、simple はほぼ一切の変更を許しません。relaxed はヘッダ名の小文字化や空白の圧縮などを吸収するため、経路上の軽微な書き換えに強くなります。実務では relaxed/relaxed が広く使われます。

鍵長は2048ビットを推奨

鍵長については RFC 8301（2018年1月、Standards Track、RFC 6376 を更新）が現行の基準です。

• 署名者はすべての鍵で1024ビット以上の RSA 鍵を使わなければならない（MUST）
• 署名者は2048ビット以上を使うべき（SHOULD）
• 検証者は1024〜4096ビットの鍵で検証できなければならない
• 検証者は1024ビット未満の鍵による署名を有効とみなしてはならない（MUST NOT）
• rsa-sha1 は署名にも検証にも使ってはならない（MUST NOT）。RFC 8301 はこれを歴史的（historic）に分類しています

新規に鍵を作るなら 2048 ビット RSA が実務上の標準です。なお 2048 ビットの公開鍵は DNS の TXT レコード1文字列の上限（255文字）を超えるため、複数文字列に分割して記述します。先ほどの例で p= を括弧で分けているのはそのためです。

DKIM も単体ではヘッダ From を守らない

DKIM が保証するのは「d= のドメインがこのメッセージに責任を持つ」ことと「署名対象部分が改ざんされていない」ことだけです。d= がヘッダ From と一致している必要はありません。攻撃者は自分のドメイン evil.example で正しく DKIM 署名しつつ、From ヘッダには support@example.com と書けます。DKIM は pass しますが、なりすましは成立しています。

DMARC: 2つをヘッダ From に結びつける

ここで DMARC（Domain-based Message Authentication, Reporting, and Conformance）が登場します。DMARC の役割は3つです。

1. SPF / DKIM の結果をヘッダ From のドメインと結びつける（アライメント）
2. 結びつかなかったメールをどう扱ってほしいかポリシーで表明する
3. 自分のドメインがどう使われているかのレポートを受け取る

2026年5月に Standards Track の RFC になった

長らく DMARC の仕様は RFC 7489（2015年、Informational）でした。IETF の正式な標準ではなく、事業者の運用によって事実上の標準として支えられてきた状態です。

これが 2026年5月に更新されました。RFC 9989（Domain-Based Message Authentication, Reporting, and Conformance (DMARC)）が Standards Track として発行され、RFC 7489 と RFC 9091 を廃止しています。あわせて集約レポートを定める RFC 9990、失敗レポートを定める RFC 9991 も同月に Standards Track として発行されました。

既存の v=DMARC1 レコードはそのまま有効なので、いま動いている設定が突然壊れることはありません。ただし後述のとおり pct タグが廃止されるなど、実務に効く変更が入っています。

アライメント（識別子の整合）

DMARC の核心がアライメントです。RFC 9989 は2つの状態を定義しています。

• relaxed alignment: Author Domain（ヘッダ From のドメイン）と認証された識別子が同じ組織ドメインを持つ
• strict alignment: Author Domain と認証された識別子が完全に一致する

具体例で見ます。

[strict]
MAIL FROM: sender@example.com
From:      sender@example.com        -> 完全一致。strict でも pass
 
[relaxed]
MAIL FROM: sender@child.example.com
From:      sender@example.com        -> 組織ドメインが同じ。relaxed なら pass / strict なら fail
 
[アライメントなし]
MAIL FROM: bounce@sendgrid-like.example
From:      sender@example.com        -> 組織ドメインが異なる。SPF が pass でも DMARC は fail

DKIM 側も同じで、署名の d= とヘッダ From のドメインを比べます。

DMARC が pass するのは、SPF か DKIM の少なくとも一方が pass し、かつその識別子がヘッダ From とアライメントしている場合だけです。両方が必要なわけではありません。逆に言えば、SPF が pass していてもアライメントしていなければ DMARC は fail します。SaaS からメールを送っていて「SPF は通っているのに DMARC が fail する」という相談の大半がこれです。

DMARC レコードのタグ

DMARC レコードは _dmarc.ドメイン の TXT レコードとして公開します。

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; sp=none; adkim=r; aspf=r; fo=1; rua=mailto:dmarc-rua@example.com; ruf=mailto:dmarc-ruf@example.com"

RFC 9989 が定義するタグは次のとおりです。

fo の値は、0 が「すべての機構が失敗したとき」、1 が「いずれかの機構が失敗したとき」、d が DKIM 固有の失敗を含める、s が SPF 固有の失敗を含める、です。診断目的では fo=1 にしておくと情報量が増えます。

ポリシーの3段階

RFC 9989 における各値の定義は、none が「特に希望を表明しない」、quarantine が「疑わしいメールとみなす」、reject が「そのドメインの使用が無効であることの明確な表明」です。

pct タグは廃止、代わりに t=y

RFC 7489 には、ポリシーを適用する割合を指定する pct タグがありました。pct=10 なら10%のメールにだけポリシーを適用する、という段階導入のための仕組みです。

RFC 9989 はこの pct タグを削除しました（Appendix A.6「Removal of the "pct" Tag」）。代わりに用意されたのが t タグ（テストモード）です。t=y を指定すると、受信側は宣言したポリシーを1段階弱めて適用します。つまり p=quarantine; t=y は none として、p=reject; t=y は quarantine として扱われます。

これから段階導入する場合、pct=50 のような書き方ではなく、p=none から始めて p=quarantine; t=y、p=quarantine、p=reject; t=y、p=reject と進めるのが RFC 9989 に沿った形になります。

組織ドメインの決め方は DNS Tree Walk へ

もう1つの大きな変更が、組織ドメインの決定方法です。RFC 7489 は Public Suffix List（PSL）を参照する方法を説明していましたが、どの PSL を使うか、どの頻度で更新するかを規定しておらず、受信者ごとに判定が食い違う相互運用上の問題が指摘されていました。

RFC 9989 はこれを DNS Tree Walk という探索手法に置き換えました。ヘッダ From のドメインから始めて、DMARC レコードが見つかるまでラベルを1つずつ削りながら上位へ問い合わせていきます。乱用による DoS を防ぐため、ラベルが8個を超えるドメインでも DNS 問い合わせが8回を超えないようにするショートカットが組み込まれています。RFC 9989 は、公開時点で観測されたのは最大7ラベルまでだったため、将来の拡張を見込んで8を上限にしたと説明しています。

psd タグはこの探索の途中で「ここは公開サフィックスである」「ここが組織ドメインである」と明示するためのもので、指定があればその時点で探索を止めます。

Authentication-Results ヘッダの読み方

受信側が検証した結果は、RFC 8601（2019年5月、Standards Track、RFC 7601 を廃止）が定義する Authentication-Results ヘッダに記録されます。トラブル調査の起点になるので読めるようにしておきます。

Authentication-Results: mx.example.jp;
  spf=pass smtp.mailfrom=example.com;
  dkim=pass header.d=example.com header.s=selector1;
  dmarc=pass header.from=example.com

Authentication-Results: mx.example.jp;
  spf=pass smtp.mailfrom=bounce.mailer.example;
  dkim=pass header.d=mailer.example header.s=s1;
  dmarc=fail header.from=example.com

下の例では SPF も DKIM も pass していますが、smtp.mailfrom も header.d も header.from の example.com と組織ドメインが違うため、DMARC は fail しています。この形が典型的な設定漏れです。

構文は「authserv-id（検証したサーバーの識別子）」「method=result」「ptype.property=value」からなります。RFC 8601 が定義する結果値は、SPF が pass / fail / softfail / neutral / none / temperror / permerror / policy、DKIM が pass / fail / neutral / none / temperror / permerror / policy です。

レポート: RUA と RUF

DMARC の3つ目の柱がレポートです。導入初期の価値の大半はここにあります。

集約レポート（RUA / RFC 9990）

RFC 9990（DMARC Aggregate Reporting、2026年5月、Standards Track）が定めるのが集約レポートです。受信事業者が、あるドメイン宛の認証結果を集計した XML を、rua に指定した宛先へ送ります。

レポートは feedback をルート要素とする XML で、レポートのメタデータ、公開されていたポリシー、そして1つ以上の record 要素を含みます。各 record には送信元 IP、通数、ポリシー適用結果、識別子、SPF / DKIM の認証結果が入ります。RFC 9990 は、レポート期間は重ならないようにすべき（SHOULD NOT overlap）とし、典型的には 0000 UTC から始まる1 UTC 日を対象とする、と述べています。

<feedback>
  <report_metadata>
    <org_name>receiver.example</org_name>
    <date_range><begin>1786003200</begin><end>1786089600</end></date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain><adkim>r</adkim><aspf>r</aspf><p>none</p>
  </policy_published>
  <record>
    <row>
      <source_ip>198.51.100.10</source_ip><count>128</count>
      <policy_evaluated><disposition>none</disposition><dkim>pass</dkim><spf>pass</spf></policy_evaluated>
    </row>
    <identifiers><header_from>example.com</header_from></identifiers>
  </record>
</feedback>

生の XML を読むのは現実的ではないので、可視化ツールやマネージドサービスに流し込んで、送信元 IP ごとの通数と認証結果を眺めるのが実務です。

失敗レポート（RUF / RFC 9991）

RFC 9991（DMARC Failure Reporting、2026年5月、Standards Track）が定めるのが、個別メッセージ単位の失敗レポートです。ruf タグで送付先を指定し、fo タグで生成条件を制御します。

ただし RFC 9991 はプライバシー上の強い注意を与えています。失敗レポートには個人を識別できる情報（PII）が含まれ得ること、送信者・受信者の識別子や機微な業務情報が露出しうること、未編集のレポートがスパムやフィッシング、マルウェアの内容をそのまま転送してしまう可能性があることを挙げ、レポートの範囲を診断目的に絞り、編集（redaction）を適用して露出を最小化することを勧めています。

実務では、まず rua だけを設定して集約レポートで全体像を把握し、ruf は必要な期間・必要な範囲に限定して使うのが無難です。

BIMI: ロゴを表示させる仕組み

BIMI（Brand Indicators for Message Identification）は、DMARC が有効なドメインからのメールについて、受信箱に送信者のロゴを表示させる仕組みです。default._bimi.ドメイン の TXT レコードに、v=BIMI1、ロゴ SVG の URL を示す l=、証明書の URL を示す a= を書きます。

BIMI Group の実装ガイドによれば、前提条件として組織ドメインとサブドメインで DMARC が enforcement になっていることが必須です。許容されるのは p=quarantine; sp=quarantine または p=reject; sp=reject で、p=none や 100% 未満の pct 値は受け付けられないと明記されています。ロゴは SVG Tiny Portable/Secure 形式である必要があります。VMC（Verified Mark Certificate）や CMC（Common Mark Certificate）は「強く推奨されるが任意」とされる一方、自己表明の BIMI レコードは各メールボックスプロバイダでのサポートが限定的だとも述べられています。

標準化の状況としては、BIMI は2026年8月時点でまだ RFC ではありません。IETF Datatracker 上では個人提出の Internet-Draft（draft-brand-indicators-for-message-identification、最新は2026年5月1日付の revision 14）として Active な状態にあり、ワーキンググループに採択されておらず「IETF 標準化プロセス上の正式な地位を持たない」と記載されています。導入を検討する場合、この点は踏まえておく必要があります。

BIMI を「ロゴが出るマーケティング施策」として捉えると本質を見誤ります。実態はDMARC を reject / quarantine まで運用しきった組織へのご褒美であり、順序としては認証の整備が先です。

実際に確認するコマンド

設定は必ず手元で検証します。まず DNS レコードの確認です。

# MX(宛先サーバー)
dig +short MX example.com
 
# SPF(TXT の中から v=spf1 を探す)
dig +short TXT example.com
 
# DKIM 公開鍵(セレクタを指定)
dig +short TXT selector1._domainkey.example.com
 
# DMARC ポリシー
dig +short TXT _dmarc.example.com

$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=none; rua=mailto:dmarc-rua@example.com; fo=1"

DKIM の秘密鍵と DNS 上の公開鍵が対応しているかは、OpenDKIM 付属の opendkim-testkey で確認できます。

opendkim-testkey -d example.com -s selector1 -k /etc/dkim/selector1.private -vvv

-d は署名するドメイン、-s は取得・テストするセレクタ、-k は秘密鍵ファイルのパス、-v は出力の詳細度を上げる指定です。このツールは DNS から公開鍵を取得して秘密鍵と突き合わせ、あわせて秘密鍵ファイルの権限が緩すぎないかも警告します。

実際にメールを送って認証結果を見るなら swaks が便利です。

swaks --to test@example.jp \
      --from notice@example.com \
      --server mail.example.com --port 587 \
      -tls --auth LOGIN \
      --header "Subject: SPF/DKIM/DMARC test"

-t, --to が宛先、-f, --from がエンベロープ From、-s, --server が接続先サーバー、-p, --port がポート、-tls が STARTTLS の要求、-a, --auth が SMTP 認証、--header が任意ヘッダの追加です。届いたメールの Authentication-Results ヘッダを見て、spf / dkim / dmarc がすべて pass しているかを確認します。なお -tls で要求する STARTTLS は SMTP を TLS で包むもので、TLS 自体の仕組みは TLS 1.3 と HTTPS ハンドシェイクの仕組みを参照してください。

運用の進め方: p=none から段階導入する

いきなり p=reject にすると、自分の正規メールが止まります。次の順序で進めます。

自社ドメインでメールを送っている経路をすべて洗い出します。メールサーバー、業務システムの通知、マーケティングツール、決済サービス、採用管理システム、監視アラート。想像より多いのが普通で、「誰も把握していない古いフォームメーラー」が出てくることもよくあります。

各経路について SPF に送信元を登録し、DKIM 署名を有効にします。このときヘッダ From とアライメントするかを必ず確認します。SaaS 側で独自ドメインの DKIM 署名（d= を自社ドメインにする設定）を有効にできるなら、それが最も確実です。SPF の10ルックアップ制限にも気を配ります。

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-rua@example.com; fo=1"

この状態では受信側の扱いは何も変わりません。数週間から数か月、集約レポートを眺めて「認証が通っていない正規の送信元」を潰していきます。ここを飛ばすと必ず事故ります。

レポート上で正規メールがほぼ 100% pass するようになったら、p=quarantine; t=y、p=quarantine、p=reject; t=y、p=reject と進めます。各段階で数週間はレポートを監視します。サブドメインの扱いは sp、存在しないサブドメインは np で別途制御できます。使っていないサブドメインからのなりすましを防ぐには np=reject が有効です。

保有しているだけでメールを送らないドメインは、最初から拒否を宣言できます。

example-unused.com.        IN  TXT  "v=spf1 -all"
_dmarc.example-unused.com. IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-rua@example.com"

こうした「ドメインの守り方」の考え方は、2026年 日本のセキュリティインシデントまとめで扱ったフィッシング関連の事例とも地続きです。Web 側の防御である Content Security Policy と同様、宣言的なポリシーを DNS に置いて第三者に守らせる、という発想です。

転送とメーリングリストで壊れる問題、そして ARC

DMARC を強めるときに最大の障害になるのが間接的なメール経路です。この問題は RFC 7960（DMARC と間接メールフローの相互運用性の問題、2016年9月、Informational）にまとまっています。

RFC 7960 が挙げる代表的なシナリオです。

転送で SPF が壊れる構図はこうです。

example.com --(送信)--> forwarder.example --(転送)--> 最終受信者
 
最終受信者から見た送信元 IP は forwarder.example のもの。
example.com の SPF にその IP は載っていない -> SPF fail
DKIM が生きていれば DMARC は救われるが、本文が書き換われば DKIM も fail

メーリングリストの多くは、この問題への対処として From ヘッダを書き換える方法を取ります。RFC 7960 も、RFC5322.From をリストのドメインに書き換えるとアライメントを成立させられる一方、DMARC 本来のセキュリティ目的を損ない、返信の挙動も複雑にする、と指摘しています。

ARC: 認証結果の引き継ぎ

この状況を改善するために設計されたのが ARC（Authenticated Received Chain）で、RFC 8617（2019年7月、Experimental）が定義しています。RFC 8617 は ARC を「メッセージに対する認証済みの管理の連鎖（chain of custody）を提供する」ものと説明しています。

中継者は、メールを受け取った時点での認証結果を記録し、署名して次へ渡します。ARC が定義するヘッダは3つです。

各ヘッダには i= タグでインスタンス番号（1〜50）が付き、中継の順序を表します。連鎖の検証状態は cv= で示され、none（先行する連鎖なし）、pass（先行連鎖の検証成功）、fail（検証失敗）の3値を取ります。

最終受信者は、DMARC が fail していても「信頼できる中継者が、その手前では認証が通っていたと証明している」と判断できれば、配送を通す選択ができます。

受信側の要件: Gmail / Yahoo / Outlook.com

送信ドメイン認証が「あったほうがよいもの」から「ないと届かないもの」に変わったのは、大手メールボックスプロバイダが要件を明文化したことが大きな転機でした。

Gmail

Google の「メール送信者のガイドライン」によれば、2024年2月1日から、Gmail アカウント宛にメールを送るすべての送信者に次が求められます。

• 送信ドメインに SPF または DKIM を設定する
• 送信ドメインまたは IP に有効な正引きと逆引き（PTR レコード）を用意する
• メール送信に TLS 接続を使う
• Postmaster Tools 上の迷惑メール率を 0.3% 未満に保つ
• メッセージを RFC 5322 に沿って整形する
• Gmail の From ヘッダを騙らない（Google は Gmail が DMARC の quarantine ポリシーの適用を開始すると述べています）

さらに 1日あたり 5,000 通を超えて Gmail アカウントへ送る送信者には、次が追加されます。

• SPF と DKIM の両方を設定する
• 送信ドメインに DMARC を設定する。ポリシーは none でよいと明記されています
• 直接送信するメールでは、From ヘッダのドメインが SPF ドメインか DKIM ドメインのいずれかとアライメントしていること
• マーケティングメールと購読メールはワンクリック登録解除に対応し、本文にも解除リンクを明示する

迷惑メール率については、ガイドライン中で0.10% 未満に保ち、0.30% 以上には決して到達しないようにすると述べられています。全送信者向けの記述にある 0.3% は「越えてはならない線」、0.10% は「目標」と読むのが妥当です。

ワンクリック登録解除は RFC 8058（Signaling One-Click Functionality for List Email Headers、2017年1月、Standards Track）が定義するものです。次の2つのヘッダを付けます。

List-Unsubscribe-Post: List-Unsubscribe=One-Click
List-Unsubscribe: <https://example.com/unsubscribe/abc123>

RFC 8058 では、List-Unsubscribe-Post の値は List-Unsubscribe=One-Click でなければならず、受信側は List-Unsubscribe の HTTPS URI に対して HTTPS の POST を行い、このキーと値のペアをリクエストボディとして送ります。実装側は POST を受け付けるエンドポイントを用意する必要があります。GET だけの実装では要件を満たしません（HTTP ステータスコードの実践的な使い分けも参考になります）。

Yahoo

Yahoo の送信者向けベストプラクティスは、2024年2月から次の送信基準の適用を開始すると述べています。

• すべての送信者: SPF または DKIM を最低限実装する
• 一括送信者: SPF と DKIM の両方を実装し、最低でも p=none の有効な DMARC ポリシーを公開する
• From ヘッダのドメインが SPF ドメインか DKIM ドメインとアライメントしていること
• ワンクリック登録解除（RFC 8058 の POST 方式）が強く推奨される
• 登録解除は2日以内に反映する
• 迷惑メール率を 0.3% 未満に保つ

なお Yahoo の当該ページ上では、一括送信者を定義する具体的な通数の閾値は確認できませんでした（未確認）。

Outlook.com

Microsoft は 2025年に、Outlook.com / Hotmail.com / Live.com 宛の大量送信者に対する要件を発表しました。Microsoft Tech Community のブログ「Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders」によれば、1日あたり 5,000 通以上を送る送信者に対し、SPF と DKIM の両方が pass すること、DMARC レコードを公開し、SPF または DKIM が 5322.From ドメインとアライメントした状態で DMARC を通過することが求められます。適用開始は 2025年5月5日で、当初は非準拠メールを迷惑メールフォルダへ振り分ける運用とされていました。

その後、非準拠メールを 550 5.7.515 Access denied で拒否する方針に変わったと複数の情報源が伝えていますが、拒否への切り替え時期の正確な確定は未確認です。実務上は「2025年以降、Outlook.com 宛の大量送信では SPF / DKIM / DMARC が必須」と理解しておけば足ります。

3社の要件を並べる

3社に共通するのは「SPF か DKIM のどちらか一方がヘッダ From とアライメントした状態で DMARC を通す」という点です。ここさえ満たせば、少なくとも認証面での要件はおおむねクリアできます。

日本国内の状況

日本でも行政からの働きかけが続いています。総務省は 2025年9月1日付で、電気通信事業者団体向けにフィッシング対策の強化に関する要請を公表しており、メールのフィルタリング精度の向上とあわせて、DMARC の導入および DMARC ポリシー（隔離・拒否）の設定が求められています。政府の「国民を詐欺から守るための総合対策2.0」（2025年4月22日、犯罪対策閣僚会議決定）でも、送信ドメイン認証技術（DMARC 等）への更なる対応促進が掲げられています。

フィッシング対策協議会も、サービス事業者向けになりすまし送信メール対策として送信ドメイン認証の導入を案内しています。同協議会の案内では、いきなり強いポリシーを設定するのではなく「まずは DMARC レポートを取得し、正規メールとなりすまし送信メールの配信状況を確認することから始め、ポリシーを調整していく」という段階的なアプローチが示されています。本記事のフェーズ3以降と同じ考え方です。

まとめ

• メールにはエンベロープ From（RFC 5321）とヘッダ From（RFC 5322）の2つの差出人があり、ユーザーに表示されるのはヘッダ From。SMTP 自体に差出人の検証機構はない
• SPF（RFC 7208）は送信元 IP を認可する仕組みで、検証対象はエンベロープ From と HELO。DNS ルックアップは10回まで、超えると permerror。ptr は使わない
• DKIM（RFC 6376 / 8301）は電子署名。セレクタ._domainkey.ドメイン に公開鍵を置く。2048ビット以上を推奨、rsa-sha1 は禁止。l= タグは避ける
• SPF も DKIM も単体ではヘッダ From を守らない。両者をヘッダ From に結びつけるのが DMARC のアライメント
• DMARC は 2026年5月に RFC 9989 / 9990 / 9991 として Standards Track 化され、RFC 7489 は廃止。pct は削除され t=y（テストモード）に置き換わり、組織ドメインの判定は DNS Tree Walk になった
• 運用はp=none でレポートを集めるところから。SPF / DKIM のアライメントを整えてから quarantine、reject へ段階的に上げる
• 転送やメーリングリストでは認証が壊れる（RFC 7960）。これを緩和するのが ARC（RFC 8617、Experimental）
• Gmail・Yahoo・Outlook.com はいずれも一括送信者に SPF / DKIM / DMARC とアライメントを要求している。もはや必須要件

送信ドメイン認証は、DNS に数行のレコードを足すだけの作業に見えて、実際には「自組織が誰の名前でメールを送っているか」の棚卸しそのものです。レポートを見ると、知らなかった送信経路が必ず出てきます。まずは p=none と rua だけ設定して、自分のドメインの現実を眺めるところから始めるのが確実です。

参考リンク

• RFC 5321: Simple Mail Transfer Protocol
• RFC 5322: Internet Message Format
• RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
• RFC 8301: Cryptographic Algorithm and Key Usage Update to DKIM
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 9990: DMARC Aggregate Reporting
• RFC 9991: DMARC Failure Reporting
• RFC 8601: Message Header Field for Indicating Message Authentication Status
• RFC 7960: Interoperability Issues between DMARC and Indirect Email Flows
• RFC 8617: The Authenticated Received Chain (ARC) Protocol
• RFC 8058: Signaling One-Click Functionality for List Email Headers
• Google: メール送信者のガイドライン
• Yahoo Sender Hub: Best Practices
• Microsoft: Strengthening Email Ecosystem - Outlook's New Requirements for High-Volume Senders
• BIMI Group: Implementation Guide
• IETF Datatracker: Brand Indicators for Message Identification (BIMI) draft
• 総務省: フィッシング対策に関する要請（2025年9月1日）
• フィッシング対策協議会: なりすまし送信メール対策について
• swaks
• opendkim-testkey(8) manual
• DNS の仕組み入門（当ブログ）
• 公開鍵暗号とデジタル署名 入門（当ブログ）
• TLS 1.3 と HTTPS ハンドシェイクの仕組み（当ブログ）
• Content Security Policy(CSP)入門（当ブログ）
• HTTP ステータスコードの実践的な使い分け（当ブログ）
• 2026年 日本のセキュリティインシデントまとめ（当ブログ）