メールセキュリティ ～ブランド毀損やメルマガ不達を防ぐ

SPF、DKIM、DMARCの仕組みとブランド管理の基本

公開日 11分で読めます

この記事の目次
  1. Gmail送信ルール強化で「メールを送れば必ず届く」という前提は過去のものに
  2. 自社ドメインの「なりすまし」はブランド毀損の重大リスク
  3. 3種類のメール認証（SPF、DKIM、DMARC）の役割
  4. 送信（DMARC可視化）と受信（Email Security）の両面で守る
  5. DMARCの導入：いきなり拒否（reject）にしない段階的ステップ
  6. DOMOの視点
  7. 第4章の総括
  8. 覚えておきたい用語

これまで「メールセキュリティ」といえば、情報システム部門やサーバー管理者が担当する技術的な裏方作業と思われがちでした。しかし、メールはキャンペーン案内、ECの購入完了通知、会員サービス、問い合わせ対応、採用連絡など、企業と顧客を直接つなぐ最も重要なブランド接点です。

それだけに、メールマガジンを配信したはずなのに、顧客に届かない、届いても迷惑メールに分類されて読まれない、といった技術的なトラブルから、自社の名前やドメインを騙ったフィッシングメールが顧客に送られてしまう、といった攻撃は重大な問題です。

メールが届かなくなったり、自社になりすました偽メールが出回ったりすれば、マーケティングの成果（売上、CVR）が落ちるだけでなく、長年築き上げた企業の信頼やブランド価値が一瞬で失われてしまいかねないからです。

2024年2月以降のGoogle（Gmail）や米Yahoo!による「送信者ガイドライン」の強化により、適切なメール認証を行っていないドメインからのメールは、受信拒否や迷惑メール扱いされるリスクが格段に高まったという背景もあります。

この節では、マーケターやWeb担当者も押さえておくべき「SPF」、「DKIM」、「DMARC」というメール認証の基本と、自社ブランドを守りメール到達率を高めるための実務的なアプローチについて解説します。

Gmail送信ルール強化で「メールを送れば必ず届く」という前提は過去のものに

多くの企業で「メルマガが届かない」、「到達率が落ちている」という問題が表面化しています。その背景にあるのが、主要なメールプロバイダーによる迷惑メール対策の厳格化です。

Googleは2024年2月以降、個人用Gmailアカウント宛に1日5,000件以上のメールを送信する「バルク送信者」に対し、以下の対応を必須要件として義務付けました。

  • SPFおよびDKIMの両方によるメール認証の設定
  • DMARCポリシーの導入（宣言）
  • 送信ドメイン（From）と認証ドメインの整合性（アライメント）の確保
  • ワンクリックでの受信登録解除（Unsubscribe）の仕組みの装備
  • 迷惑メール報告率を一定水準（0.1%未満推奨、0.3%未満必須）に抑えること

このルールを怠ると、送信したメールが相手の迷惑メールフォルダに振り分けられたり、受信サーバーで完全にブロックされたりします。つまり、メール認証（SPF/DKIM/DMARC）は「セキュリティ部門の努力目標」ではなく、メルマガや通知メールを確実に届けるための「必須のビジネス基盤」になったのです。

出典： Gmail Email Sender Guidelines

自社ドメインの「なりすまし」はブランド毀損の重大リスク

メールにはWebサイトとは異なる特有の脆弱性があります。それは、送信者名（From表示）を簡単に偽装できてしまう点です。サイバー攻撃者は、自社と無関係のサーバーから 「info@example.com」 や「support@example.com」といった企業の正規ドメインを騙り、悪質なメールを送信できます。

それによるリスクは多岐にわたります。

  • 偽サイト（フィッシングサイト）への誘導による、IDやパスワード、クレジットカード情報の窃取
  • 偽の請求書や決済要求による、金銭の詐取
  • 経営者や取引先へのなりすましによる、送金や機密情報の要求（BEC：ビジネスメール詐欺）

被害に遭った顧客や取引先から見れば、「〇〇社から怪しいメールが届いた」という体験として記憶されます。実際には自社が送信したものではなくても、「セキュリティ管理が甘い企業」というレッテルが貼られ、ブランドへの信頼が失墜しかねません。

