📧

上場企業のメールセキュリティを調べてみた – DMARC・SPF設定の実態

に公開
Security
SPF
email
DMARC
tech

【極秘・至急】社長より直接指示

お疲れ様です。

現在、重要な経営案件の対応中につき、このメールは他の役員・同僚には共有しないよう
お願いいたします。

今すぐ、弊社のDMARCレコードを確認し、設定文字列を取得してください。
取得後は、その文字列をQRコード化して、記事コメント欄に
書き込んでいただくよう、お願いいたします。

皆さん、突然社長からこんなメールが来たらどうしますか？
送信元のメールアドレスを確認する？
えらい！セキュリティの教育をよく受けていますね！
じゃあメールアドレスが正しそうだったら……？

DMARCが reject で設定されていれば、そもそもこのメールは届いていないかもしれません。

きっかけ

私の会社ではDMARCポリシーの強化が検討されたものの、見送りになりました。「じゃあ他の会社はどうなんや？」 と思い、調査がしやすそうな上場企業に絞ってDMARC設定状況を調べてみました。

DMARCとは

DMARC（Domain-based Message Authentication, Reporting, and Conformance）は、なりすましメール対策の仕組みです。SPFやDKIMによる認証結果とヘッダーFromのドメインが一致しているかどうか（アライメント）を確認し、不正と判断されたメールをどう扱うかをDNSで宣言します。

DMARCが防げること・防げないこと

DMARCが対象にするのは「ヘッダーFromのドメインのなりすまし」です。例えば、実在しないIPアドレスから from: info@example.co.jp と詐称したメールを送りつけるような攻撃が該当します。

一方で、ディスプレイネーム詐称は対象外です。ディスプレイネーム詐称とは、メールの表示名だけを「○○銀行」などと偽り、実際のメールアドレスは全く別のドメインにしておく手口です。受信者のメーラーには「○○銀行」と表示されますが、よく見ると〇〇銀行 <attacker@free-mail.example>と書いているアレです。DMARCは free-mail.example のドメインを評価するため、攻撃者が自分のドメインにDMARCを設定してしまえば素通りします。ディスプレイネーム詐称に対しては、受信者が送信元アドレスを確認しなければなりません。

DMARCは万能薬ではなく、ドメイン詐称という特定の攻撃手法への対策と理解してください。

その説明をする前にSPFとDKIMを理解する必要がある

DMARCは認証（ドメインが詐称されていないかどうか）にSPF認証とDKIM認証の結果を用います。
知っているかたは飛ばしてください。

少し長くなるぞ

SPFの仕組み

SPF（Sender Policy Framework）は、ドメインのDNSに「このドメインを使ってメールを送ってよいサーバー・IPアドレス一覧」を登録しておき、そのIPアドレスと照合する技術です。
受信サーバーはメールを受け取ったとき、エンベロープFrom（SMTPプロトコル上の送信元） のドメインのSPFレコードを参照し、送信元IPアドレスが正規かどうかを確認します。

SPFのポリシーには次のようなものがあります。正確には、限定子と呼ばれる-や~がポリシーにあたり、IPアドレス等と組み合わせるのですが、allと組み合わせた方が説明しやすいのであしからず。記述方法には詳しく触れません。

記述 ポリシー 受信サーバーの動作
-all fail 指定されたIPアドレス以外からのメールを拒否する
~all softfail 指定されたIPアドレス以外からのメールに印を付ける
（迷惑メールフォルダに隔離する）
?all neutral 指定されたIPアドレス以外からのメールの扱いは受信サーバーによる

-allが理想ではありますが、実際には~allが使われることも多いです。これは、自動転送やクラウドサービスとの兼ね合いで正規メールが認証失敗するケースがあり、-all にすると正規メールまで弾くリスクがあるためです。
?allが使われる場合の理由としては、とりあえずSPFの設定はするものの、送信元の洗い出し中だったり……ですかね？なら~allでよくない？よくわかんない……

