最初のDMARCレポートには、ほぼ必ず驚きがあります。見覚えのないIPアドレスが、あなたのドメインをFromに使って何千通ものメールを送っているのです。昨年の春に営業チームが登録したツールのこともあれば、転送サービスのこともあります。まれに、あなたになりすましている第三者のこともあります。このガイドでは、不明な送信元を一つずつ特定し、分類し、対処を決めるための再現性のある手順を紹介します。推測に頼らず、正規のメールを壊すこともありません。
結論#
DMARCレポートで不明な送信元を特定するには、その送信元IPについて次の4つの確認を順番に行います。IPの逆引きDNS（PTR）名、そのIPが自社または委託先ベンダーが公開しているSPFのincludeでカバーされているか、生のレポートにあるDKIM署名のドメイン（d=）、そしてレジストリ検索で分かるIPブロックの所有者です。そのうえで、その送信元を次のいずれかに分類します。忘れられたサービス、自社のサーバーまたはスクリプト、転送サービス、社内メールのプロバイダー、なりすまし。正規の送信元は認証を通し、転送サービスはほとんどの場合そのままにし、なりすましはp=rejectに任せます。どのグループに属するかが分かる前に、送信元をブロックしたり「修正」したりしてはいけません。最初の確認には無料の逆引きDNS検索が使え、1件のレポートの生のフィールドを確認するには無料のDMARCレポート解析が使えます。
まずレポートがすでに示している情報を集める#
何かを調べる前に、その行から分かることをすべて集めましょう。不明なIPごとに、次を書き留めます。
- IPアドレスと、送信したメッセージ数。
- SPFとDKIMの結果と、それぞれがFromドメインとアライメントしていたかどうか。
- ディスポジション、つまり受信側がどう処理したか（none、quarantine、reject）。
- 生のXMLが見られる場合は、SPFとDKIMのチェックに使われたドメイン。
最後の項目は、思う以上に役立ちます。DKIMがd=example.comで成功している行は、あなたのドメインの下で公開された鍵で署名されていることを意味し、あなたか、あなたが設定したベンダーが用意したものだと分かります。DKIMがd=vendor.example.netで成功し、SPFもベンダーのバウンスドメインで成功している行は、ベンダーが自分自身のために認証済みメールを送っていて、あなたのドメインはFromに載っているだけだということです。これは典型的な、アライメントしていないサードパーティの送信元です。SPFとDKIMの両方が失敗しているか存在しない行は、なりすましか、未設定のリレーである可能性がはるかに高くなります。
お使いの監視ツールが送信元にわかりやすい名前を表示している場合も、それはヒントであって証拠ではありません。名前は逆引きDNSのパターンから推測されたものなので、以下の手順で必ず確認してください。
ステップ1：逆引きDNS名を調べる#
正規の送信元のほとんどは、送信に使うIPにPTRレコードを公開しています。逆引きを実行します。
dig -x 203.0.113.42 +short
mail-42.sendingplatform.example.net.
ホスト名がサービス名そのものを示していることはよくあります。ただし、2点注意が必要です。
- 正引きで確認する。 そのホスト名のAレコードを調べ、同じIPが返ることを確認します。PTRレコードはIPの所有者が管理するため、誰でも好きな名前を名乗れます。信頼できるのは、同じIPに正引きできる名前だけです。
- PTRがない、または汎用的な名前であること自体が情報になる。
static-203-0-113-42.hosting.exampleのようなホスト名は、たいていレンタルサーバーか家庭用回線であり、メール配信プラットフォームではありません。これは、評判の良いベンダーよりも、なりすましや自前のスクリプトに当てはまります。
ターミナルが手元にない場合は、逆引きDNS検索ツールでワンクリックで調べられます。
ステップ2：そのIPがSPFの範囲に入っているか確認する#
自分のSPFレコードを見て、このIPが直接、またはincludeを通じてカバーされているかを確認します。
example.com. TXT "v=spf1 include:_spf.google.com include:sendingplatform.example.net ~all"
ステップ1で分かったベンダー名がすでにinclude:に含まれているなら、過去に誰かが許可したということです。その送信元はあなたのもので、残る疑問はなぜアライメントに失敗しているのかです。多くの場合、ベンダーのSPFはベンダー自身のバウンスドメインで成功しており、それはFromドメインとアライメントせず、かつあなたのドメインのDKIM署名が設定されたことがないためです。対処はDKIM側で行います。詳しくはDMARCアライメントの失敗で説明しています。
IPがカバーされていないうえに、PTRが聞いたこともないベンダーを指している場合は、忘れられたサービスか、見知らぬ第三者のどちらかです。調査を続けましょう。ドメインをSPF・DKIM・DMARCチェッカーにかければ、現在のSPFレコードの内容も確認できます。
ステップ3：DKIMの署名ドメインを読む#
生のレポートにDKIMの結果が載っている場合、署名ドメインとセレクターが記されています。よくあるパターンは3つです。
d=が自分のドメイン。 社内システム、または設定済みのベンダーが、あなたの鍵で署名しています。DNSでセレクターを探せば、どの鍵か分かります。セレクターに見覚えがなければ、DKIMセレクターの調べ方を確認してください。d=がベンダーのドメイン。 認証はベンダーのためのもので、あなたのためではありません。ベンダーを特定できれば修正できます。- DKIMの結果がまったくない。 送信元は署名していません。小さなスクリプト、プリンター、古いCMSプラグイン、そしてなりすましは、どれもこの見え方になります。
レポートではなく受信したメッセージのヘッダーしか手元にない場合は、メールヘッダー解析でDKIMの判定と署名の有無を確認でき、d=のドメインはDKIM-Signatureの行から自分で読み取ります。
ステップ4：IPブロックの所有者を調べる#
PTRがない、または手がかりにならない場合は、地域インターネットレジストリにそのアドレスを問い合わせます（WHOISまたはRDAP検索）。結果には、そのブロックを保有する組織名が出てきます。多くはホスティング会社かクラウドプロバイダーです。これが示すのはトラフィックの発信元であって、誰に責任があるかではありません。調査の範囲を絞るために使い、誰かを非難する根拠にはしないでください。有名なメール配信プラットフォームが所有するブロックなら、「忘れられたベンダー」という見方を裏付けます。逆引きDNSのない格安ホスティング会社のブロックなら、逆の方向を示します。
分類してから対処する#
4つの確認を終えると、ほとんどの送信元は次の5つのグループのどれかに入ります。
| 分類 | レポートでの見え方 | 対処 |
|---|---|---|
| 忘れられた、または未承認のサービス | PTRが既知のプラットフォームを示す。SPFまたはDKIMがベンダーのドメインで成功し、あなたのドメインでは成功していない | 担当者に確認する。必要なメールなら、お使いのドメインのDKIM署名を追加する。不要なら、アカウントを閉鎖する |
| 自社のサーバーまたはスクリプト | IPが自社のホスティングと一致する。DKIMがないことが多い。深夜など変な時間帯に少量 | 正規のメールシステム経由で送るか、自社の鍵で署名する |
| 転送サービスまたはメーリングリスト | 送信元がメールボックスプロバイダーまたはリストのホスト。SPFは失敗する。DKIMは成功することもあるが、メッセージが改変されると壊れる | 基本的には無視する。DKIMのアライメントに頼り、転送サービスを一つずつ追いかけない |
| 社内メールを中継するメールボックスプロバイダー | 社内メールで使っているプロバイダーと一致する | そのプロバイダーがSPFに含まれ、あなたのDKIM鍵で署名していることを確認する |
| なりすまし | 自社と無関係。PTRがない、または汎用的。SPFもDKIMも失敗。急に量が増える | 失敗のままにしておく。rejectポリシーはこのためにある |
避けたいのは、見慣れないものをすべてなりすましとみなすことです。忘れられた請求書発行ツールがまだアライメントに失敗しているうちにポリシーを厳しくすると、自社の請求書を自分で拒否することになります。先に分類しましょう。安全にポリシーを厳しくしていく順序は、p=noneからp=rejectへの移行で説明しています。
次回の特定を楽にする#
最初の1回は時間がかかります。2回目以降は、もっと短く済むはずです。次のような習慣が役立ちます。
- 一覧を作っておく。 正規の送信元ごとに1行、担当者、メールの種類、認証方法を記録します。簡単なシートの作り方はDMARCモニタリングで紹介しています。
- 新しいツールは導入前に確認する。 「このツールは当社のドメインで送信するか」という簡単な確認ステップを設けるだけで、不明な送信元の大半を防げます。
- 古いアカウントを見直す。 無料トライアルや代理店のツールが動いたままになっているのは、予想外の送信元としてよくある原因です。
- 判断を記録する。 ある送信元を転送によるノイズと判断したら、次の担当者が同じ調査を繰り返さないよう書き残します。
DMARCレポートは、名前の特定を助けます。送信元IPごとに逆引きDNSを引き、Google、Microsoft 365、Amazon SES、SendGrid、Mailchimpなど約25の一般的な送信元を識別します。識別できないものは、生のホスト名か「Unknown sender」として表示されます。送信元にタグやラベルを付けたり、許可リストに入れたりすることはできないため、台帳としては引き続き自作のシートが基準になります。また、送信元のDKIM署名ドメインやセレクターも表示されないため、ステップ3には生のレポートか受信メッセージのヘッダーが必要です。生のファイルが欲しい場合は、rua=のリストにメールボックスのアドレスも残しておいてください。
送信元がなりすましだった場合は？#
その送信元があなたと無関係だと証拠が示しているなら、修復すべきことはほとんどありません。やるべきは、失敗が実際に効力を持つようにすることです。rejectポリシーを設定し、正規のメールを認証できていれば、DMARCに対応する受信側は、なりすましメールを拒否するか迷惑メールに振り分けます。なりすましの送信そのものは止められません。できるのは、あなたのポリシーを適用する受信側で、そのメールが失敗するようにすることだけです。
次のような追加の対応も妥当です。
- 後の週と比較できるよう、量と日付を記録しておく。
- 送信元IPを、ブラックリストチェッカーで公開ブロックリストに照合する。
- キャンペーンが大規模で、顧客を狙っている場合は、サポートチームにそのメッセージの特徴を伝える。
集計データを送らない小規模な受信側もあるため、レポートで全体像を把握することはできません。静かな週があっても、悪用キャンペーンが終わったと考えないでください。
よくある質問
01DMARCレポートのIPアドレスの所有者はどうすれば分かりますか？
まず逆引きDNS（PTR）を調べ、そのホスト名が同じIPに正引きできることを確認します。次に、そのIPが自社のSPFレコードのincludeでカバーされているかを確認し、生のレポートからDKIMの署名ドメインを読み取ります。それでも手がかりがなければ、WHOISまたはRDAP検索でそのIPブロックを保有する組織が分かり、責任の所在を証明するわけではありませんが、調査の範囲を絞れます。
02DMARCレポートの不明な送信元は、必ずなりすましですか？
いいえ。最初のレポートに出てくる不明な送信元の多くは正規のものです。誰かが登録したマーケティングツールや請求ツール、転送サービス、あるいはスクリプトを動かしている自社のサーバーなどです。見慣れないIPをすべて攻撃者とみなすと、ポリシーを厳しくしたときに自社のメールを拒否してしまいかねません。まず送信元を分類し、自社と無関係な場合にだけ、なりすましとして扱ってください。
03転送サービスがレポートでDMARCに失敗するのはなぜですか？
メッセージが転送されると、転送サーバーのIPは自社のSPFレコードに含まれないため、SPFは失敗するか、アライメントしません。メッセージが改変されていなければDKIMは成功し続けられるため、DKIMのアライメントのほうが確実な方法です。転送によるノイズは、送信元を一つずつ追いかけるよりも、そのままにしておくほうが通常は安全です。
04不明な送信元を拒否リストに追加してブロックできますか？
DMARCに拒否リストはありません。結果はポリシーで制御します。正規の送信元はアライメントした認証を通し、それ以外は失敗します。rejectポリシーを設定すると、DMARCに対応する受信側は、失敗したメールを拒否するか迷惑メールに振り分けます。あなたのドメインを名乗った送信そのものは止められず、ポリシーを適用する受信側でそのメールが失敗するようにすることしかできません。
自分のドメインで誰が送っているかを把握するのはメール衛生の半分で、残りの半分は送信先のリストです。無料プランの料金ページでは、100クレジットでリストに対してフル検証を実行でき、無料メールチェッカーは1件ずつのアドレスに対応します。認証が整っていても、受信トレイに届くには健全なリストが必要です。
