LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

送信ドメイン認証とは——SPF・DKIM・DMARCの3点セットの関係

送信ドメイン認証とは、受信側のメールサーバーがDNSに公開された情報を照合し、届いたメールが名乗っているドメインから正当に送られたものかどうかを検証する仕組み全般を指します。この枠組みの中核を担うのがSPF(Sender Policy Framework)・DKIM(DomainKeys Identified Mail)・DMARC(Domain-based Message Authentication, Reporting, and Conformance)の3つの技術です。

SPFは送信元IPアドレスがそのドメインの正規の送信元として認可されているかを検証します^*2。DKIMは電子署名によってメール本文とヘッダーが送信後に改ざんされていないかを検証します^*3。DMARCはこの2つの認証結果を受け取り、ヘッダーFromのドメインとの整合性(アライメント)を判定したうえで、認証に失敗したメールをどう扱うかをポリシーとして宣言し、結果をレポートとして受け取る仕組みです^*1。3つは独立した技術でありながら、DMARCがSPFとDKIMの結果を束ねる形で機能する点が特徴です。

実務上まず押さえておきたいのは、DMARCはSPFまたはDKIMのいずれかが「アライメント済みでパス」していれば認証を通す仕組みだという点です^*1。つまりSPF・DKIMが整っていない状態でDMARCレコードだけを公開しても、正規のメールまで拒否や隔離の対象になりかねません。導入の順序としては、SPFとDKIMを先に整備し、そのうえでDMARCのポリシーを段階的に強化していく流れが公式にも推奨されています^*1。

SPFとDKIMの仕組み——DMARCが土台にする2つの認証

SPF——DNSに送信元IPの一覧を宣言する仕組み

SPFは、ドメイン所有者がDNSのTXTレコードに「このドメインからのメールを送ってよいIPアドレスやホスト」を宣言し、受信側がエンベロープFrom(SMTPのMAIL FROM)のドメインと照合する仕組みです^*2。レコードはv=spf1から始まり、includeで他ドメインの許可範囲を取り込んだり、a・mxで自ドメインのAレコード・MXレコードを参照したりできます^*2。

末尾の修飾子は判定結果を左右します。-allは宣言以外からの送信を明確に拒否(fail)、~allはおそらく非認可として弱く扱う(softfail)、?allは主張なし(neutral)を意味します^*2。例えば次のようなレコードです。

v=spf1 include:_spf.example-mailservice.com ip4:203.0.113.10 -all

DKIM——秘密鍵で署名し公開鍵をDNSで検証する仕組み

DKIMは、送信側がメールのヘッダーと本文の一部を秘密鍵で電子署名し、DKIM-Signatureヘッダーとして付加する仕組みです^*3。受信側はヘッダー中のd=(署名ドメイン)とs=(セレクタ)から、selector._domainkey.example.comのような形式でDNSのTXTレコードに公開された公開鍵を取得し、署名を検証します^*3。公開鍵レコードはv=DKIM1、k=rsa、p=(公開鍵本体)といったタグで構成されます^*3。

SPFがエンベロープFromというメールサーバー間のやり取りに紐づく認証であるのに対し、DKIMはメッセージそのものに署名を残すため、転送されても署名が保たれやすいという性質の違いがあります。両者の要点を整理すると次の通りです。

なぜ今DMARCが必須に——GoogleとYahooの送信者ガイドライン

DMARCが急速に注目を集めた背景には、GoogleとYahooが2024年2月1日から適用した送信者ガイドラインがあります。Googleは、1日あたり5,000通以上をGmailアドレスへ送るドメインに対し、送信ドメインのDMARC認証を設定するよう求めています^*4。ガイドラインでは、DMARCの適用ポリシーはp=noneでも要件を満たすとされている一方、直接送信されたメールについてはヘッダーFromのドメインがSPFまたはDKIMのいずれかとアライメントし、DMARC認証にパスすることが求められています^*4。あわせてSPFとDKIMの両方を設定し、Postmaster Toolsで確認できる迷惑メール率を0.3%未満に保つことも条件に含まれます^*4。

Yahooも同様に2024年2月から施行を始めており、明確な送信量のしきい値は示していないものの、大量送信者にはSPF・DKIM・DMARCの認証とアライメント、およびList-Unsubscribeヘッダーによるワンクリック解除の実装を求めています^*5。ワンクリック解除に関する要件は2024年6月から施行が始まりました^*5。Yahoo自身は、認証に失敗したメールを拒否する方針(p=reject)に受信側を誘導する姿勢を示しており、送信側にもより強いポリシーの採用を促しています^*5。