SPFレコードを確認する

SPFレコードはDNSのTXTレコードの中に v=spf1 ... という形式で記述されています。
せっかくなので、Zennのドメインに対してSPFレコードを実際に引いてみましょう。

dig zenn.dev TXT +short | grep spf
# "v=spf1 include:_spf.google.com ~all"

上の説明では省略しましたが、この場合は_spf.google.comを再帰的に問い合わせて、IPアドレスを取得します。
includeの他にもmxやaなどありますが、SPFにはルックアップ回数は10回までという制限があります。

DKIMの仕組み

DKIM（DomainKeys Identified Mail）はドメインの所有者がメールに電子署名を付与し、受信側がその署名をDNSに登録された公開鍵で検証する技術です。
受信サーバーはメールを受け取ったとき、ヘッダーに含まれるd=（署名ドメイン）とs=（セレクタ）をもとにDNSから公開鍵を取得し、b=に記載された署名が正しいかどうかを確認します。

SPFが「送信元IPアドレスを検証する技術」であるのに対し、DKIMは「メール内容そのものが改ざんされていないかを検証する技術」と言えます。
DNSに公開鍵を置けるのは秘密鍵を持っているドメイン管理者なので、署名の検証に成功すれば正しい送信元から送られているということです。

Zennから来たメールは次のようになっています。

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zenn.dev; h=date:from:subject:mime-version:to:content-type: content-transfer-encoding:cc:content-type:date:feedback-id:from:subject:to; s=s1; bh=kyoxpDWyybhb/DJATIX4lI/V4m8MsNdh0im1Pi5/Zts=; b=（略）
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sendgrid.info; h=date:from:subject:mime-version:to:content-type: content-transfer-encoding:cc:content-type:date:feedback-id:from:subject:to; s=smtpapi; bh=kyoxpDWyybhb/DJATIX4lI/V4m8MsNdh0im1Pi5/Zts=; b=（略）

2つあるのはZennのほかにメール配信サービスであるSendGridも署名しているためです。

DKIMレコードを確認する

DKIMレコードは<セレクタ>._domainkey.というサブドメインのDNSのTXTレコードとして公開されています。セレクタ名は任意で、用途によって複数使い分けることもできますが、s1、s2などが多いです。
では、ZennのDKIMレコードを実際に引いてみましょう。

dig s1._domainkey.zenn.dev TXT +short
# s1.domainkey.u13637151.wl152.sendgrid.net.
# "k=rsa; t=s; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxfhLZg12MM9vNfKiSEmvz058sRWe93sDS+Tul7lyR986AdM8xNGbfULI1SI6P+Dg7GJ5YxKiTicaOEmuYhCm1JFAT+KUi/Z6Opx+aVTkLxPtBEUQYQRhadAIt5GsMmm4lybtITdVdfuCx3EcycYzh/Ey1Sy4MrPe6IWBj3xGvJFaB4rFa/VvS9VeeCvO9ZhzSC5iA" "4dNX/1coSeOnVHqIkKqjOG5DzoqJJZtKySxsMa4n8U3DQBpWABZrsNrxI1YYI133pCJMXuVmcD3qPWcDTh5cXszypGk9uP4xy7DVL9KjNh6r01o7wbEqvFeW5IznaSJV8W9cjz9vSXoVUtzEQIDAQAB"

アライメント

SPFはエンベロープFromのドメインを検証しますが、ユーザーがメーラーで実際に目にする送信元はヘッダーFromです。この2つは仕様上異なっていてもメールが送れるため、SPF認証をパスしていてもヘッダーFromが詐称されているケースがあります。

DMARCではこの問題に対応するため、「SPF/DKIMで認証されたドメインとヘッダーFromのドメインが一致しているか」 も確認します。これをアライメントといいます。