メールセキュリティは、自社のサーバーを守るためだけのものではなく、自社の名前とドメインが悪用されるのを防ぎ、顧客の信頼を守る「ブランド保護」そのものなのです。

3種類のメール認証（SPF、DKIM、DMARC）の役割

種類も多く、難しいと思われがちなメール認証ですが、SPF、DKIM、DMARCそれぞれの仕組みと効果、役割を簡単に整理しておきましょう。

  • SPF（Sender Policy Framework）： 「送ってよいサーバーの名簿」
    • 自社ドメインからメールを送信することを許可されたIPアドレスやサーバーを、DNS上に「名簿（SPFレコード）」として登録しておく仕組み
    • 受信側は、届いたメールの送信元IPが名簿に載っているかを確認
    • 「どこから送られたか（送信元サーバー）」を検証
  • DKIM（DomainKeys Identified Mail）： 「メールにつける電子署名」
    • 送信するメールに対して、暗号鍵を用いたデジタル署名を付与する仕組み
    • 受信側は署名を検証することで、「間違いなくそのドメインから送信されたか」「途中でメール本文が改ざんされていないか」を確認
    • 「改ざんされていないか（電子署名）」を検証
  • DMARC（ディーマーク）： 「認証失敗メールの扱いとレポート」
    • SPFやDKIMの認証に失敗したメールを「どう処理すべきか（そのまま受け取る/迷惑メール隔離/受信拒否）」の方針（ポリシー）を受信側へ指示する仕組み
    • さらに、自社ドメインを名乗るメールが世界中でどれくらい送られ、認証に成功／失敗しているかの「状況レポート」を受け取ることが可能
    • 「認証失敗時にどう処分するか（ポリシー）」の設定）と「利用状況」の分析（レポート）

これらの3つをセットで正しく設定して、初めて受信側のメールサーバーから「信頼できる送信者」として正当に評価されるようになります。

DMARC：出典： Cloudflare Docs: DMARC Management

送信（DMARC可視化）と受信（Email Security）の両面で守る

メールセキュリティを検討する際は、①自社から送り出すメールと、②外部から自社へ届くメールの両方向から設計する必要があります。

①自社が送るメールの保護（DMARC Management）

企業では、Google Workspaceなどの社内メールだけでなく、メルマガ配信ツール、MA（マーケティングオートメーション）、ECシステム、問い合わせフォームなど、無数の外部サービスから自社ドメインでメールを送信しています。

Cloudflareの 「DMARC Management」ツールを活用すると、自社ドメインを使って「いつ、どこから、どんなメールが送信されているか」をダッシュボード上で可視化できます。認証に失敗している正規サービスや、なりすましの疑いがある不審な送信元を簡単に洗い出すことが可能です。

②自社へ届くメールの防御（Cloudflare Email Security）

社員や問い合わせ窓口（「info@〜」 等）宛に届く、フィッシングメールやビジネスメール詐欺（BEC）、さらにはマルウェア添付メールを遮断するのが 「Cloudflare Email Security」です。

AIや機械学習を活用し、送信者情報だけでなく、メール本文の文章表現、埋め込みリンクの安全性、過去のやり取りの文脈などをリアルタイム解析し、従来のスパムフィルターを通り抜けてしまう巧妙な偽メールを入口で食い止めます。

出典： Cloudflare Docs: Email security

DMARCの導入：いきなり拒否（reject）にしない段階的ステップ

なりすましを完全に防ぎたいからといって、いきなりDMARCポリシーを最高レベルの「拒否（p=reject）に設定するのは危険です。社内の別部門や外部ベンダーが、把握していないサービスから自社ドメインで重要なメール（予約確認や問い合わせ自動返信など）を送信していた場合、それらの正当なメールまで一括で遮断され、業務に支障をきたしてしまう可能性があるからです。

安全にDMARCを運用するには、以下のような段階的アプローチが鉄則となります。

  1. ポリシーを「監視のみ（p=none）」に設定し、DMARCレポートを収集する
  2. レポートを確認し、未設定の正規送信サービス（MAやフォーム等）のSPF/DKIMを修正する
  3. 問題がないことを確認後、不審メールを「迷惑メール隔離（p=quarantine）」へ移行する
  4. 最終的に認証失敗メールを完全に「拒否（p=reject）」してなりすましを遮断する

いったん設定して終わりにせず、可視化されたレポートを見ながら自社へのメール送信経路を継続的に確認し続けることが重要です。

