サイトアイコン IT & ライフハックブログ｜学びと実践のためのアイデア集

DMARCとは？生成AI時代のフィッシング対策、SPFとDKIMとの違いと導入手順

greeden
neon lights in envelope shape

Photo by Maksim Goncharenok on Pexels.com

生成AIによって自然な文面を作りやすくなれば、誤字や不自然な言い回しだけでフィッシングメールを見分ける方法は頼りにくくなります。

DMARC（Domain-based ​Message ​Authentication, ​Reporting ​and ​Conformance）は、受信者に見える差出人ドメインが正規の送信経路で使われているかを確認し、認証に失敗したメールの扱いをドメイン所有者が示す仕組みです。

ただし、DMARCが判定するのは文面の真偽ではなくドメイン認証です。

似た文字列の別ドメイン、表示名だけのなりすまし、正規アカウントの乗っ取り、危険な本文やURLまではDMARCだけで防げません。

まず押さえるべき結論

政府がDMARCの導入を促す理由

政府の「国民を詐欺から守るための総合対策2.0」では、総務省と警察庁による送信ドメイン認証技術の周知と、なりすましメールの受信拒否を要求するポリシーでの運用検討が示されています。

これは、メールの表示名や見た目だけでは正規の連絡か判断しにくく、事業者側でドメインの悪用を抑える必要があるためです。

警察庁も、企業の本物のメールアドレスになりすました誘導が確認されているとして、送信側と受信側の双方にDMARCの導入検討を案内しています。

生成AIは不自然さの少ない文面を作る手段になり得ますが、DMARCは「その文章を誰が作ったか」を調べる技術ではありません。

受信者に見えるドメインが、SPFまたはDKIMで認証されたドメインと整合するかを機械的に確かめます。

SPFとDKIMとDMARCの役割

三つの技術は同じ検査を重ねているのではなく、それぞれ異なる対象を確認します。

送信ドメイン認証の役割
技術 確認するもの DMARCとの関係
SPF 送信元IPアドレスが、SMTPのMAIL ​FROMで使われるドメインから許可されているか SPFに合格し、そのドメインが表示上のFromドメインと整合すればDMARCの合格条件になります。
DKIM メールに付いた電子署名が有効で、署名後に対象部分が改変されていないか DKIMに合格し、署名のd=ドメインが表示上のFromドメインと整合すればDMARCの合格条件になります。
DMARC 表示上のFromドメインとSPFまたはDKIMの認証ドメインが整合しているか 失敗時の処理方針をDNSで示し、必要に応じてレポートを受け取ります。

DMARCは、SPFとDKIMの両方に合格することを必須にはしていません。

少なくとも一方が認証に合格し、その認証ドメインが表示上のFromドメインと整合すればDMARCは合格できます。

アライメントが必要な理由

アライメントは、認証に使ったドメインと、受信者に見えるFromドメインの関係を確認する考え方です。

たとえば、表示上の差出人がnotice@example.co.jpで、DKIM署名のd=がexample.co.jpなら、同じドメインとして整合します。

一方、無関係なドメインのSPFに合格しただけでは、example.co.jpを名乗るメールの正当性を示せません。

整合にはrelaxedとstrictがあり、既定はrelaxedです。

strictを一律に選ぶのではなく、サブドメインを含む実際の配信設計に合わせて決めます。

DMARCポリシーの違い

DMARCポリシーの意味
設定 ドメイン所有者が示す方針 主な用途
p=none DMARCの結果だけを理由に特別な処理を求めません。 正規メールの送信元を把握し、認証失敗を調べる監視段階です。
p=quarantine DMARCに失敗したメールを疑わしいものとして扱うよう求めます。 迷惑メールフォルダへの振り分けなどを想定した強化段階です。
p=reject DMARCに失敗したドメイン利用を正当でないものとして扱う方針を示します。 正規の送信経路を確認した後の強制段階です。

ポリシーは受信側への処理方針であり、受信事業者はDMARC以外の情報も含めて最終的な扱いを決めます。

p=rejectを公開すればあらゆる不審メールが消える、という意味ではありません。

現行仕様で確認したいDMARCタグ

