DMARCとは、SPFとDKIMの結果とFromのドメインを照らし合わせ、認証に失敗したメールの扱いと報告先を、送信側のドメインが受信側に示す仕組みです。
今日やることは2つです。自社ドメインにDMARCレコードがあるかをDNSの管理者に確かめることと、自社の名前でメールを送っているサービスを書き出すことです。2つ目が、後の不達の問題を防ぐ材料になります。
なぜ「なりすまし」と「届かない」が同じ話になる？
受信側から見ると、本物らしいかどうかを確かめる材料が同じだからです。
IPAの解説（2026年8月）は、送信元がSPFやDMARCなどを適切に設定していない場合、メールソフトに表示される差出人は偽装が可能だと説明しています。だから受信側は、認証の結果を見て扱いを決めるようになりました。
総務省の資料に載っているメール認証技術のガイドライン案（2024年3月29日版）は、受信の判断を厳しくする動きが広がっていると説明しています。自社のメールを安定して届けたいなら、送信ドメイン認証へ正しく対応することが今後より重要になるという内容です。
つまり設定がない会社には、2つのことが同時に起こり得ます。
- 他人が自社名で送ったメールを、受信側が見分けにくい
- 自社が送った本物のメールが、確かめられないメールとして扱われる
SPF、DKIM、DMARCはそれぞれ何をする？
3つの役割は次のとおりです。
| 方式 |
何を確かめるか |
自社で決めること |
| SPF |
送信元のサーバーが、そのドメインから送ってよいものか |
送信を許すサーバーやサービスの一覧 |
| DKIM |
電子署名が正しいか |
署名を付ける送信元と、公開鍵の設定 |
| DMARC |
SPFかDKIMの結果がFromのドメインと一致しているか |
失敗時の扱いと報告先 |
いずれもDNSへの設定が要るので、ドメインの管理者が作業します。ガイドライン案は、DMARCの導入にはSPFかDKIMの導入が必須で、両方の導入が望ましいとしています。
要点は「一致」です。DMARCの仕様（RFC 7489）は、署名が有効なだけでは足りない理由を、どのドメインでも署名は付けられるからと説明しています。Fromに表示されるドメインとの一致まで見て、初めて本物らしいと判断できます。
会社のメールが届かなくなる理由は？
原因はだいたい次の4つに分かれます。
1. 認証がそもそも設定されていない
Googleの送信者ガイドラインは、2024年2月1日以降、Gmailアカウントへ送るすべての送信者にSPFまたはDKIMの設定を求めています。1日5,000件を超えて送る場合は、SPFとDKIMの両方に加え、DMARCの設定も必要です。要件を満たさない場合、想定どおりに配信されなかったり、迷惑メールに分類されたりする可能性があるとしています。
Yahooの送信者向けの案内も、大量送信者にSPFとDKIM、p=none以上のDMARCを求め、すべての送信者にDMARCの公開を強く勧めています。Microsoftのサポートページは、Outlook.comなど個人向けサービスに同じドメインで5,000件以上送る送信者について、認証の要件を満たさないメールが拒否された場合のエラーを案内しています。
Gmailや個人向けOutlookで受け取る個人事業主や協力会社があれば、これらの要件は自社の送信にも関わります。
2. 自社のドメインで送る別のサービスが漏れている
見落としやすいのはここです。社員のメールとは別に、次のような所から自社のドメインで送っていることがあります。
- ホームページの問い合わせフォームの自動返信
- 請求書や受発注のシステム
- 配信サービスのメールマガジン
- 複合機のスキャン送信
SPFの一覧に入っていない、DKIMの署名がない、といったサービスは認証に失敗します。ガイドライン案は、配信を事業者に任せる場合に、依頼元と事業者のどちらが署名の鍵を管理するかを含めて設定を整えるよう示しています。
たとえば、部品メーカーの生産管理システムが出荷通知を自社ドメインで自動送信している場合、担当者の普段のメールは届くのに、出荷通知だけが相手の迷惑メールに入る、という形で現れることがあります。導入したベンダーや保守会社にしか設定が分からない場合もあるので、書き出すときに問い合わせ先も並べます。
3. Fromのドメインと一致していない
委託先のドメインでSPFに通っていても、Fromが自社ドメインならDMARCでは一致しません。Googleのガイドラインも、ダイレクトメールではFromのドメインがSPFまたはDKIMのドメインと一致している必要があると書いています。「SPFは通っているのに」という場面で、先に疑う点です。
4. 転送やメーリングリストを経由している
相手側で自動転送されると、転送先でSPFの認証に失敗することがあります。ガイドライン案は、転送されるメールについてはDKIMへの対応を必須とし、SPFだけに頼らないよう示しています。RFC 7489も、メーリングリストなどの経由で認証やドメインの一致が失われることがあると説明しています。
p=rejectを急がない
reject は受信側にメールの拒否を求める設定です。全送信元を確かめないまま強めると、2や3の問題を抱えた本物のメールも止まります。なりすまし対策のつもりで、自社の請求書を止めることになりかねません。
設定はどの順番で進める？
Googleの設定案内とガイドライン案は、どちらもp=noneから始めることを示しています。
- 自社の名前で送っているサービスを書き出す
- 各サービスのSPFとDKIMを整える
- p=noneとレポートの宛先（rua）を設定する
- レポートで、知らない送信元と失敗している正規の送信元を確かめる
- 問題がなくなってからquarantine、rejectへ強める
3のレコードは、Googleの案内によれば _dmarc.自社ドメイン のTXTレコードで、次のような形です。宛先は自社のアドレスに置き換えます。
v=DMARC1; p=none; rua=mailto:[email protected]
ポリシーの違いは次のとおりです。
| 値 |
認証に失敗したメールの扱い |
| none |
そのまま配信し、レポートに記録する |
| quarantine |
迷惑メールとして扱うよう求める |
| reject |
拒否するよう求める |
p=noneは様子を見る段階で、なりすましメールも届きます。「DMARC設定済み」と言えても、ここで止まれば、なりすましを止める効果は限られます。
強めるのにかかる期間は、送信元の数で変わります。レポートはそのまま読むのが難しいので、ガイドライン案もツールや解析サービスの利用を検討するよう書いています。DMARC導入・運用支援サービスの比較で、レポートの読み取りと設定の代行がどこまで含まれるかを確かめられます。
DNSの管理そのものが委託先任せで誰も見ていない会社は、DNSセキュリティの比較も参考に、ドメインの管理者をはっきりさせます。
メールを送らないドメインはどうする？
見落としやすいのが、キャンペーン用やブランド用に取って、メールを使っていないドメインです。
2023年2月に総務省、警察庁、経済産業省がクレジットカード会社等に出した要請は、メールの送信を行わないドメインを含めてDMARCを導入し、受信拒否のポリシーで運用することを求めています。カード会社向けの要請ですが、考え方は一般の会社でも使えます。送らないと分かっているドメインなら、不達の心配が少なく、受信拒否を設定しやすいからです。
自社名の偽メールが届いたと連絡が来たら？
取引先からの連絡は、責めるものではなく貴重な報告です。次の順で動きます。
- 連絡をくれた相手に、開かないようお願いする
- 届いたメールの差出人と日時を聞き、社内の担当者へ回す
- ホームページなどで注意を呼びかけるかを判断する
- 自社のアカウントが乗っ取られていないかを確かめる
4を飛ばさないでください。本物のアカウントから送られている場合は、DMARCの設定では止まりません。多要素認証の確認とパスワードの変更が先です。
なりすましは、3方向あるメールの守りの1つです。ほかの2方向はメールセキュリティの3方向の整理で、自社が受け取った攻撃メールの扱いは標的型攻撃メールを開いた時の社内の動きで扱っています。受信側の製品はメールセキュリティ製品の比較で確かめられます。メールのほかの論点はメールセキュリティの一覧にあります。
