25年９月号 セキュリティコラム「課題が残る送信ドメイン認証の導入・運用」～Gmailショックから1年半、DMARCの現状について～

JSSEC セキュリティコラム

25年９月号「課題が残る送信ドメイン認証の導入・運用」
～ Gmailショックから1年半、DMARCの現状について ～

 

JSSEC副会長・理事
KDDI株式会社　本間 輝彰

 

私たちが日常的に使用するスマートフォン、その便利さの裏には思わぬ落とし穴が潜んでいます。それが、スマートフォン利用者をターゲットにしたサイバー犯罪です。本コラムでは、利用者自身を含め身近なスマートフォンユーザーに起こりうるサイバー攻撃の実態を掘り下げ、その手口と対策について解説していきます。

2023年10月3日にGoogle（Gmail）が「New Gmail protections for a safer, less spammy inbox」※1というタイトルで、また、米国のYahooメールが「More Secure, Less Spam: Enforcing Email Standards for a Better Experience」※2というタイトルで、2024年2月1日からメール送信者に対して新たな要件を発表しました。同様に、iCloudメールは2025年3月6日に「Postmaster information for iCloud Mail」※3というタイトルで、Microsoftも2025年4月3日にMicrosoftブログ内で「Strengthening Email Ecosystem: Outlook’s New Requirements for High-Volume Senders」※4というタイトルで、メール送信者に対する新たな要件を発表しています。その結果、海外の主要なフリーメールサービスでは、メール送信者に対して同様の送信条件を求める動きが広がっています。

各サービスでのメール送信者への要求として、DMARC（Domain-based Message Authentication, Reporting and Conformance ）の対応を求めており（DMARCポリシーは「none」でも可）、これは主にフィッシングメールをはじめとする大量の迷惑メールやスパムメールの増加に対応するためと推測されます。DMARC対応を求めることで、DMARC未対応のメールは拒否し、さらにDMARCに対応しているメールであっても、送信方法や管理が不適切な場合、または送信ドメインのレピュテーションを判定することにより、不必要なメールを排除することが目的の一つと考えられます。

その結果、日本国内においてもDMARCの導入が一気に加速しています。また、DMARCの普及と併せて、自社ブランドを保護しメールの信頼性を高めるために、メールアプリ等で送信元のブランドロゴを表示するBIMI（Brand Indicators for Message Identification）に対応する企業も増えています。

一方で、一部の企業やサービスでは、DMARCやBIMIの設定、さらにはDMARCによって要求されるSPFやDKIMの設定に不備が散見されます。こうした背景を踏まえ、DMARCやBIMIの導入・運用上の課題について解説します。たとえ対応していても、設定に不備があれば正しく機能せず、最悪の場合、メールの送信に支障をきたす可能性もあります。これにより、利用者の安心・安全なメール利用が阻害される恐れもあります。

本コラムが、正しい設定の参考となり、安全・安心なメール環境の実現に役立つことを願っています。

※1 https://blog.google/products/gmail/gmail-security-authentication-spam-protection/
※2 https://blog.postmaster.yahooinc.com/post/730172167494483968/more-secure-less-spam
※3 https://support.apple.com/en-in/102322
※4 https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730

 

Gmail、Yahoo！メール※5、iCloudメール、Microsoftのメール送信者の要求について

4社のメール送信者への要求の比較を示します（GmailとYahoo!メールは、内容は同一）。各サービスで若干の際はあるものの、SPF/DKIM/DMARCの対応が必須となっており、また、送信するメールに対する苦情率の削減、配信メールに対する解除機能など、共通の条件を要求しています。

表1 各メールサービスの送信者への要求ガイドライン

※5 Yahoo!メールは米国のYahoo!社が提供するメールサービス（LINEヤフー株式会社が提供するメールは対象外）。

 

DMARCとは

DMARCは、RFC 7489で規定されているメールの送信ドメインの正当性を検証し、不正なメールの排除や信頼性向上を目的としたメール認証技術です。DMARCは、SPF（Sender Policy Framework）やDKIM（DomainKeys Identified Mail）といった2つの送信ドメイン認証技術の認証結果と、それらの課題に対する対策を組み合わせて運用されます。

また、DMARCでは「reject」「quarantine」「none」の3つのポリシー設定が可能で、送信側がメールの取り扱い方を決める※6ことができます。「reject」は認証に失敗したメールを拒否し、「quarantine」は迷惑メールフォルダなどに振り分け、「none」は対策を行わない設定です。