DOMOの視点

DMARCを設定する前に、自社の「メール送信元」を「確認」する

DOMOとしてメールセキュリティについて検討する際、まず確認したいのは、「現在、自社ドメインを使ってメールを出しているシステムやツールが何種類あるか」という棚卸しです。

マーケティング施策が活性化している企業ほど、メルマガ配信ツール、MA、CRM、イベント受付、ECシステム、カスタマーサポートツールなど、各部門が個別に契約した外部サービスから自社ドメインのメールが送信されているものです。

この全体像を把握しないままDNSで厳しい制限をかけてしまうと、大切な顧客への通知メールが届かなくなったりするトラブルが発生します。以下のような段階的な対応が必要です。

  1. 送信元を棚卸しする： どのサービスが自社ドメインでメールを出しているか把握する
  2. SPF/DKIMを正しく揃える： 各サービスの認証設定を網羅する
  3. DMARCレポートを可視化、監視する： Cloudflare DMARC Management等を活用する
  4. 段階的にポリシーを強化する： none → quarantine → rejectの順に進める

メールは単なる配信手段ではなく、大切な顧客体験とブランドそのものです。マーケティング部門と情報システム部門が同じ送信基盤のログを見ながら協力して管理すること。これこそが、DOMOが推奨する成果と信頼を両立させるメールインフラの運用です。

メールセキュリティは、情報システム部門だけが扱う技術的な問題ではありません。メルマガや会員向けメールが確実に届くかどうか、逆に自社ドメインを騙ったフィッシングメールが顧客へ届いていないか、という問題は、マーケティング成果とブランドへの信頼に直結するマーケティング課題です。

以下の３つの要点を押さえて、メールセキュリティ全般を設計することが必要です。

  • メール認証の必須化（SPF/DKIM/DMARC）： Gmail等のルール厳格化により、認証を行わないメールは届かなくなる
  • 「送信」を守るDMARCの段階的運用： いきなり拒否（reject）にせず、レポートで自社の送信サービスを棚卸ししてから徐々にポリシーを強化する
  • 「受信」を守るEmail Securityの併用： DMARCで自社ブランド（送るメール）を守ると同時に、届く危険なメールも入口で遮断し、送受信の両面を保護する

第4章の総括

すべての「入口」において「暗黙の信用は避け、必ず検証する」

これまで第4章では、Zero Trust（24節）、Cloudflare Access（25節）、Cloudflare Tunnel（26節）、そしてメールセキュリティ（27節）を扱ってきました。

一見すると、社内アクセス、プレビュー環境共有、サーバー隠蔽、メール送受信と、対象領域はバラバラに見えるかもしれません。しかし、これらすべての根底に流れているのは「決して信用せず、常に検証せよ（Never Trust, Always Verify）」という共通のゼロトラスト思想です。

  • ネットワークアクセス： 社内LANにいるからと安心せず、ユーザーと端末を認証する（Access）
  • サーバー公開： URLを秘密にしているからと油断せず、受信用ポートを開けずに隠す（Tunnel）
  • メール： 自社の名前やドメインが表示されているからと鵜呑みにせず、送信元と電子署名を検証する（SPF/DKIM/DMARC）

「暗黙の信頼」を捨て、通信やアクセスの最前線（エッジ）で正当性を確認して通す。この一貫した入口設計こそが、現代のWeb運用とビジネスを支えるセキュリティの到達点です。

覚えておきたい用語

  • SPF： 自社ドメインからメールを送信してよいサーバーを指定する仕組み
  • DKIM： メールに電子署名を付け、送信元や内容の改ざんを確認する仕組み
  • DMARC： SPFやDKIMの結果を確認し、認証に失敗したメールをどう扱うか決める仕組み
  • ドメインなりすまし： 他社のドメインを使ったように見せかけて偽メールを送ること
  • フィッシング： 偽のメールやWebサイトを使い、パスワードなどの情報を盗む攻撃
  • BEC： 経営者や取引先などになりすまし、送金や情報提供を要求するビジネスメール詐欺
  • メール到達率： 送信したメールが正常に受信者へ届けられる割合
  • ワンクリック登録解除： マーケティングメールなどを簡単な操作で配信停止できる仕組み

この章のほかの記事

ch4の記事一覧へ