DMARC対応の完全ガイド：仕組みから運用回避策まで

先日紹介しました業務で使えるメール技術の教科書何故この本を読むのか、それは業務で利用しているメールアドレスのDMARCポリシーをrejectにするためでした。 今一度DMARCについて、そしてDMARCポリシーをrejectにする理由について改めて解説します。

メールは古の技術です。そのうえインターネットが研究者など限られた人だけで利用され、性善説で運用されていた時代のプロトコルのため、セキュリティが極めて脆弱です。特に送信者情報を容易に詐称できることから、なりすましたメールのリンクから偽サイトに誘導してウィルスをダウンロードさせたり、個人情報を入力させるなどの手口に悪用されやすいという問題があります。

【重要】社長⋅役員を装う「LINEグループ作成依頼」メールによる詐欺にご注意ください

私の会社でも社長を騙るメールがガンガン送られてて来ます。腹が立つことに、文章は毎回異なり、しかもいかにも社長が言いそうな口調でLINEグループを作れ、と言ってきます。社内に注意喚起を行うとともに Gmailの高度なフィッシングと不正なソフトウェアへの対策を使って、従業員の名前で送ってくるメールは迷惑メールボックスに送られるようにしました。

これで分かるように、メールはそもそも送信者の名前を任意に設定できるのでなりすましは簡単。もっともこの詐欺メールは送信ドメインがhotmailなので一発で分かるのですが、送信メールアドレスすらなりすましができてしまうのが電子メールです。そしてその送信メールアドレスのドメインのなりすましを判定するのがDMARCになります。 この数か月DMARCに四苦八苦していました。その結果分かったことを如何にまとめました。今後DMARCを設定する人の参考になればと思います。

はじめに：なぜ今DMARCなのか

最近、DMARC対応が必須化され、それも p=none（何もしない）ではなく p=reject（拒否）の設定を将来的に必須とする企業が増えてきました。

DMARC認証導入が義務化されているって本当？わかりやすく解説

Google、Yahoo、Microsoftなどのメールサービス事業者は、DMARCを設定していない送信元からのメールを迷惑メールと判定したり、受信を拒否したりする方針を強めています。 これは一般のユーザーにはあまり関係ない話に見えますが、メールを利用したサービスを提供している企業にとっては死活問題です。例えば、AWSのAmazon SESを使ってメール送信システムを構築していても、DMARC未対応であればメールがすべて受信拒否され、システムが破綻してしまう可能性があります。

DMARCとは

DMARCは、メールのなりすましを防ぐためのセキュリティプロトコルです。これにより、受信者はメールが正規の送信元から送られたものかを確認でき、フィッシング詐欺などを防ぐことができます。 概要は以下の通りですが、実際にはこれらが複雑に絡み合っています。

• SPF (Sender Policy Framework): メール送信を許可されたサーバーのIPリストを定義するプロトコル。
• DKIM (DomainKeys Identified Mail): メールの改ざんがないか確認するための電子署名に関するプロトコル。
• DMARC (Domain-based Message Authentication, Reporting, and Conformance): メールの認証に失敗した場合の対処方法（隔離、拒否など）を定めるプロトコル。SPFやDKIMの結果を活用して機能します。

DMARCによる判定を理解するには、構成要素であるSPFとDKIM、そして「アライメント」という概念の理解が不可欠です。

1. SPF (Sender Policy Framework)

「IPアドレスによる許可リスト」です。 メールの受信側（受信メールサーバ）が、「このメールを送ってきたIPアドレスは、送信元ドメインのDNSレコードに登録されている正規のものか」を確認します。 送信側はドメインのDNSにTXTレコード形式でSPFレコードを登録し、『このドメインはIPアドレス XXX.XXX.XXX.XXX からメールを送りますよ』と記述します。以下が記述例です。

v=spf1 ip4:192.0.2.0 ip4:192.0.2.1 include:examplesender.email -all

SPFの弱点

受信したメールがさらに別のメールアドレスに「転送」された場合、SPFは失敗します。転送サーバのIPアドレスは、元の送信元の許可リストには含まれていないためです。

重要：SPFアライメントとは

DMARCでは「アライメント（一致）」という概念が重要です。これを理解するために、まず2つの「差出人」の違いを知る必要があります。

• Envelope-From (封筒の差出人): システムがメール配送に使う宛先。エラーメールの返送先など。転送されると、転送サーバのドメインに書き換わります。
• Header-From (便箋の差出人): メールソフト上で受信者が目にする差出人。転送されても通常は変わりません。

SPFアライメントの判定

• SPF認証（Check）: Envelope-Fromのドメインと送信元IPアドレスを比較します。転送された場合、転送サーバのドメインでチェックされるため、ここだけならPASSすることが多いです。
• SPFアライメント: Envelope-Fromのドメインと、Header-Fromのドメインが一致しているかを見ます。 転送されると Envelope-From は転送サーバのドメインに置き換わりますが、Header-From は元々の送信ドメインのままです。そのため、転送されたメールはSPFアライメントがNG（不一致）となります。

2. DKIM (DomainKeys Identified Mail)

「メール情報へのデジタル署名（改ざん検知）」です。

DKIM送信時の仕組み:

• 送信メールサーバは、メールの「本文」や「件名」などの項目を組み合わせてハッシュ関数を通し、ハッシュ値（指紋）を作成します。
• このハッシュ値を、送信メールサーバが持つ秘密鍵で暗号化（署名）します。これが DKIM-Signature としてメールヘッダに記載されます。
  • 秘密鍵は送信メールサーバ側（Google等）が厳重に管理し、ユーザーは触れません。