DMARCでは次のどちらかを満たすとき、認証成功となります。

  • SPF pass かつ SPFアライメント pass
  • DKIM pass かつ DKIMアライメント pass

メール配信サービスを使うとエンベロープFromにサービス側のドメインが入りがちで、アライメントが通りにくくなります。そのような場合にDKIMアライメントで担保する構成となっています。

アライメント含めDMARCの概要は JPNIC Newsletter No.84 - インターネット 10分講座●なりすましメール対策のためのDMARCとその導入・運用 が分かりやすいのでご参照ください。
私がまだ「DMARCってSPFとDKIMのORみたいなもんだろ！」と思っていた頃に読んだものです。
アライメントの図解
アライメントの図解（JPNIC Newsletter No.84 より引用）

DMARCのポリシー

ポリシー 動作
none 監視のみ。メールはそのまま届く
quarantine 迷惑メールフォルダへ隔離
reject 受信拒否

none はレポートを受け取って実態を把握するための第一ステップです。フィッシング対策として機能するのは quarantine か reject のみで、reject まで到達して初めて完全な対策になります。

DMARCレコードを確認する

DMARCレコードはドメイン自身ではなく、_dmarc. というサブドメインのTXTレコードとして公開されています。受信サーバーは _dmarc.<送信元ドメイン> を引いてポリシーを取得します。

# DMARCは _dmarc.<ドメイン> のTXTレコードを引く必要がある
# p= のポリシー（none/quarantine/reject）と rua= のレポート送信先に注目
dig _dmarc.zenn.dev TXT +short
# "v=DMARC1;p=quarantine;rua=mailto:c4d6881988@rua.easydmarc.com;ruf=mailto:c4d6881988@ruf.easydmarc.com;fo=1;"

rua（Reporting URI for Aggregate）はDMARC運用の基本で、集計レポートの送信先を指定します。認証の通過・失敗の統計がXMLで定期的に届き、どのサーバーから自ドメイン名義のメールが送られているかを把握するために必要です。設定していないとレポートが届かず、noneのまま放置される原因になります。
ruf（Reporting URI for Forensic）はフォレンジックレポートの送信先で、認証失敗メールの統計が届きますが、メールの詳細（件名・本文・送信元IPアドレスなど）が含まれるため、プライバシー上の懸念からサポートしない受信サーバーも多く、実際にはほとんど届かないケースもあります。Gmailはフォレンジックレポートを送信しません。設定は任意と考えて問題ありません。

BIMI

DMARCのポリシーを強化すると、BIMI（Brand Indicators for Message Identification）というおまけも付いてきます。BIMIはメーラー上に送信者のブランドロゴを表示できる仕組みで、quarantine か reject が前提条件です。

楽天・SBI・クレジットカード会社のBIMIアイコン表示例
JCBの例。銀行、証券会社、クレカ会社などからのメールにアイコンが表示されます。

Gmailなど対応済みのメーラーで受信すると、差出人の横に会社のロゴが表示されます。フィッシングメールにはロゴが出ないため、受信者がひと目で本物か判別しやすくなります。

VMC（Verified Mark Certificate）という電子証明書とセットで使うことでロゴの正当性が保証されます。Google Workspaceなどでは認証済みマーク（青いチェックマーク）も表示されます。

受信者にとっての視認性向上だけでなく、ブランド認知・メール開封率向上といったマーケティング効果も期待できます。「セキュリティ予算が取りにくい」という状況では、このマーケティング効果を経営層への説明材料にするのも有効かもしれません。

実際の認証結果を見てみる

私のGmail宛にZennから来たメールのヘッダーでDMARCの認証結果を見てみましょう。

Authentication-Results: mx.google.com;
       dkim=pass header.i=@zenn.dev header.s=s1 header.b=AFeokK8A;
       dkim=pass header.i=@sendgrid.info header.s=smtpapi header.b=hw5kv8tq;
       spf=pass (google.com: domain of bounces+<ワイのアカウント>=gmail.com@em8865.zenn.dev designates 159.183.10.0 as permitted sender) smtp.mailfrom="bounces+<ワイのアカウント>=gmail.com@em8865.zenn.dev";
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=zenn.dev