これらのガイドラインが要求する水準は最低限p=noneですが、none止まりでは受信側の処理を変えない「監視のみ」の状態にとどまります。ガイドライン対応を入り口としながら、なりすまし対策として実効性のあるquarantineやrejectまで引き上げるかどうかは、各社の判断に委ねられている状況です。

DMARCのポリシーとアライメント——none・quarantine・rejectの意味

DMARCレコードはDNSの_dmarc.example.comにTXTレコードとして公開します^*1。中心となるのがpタグで、認証に失敗したメールをどう扱うかを次の3段階で宣言します^*1。

• none——受信側に特定の措置を求めない状態です。メールの配送には影響させず、認証結果のレポートだけを収集します^*1。
• quarantine——認証に失敗したメールを、迷惑メールフォルダへの振り分けなど疑わしいものとして扱うよう求めます^*1。
• reject——認証に失敗したメールをSMTP通信の段階で拒否するよう求める、最も強い設定です^*1。

DMARCの認証結果は、SPFまたはDKIMの少なくとも一方が「パス」し、かつヘッダーFromのドメインとアライメントしていることで決まります^*1。アライメントの厳格さはadkim=とaspf=タグで調整でき、r(緩和)はサブドメインも許容し、s(厳格)は完全一致のみを認めます^*1。加えてpctタグで、ポリシーを適用するメッセージの割合を0〜100の範囲で指定でき、段階的な展開に使えます^*1。

レコードの例は次の通りです。

v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-rua@example.com; ruf=mailto:dmarc-ruf@example.com; adkim=r; aspf=r

実務では、いきなりrejectを設定するのではなく、none→quarantine→rejectの順にpct(割合)を引き上げながら移行する進め方が一般的です。理由は、社内の正規の送信元(業務システムやSaaS経由のメール配信など)でSPF・DKIMの設定が漏れていた場合、reject設定下では該当メールがそのまま届かなくなるためです。

DMARCレポートの読み方——集約レポート(RUA)と失敗レポート(RUF)

DMARCレコードのrua=タグで指定した宛先には、受信側から定期的に集約レポート(Aggregate Report)がXML形式で送られてきます^*1。集約レポートには、送信元IPごとのSPF・DKIMの認証結果、アライメントの成否、適用されたポリシーの内訳がまとまっています。日々の受信状況を俯瞰し、想定外の送信元からの配信や、正規のはずの送信元で認証が失敗していないかを確認する材料になります。

一方ruf=タグで指定する失敗レポート(Forensic Report)は、個別のメール単位で認証失敗の詳細を報告する仕組みです^*1。ただし本文の一部が含まれる形式のため、個人情報保護の観点から対応していない受信側も多く、集約レポートに比べると実際に届くケースは限られます。運用の軸足は集約レポートの継続的な確認に置き、失敗レポートは補助的な位置づけで捉えておくと実態に合います。

レポートは1つのメールサービスから送られてくるだけでも量が多く、複数の受信側からのXMLを人手で読み解くのは負荷が高い作業です。DMARCレポートを集計・可視化する専用サービスやツールを組み合わせ、送信元IPの棚卸しと異常検知を継続的に回す体制が実務上は欠かせません。

BIMIとの関係——ロゴ表示に必要なDMARC強制化

BIMI(Brand Indicators for Message Identification)は、認証済みのメールに送信元企業のロゴを受信トレイに表示させる仕組みです^*6。BIMIの仕様では、ドメインの組織ドメインおよびヘッダーFromのドメインの両方でDMARCポリシーがquarantineまたはrejectであることが参加の前提条件とされています^*6。ポリシーがnoneのままでは、ロゴ表示の対象になりません^*6。pct=100であることや、サブドメインポリシー(sp=)がnoneでないことも条件に含まれます^*6。

BIMIのレコードはdefault._bimi.example.comのようなDNSのTXTレコードとして公開し、v=BIMI1、l=(ロゴ画像のURI)といったタグで構成されます^*6。多くの受信側でロゴを実際に表示させるには、登録商標などを証明するVMC(Verified Mark Certificate)の取得も必要になります^*6。

つまりBIMIは、DMARCのポリシーを引き上げた先にある副次的なメリットという位置づけです。BIMI表示を目的にDMARCを強化する企業もありますが、なりすまし対策そのものの効果はポリシー強化の段階で先に得られます。ロゴ表示はその延長線上の取り組みと捉えておくと、優先順位を見誤りにくくなります。