DMARCを導入することで、自社ドメインの詐称を防ぎ、メールの信頼性向上に重要な役割を果たします。

※6 受信側では設定したDMARCポリシーとは異なる動作をする場合もあります。

 

DMARCの普及状況

GmailやYahoo!メールがDMARC対応を要求するまでは、国内におけるDMARC導入は非常に緩やかな増加にとどまっていました。しかしながら、2024年2月に両社がDMARC対応を求め始めたことをきっかけに、国内のDMARC導入は一気に加速しました。図1の東証トップ225企業のDMARC導入率推移を見ると、2025年2月頃に急激に対応率が上昇していることがわかります。その後も順調に増加し、2025年9月現在では約90%以上の企業がDMARCを導入している状況となっています。

図1 東証Top 225企業のDMARC導入率推移 － KDDI調査結果

しかしながら、各サービスにおいてDMARC導入時のポリシーが「none」でも許容されていたため、多くの企業がDMARCを導入しても、「none」の設定のまま運用しているケースが多く見られます。この状態では、DMARCの導入効果が十分に発揮されず、実質的なメールの保護や不正メールの排除といったメリットを得られません。特に、「none」を継続することには、以下のようなデメリットがあります。

● 不正メールの排除やドメインの信頼性向上といった、DMARCの本来の目的が達成されない。
● メールの信頼性やブランド保護の効果が限定的となり、結果としてセキュリティリスクが残る。

また、図2に示す各国の株式トップ企業のDMARC導入率を見ると、ほとんどの国では「reject」や「quarantine」を設定している企業の割合が60％を超えており、日本の約30％と比較して倍以上となっています。さらに、多くの国で、「reject」を設定している企業が最も多いのも特徴です。このような状況から、国内の企業においても、DMARCポリシーを「none」から「reject」へ変更することが求められます。

図2 各国の株式TOP企業のDMARC導入率 － KDDI調査結果

 

SPFの導入・運用上の課題

SPFは、メール送信時のFromアドレス（Envelope-From）のドメインに対し、そのメールが正規の送信システムから送られているかどうかを判定する技術です。これを実現するために、送信サーバのIPアドレス（ドメイン、MX、Aレコードなどを含む）をDNSのTXTレコードに登録する必要があります。これにより、受信側はDNS情報を参照して、正当な送信元かどうかを検証できます。

この、SPFレコードを記述する際に、SPFの仕様の理解が不十分、作成時のミス、運用上の問題などにより、下記のような記述ミスの問題が散見されています。

● 参照先のSPFレコードが存在しない：存在しないドメインを「include」で参照しようとすると、SPFの認証結果が「PermError」となる。
● DNSの問い合わせ回数が11回以上になっている：「include」などを使い複数の参照先があるときに、DNSクエリの最大回数が11回以上となりSPFの認証結果が「PermError」となる。
● 「include」がループ（相互参照）している：「include」でSPFレコードを相互参照し合うと、ループによりDNSのクエリ回数が増加し、その結果、DNSのクエリ回数が11回以上となり、SPF認証結果が「PermError」となる。
● 未定義のパラメータの使用：記述ミスと思われるが、SPF標準にないパラメータを使っており、記述内容次第ではSPF認証が「PermError」となる可能性がある。
● 区切り文字が不適切など構文ミス：記述ミスと思われるが、各パラメータの区切り文字がないなど構文にミスがあり、SPF認証が「PermError」となる可能性がある。

表2に、約8.6万ドメインに対してSPFレコードの有無と記述内容について調査を行った結果を示します。表2から見て分かるように、約14％のドメインに記述ミスがあることが判明しています。DMARCを導入する際、DKIMを併用せずにSPFのみで認証を行う場合、SPFの認証結果が「PermError」となると、DMARCの認証も「Fail」扱いとなります。特に、DMARCポリシーが「reject」や「quarantine」に設定されていると、正当なメールであってもDMARC認証が「Fail」となり、届かなくなる恐れがあるため、導入後はSPFレコードの記述に誤りやミスがないかを確認することが重要です。

表2 SPFレコードの記述内容の調査結果

また、SPFを導入した後も、システムの設備更新や外部サービスの都合により送信IPアドレスが変更されるケースがあります。この場合、SPFレコードの修正が必要ですが、その修正を怠ると、結果としてSPFレコードに問題が生じることがあります。したがって、SPF導入後は定期的にレコードの内容を確認し、問題がないかをチェックすることも重要です。

 