SPF、DKIM、DMARC共にpass（認証成功）していますね。

DMARCを取り巻く外圧

GmailのDMARC要件騒動

2023年10月、Googleが「メール送信者のガイドライン」を発表したことで業界に衝撃が走りました。2024年2月1日以降、Gmail宛に1日5,000件以上送信する「バルクメール送信者」には、SPF及びDKIMの認証に加え、DMARCレコードの公開が求められるようになりました。迷惑メール扱いや配信拒否などの影響を受ける可能性があると宣言したのです。

「メルマガがGmailに届かなくなる！」など大きな話題になり、多くの企業が対応を迫られました。

ただし、GoogleのガイドラインでDMARCに求めるのは p=none 以上、つまりDMARCレコードが存在していさえすれば最低限はクリアできます。本質的な問題は「これを機にDMARCレコードをとりあえず none で設定して終わりにしてしまい、ruaを設定していない企業が多く生まれた」という点にあります。rua なしではDMARCレポートが届かず、自ドメインの送信実態を把握できないまま none のままで放置されがちです。

https://support.google.com/a/answer/81126

各業界のガイドライン動向

フィッシング被害の急増を受け、国内でも業界横断でDMARCの reject 適用が推進されています。

金融庁は2024年10月に「金融分野におけるサイバーセキュリティに関するガイドライン」を公表し、DMARCを含む送信ドメイン認証を基本的な対応事項として位置づけました。

総務省は2025年9月1日、電気通信事業者協会など4業界団体に対してフィッシングメール対策強化の要請を実施しました。DMARCポリシーの隔離・拒否設定を進めるよう求め、2025年9月から2026年8月末まで3ヶ月ごとに進捗報告を義務付けています（行政指導）。

日本証券業協会は2025年10月15日にガイドラインを改正し、証券会社が顧客に送るメールについてDMARCポリシーを reject にすることを対応必要事項として明記しました。

調査概要

調査日時

2026年3月1日

対象

JPX（日本取引所グループ）が公表している上場銘柄一覧（2026年1月末時点）を利用し、その中からドメインを自動で特定できた上場企業3,745社を対象に調査しました。調査項目はSPFレコード・DMARCレコードのDNS設定状況です。

後述の通り、メールドメインを特定するのが難しく、WebサイトURLのドメインを使用しています。Webサイトを特定できなかった企業については集計の対象外としています。

WebサイトのドメインでMXレコードがある企業 （つまり、少なくとも受信用のメールドメインとして使っているであろう企業） [1]は3,479社で、残りの約266社はMXレコードなし（そのドメインでメール受信をしていない）です。MXレコードなしとは、Webサイトのドメインがexample.co.jpでメールドメインがexample.comのケースやサブドメインで運用しているケースです。とくに〇〇ホールディングスや◯◯グループは事業会社の方でメールを運用しており、MXレコードがないことが多いです。

今回は、MXなし企業もあえて集計対象に含めています。
MXなし⇒SPF/DMARC設定不要 ではないからです。
メールを受信しないドメインであっても、攻撃者はそのドメインをヘッダーFromに詐称したなりすましメールを送り付けることができます。 受信しないからといって野放しにしておくと、自社ブランドのなりすましに悪用されるリスクがあります。受信用MXがなくても、SPFに v=spf1 -all（すべて拒否）を設定し、DMARCに p=reject を設定しておくことが推奨されます。MXなし企業のSPF・DMARC設定状況も、今回の調査で確認したかったポイントのひとつです。

企業のメールドメイン特定難しすぎ問題

