目次
スポンサーリンク
メールの表示名と認証されたドメインを分ける
メールに会社名や自分のドメインが表示されていても、それだけで正規の送信とは判断できません。SPF、DKIM、DMARCは、送信経路や署名、表示上のドメインとの整合を確認するための仕組みです。三つの名称をDNSへ追加しただけで、すべてのなりすましが止まるわけではありません。
本記事は2026年10月18日に確認したMicrosoft LearnとDMARCの基本設計資料を踏まえた運用解説で、特定の攻撃被害の速報ではありません。RFC 7489は基本概念の説明に参照し、実際の設定は利用中のメール提供元の現行資料で確認します。以下の構成と段階的な確認手順は、本サイトが提案する仮想例です。
SPFとDKIMは同じものを確認していない
SPFは、配送時に使われる送信元ドメインなどについて、送信サーバーが許可された経路かを確認します。利用者がメール画面で見るFromの表示だけを直接保証するものではありません。外部の配信サービスでSPFが成功しても、自社のFromと整合するとは限りません。
DKIMは、メールに付いた署名と署名したドメインを確認する仕組みです。署名が有効でも、それが自社のFromと結び付いたドメインかを別に見ます。また、署名は本文の主張が正しいことや、送信者のアカウントが侵害されていないことを保証しません。
DMARCでは、表示に使うFromのドメインと、認証に成功したSPFまたはDKIMのドメインの整合を確認します。少なくとも一方が認証に成功し、適用する整合の条件も満たすことが重要です。三つの結果を単に別々の合格マークとして並べないでください。
基本となる資料：Microsoft Learn DMARCの構成。
スポンサーリンク
DNSを変える前にすべての送信経路を列挙する
仮想のWeb運営組織では、社員のメールだけでなく、会員登録、パスワード再設定、請求書、問い合わせ、ニュースレター、監視通知が別のサービスから送られているとします。一部を忘れたまま厳格化すると、重要な通知が届かなくなるおそれがあります。
本サイトは、送信サービス、業務の担当者、From、実際の配送に使うドメイン、DKIM署名のドメイン、設定変更先を一覧にすることを勧めます。配信停止した古いサービスも、設定だけが残っていないかを確認します。DNSを触る人と業務の送信元を知る人の両方が必要です。
問い合わせフォームでは、入力した利用者のメールアドレスをそのまま自社の送信元のように扱わない設計も検討します。自社が管理する送信元を使い、返信先を用途に沿って設定するなど、メール提供元の仕様と送信の責任を一致させます。
DMARCの方針はレポートを見ながら段階的に進める
Microsoftの資料は、DMARCの構成と段階的な展開を説明しています。一般にp=noneは失敗メールへの処置を要求しない観測段階、quarantineやrejectはより強い取り扱いを求める方針です。ただし、最終的な扱いは受信側の仕組みや判断にも依存します。
方針を厳しくした事実だけを成果にせず、正規の送信経路が認証と整合を満たすことを先に確かめます。繁忙期だけ動く請求処理や月次メールもあるため、短い観測だけで問題なしと判断しないことが重要です。観測期間は業務の送信周期に合わせます。
一方で、p=noneのままレポートを誰も読まなければ、点検の機会を活用できません。担当者、確認頻度、未知の送信元を発見したときの問い合わせ先、次の段階へ進む条件を決めます。すべての失敗が攻撃とは限らないため、正規サービスの設定不備と不明な送信を切り分けます。
スポンサーリンク
レポートと実際のメールを両方確認する
集計レポートは、自社のドメインを使う送信元や認証結果の傾向を把握するのに役立ちます。受信側が提供するレポートの範囲や頻度は一様ではありません。レポートに出ない通信がないと断定せず、重要なメールはテスト送信した実物も確認します。
受信したメールでは、信頼できる受信システムが付けた認証結果を見て、SPF、DKIM、DMARCと各ドメインを照合します。メール本文に書かれた「認証済み」の文字や、外部から自由に付けられるヘッダーだけを証拠にしません。
レポートの受け取り先には、組織が継続して管理できる窓口を使います。外部サービスへ転送して分析するなら、含まれる情報、保管、アクセス権、委託条件を確認します。詳細な失敗報告を無条件に増やすのではなく、必要性とプライバシーを考慮して提供元の手順を選びます。
転送や中継で失敗する経路を把握する
メールが別のサービスへ転送されると、配送元が変わるなどしてSPFの判定に影響することがあります。中継の途中で本文やヘッダーが変更されれば、DKIMの検証にも影響し得ます。転送を経由する正規メールがあることを、導入前の一覧へ含めてください。
重要な取引先や利用者が利用する転送経路を、管理できるテストアカウントで確認します。失敗を見つけたからといって、認証を全面的に緩めたり、他人のドメインを自社DNSへ追加したりしないでください。どのサービスが何を書き換えるかを調べ、利用する提供元の対応方法を検討します。
Webの問い合わせ通知が届くことと、利用者への自動返信が届くことも別々に確かめます。送信APIの成功応答は受信箱への到着を保証しないため、バウンスや利用者からの問い合わせを見られる体制も必要です。
Web通知と一斉配信を分けた導入例
仮想の組織で、社員用メール、会員登録の自動通知、月一回のニュースレターを別のサービスで送るとします。社員用メールだけを試して正常だったとしても、月次の送信を確認するまでは、すべての正規経路を検証したことにはなりません。送信量の多さだけで重要度を判断せず、利用者の復旧や請求に必要な通知も対象にします。
本サイトの提案は、最初に業務ごとのテストメールを送信し、受信側の認証結果と表示されたFromを対応付けることです。SPFやDKIMが成功していても、認証されたドメインが期待したものかを確認します。配信サービスの初期設定のまま送った場合と、独自ドメインを正規の手順で設定した場合を同じと考えないでください。
観測段階では、レポートに現れた送信元を担当者へ照会し、正規、廃止予定、不明に分けます。不明な送信元をすべて許可へ追加するのではなく、利用する必要があるサービスかを先に確認します。古い仕組みを止められるなら、認証の例外を増やすより送信経路を減らす方が管理しやすくなります。
方針を変更する日には、重要な通知の成功を受信側で確認し、配送エラーと問い合わせの増加を見ます。切り戻す場合も、理由を記録せず観測段階へ戻したままにしないでください。設定の不一致を直す担当者と次の確認日を決め、正規の配送を守りながら方針を進めます。
| 送信業務 | 確かめるメール | 確認する結果 |
|---|---|---|
| 会員登録 | 登録直後の自動通知 | 表示Fromと認証ドメインの整合 |
| パスワード再設定 | 専用アカウントの再設定通知 | 配送と正規リンクの案内 |
| ニュースレター | 実際の配信サービスの試験便 | DKIM・SPF・DMARCと転送時の挙動 |
| 問い合わせ | 管理者通知と利用者への返信 | それぞれの送信経路と認証結果 |
新しい配信サービスを追加するときの承認
配信サービスの契約時にDNS設定の依頼だけが届くと、何のメールを誰が送るかが不明なまま許可が増えます。送信する業務、利用するFrom、設定を管理する担当者、停止時の手順を申請の段階で確認すると、後の棚卸しを減らせます。
運用終了時には、提供元の説明に沿って不要な認証設定や権限を整理し、残す必要のあるドメイン設定と区別します。削除前には別の業務が共有していないかを確認してください。DMARCの導入を一度きりのDNS作業ではなく、送信元の追加と廃止に連動した変更管理にすることが重要です。
スポンサーリンク
成功率だけで判断しない評価方法
集計の成功率が高くても、件数の少ない重要通知だけが失敗している可能性があります。総数だけでなく、業務ごとの送信、提供サービス、認証されたドメインを分けて見ます。利用者がアカウントへ戻るための再設定通知などは、量が少なくても個別に試験する価値があります。
逆に、大量の不明な送信が失敗として現れた場合、それを減らすために許可を広げるのは本末転倒です。正規の送信と関係があるかを確認し、攻撃の可能性と設定ミスを別々に扱います。レポートの数字を、侵害されたアカウント数や被害件数へ読み替えないようにしてください。
社内へ報告する場合は、設定済みという事実、実メールで確認できた経路、まだ確認していない経路、次に適用する方針を分けて記載します。すべての偽メールを防げたと案内するのではなく、守れるドメインと残る業務上の対策が分かる説明にします。
守れる範囲と守れない範囲を共有する
DMARCは、自社の正確なドメインを名乗るメールの扱いを改善するために有効です。しかし、よく似た別ドメインや表示名の詐称、正規アカウントを奪われた後の送信まで、同じ仕組みだけで防げるわけではありません。メール認証の合格を、送金や権限変更の承認に置き換えないようにします。
運用の確認では、新しい配信サービスの追加、ドメインの変更、担当者交代を見直しのきっかけにします。DNSにレコードが存在することだけでなく、今動くメールが想定した認証と整合を満たすことを継続して確認します。
優先順位は、送信元の棚卸し、実メールの認証結果の確認、レポートの運用、方針の段階適用です。認証の設定と、重要な依頼を別経路で確かめる業務手続きを組み合わせることが、Web運営にとって実効性のあるなりすまし対策になります。
スポンサーリンク
参考資料
以下は本文の作成時に直接確認した一次資料です。確認日は2026年10月18日です。設定や提供条件は、利用環境に対応した資料も確認してください。