DKIMの導入・運用上の課題

DKIMのパラメータには、署名された日時を示す「t=」と、署名の有効期限を示す「x=」というパラメータがあります。これらはオプションのため、必ずしも付与する必要はありませんが、一部のメールでは付与された状態で送信されることがあります。

「t=」パラメータは、署名した日時を示しますが、送受信サーバ間で時刻の同期が完全ではないため、受信側で未来の日時として認証されるケースもあります。仕様上は、「未来の日時は無視してもよい（MAY）」とされていますが、実運用では無視されずに認証に失敗する場合もあります。

一方、「x=」は署名の有効期限を示します。通常、送信側が適切な期限を設定していれば、リアルタイム検証では有効期限切れになることは少ないですが、一部のサービスやツールでは、メール受信時にDKIM認証を行うため、有効期限が短すぎると認証に失敗することがあります。

このように、「t=」や「x=」といった時刻に関するパラメータは、双方の時刻同期の問題や、受信側の実装により、検証結果が想定外の時間帯になることがあります。そのため、これらの条件を踏まえた適切なパラメータ設定が求められます。

 

DMARCの導入・運用上の課題

MARCレコードも、SPFレコードと同様に、仕様の理解不足や記述ミスなどにより、設定しているパラメータに誤りがあるケースが一部存在します。記述ミスがあると、正規のメールであっても、受信側のDMARC認証結果が「PermError」となり、これが「fail」と同じ処理とされることが一般的です。特に、DMARCポリシーが「reject」や「quarantine」に設定されている場合、メールが不達になるリスクがあります。

また、DMARCレコードの記述ミスとしては、以下のような例が散見されます。

● 「v=DMARC1」の後に不要な文字が含まれているなど
● DMARCポリシーが存在しない、（記述ミスの可能性が高いが）DMARCポリシーに未定義のポリシーを使っている
● （記述ミスの可能性が高いが）パラメータと値の区切り文字が不適切
● （記述ミスの可能性が高いが）パラメータ間の区切りが不適切（セミコロンで区切らず、スペースやタブになっているなど）
● 「RUA」や「RUF」で設定するメールアドレスの記述が不正（「PermError」にはならない可能性が高いが、レポートメールは送信されない）
● その他記述の不正（未定義のパラメータ、フォーマット、オプションの使用、パラメータの重複など）

表3のように、DMARCレコードの記述内容について調査した結果、約0.5%のドメインでDMARCの記述が誤っていることが判明しています。このような問題を起こさないためにも、DMARC導入時には、DMARCレコードの記述内容が正しいか検証することが重要となります。

表3 DMARCレコードの記述内容の調査結果

また、DMARCの記述に関する問題ではないですが、フィッシングメールを送信する攻撃者は、存在するドメインを詐称してメールを送信してくる場合があります。したがって、自社ドメインを保護するためにも、DMARCを導入し、ポリシーを“reject"”とすることが推奨されます。

なお、ここで重要なのは、メールを送信しないドメインであっても詐称される可能性があるため、全てのドメインに対してDMARCを導入することが必要となります。

 

メーリングリスト（ML）・メール転送問題

MLやメーリングリストでは、受信したメールを登録済みのアドレスに再送信するのが一般的です。しかし、その再送信時に、再送先のメールアドレスが送信不可となった場合、送信者にはエラーメール（NDR）が返されます。この結果、再送先のメールアドレスが送信者に漏れる可能性や、送信者側が見知らぬアドレスへの不達通知を受け取ることで疑問を抱く恐れがあります。

こうした問題に対処するために、転送元でEnvelope-Fromを再送用のアドレスやnullに置き換えて送信する方法が採られることがあります。Envelope-Fromを書き換えることで、もしメールが不達になった場合でも、NDRは再送用のアドレスに返信されたり、破棄されたりするため、送信者には通知が届かなくなります。

図3 ML・メール転送時の問題事例

しかしながら、DMARCを導入している場合において、Envelope-Fromを書き換えると、再送信先ではSPF認証は「pass」しますが、Header-FromとEnvelope-Fromのドメインが異なるため、DMARCにおけるSPF認証は「fail」になります。送信側がDKIMを導入していれば、DMARCにおけるDKIM認証は「pass」するため問題はありませんが、DKIMを導入していない場合は、DMARCの判定はSPFの認証結果に基づくため、「fail」となります。これにより、DMARCポリシーが「reject」や「quarantine」に設定されていると、メールが不達となる可能性があります。