JPXから企業一覧はダウンロードできますが、証券コードとドメインの対応付けが一筋縄ではいきません。
まず、メールアドレスが公開されていないことが多いです。そのため、公式Webサイトのドメインが、メールのドメインと同じだと仮定して、Webサイトを特定する方針としました。

しかし、Webサイトの特定も少々面倒でした。

  • Yahoo!ファイナンスや株探などの株式情報サイトはスクレイピングを利用規約で禁止している
  • ドメイン情報を提供するサービスも存在するが有料

最終的に JPXの東証上場会社情報サービスのスクレイピングとEDINET（金融庁の開示データベース）のAPIを組み合わせてドメインを特定しました。

具体的な手法は別記事で解説する……かも。

先行調査

https://www.proofpoint.com/jp/newsroom/Proofpoint_research_reveals_DMARC_policy_level_Nikkei_225_companies_is_behind_rest_of_the_world

私の調査がモタモタしているから調査準備をしている間にこんなものが出ていました。
こちらは日経225のみを対象としたものです。

調査結果と考察

ポリシー分布の全体像

SPF/DMARC ポリシー分布
SPF/DMARC ポリシー分布
SPFについては、~all（softfail）が70.5%と大多数を占め、-all（fail）は20.7%にとどまります。

SPFレコードが複数ある場合はRFC違反です。 「未設定/その他」には複数レコードによるエラーが13社含まれます。

DMARCについては、noneが52.0%と最多で、quarantineが9.3%、rejectはわずか4.1%です。未設定は34.5%と、3社に1社はDMARCレコード自体が存在しない状況です。実質的な防御力を持つ reject はまだごく少数派です。

DMARCポリシーがp=（空白）の会社が2社存在し、「未設定」に区分しています。

また、MXレコードがなくても、きちんとSPF・DMARCを設定する企業は設定していることが伺えます。

業種別ヒートマップ

業種別メールセキュリティ対応率ヒートマップ
業種別メールセキュリティ対応率ヒートマップ
業種別に見ると、やはり金融業界のDMARC対応が際立っています。
銀行業は rejectまたはquarantine 率が51%と最も高く、ガイドラインの影響がデータにも表れています。一方、ヒートマップが真っ赤な通り、他業種ではほとんどが設定しておらず、業種間の格差は大きいです。

軒並み低いため、憶測ですが、DMARC対応の優先度は企業がBtoCなのかBtoBなのかで変わることが考えられそうです。BtoC企業では顧客向けにフィッシングメールが送られると大量の被害者が発生し、ブランド毀損や顧客離れに直結するため、DMARCによる防御が急務になりやすい傾向があります。一方、BtoB企業ではやり取りの相手が限定的で、取引先との信頼関係の中でメールの真正性が担保されている意識があるため、優先度が上がりにくいと考えられます。

DMARCレポート設定状況

DMARCレポート設定状況
DMARCレポート設定状況
DMARCの rua/rufの設定状況を見ると、DMARCを設定していながら rua なし（レポート受信先未設定）が817社（21.8%） います。
前述のGmail騒動で「とりあえずDMARCレコードをnoneで追加した」企業の中に、rua を設定せずに終わったケースも含まれているとみられます。rua がなければDMARCレポートは届かず、自ドメインの送信実態を把握できないまま放置されます。ポリシーを quarantine や reject に強化していくためには、まずレポートで現状を可視化するステップが不可欠です。

ちなみにrua の送信先として最も多いのは report.securemx.jp（154社 / 9.4%）で、rua.powerdmarc.com（87社）、dmarc25.jp（82社）、vali.email（79社）などのDMARCレポート分析サービスが続きます。
dmarc25.jpは冒頭で紹介したアライメントの解説記事を担当しているTwoFive社ですね。
rua 送信先ドメイン ランキング
rua送信先ドメインランキング

SPF DNSルックアップ回数

