メール認証（SPF・DKIM・DMARC）— なりすましメールを防ぐ仕組みと導入順

なぜ今、メール認証が重要なのか

フィッシングやビジネスメール詐欺（BEC）は、技術が進んだ今でも非常に成功率の高い攻撃です。その理由のひとつは、受信者が「このメールは本当にその会社・その人物から送られたのか」を見分けにくいことにあります。

たとえば、攻撃者が経理部宛てに「至急、振込先を変更してください」というメールを送り、送信者名を取引先の担当者らしく見せるのは難しくありません。表示名だけを見て判断する運用では、ソーシャルエンジニアリングに引っかかる確率が一気に上がります。

メール認証は、この「送信元のなりすまし」を技術的に減らすための基礎です。特に、自社ドメインを使ったなりすまし送信を防げるかどうかは、ブランド保護だけでなく、取引先や顧客の安全にも直結します。

SPF・DKIM・DMARC は何が違うのか

この 3 つはまとめて語られがちですが、実際には見ているポイントが異なります。

SPF は「このサーバーから送ってよい」を宣言する

SPF は、送信元ドメインの所有者が「このドメインのメールは、このサーバー群から送ります」と DNS の TXT レコードで公開する仕組みです。

受信側は、SMTP のエンベロープ送信元と実際の送信元 IP を見て、許可された送信元かどうかを判断します。シンプルで分かりやすい一方、転送 に弱いという有名な弱点があります。別のメールサーバーが中継に入ると、元の送信元 IP と一致しなくなり、正当なメールでも失敗することがあります。

DKIM は「このメールは改ざんされていない」を示す

DKIM は、送信側がメールヘッダーや本文に対して デジタル署名 を付け、受信側が DNS 上の公開鍵で検証する仕組みです。

これにより、メールが配送途中で書き換えられていないか、署名したドメインがどこかを確認できます。SPF と違って転送に比較的強いのが利点ですが、受信側に「失敗したら拒否してよい」とまでは伝えられません。

DMARC は「失敗したメールをどう扱うか」を決める

DMARC は、SPF と DKIM の結果に加えて、表示上の送信元ドメインと認証に使われたドメインが整合しているかを確認し、失敗したメールをどう扱うかを受信側に示す仕組みです。

ここで重要なのが alignment（整合性） です。単に SPF か DKIM が通ればよいのではなく、「その認証結果が From ヘッダーに表示されているドメインと関係しているか」を見ます。これによって、見かけだけ自社ドメインを装ったメールをより厳密に排除できます。

3 つを別々に見ると誤解しやすい

「SPF を設定したから安心」「DKIM を有効にしたから十分」と考えるのは危険です。3 つはそれぞれ役割が違うため、単独では穴が残ります。

• SPF だけ: 送信元 IP の管理には役立つが、転送や一部 SaaS 連携で失敗しやすい
• DKIM だけ: 署名は確認できるが、失敗時のポリシーを受信側へ明示できない
• DMARC だけ先に強制: 正規の送信経路を洗い出せていないと、自社の正当なメールまで弾く

特に実務で大切なのは、「メール認証は DNS の設定作業ではなく、自社がどこからメールを送っているかを棚卸しする運用作業 でもある」という理解です。Microsoft 365 や Google Workspace だけでなく、採用管理ツール、SFA/CRM、マーケティング配信、問い合わせ管理、請求書送信サービスなど、実は多くの SaaS が自社ドメインでメールを送っています。

導入順は「可視化 → 署名 → ポリシー強化」が安全

メール認証は、いきなり厳しくすれば良いわけではありません。安全に進めるなら、次の順番が基本です。

1. 送信元を棚卸しする

まず、自社ドメインを使ってメールを送るシステムを洗い出します。ここが曖昧だと、後で正規メールを止める事故につながります。

• メール基盤（Microsoft 365 / Google Workspace）
• 問い合わせフォーム
• MA / CRM / 採用ツール
• 請求・通知・予約送信サービス
• 子会社やブランド別ドメイン

2. SPF を整理する

次に、正当な送信元だけを SPF に載せます。古いベンダーや使っていない送信経路が残っていないかも確認します。

3. DKIM を有効にする

主要な送信基盤で DKIM 署名を有効にします。署名が付いていない送信経路が残っていると、後で DMARC を強めたときに事故が起きやすくなります。

4. DMARC を p=none から始める

いきなり quarantine や reject にせず、まずは監視モードでレポートを受け取ります。これにより、「どのメールが認証に失敗しているか」「想定外の送信経路が残っていないか」を可視化できます。

5. quarantine → reject と段階的に強める

レポートと配信影響を確認しながら、徐々にポリシーを強化します。段階的に進めることで、現場への影響を抑えながら防御を固められます。

example.jp.                 TXT  “v=spf1 include:spf.protection.outlook.com -all”
selector1._domainkey.example.jp. TXT  “v=DKIM1; k=rsa; p=MIIBIjANBgkq…”
_dmarc.example.jp.         TXT  “v=DMARC1; p=none; rua=mailto:dmarc@example.jp; adkim=s; aspf=s”

現場でよくある落とし穴

使っている SaaS を見落とす

最も多いのがこれです。特に「普段は情シスが触らない部門ツール」が落とし穴になります。マーケティング部門や採用部門が独自に契約した配信サービスが DMARC 失敗の原因になることは珍しくありません。

転送やメーリングリストで SPF が崩れる

SPF は転送に弱いため、転送や再配送の多い環境では SPF だけに頼れません。だからこそ DKIM を組み合わせる意味があります。

p=reject を急ぎすぎる

DMARC の理想形は reject ですが、棚卸しやレポート分析が不十分なまま適用すると、自社の通知メール・採用メール・問い合わせ返信メールまで届かなくなる可能性があります。

「From 表示名」を人が信じてしまう

技術的な認証が整っていても、利用者が表示名だけで判断してしまうと、似たドメインや別ドメインからの詐欺には引っかかります。AI時代のフィッシング対策のように、最終的には利用者教育も欠かせません。

メール認証だけでは防げないもの

メール認証は強力ですが、万能ではありません。以下のような攻撃は別の対策も必要です。

• 正規アカウント侵害: 本物のアカウントが乗っ取られて送られるメール
• 類似ドメイン攻撃: example.co.jp ではなく examp1e.co.jp のような偽ドメイン
• 取引フロー悪用: 過去のやり取りに便乗して振込先変更を依頼する詐欺
• 正規ドメイン発の悪性添付: 認証は通っていても中身が危険なケース

そのため、メール認証は単独で考えるのではなく、多要素認証、パスキー、権限管理、利用者教育、メールセキュリティ製品と合わせて使うのが基本です。個人向けの観点では、パスキーとパスワードレス認証や MFA の基礎もあわせて押さえておくと理解が深まります。

まず何から始めるべきか

もしまだ何も設定していないなら、最初の 30 日は次の順番で十分です。

メール認証は、派手な防御策ではありません。しかし、フィッシングや BEC の入り口を地道に狭める、非常にコスト効率のよい基盤対策です。特に「自社の名前を使ったなりすまし」を止めることは、社内だけでなく顧客や取引先の被害防止にもつながります。

次に読むなら、攻撃者がどのように人をだますのかを整理した フィッシングとソーシャルエンジニアリング もおすすめです。攻撃の流れと防御の設計を両方で理解すると、メール認証の意味がより立体的に見えてきます。