独自ドメインのメール認証：SPF・DKIM・DMARCと外部送信を点検
この記事の内容
独自ドメインのメール認証を見直すときは、普段使うメールだけでなく、予約、請求、問い合わせフォームなど、会社名義で送信するサービスをすべて確認します。正規の送信元を把握せずにDMARCの設定を厳しくすると、必要なメールまで届きにくくなる場合があります。
この記事では、少人数の事業者がDNS設定を変更する前に作る一覧と、確認する順序を説明します。具体的なレコード値は利用サービスで異なるため、自社の公式手順に合わせて設定してください。
会社のドメインで送るサービスを列挙する
最初に、通常のメール、予約通知、請求書送付、メール配信、Webサイトのフォーム、自動化ツールを一覧へ載せます。事業主が普段ログインしていないサービスからも、会社のアドレスで送信していることがあります。
一覧には、サービス名、表示される差出人アドレス、担当者、送る頻度、認証設定の公式案内、テスト結果を記録します。月末にしか送らない請求メールや、予約が入った時だけ送る通知も含めてください。
架空の会社で、通常メールがGoogle Workspace、予約通知が別サービス、請求書が会計ソフトなら、三つの送信経路を確認します。Workspaceの設定だけを済ませて「会社のメール認証は完了」と判断しないことがポイントです。
SPF・DKIM・DMARCの役割を区別する
SPFは、そのドメインに代わって送信するサーバー等を示す仕組みです。DKIMは送信メールに付ける署名を使い、DMARCは表示上の差出人ドメインと認証の整合を確認し、認証に合わないメールへの扱いを示します。
| 仕組み | 確認する主な対象 | 点検時の問い |
|---|---|---|
| SPF | 許可する送信元 | 正規の送信サービスが含まれるか |
| DKIM | 送信時の署名 | 対象ドメインで署名されるか |
| DMARC | 認証と差出人の整合・方針 | 正規メールが条件に合うか |
| レポート | 認証結果の集計 | 誰が読み問題を確認するか |
Googleの公式案内では、SPFレコードは各ドメインに一件とし、その中へ必要な送信元を含める構成が示されています。サービスを追加するたびにSPFのTXTレコードを別々に増やす方法は避け、既存の値と公式指示を照合します。GoogleのSPFレコード解説
既存のDNS値と設定担当を確認する
DNSを変更する前に、現在のレコード名、種類、値、TTL、変更日時を控えます。ドメインを取得した会社と、現在DNSを管理する会社が違う場合もあるので、実際に反映される管理画面を確認してください。
DKIMでは、DNSへ公開鍵の情報を追加するだけでなく、送信サービス側で認証を開始する操作が必要な場合があります。Google Workspaceの設定手順も、管理画面とDNSの作業を含みます。GoogleのDKIM設定
既存のレコードを削除して最初から作り直す前に、何のサービスが使っているかを調べます。使途が不明な値は、外部の制作会社や過去の担当者へ確認する対象です。設定に自信がない場合は、自社の送信元一覧と現行値を用意して、管理事業者へ相談すると話が進みやすくなります。
DMARCはレポートを見ながら段階的に進める
GoogleはDMARCを段階的に導入し、まず監視のための方針から始め、レポートを確認して次の方針へ進む手順を案内しています。一般にnoneは監視段階、quarantineは隔離、rejectは拒否を求める方針ですが、受信側の処理も関わるため、到達を保証する設定ではありません。GoogleのDMARC導入手順
レポートの受取先は、担当者が変わっても会社で確認できる窓口にします。届いているだけで誰も見ない状態では、問題を発見できません。外部の解析サービスを使う場合は、料金と扱う情報を確認します。
公式の例にあるメールアドレスや値を、そのまま自社のDNSへ貼らないでください。自社のドメイン、受取先、送信構成に合わせて作成します。また、観測期間は日数だけでなく、月次請求など頻度の低い正規メールも確認できたかで判断します。
送信経路ごとに認証結果と到達を確認する
テストでは、通常メールだけを一通送って終えず、予約通知、フォームの自動返信、請求送付など、実際に使う経路を確認します。顧客へ試験メールを一斉送信する必要はなく、自社で管理する確認用の宛先やサービスの試験機能を使います。
記録するのは、送信日時、送信サービス、差出人、受信先、届いた場所、SPF・DKIM・DMARCの結果です。Googleのトラブルシューティングは、メールヘッダーから認証結果を調べる方法を案内しています。GoogleのDMARC問題調査
架空の確認結果で、通常メールは通るが予約通知だけ認証に合わないなら、ドメイン全体を緩めたままにする前に、そのサービスの正規の設定を確認します。転送など経路の違いも影響するため、結果の一部だけで原因を断定しないようにします。
変更履歴と戻す条件を残す
設定の変更は、一度に多くの値を変えるより、どの変更が何に影響したかを確認できる単位で行います。変更前後の値、実施者、理由、確認した送信経路を残します。
問い合わせが増えた、正規メールの不達を確認した、レポートに説明できない失敗がある、といった場合に誰へ相談するかを決めます。戻す場合も現行値と影響を確認し、記録した以前の構成へ適切に戻せるようにします。DNSの変更が即時にすべての受信先へ反映される前提にはしません。
メール認証は一度設定して終わりではありません。新しい送信サービスの導入、ドメイン変更、委託先の交代が見直しの契機になります。認証が合格しても必ず受信箱へ届くとは限らないため、配送状況や顧客からの連絡と合わせて運用します。まずは正規の送信元一覧を作るところから始めましょう。