さらに、送信側でDKIMに対応している場合でも、転送元で送信者が付与したDKIM署名を削除し、代わりに新たにDKIM署名を付与して送信するケースもあります。その結果、受信側ではDKIM認証は「pass」しますが、DMARCにおけるDKIM認証は「fail」になることがあります。このように、送信側がDKIMを導入していても、転送の仕組みや設定次第では、最終的にDMARCが「fail」となり、メールが不達になる場合があります。

図4 ML・メール転送時の問題事例 その2

このような問題を回避するためには、メールを再送信する際に、少なくとも送信元で付与されたDKIM署名は削除せずにそのまま再送信する必要があります。また、再送信時に件名を書き換えるケースもありますが、DKIM署名は署名時の内容に基づいているため、件名を変更するとDKIM認証は「fail」します。したがって、再送信を行う場合は、送信元のサーバが付与したヘッダ情報や署名内容を一切書き換えずに送信することが重要です。

特に、DKIMはさまざまなヘッダ情報を署名しているため、件名だけでなく他のヘッダ情報も書き換えない方が安全です。ヘッダ情報の改変を避けることで、認証の失敗を防ぎ、メールの信頼性を維持できます。

なお、DKIMを導入していない場合には、ARC（Authenticated Received Chain）という技術を用いることで一定の回避策が取れますが、ARCの普及は限定的であり、十分な効果が期待できるとは限りません。したがって、問題を防ぐためには、やはり送信側でのDKIM導入が推奨されます。

 

BIMIの導入・運用上の課題

自社ブランドを騙ったフィッシング対策として有効であり、また、ロゴを表示することでメールの開封率などの向上が期待できるBIMIを導入する企業が徐々に増えつつあります。しかしながら、BIMIは新しい技術であるため、導入・運用上の課題が十分に認知されていないケースもあります。せっかくBIMIに対応しても、必要な条件を満たしていない場合、期待される動作が得られないことがあります。以下は、過去に確認されたBIMI導入時の代表的な問題事例です。

● DMARCポリシーは「reject」または「quarantine」に設定されている必要がありますが、「none」と設定されているドメインも存在します。
● DMARC対応は、「Header-From」ドメインと、その親ドメインの両方で行う必要がありますが親ドメインでDMARC対応していないケースがあります。なお、親ドメインがDMARC対応していれば、そのサブドメインも親ドメインの設定を継承するため、「Header-From」側の対応が必ずしも必要ないケースもあります。
● DMARCでは、サブドメインに対するポリシー「sp」の設定が可能ですが、「sp」も「reject」または「quarantine」に設定されている必要があります。一部では、「none」と設定されているケースもあります。
● DMARCでは、認証適用率を設定できる「pct」がありますが、BIMI対応には「pct=100」に設定する必要があります。一部のドメインで、この設定が満たされていない場合もあります

BIMIレコード記述があるが、DMARCポリシーが「none」となっているドメイン数、企業数は、それぞれ0.9%、1.8%と存在していることを確認しています。

表4 BIMIレコード記述があり、DMARCポリシーが”none”のドメイン・企業数

このような問題を回避するためには、BIMI導入後にロゴが正しく表示されるかを十分に確認することが重要です。また、メールサービスごとにBIMIの表示条件が異なる場合もあるため、複数の対応メールサービスで動作確認を行うことも推奨されます。

 

VMC/CMC・ロゴファイル公開時の問題

BIMIでは、VMCやCMCの証明書と表示するブランドロゴ（SVGファイル）をWebサーバに公開し、その保存先をBIMIレコードに記載します。証明書やブランドロゴを公開する際には、証明書発行元のWebサーバと自社Webサーバ（SIer先のサーバも含む）で公開するケースが一般的です。証明書発行元のWebサーバは、証明書やブランドロゴを適切に公開できる設定になっていますが、自社Webサーバは、自社サービスの仕様に特化した設定となっている場合が多く、証明書やロゴの公開に適さないケースもあります。以下は、その際に確認される代表的な課題です。