SPF DNSルックアップ回数の分布
SPF DNSルックアップ回数の分布
RFC 7208では、SPF評価時のDNSルックアップ回数を10回以内と定めています。これを超えると評価が中断されSPF認証失敗扱いになります。
調査対象の中で 84社がルックアップ11回以上となっており、技術的にはSPF認証が失敗しうる状態です。
ちなみに最多は37回でした。

SPFルックアップが積み上がりやすい原因は、Microsoft 365、Google Workspace、各種SaaS（マーケティングツール、顧客対応システム等）などの導入で、それぞれの include を追加していってしまうことです。
解決策としては、不要な include の棚卸し・削除、SPFフラット化、サブドメイン分離などがあります。

市場区分での傾向

市場区分別のreject/quarantine率は次のようになっています。

市場区分 DMARC reject/quarantine 率
プライム 18.4%
スタンダード 8.7%
グロース 12.9%

プライムが最も高いのは、ガバナンス要件が厳しく、情報セキュリティへの投資や専任人材の確保も進んでいる企業が多いからでしょうか。
グロースがスタンダードを上回っている点に関しては、グロース企業のIT系が占める比率が高く、セキュリティの重要性を技術的に理解しているエンジニアが社内にいる可能性が高いこと、また Google Workspace や Microsoft 365 にメール基盤が集約されているケースが多く、これらのサービスが DMARC 設定を推奨・容易にしていることが考えられます。
スタンダードが最も低いのは、いわゆる中間層の課題を示唆しています。プライムほどガバナンス圧力が強くなく、グロースほどITリテラシーが高くない企業が多い層で、セキュリティ対策が後回しになりやすいと考えられます。

メールサービスの傾向

参考までに、MXレコードから確認できた利用メールサービスの分布です。Microsoft 365 が29.7%、Google Workspace が23.4%と2大クラウドメールで過半数を占めます。国内ベンダーではruaランキングにも登場していましたが、情報漏洩事件で話題になってしまったSecureMXが7.5%と続きます。
MXレコード サービス別上位20

隠れたシステム問題

DMARCのポリシーを簡単に強化できない理由について、部門主導で導入されたシステムを情シスが把握できていないことが多くの企業で課題になっています。
知人は、社名変更に伴うドメイン変更でやっとポリシーを見直せたと言っていました。

マーケティング部門が独自に契約したメール配信ツール、カスタマーサポートシステム、ERP連携ツール、さらには複合機など、「誰かが設定したが情シスが把握しきれていない」送信元が積み重なっている状態です。こうした隠れたシステムの洗い出しは泥臭い作業ですが、DMARCレポートを活用すると自ドメインからどのIPアドレスがメールを送っているかが可視化されます。

p=none でDMARCレコードを設定して rua でレポートを受信し始めるだけでも、現状把握の大きな一歩になります。専用ツールや専門のDMARCレポート分析サービスを使えばその解析がさらに楽になります。

まとめ

  • 上場企業全体では、DMARCの reject 設定はまだ4.1%と少数派
  • 金融業界（特に銀行業）は金融庁ガイドラインの影響でDMARC対応が進んでいる
  • rua を設定しておらず、監視できていない会社が相当数いる
  • SPFのルックアップ超過（11回以上）は84社で確認され、管理の難しさが表れている

DMARCは p=none からでも始められます。設定されていない場合は、まずDMARCレコードに rua を設定してレポートを受け取ることで、自社ドメインの送信実態を把握するところから始めてみてはいかがでしょうか。
また、いつGoogleなど大手による規制や官公庁・業界団体からの勧告が出されても慌てないよう、早いうちからレポートを解析し、改善していくことが望まれます。

……え、私の会社ですか？

参考資料

脚注

  1. RFC 7505 にてMXに.を指定し配送不可であることを明示するNull MXが規定されています。つまり、MXレコードがあっても受信メールドメインとは限りません。確認できた Null MX は9社、うちSPF-allは7社、SPF-allかつDMARCrejectは4社でした。（2026/03/04 修正） ↩︎

Discussion