SPF・DKIM・DMARCの状態は、無料の確認サイトでDNSのレコードを見て、実際に送ったメールのヘッダーを読めば分かります。
今日やることは、自社のドメインから手元の別のメールアドレスへ1通送り、その結果を記録することです。専門のツールを入れる必要はなく、管理者の権限も要りません。使うのはブラウザとメールソフトだけで、確認する経路が1つなら短い時間で終わります。
調べる場所はなぜ2か所ある？
DNSを見ると「レコードが置かれているか」が分かり、ヘッダーを見ると「実際のメールが認証に通ったか」が分かります。どちらか片方では判断を誤ります。
レコードが正しくても、登録していないサービスから送ったメールは失敗します。逆に、ヘッダーで1通合格しても、ほかの経路が合格している保証にはなりません。Googleの送信者ガイドラインも、メールサービスのプロバイダを利用している場合は、プロバイダがSPFとDKIMで認証していることを確かめるよう求めています。
手順1：確認サイトでDNSのレコードを見る
Google Admin ToolboxのDigは、ドメイン名を入れるとDNSの内容を表示する無料の道具です。Check MXにも、MXとSPFのレコードを確かめる機能があります。example.co.jp の部分を自社のドメインに替えて、次の2か所を調べます。
| 調べるもの |
入れる名前 |
見る内容 |
| SPF |
example.co.jp |
v=spf1 で始まるTXTが1本あるか |
| DMARC |
_dmarc.example.co.jp |
v=DMARC1 で始まるTXTがあるか |
SPFの行が2本ある場合は、それだけで設定の誤りです。Microsoftの文書のとおり、同じドメインに複数のSPFレコードがあるとpermerrorになります。直し方はSPFの設定方法と複数サービスの注意点で説明しています。
DMARCの行では p= の値を読みます。Googleの文書によると、意味は次のとおりです。
- p=none：メールをそのまま配信し、記録だけ行う
- p=quarantine：認証に失敗したメールを迷惑メールとして扱う
- p=reject：認証に失敗したメールを拒否する
p=none は未設定ではなく、確認の段階にあたります。Microsoftの文書も、テストとチューニングに使う値と説明しています。あわせて rua= があるかを見ます。これは集計レポートの送り先で、Googleは常に含めるよう案内しています。
DKIMはこの段階では調べません。レコード名にセレクターという値が入るので、ドメイン名だけでは探せないためです。手順3で実際のメールから値を取ります。
手順2：実際のメールのヘッダーを読む
自社のドメインから、自社以外のアドレスへ1通送ります。受け取った側でヘッダーを開きます。開き方はメールソフトごとに異なります。
ヘッダーの中で Authentication-Results という行を探します。形はMicrosoftの文書に載っていて、次のように並びます。
spf=pass (sender IP is 192.168.0.1) smtp.mailfrom=contoso.com
dkim=pass (signature was verified) header.d=contoso.com
dmarc=pass action=none header.from=contoso.com
見る点は2つです。1つ目は spf=、dkim=、dmarc= の結果です。2つ目は smtp.mailfrom=、header.d=、header.from= のドメインが自社のものか、です。
ヘッダーは長く読みにくいので、貼り付けて整形してくれる道具も使えます。GoogleのMessageheaderやMicrosoftのMessage Header Analyzerです。ヘッダーには社内のサーバー名やアドレスが含まれるので、社外秘にあたるメールではなく、確認用のテストメールで使います。
手順3：DKIMのレコードを確かめる
同じヘッダーの DKIM-Signature の行を探します。d= が署名したドメイン、s= がセレクターです。DNSでは セレクター._domainkey.ドメイン名 という名前で公開されています。
Googleの文書によると、Google Workspaceのセレクターのデフォルトは google です。Microsoft 365ではCNAMEレコードを使い、selector1 で始まる形の値が例として出ています。DKIM-Signatureの行が無ければ、そのメールには署名が付いていません。
結果ごとに次にすることは？
| ヘッダーの結果 |
読み方 |
次にすること |
| 3つともpass |
その経路は合格 |
ほかの経路も同じように確かめる |
| spf=permerror |
レコードが2本、または参照が10回超など |
SPFレコードを1本にまとめ、参照を減らす |
| dkim=none |
署名が無い |
メールサービスの案内どおりDKIMを有効にする |
| dmarc=none |
DMARCレコードが無い |
SPFとDKIMを確かめてからDMARCを置く |
| spfはpass、dmarcはfail |
認証されたドメインとFromが不一致 |
サービス側で独自ドメインの署名を設定する |
最後の行は、見落としやすい形です。Microsoftの文書によると、DMARCはSPFやDKIMに合格したドメインと、Fromアドレスのドメインが揃っているかを確かめます。配信サービスが自社のドメインで送っていると、spf=pass でも smtp.mailfrom= がそのサービスのドメインになり、Fromと揃いません。同じ文書のとおり、SPFとDKIMの両方の確認に失敗するとDMARCも失敗します。
DMARCをこれから置く場合は、順番を守ります。Googleの文書は、SPFやDKIMの設定後、48時間あけてDMARCを設定するよう案内し、最初のポリシーは none にするよう勧めています。
どの経路まで調べればいい？
自社のドメインを差出人にしている経路をすべて調べます。社員が普段使うメールだけでは足りません。
たとえば、製造業の会社が受発注システムの通知、問い合わせフォームの自動返信、展示会の案内メールを同じドメインで送っている場合です。社員のメールは合格でも、システムの通知だけ dkim=none ということが起こりえます。発注や納期の連絡が取引先で迷惑メールに入れば、業務に影響します。経路ごとに次のような表を作って残します。
| 経路 |
spf / dkim / dmarc |
確認した日 |
| 社員の通常メール |
|
|
| 受発注システムの通知 |
|
|
| フォームの自動返信 |
|
|
| 案内メールの配信 |
|
|
新しいサービスを入れたときと、DNSを触ったときに表を更新します。実メールで確かめる理由は、DNSの見た目が正しくても、経路ごとに結果が変わるからです。Microsoftの文書によれば、SPFは左から順に評価され、一致した時点で止まるので、参照の上限を超えていても失敗しない送信元があります。
受信側が送信者に認証を求める例もあります。Gmailはすべての送信者にSPFかDKIMを求め、1日5,000件以上の送信者にはSPF、DKIM、DMARCのすべてを求めています。Yahooも一括送信者に3つの設定を求めています。
自社で直せないときは？
レコードの変更先が社外の制作会社やプロバイダなら、調べた表をそのまま渡すと、どの経路の何を直すかが伝わります。経路が多くて手が回らない場合は、DMARC導入・運用支援サービスの比較で支援の範囲を確かめられます。DNSの設定を預ける相手や管理の守りまで見直すならDNSセキュリティの比較もあわせて見てください。
なりすましを防ぐ設定は、自社の名前を守る側の対策です。自社に届くメールの守りは別の話なので、メールのセキュリティ対策とメールセキュリティ製品の比較で確かめます。