DKIM受信時の仕組み:

• 受信メールサーバは、ドメインのDNSレコードに登録されている公開鍵を使って、メールヘッダにある署名（DKIM-Signature）を復号します。
• 復号して出てきたハッシュ値と、受信したメールから自分で計算したハッシュ値を比較します。これらが一致すれば、「送信者が間違いなく本人であること」と「改ざんされていないこと」が証明され、PASSとなります。

転送されてIPが変わっても、メールの中身がいじられなければPASSとなります。

【DNSレコードの例】 v=DKIM1; k=rsa; p=XXXXXX...

• v: バージョン（通常はDKIM1）
• k: 鍵の種類（RSAなど）
• p: 公開鍵（ここに長い文字列が入ります）

【メールヘッダ（DKIM-Signature）の主な項目】

• a: アルゴリズム（例：rsa-sha256）。送信サーバが決定します。※古い rsa-sha1 は非推奨です。
• c: 正規化のルール（例：relaxed/relaxed）。厳密すぎると転送時の微細な変化でFAILになるため、緩やかな設定が一般的です。
• h: 計算に使った項目。Googleは通常 From, To, Date, Subject, Message-ID などを選択します。
• b: 暗号化された署名データそのもの。
• s: セレクタ（DNSのどこを見に行けばよいかの指定）。
• d: この署名（公開鍵）を持っているドメイン。

DKIMアライメント

署名に使われたドメイン（d=タグ）が、Header-From（差出人）と一致しているかを確認します。 Header-From は転送されても元々のドメインのまま維持されるため、DKIMアライメントは転送に強く、崩れにくいのが特徴です。

DKIMの思わぬ落とし穴

SPFは転送に弱い一方、DKIMは有効な対策のように思えます。しかしDKIMにも弱点があります。メールを転送する際、中間のメーリングリストサーバなどが 「勝手に件名に連番を振る（例：[ML:001]）」などの加工を行うと、ハッシュ値が変わってしまうため、DKIM認証も失敗（FAIL）します。

3. DMARCの判定とARCによる救済

DMARC合格の条件 DMARCが PASS（合格）となる条件は以下の論理式で表されます。

(SPF認証 OK かつ SPFアライメント OK) OR (DKIM認証 OK かつ DKIMアライメント OK)

メールが転送されると、SPFアライメントはIP不一致でFAILとなり、DKIMも件名書き換え等でFAILになることがあります。両方失敗すると DMARC FAIL となり、ポリシー（p=quarantine や p=reject）に従って隔離・拒否されます。 しかし現実には、転送設定は送信側でコントロールできません。そこで登場するのが ARC (Authenticated Received Chain) です。

ARC (Authenticated Received Chain)

ARCは転送サーバと受信側サーバの連携機能です。

• 転送サーバ: メール受信時にDMARC（SPF/DKIM）を確認。「私が受け取った時はPASSでした」という証拠（ARC署名）をヘッダに加えて転送します。
• 受信サーバ: 届いたメールのDMARCが失敗していても、ARCヘッダを確認。「もともとはPASSだった」という証拠があれば、そのメールを救済（Override）します。 救済されたメールはDMARCポリシーの対象外となり、受信箱に送られます。

4. それでもDMARC FAILになるメールを救いたい場合

ARC非対応のサーバ経由など、どうしても救済が必要な場合の運用回避策です。

Google WorkspaceのIP許可リスト（受信側設定）

最終的な受信先が自社のGoogle Workspaceである場合、「管理コンソール」の設定で特定のIPアドレスを許可リストに追加できます。 https://support.google.com/a/answer/60751?hl=ja

例：取引先のMLサーバ（customer@example.com）を経由して自社（taro@mycompany.com）に届く場合。

設定：自社のGoogle管理画面で、取引先のMLサーバのIPアドレスを「メールの許可リスト」に登録します。 効果：これにより、DMARC認証に失敗しても「管理者による許可（Local Policy）」として救済され、受信箱に届きます。※これはDNS設定ではなく、受信側の独自設定です。

Googleの自動判定（ヒューリスティック）

今回私が設定したのはGoogle（Gmail）になりますが、Google（Gmail）は、ARCがなくても、メールのヘッダ情報や通信パターンから「これは転送メールだ」と自力で推測・判断することがあります。この場合も forwarded として救済されることがあります。

DMARCレポートと運用の進め方

理想は100%のDMARC対応ですが、転送メール等の存在により、現実には困難です。そこでDMARCレポートを活用します。 DMARCレコード（例：v=DMARC1; p=none; rua=mailto:report@…）を登録すると、1日1回、各受信メールサーバ（Google, Outlook等）からXML形式のレポートが送られてきます。 これには「いつ、どのIPから、どのドメイン宛に送られ、SPF/DKIMの結果がどうだったか」が記載されています。 最近はレポート分析ツールやAIを活用してこのXMLを分析し、自社のメール送信状況が正常であることを確認しながら、ポリシーを段階的に強化していくのが定石です。

推奨ステップ: p=none（何もしない・監視のみ） ↓ p=quarantine（隔離） ↓ p=reject（拒否・最終目標）

補足：pctパラメータについて p=quarantine などには pct（パーセンテージ）を設定できます。 これは「DMARCがFAILになったメールのうち、何％を隔離対象とするか」を0-100で指定する値です。 例えば pct=50 とした場合、FAILしたメール4通のうち必ず2通が隔離されるわけではなく、1通ごとに「50%の確率で隔離、50%の確率で素通し（救済）」の抽選が行われます。そのため、全部隔離されることもあれば、一通も隔離されないこともあります。