SPFは「このドメインで送ってよいサーバー」の申告で、DKIMはメールへの電子署名です。DMARCは、その2つの結果をFromのドメインと照らし合わせ、失敗時の扱いとレポートの送り先を受信側へ伝えます。3つは競合するものではなく、役割を分担しています。
今日やることは、自社のドメインの現状を確かめることです。コマンドプロンプトで次の2行を実行すると、SPFとDMARCの有無が分かります（example.co.jpを自社のドメインに置き換えます）。
nslookup -type=txt example.co.jp
nslookup -type=txt _dmarc.example.co.jp
v=spf1 で始まる行があればSPF、v=DMARC1 で始まる行があればDMARCが公開されています。DKIMはこの方法では分かりにくいので、後の節のとおり届いたメールで確かめます。
3つの役割を1枚で分けると？
|
SPF |
DKIM |
DMARC |
| ひとことで |
送ってよいサーバーの一覧 |
メールへの電子署名 |
判定の基準と報告の依頼 |
| 受信側が見るもの |
送信元サーバーのIPアドレス |
署名と公開鍵 |
SPFとDKIMの結果とFromのドメイン |
| DNSに置くもの |
ドメインのTXTレコード |
セレクター._domainkeyの鍵（TXTやCNAME） |
_dmarcのTXTレコード |
| 仕様 |
RFC 7208 |
RFC 6376 |
RFC 9989 |
なぜ3つ要るのか。受信者の画面に見えるFromのドメインを直接守れるのは、DMARCだからです。
SPFとDKIMは、それぞれ「あるドメイン」の確認です。そのドメインが、画面のFromと同じとは限りません。Microsoftの解説のとおり、DMARCはSPFかDKIMが合格し、しかもそのドメインがFromと揃っていることを確かめます。どちらか一方が揃って合格すれば、DMARCは合格です。
DMARCだけ先に公開しても、合格の材料がありません。だからSPFとDKIMが土台になります。
DMARCの仕様は2026年5月に更新された
DMARCの仕様は、2026年5月にRFC 7489からRFC 9989へ置き換わりました。レコードは引き続き v=DMARC1 で始まります。段階導入に使われてきた pct タグは、値どおりに適用されにくかったことから削除されました。解説記事や各社の手順には pct の記載がまだ残っているので、参照する日付に気をつけてください。
自社で揃える順番は？
順番の要点は、いきなり止めず、見てから強めることです。
1. 送信元を洗い出す
自社のドメインでメールを送っているものを全部書き出します。メールサービスのほか、配信サービス、問い合わせフォーム、予約や請求のサービス、基幹システム、複合機、監視装置です。
たとえば工場がある会社なら、基幹システムの注文請書の通知や、設備の異常を知らせるメールを、社内のサーバーから自社のドメインで送っている場合があります。普段のメールの担当者が知らない送信元の代表です。後の手順でこれらが不合格になっても、DMARCのレポートを見れば気づけます。
2. SPFを設定する
洗い出した送信元をすべて、ドメインのSPFレコードに書きます。Googleのガイドラインは、サードパーティの送信者が含まれていないと、そのメールが迷惑メールに分類されやすくなるとしています。
気をつける点が2つあります。RFC 7208によれば、1つのドメインにSPFレコードを複数置くとエラーになります。サービスを足すときは行を増やさず、1行に書き足します。また、include などDNSの照会を伴う語は合計10回までで、超えるとエラーになります。配信サービスを増やし続けている会社は、ここで引っかかることがあります。
3. DKIMを設定する
送信元ごとに、自社のドメインの署名を付けます。設定の場所はメールサービスごとに違います。仕組みと、配信サービスで忘れやすい点はDKIMの電子署名の仕組みと必要な設定に分けて書きました。
SPFだけで済ませない理由は、メールが転送されるとSPFは失敗することがある一方、署名は対象が変わらない限り有効なままだからです。Googleの要件でも、大量に送る場合は両方の設定が必要です。
4. DMARCをp=noneで公開する
SPFとDKIMが整ったら、_dmarc にTXTレコードを置きます。形は次のとおりです。
v=DMARC1; p=none; rua=mailto:[email protected]
p=none は、失敗したメールの扱いを受信側に指定しないという意味で、rua は集計レポートの送り先です。Googleの手順も、最初はnoneから始めることを勧めています。レポートの宛先は、DMARCレコードと同じドメインのアドレスにするのが通常で、別のドメインへ送るには追加の設定が要ります。
5. レポートを読み、送信元の抜けを直す
ここが一番時間がかかります。レポートには、自社のドメインを名乗るメールの送信元と、合否が並びます。正規の送信元が不合格なら、SPFかDKIMを直します。知らない送信元が出てきたら、部署に確かめます。
レポートはXMLという機械向けの形式なので、そのままでは読みにくいものです。件数が多い会社は、読み解きを助けるサービスを検討する手があります。DMARC・なりすましメール対策サービスの比較で違いを見られます。
6. quarantine、rejectの順に強める
正規のメールが合格するようになったら、p=quarantine（隔離）に上げ、また様子を見てから p=reject（拒否）へ上げます。RFC 9989は、メーリングリストへ投稿する利用者がいるドメインに注意を促しています。rejectを公開する前に、少なくとも1か月はnoneで公開してレポートを確かめる形です。期間は自社の送信の周期を踏まえて決めます。月末の請求や四半期の案内など、たまにしか出ないメールも1周見てから進めます。
受信側は、指定どおりに処理するとは限りません。Microsoftの解説も、実際の扱いは宛先のシステムによると説明しています。
7. メールを送らないドメインも塞ぐ
持っていて使っていないドメインも、自社名をかたるのに使われる余地があります。Microsoftの解説は、使っていないドメインからメールが送られないようDMARCレコードを公開するよう案内しています。行政も、2023年にクレジットカード会社等へ出した要請で、メールを送らないドメインを含む導入を求めました。この要請の宛先はカード会社等ですが、考え方は参考になります。
設定できたか、どう確かめる？
DNSを見るだけでは足りません。実際のメールで確かめます。
外部のアドレスへ送ったメールのヘッダーを開き、Authentication-Resultsの行を見ます。Gmailなら「メッセージのソースを表示」です。
spf=pass
dkim=pass
dmarc=pass
Microsoftの解説にあるとおり、形式は受信側のシステムで少しずつ違います。3つのpassに加え、DKIM-Signatureの d= が自社の組織のドメインかも見ます。送信元ごとに1通ずつ確かめて、表にしておくと、次の担当者への引き継ぎにも使えます。
| 送信元 |
SPF |
DKIM（d=） |
DMARC |
| メールサービス |
pass |
pass（自社） |
pass |
| 配信サービス |
|
|
|
| 基幹システムの通知 |
|
|
|
うちの規模でも必要？
規模にかかわらず、一度は確かめる価値があります。
Googleのガイドラインは、Gmailへ送るすべての送信者にSPFかDKIMを求め、個人のGmailへ1日5,000件以上送る場合は3つとも求めています。DMARCはp=noneでも要件は満たせます。同じページは、認証されていないメールが迷惑メールに分類されたり拒否されたりすることがあるとしています。
3つを揃えても、できることには限りがあります。守れるのは自社のドメインそのものを名乗るメールです。よく似た別のドメインからのメール、表示名だけ自社名にしたメール、乗っ取られた正規のアカウントからのメールは、別の守りが要ります。送金をだます手口には振込先の変更を確かめる経理の手順で備えます。受信側はメールセキュリティ製品の比較で確かめられます。DNSの改ざんや設定の管理まで見直すなら、DNSセキュリティの比較も手がかりになります。
メールの守りのほかの論点はメールのセキュリティ対策にまとめています。作業の第一歩は、送信元の一覧です。ドメインの管理者と、配信サービスを契約している部署に、今週中に一度聞いてみてください。