導入の進め方——現状把握からポリシー強化までの6ステップ

DMARCの導入は、既存のメール送信環境を止めずに段階を踏んで進めることが前提になります。一般的な進め方は次の6段階です。

ステップ1・現状把握——自社ドメインから送信しているメールシステムを洗い出します。業務システムの自動通知、SaaSのメール配信、マーケティングツールなど、想定より多くの送信元が見つかることが少なくありません。

ステップ2・SPFの整備——洗い出した送信元をすべて含むSPFレコードを作成します。DNSルックアップの回数には上限があるため、includeの入れ子が深くなり過ぎないよう構成にも注意が必要です^*2。

ステップ3・DKIMの整備——各送信元でDKIM署名を有効化し、鍵を発行してDNSに公開します^*3。SaaS側で署名機能を持つサービスも多く、設定手順はサービスごとに異なります。

ステップ4・DMARC=noneで開始——p=noneでDMARCレコードを公開し、rua=でレポート宛先を指定します^*1。この段階では受信側の処理は変わらず、既存のメール配信への影響はありません。

ステップ5・レポート分析——数週間から数か月分の集約レポートを確認し、正規の送信元がすべて認証をパスしているかを検証します。認証に失敗している送信元があれば、SPF・DKIMの設定を見直します。

ステップ6・ポリシー強化——正規の送信元がおおむね認証をパスする状態になったら、pctを段階的に引き上げながらquarantine、続いてrejectへと移行します^*1。移行後もレポートの確認は継続し、新たな送信元が追加された際の認証漏れに備えます。

内製と外注の分かれ目——DMARC運用体制で判断する

DMARCの導入自体はDNSレコードの設定であり、手順を追えば技術的な難度は高くありません。判断が分かれるのは、送信元の洗い出しとレポート分析にかかる工数です。グループ会社や事業部が多く、送信元システムが分散している企業ほど、洗い出しの負荷は大きくなります。

外部の専門パートナーに委託する場合は、レコード設定だけでなく、レポートの継続的な分析とポリシー強化の判断まで含めて依頼できるかどうかが選定の分かれ目になります。DMARCは一度設定して終わりではなく、送信元の増減に応じて継続的な見直しが要る運用です。導入時点の設定支援にとどまるのか、運用フェーズまで伴走してもらえるのかを事前にすり合わせておくと、導入後のギャップを防ぎやすくなります。

。送信元システムの数や既存のSPF・DKIM設定の状況によって、必要な工数は変わってきます。現状の送信環境を棚卸ししたうえで、内製・外注の切り分けを検討することが実務的です。

まとめ：DMARC導入で押さえる3つの判断軸

本稿ではDMARC・送信ドメイン認証の仕組みと導入の進め方を、公式情報をもとに整理しました。要点は3つに集約できます。第一に、DMARCはSPF・DKIMの認証結果とアライメントを組み合わせ、なりすましメールへの対処方針をポリシーとして宣言し、レポートで結果を受け取る仕組みです^*1。第二に、GoogleとYahooは2024年2月からDMARCの導入を事実上の前提としており、対応の緊急度は高まっています^*4*5。第三に、導入はnoneでの監視から始め、レポートを分析しながらquarantine・rejectへ段階的に強化する進め方が実務的であり、送信元が分散した環境ほど分析工数が内製・外注の判断材料になります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：IETF「RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)」（2015年3月）（https://datatracker.ietf.org/doc/html/rfc7489）
2. *2　出典：IETF「RFC 7208: Sender Policy Framework (SPF)」（2014年4月）（https://datatracker.ietf.org/doc/html/rfc7208）
3. *3　出典：IETF「RFC 6376: DomainKeys Identified Mail (DKIM) Signatures」（2011年9月）（https://datatracker.ietf.org/doc/html/rfc6376）
4. *4　出典：Google「Email sender guidelines」（Google Workspace Admin Help）（https://support.google.com/a/answer/81126?hl=en）
5. *5　出典：Yahoo「Yahoo Sender Hub FAQs」（senders.yahooinc.com）（https://senders.yahooinc.com/faqs/）
6. *6　出典：IETF「Brand Indicators for Message Identification (BIMI)」（Internet-Draft）（https://datatracker.ietf.org/doc/html/draft-brand-indicators-for-message-identification）

Tweet