生成AIによって自然な文面を作りやすくなれば、誤字や不自然な言い回しだけでフィッシングメールを見分ける方法は頼りにくくなります。
DMARC（Domain-based Message Authentication, Reporting and Conformance）は、受信者に見える差出人ドメインが正規の送信経路で使われているかを確認し、認証に失敗したメールの扱いをドメイン所有者が示す仕組みです。
ただし、DMARCが判定するのは文面の真偽ではなくドメイン認証です。
似た文字列の別ドメイン、表示名だけのなりすまし、正規アカウントの乗っ取り、危険な本文やURLまではDMARCだけで防げません。
まず押さえるべき結論
- DMARCは、SPFまたはDKIMの認証結果と、受信者に見えるFromドメインとの整合を確認します。
p=noneは監視用であり、DMARCに失敗したメールの隔離や拒否を要求する設定ではありません。p=quarantineやp=rejectへ進む前に、正規の送信サービスと転送経路を洗い出す必要があります。- 現行のIETF標準では、旧仕様の
pctは廃止され、テスト用途のtが定義されています。 - 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ポリシーの違い
| 設定 | ドメイン所有者が示す方針 | 主な用途 |
|---|---|---|
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と一緒に語られる技術
- ARC：転送やメーリングリストを通る前の認証結果を、仲介者が署名付きで引き継ぐ仕組みです。DMARCそのものを置き換える技術ではありません。
- MTA-STSとTLS-RPT：メール配送時のTLS利用方針と、その失敗状況の報告に関わります。Fromドメインのなりすまし対策とは役割が異なります。
- BIMI：対応する受信サービスでブランドロゴ表示を目指す仕組みです。DMARCがquarantineまたはrejectで運用されていることが前提で、表示条件や証明書の扱いは受信事業者によって異なります。
DMARCだけでは防げない攻撃
攻撃者が正規ドメインによく似た別ドメインを取得した場合、その別ドメインが自分のメールを正しく認証することは可能です。
表示名だけを「株式会社〇〇」に変えたメールや、乗っ取られた正規アカウントから送られたメールも、DMARCだけでは排除できません。
受信側では、メール内のリンクを安易に開かず、公式サイトのブックマークや公式アプリから確認する手順を決めておく必要があります。
個人と事業者が詐欺連絡を受けたときの判断基準は、関連記事「詐欺注意喚起：いま増えている手口と先に確認すべき防衛策」でも確認できます。
運用で起こりやすい誤解
- p=noneを設定すれば拒否できる：
p=noneは監視用です。失敗メールへの隔離や拒否を要求しません。 - spを省略すると必ず無防備になる：
spがなければ、原則として適用可能なpがサブドメインにも使われます。別方針が必要なときに明示します。 - strictのほうが常に安全である：strictは認証ドメインの完全一致を求めます。サブドメインを使う正規配信への影響を調べて選びます。
- ARCがあれば転送問題はすべて解決する：ARCは認証履歴を伝える材料です。受信側の評価や仲介者への信頼も関係します。
- DMARCがあればフィッシング対策は完了する：類似ドメイン、表示名詐称、アカウント侵害、本文の危険性には別の対策が必要です。
運用開始後に見る指標
- 正規の送信サービスをすべて担当部署と対応付けられているか
- 送信元ごとにSPFまたはDKIMが合格し、Fromドメインと整合しているか
- 所有者を確認できない送信元が残っていないか
- ポリシー変更後に、正規メールの不達や誤判定が発生していないか
- 新しい配信サービスを追加するとき、認証設定を確認する手順が守られているか
DMARCの導入はDNSレコードを一度公開して終わる作業ではありません。
送信経路の棚卸し、認証の整合、レポート確認、方針強化、変更管理を一つの運用として続けることで、正規ドメインを直接かたるメールを届きにくくできます。
参考資料
- 警察庁「国民を詐欺から守るための総合対策2.0」
- 警察庁「フィッシング対策」
- IETF RFC 9989「Domain-Based Message Authentication, Reporting, and Conformance」
- 迷惑メール対策推進協議会「送信ドメイン認証技術 DMARC導入ガイドライン」
- BIMI Group「Implementation Guide」
この記事に関連する株式会社greedenの取り組み
メール認証はDNS設定だけで終わらず、配信経路の棚卸しと継続点検が欠かせません。株式会社greedenは、要件定義から実装、保守運用まで一気通貫のWebシステム開発で、事業に合う運用基盤づくりを支援します。