運用で使う主なタグ
タグ 役割
p 組織ドメインに対するnone、quarantine、rejectの方針を示します。
rua 集計レポートの送付先を指定します。
ruf メッセージ単位の失敗情報の送付先を指定します。受信側が送付するとは限らず、情報の取扱いにも配慮が必要です。
adkim、aspf DKIMとSPFのアライメントをrelaxedまたはstrictに指定します。
sp 既存サブドメインに別の方針を指定します。省略時は、適用可能なpの方針がサブドメインにも使われます。
t 現行仕様で定義されたテストモードです。利用前に、採用するメール事業者の対応状況と案内を確認します。

pctは現行仕様から削除された

旧仕様では、ポリシーを適用する割合をpct=50のように指定する例がありました。

現行のRFC ​9989では、実装ごとの適用差が大きかったことからpctが廃止され、テスト用途としてtが導入されています。

古い設定例をそのまま新規導入のひな型にせず、利用中の受信事業者と配信サービスの対応状況を確認してください。

DNSレコードの基本例

次は、集計レポートを受け取りながら送信元を確認する最小例です。

_dmarc.example.co.jp. ​IN ​TXT ​"v=DMARC1; ​p=none; ​rua=mailto:dmarc-reports@example.co.jp"

正規の送信経路を確認し、認証失敗を是正した後は、組織の判断に応じて方針を強化します。

_dmarc.example.co.jp. ​IN ​TXT ​"v=DMARC1; ​p=reject; ​rua=mailto:dmarc-reports@example.co.jp; ​sp=reject; ​adkim=r; ​aspf=r"

example.co.jpとレポート用メールアドレスは説明用です。

実環境では、利用ドメイン、サブドメイン、送信サービス、転送、メーリングリストの構成に合わせて設計します。

安全に導入する4段階

送信元を棚卸しする

顧客通知、請求、採用、マーケティング、問い合わせ返信など、組織名義でメールを送る経路を一覧にします。

社内メールサーバーだけでなく、CRM、メール配信サービス、採用管理、請求サービスなどの外部委託先も対象です。

ここで漏れた正規サービスは、方針を強化した後に受信されにくくなるおそれがあります。

SPFとDKIMを整える

各送信元でSPFの許可設定とDKIM署名を確認し、表示上のFromドメインとのアライメントを成立させます。

SPFは転送で認証に失敗しやすいため、DKIM署名が転送後も有効に保たれる設計を確認します。

SPFの-allやstrictアライメントを先に強制するのではなく、正規経路への影響を検証してから変更します。

p=noneで集計レポートを読む

ruaで受け取る集計レポートから、送信元IP、SPFとDKIMの結果、アライメント、メール件数を送信サービス別に確認します。

未知の送信元を直ちに攻撃と決めつけず、社内の未申告サービスや委託先でないかを照合します。

失敗を直してポリシーを強化する

正規メールの失敗原因を解消した後、p=quarantineを経てp=rejectへの移行を検討します。

移行日は固定の短期日程で決めず、正規の送信経路が揃い、問い合わせ対応と切り戻し手順を準備できたかで判断します。

変更後も、新しい配信サービスの追加、DKIM鍵の更新、ドメイン構成の変更を継続して点検します。

DMARCと一緒に語られる技術

DMARCだけでは防げない攻撃

攻撃者が正規ドメインによく似た別ドメインを取得した場合、その別ドメインが自分のメールを正しく認証することは可能です。

表示名だけを「株式会社〇〇」に変えたメールや、乗っ取られた正規アカウントから送られたメールも、DMARCだけでは排除できません。

受信側では、メール内のリンクを安易に開かず、公式サイトのブックマークや公式アプリから確認する手順を決めておく必要があります。

個人と事業者が詐欺連絡を受けたときの判断基準は、関連記事「詐欺注意喚起：いま増えている手口と先に確認すべき防衛策」でも確認できます。

運用で起こりやすい誤解

運用開始後に見る指標

DMARCの導入はDNSレコードを一度公開して終わる作業ではありません。

送信経路の棚卸し、認証の整合、レポート確認、方針強化、変更管理を一つの運用として続けることで、正規ドメインを直接かたるメールを届きにくくできます。

参考資料

メール認証はDNS設定だけで終わらず、配信経路の棚卸しと継続点検が欠かせません。株式会社greedenは、要件定義から実装、保守運用まで一気通貫のWebシステム開発で、事業に合う運用基盤づくりを支援します。

モバイルバージョンを終了