● Webサーバのメンテナンス時の考慮不足：メンテナンス中に証明書やブランドロゴの取得ができず、結果としてBIMI認証が行われず、ロゴが表示されない場合があります
● キャッシュ禁止設定：クライアント側にキャッシュさせたくないサービス仕様の場合、Webサーバのキャッシュ設定を「no-cache」「no-store」「max-age=0」などにしていることがあります。これにより、メール送信時に毎回証明書やロゴを取得し直す必要が生じ、大量のメール送信時にはHTTP DDoS攻撃のような負荷がかかり、結果的にロゴの表示ができなくなることがあります。また、キャッシュを禁止していると、BIMI認証のたびにファイルを取得する負荷も増大します。
● 長期間のキャッシュ設定：サーバの負荷軽減のためにキャッシュ時間を長く設定している場合、証明書の有効期限切れに気付かず、結果としてBIMI認証に失敗し、ロゴが表示されなくなるケースもあります。

表5に証明書・ロゴを公開している約1,200ドメインのWebサーバのキャッシュ設定時間を調査したところ、キャッシュ禁止しているサーバが4.1％にのぼっています。

表5 Webサーバのキャッシュ設定時間（除く証明書発行先サーバを除く）

自社Webサーバは、運用や仕様の関係で証明書やロゴの公開に適さない設定になっている場合も多いため、これらの問題を避けるには、証明書発行会社のWebサーバで公開することが推奨されます。

なお、実際に2,969ドメインについて調査した結果、約60%のドメインは証明書発行会社のサーバで公開しています。

表6 証明書・ロゴファイルの公開先

VMC/CMCの証明書の有効期限は1年ですが、更新漏れや証明書の入替忘れが散見されるケースがあります。約半年間の調査結果では、30の企業において、更新漏れや証明書の入替忘れを確認しています。

Webサーバの証明書は、有効期限が切れるとWebアクセスに直接影響するため、期限切れに気づきやすいです。多くの場合、証明書の更新に必要なツールや手順も確立されており、更新漏れや入替忘れは近年ではあまり見られません。

しかしながら、VMC/CMCの証明書は、サーバ証明書の更新手順と異なり、各社の運用ポリシーに委ねられているため、更新されていなくてもメールの疎通にはすぐに影響が出ないケースもあります。そのため、気づきにくいという課題があります。

このため、BIMI導入時には、証明書の更新手順を含めた運用計画を事前に作成し、適切に管理・実施することが重要となります。

VMC/CMCの証明書にはロゴデータが含まれており、BIMI認証時には、証明書内のロゴとWebサーバに公開されているロゴファイルが一致している必要があります。しかし、一部のサービスでは、証明書に含まれるロゴデータとWebサーバに公開されているロゴファイルが異なるケースが確認されています。ロゴが不一致の場合、仕様違反となり、BIMIの認証に失敗する恐れがあります。メールアプリに表示するロゴを変更したい場合は、再度証明書の発行が必要となるため、注意が必要です。

なお、BIMI対応している企業におけるロゴ不一致の有無について調査した結果、3.8%のドメイン、4.3%の企業でロゴが不一致していることを確認しています。

表7 ロゴ不一致ドメイン・企業数

※7 パブリック証明事業は、Sectigo社への売却により2025年3月12日以降の新規受付は停止

 

まとめ

Googleをはじめとするメールサービスプロバイダーからの要請もあり、DMARCを導入する企業が増えています。さらに、DMARCを導入した企業の中には、フィッシング対策の強化を目的としてBIMIを導入するケースも徐々に増加しています。

しかしながら、DMARCやBIMIを導入しても、仕様に沿った適切な設定を行い、その後も継続して設定に問題がないか確認しなければ、何らかの理由で設定に不備が生じ、結果として認証に失敗し、期待される効果を得られないだけでなく、メールの不達となるリスクもあります。

したがって、DMARC・BIMIの導入時には、設定内容に問題がないか十分に確認し、導入後も定期的に設定の状態をチェックすることが推奨されます。正しく導入されたDMARC・BIMIは、安全なメール配信を実現するための重要な仕組みです。特に作業を外部に委託している場合は、委託先がこれら課題を認識して作業出来ているかの確認も重必要となります。本コラムを参考に、継続的な見直しと運用を行うことを期待しています。

注）各調査データはDNSサーバやWebサーバへの問合せ結果をもとに算出しています。DNSサーバの応答やWebサーバの応答が何らか理由で受信できない場合も考えられ、実際の値とは誤差があることがありますので、ご承知願います（実際のサービスでのリトライ処理は、サービスによってさまざまであり、サービスによっては救済されるケースも救済せ出来ずに測定している場合があります）。