SPF・DKIM・DMARCの考え方がわかる｜メール認証の仕組みを図解
【Web自動化ツール技術解説】シリーズ
Web自動化ツールを安心して活用するために知っておきたい技術的な仕組みを、わかりやすく解説するシリーズです。専門用語にとらわれず、ツールの動きや設定の意味を理解できるように説明します。
こんにちは、LincWebの水野です。
多くのWeb自動化ツールには、メール配信機能がついています。ステップメールを送ったり、予約完了メールを自動送信したり、見込み客へのフォローを仕組み化したり。今や「メール配信」は自動化の中心ともいえる存在です。利用している個人事業主の方も多いでしょう。
しかし、この機能を使う前に、必ず設定しなくてはならない項目があります。
それが「SPF」「DKIM」「DMARC」と呼ばれるメール認証の設定です。メール認証技術は、なりすましメールやフィッシング詐欺などを防ぐために、本当に正しい送信元が送信したメールであるかを確認するためのものです。
メルマガやステップメールを配信する上では、このメール認証の設定を正しく行っておかないと、どんなに魅力的な内容のメールを送っても、迷惑メールに入ってしまったり、届かなかったりすることがあります。
つまり、メール配信を始めるためには、まず「信用される送信者」とみなされるための準備が必要なのです。メールという基盤ツールを安定して運用できることは、あなたのビジネスの信頼感にも直結すると言えるでしょう。
とはいえ、SPF、DKIM、DMARCといった言葉だけを見ると、「難しそう」と感じる方も多いでしょう。本記事では、そうした方に向けて、これら3つの仕組みをできるだけわかりやすく解説します。メール配信を安心して自動化するための「基礎知識」として、ぜひここで理解を進めておきましょう。
「Web自動化ツール技術解説」記事一覧
▶ 第1回 SPF・DKIM・DMARCの考え方がわかる｜メール認証の仕組みを図解
（今後追加予定）
目次
SPFとは？送信元のサーバーを確認する仕組み
まず最初に登場するのが「SPF（Sender Policy Framework）」です。
これは、「自分のドメインのメールは、どのメールサーバーから送るか」を、DNS上のSPFレコードで宣言しておく仕組みです。SPFの仕組みを理解するために、郵便の例に例えて説明します。
上の図では、あなたがLincUpから郵便（封筒）を受け取ったときに、これがLincUpから届いた封筒であることをどう確認するかを、SPFの仕組みに則って考えてみます。
あなたは封筒を見たとき、「これ本物かな？」と思い、まず消印を確認します。消印には「東京中央郵便局」とあります。さらにLincUpのホームページをみたら、「当社の郵便は東京中央郵便局から発送します」と書かれていました。この2つが一致したら、「あ、本物かもしれないな」と思うことでしょう。
SPFでは、まさにこれと同じことをDNSの仕組みを使って行っています。送信者は、「このドメインのメールは、このメールサーバー（IPアドレス）から送ります」とSPFレコードに登録しておき、受信者のサーバーは、届いたメールが「登録されたメールサーバーから送られた」かをチェックするのです。郵便の例で言えば、郵便局がメールサーバーにあたるわけです。
つまり、SPFは「郵便が正しい郵便局から出されたか＝メールが正しいメールサーバから送信されたか」をチェックする仕組みと言えます。
多くのスパムメールやなりすましメールは、海外の不正サーバーや自前の送信環境から送られています。そのような「登録されていないサーバー」から送られてきたメールを、受信側はSPFを使って「なりすましの可能性あり」と判断し、迷惑フォルダに振り分けたり、受信を拒否したりできるのです。
このようにSPFは、送信元サーバーの正しさを確認し、ドメインの信頼性を守るための第一ステップとなる仕組みと言えます。
DKIMとは？メールの改ざんを防ぐ仕組み
次に登場するのが「DKIM（DomainKeys Identified Mail）」です。
これは、送信者が自分のドメインに紐づく電子署名をメールに付与し、「このメールは確かに自分が送ったものであり、途中で改ざんされていない」ことを証明する仕組みです。ここでも、郵便の例に置き換えて考えてみましょう。
上の図では、あなたがLincUpから郵便（封筒）を受け取ったときに、中身が改ざんされていないことをどう確認するかを、DKIMの仕組みに基づいて表しています。
封筒を見ると、しっかり封がされており、封のところに割り印が押されています。どうやら割り印が押された後に開封はされていないようです。次にあなたは「この印鑑は本物だろうか？」と考え、「印鑑登録名義：LincUp」に基づいて法務局で保管されている印鑑登録証明書を確認したところ、印影も一致していました。この場合、「確かにLincUpが押した印鑑だ。封も開けられていない」と判断できますよね。
DKIMでは、この流れを電子的に実現しています。送信者はメールを送信する際、自分だけが持つ秘密鍵で電子署名を付与し、対応する公開鍵をDNSサーバー上にDKIMレコードとして登録します。受信側のサーバーは、その公開鍵を使って署名を検証し、「署名を付けたのは確かに送信元か」「本文やヘッダーが改ざんされていないか」を確認します。
つまり、DKIMは「メールの内容が途中で書き換えられていないこと」を保証するための仕組みと言えます。
SPFが「正しい郵便局から出されたか」を確認する仕組みだとすれば、DKIMは「中身が途中で書き換えられていないか」を確認する仕組みです。この2つが組み合わさることで、メールの信頼性を高めることができるのです。
DMARCとは？SPFとDKIMの整合性を確認して最終判断を行う仕組み
最後に登場するのが「DMARC（Domain-based Message Authentication, Reporting & Conformance）」です。
これは、SPFとDKIMの検証結果を照合し、それぞれがメールの差出人ドメイン（From）と整合しているかを確認したうえで、最終的にそのメールをどう扱うかを判断する仕組みです。さらに、送信ドメインの管理者が「認証に失敗したメールをどう処理してほしいか」というポリシー（方針）を受信側に伝える役割も担っています。
上の図では、あなたがLincUpから届いた郵便を受け取り、DMARCの仕組みに基づいてそれが本物かどうかを総合的に判断する流れを示しています。
封筒を見ると、差出人の住所は「東京都中央区」で、消印も「東京中央郵便局」なので、住所に合った郵便局から発送されていることがわかります。次に、差出人の名前は「LincUp」で、印鑑の登録名義も「LincUp」なので、確かに差出人が割り印を押したことがわかります。このように、差出人の情報と消印・印鑑が整合しているため、「これは本物の郵便だな」と判断することができます。
ちなみに、差出人の情報が消印や印鑑名義と合わない場合に郵便物をどう扱えばよいか、発送元がそのポリシーを公開します。上記の例では、整合性に問題があった場合、「不審な郵便物として保管してください」というポリシーになっています。
DMARCは、この整合チェックを電子的に行います。受信サーバーは、SPFとDKIMそれぞれの結果を確認したうえで、差出人（From）の情報とSPFやDKIMの確認に使ったドメインが整合するかを照合し、一致していない場合には「なりすましの可能性あり」と判断します。
さらに、送信元のドメイン管理者は、DNS上のDMARCレコードにポリシーを設定し、DMARC認証に失敗した場合に、受信者にメールをどう扱ってもらいたいかを宣言します。
・none（監視）：メールを受け入れてほしい
・quarantine（隔離）：迷惑メールフォルダに入れてほしい
・reject（拒否）：メールを破棄してほしい
受信側のメールサーバーは、送信元ドメインの管理者がDNS上で公開している「DMARCポリシー」を参照し、実際の処理（監視・隔離・拒否）を決定します。
SPFが「正しい郵便局から出されたか」、DKIMが「印鑑登録された印鑑で封印されているか」を確認する仕組みだとすれば、DMARCは、これら2つの整合性をチェックし、最終的に受け入れるか拒否するかを判断する仕組みと言えます。
この3つを正しく設定することで、あなたのドメインから送信されるメールは高い信頼性を保ち、迷惑メールフォルダに入るリスクを減らすことができるのです。
なぜWeb自動化ツールでメール認証の設定が必要になるのか？
ここまで見てきたように、SPF・DKIM・DMARCは「正しい送信元から届いたメールかどうか」を判断するための仕組みです。ではなぜ、LincUpのようなWeb自動化ツールを使うと、「メール認証の設定」を自分で行う必要が出てくるのでしょうか？
ポイントは、「どのサーバーからメールを送るか」が変わることです。
通常のメール送信と、メール配信サービスを使ってメール送信を行う場合の違いを、図を使って見ていきましょう。
通常のメール送信の場合
例えば、あなたが独自ドメイン（例：example.com）をXserverで契約し、そのメール機能を使ってメール送信する場合を考えてみましょう。
このとき、メールは「Xserverのサーバー」から送信され、DNS（ドメインの設定情報）にも「このドメインのメールはXserverから送信する」という情報（SPF・DKIM・DMARC）があらかじめ登録されています。送信と照合の両方がXserver内で完結しているため、特別な設定を追加する必要はありません。
つまり、送信元（Xserver）＝認証情報を登録しているサーバー（Xserver）となっており、うまく動作します。
Web自動化ツールから送信する場合
一方、LincUpやSendGridなどのWeb自動化ツールやメール配信サービスを使うと、あなたが持っている独自ドメイン（example.com）のメールを別のサーバー（LincUpのサーバー等）から送信することになります。
ここで問題になるのが、「DNS上の登録情報（SPF・DKIM・DMARC）」です。DNSにはまだ「Xserverが送信します」としか書かれていないため、LincUpから送られたメールを受け取った側のサーバーは、こう考えます。
「このメール、差出人はexample.comって書いてあるけど、送信したのはLincUpサーバーだ。DNSにはLincUpの情報が登録されていないな……。これは本物なのだろうか？」
結果として、SPFやDKIMの認証が失敗し、メールが迷惑フォルダに入ったり、拒否されることがあります。
これを防ぐには、あなたの独自ドメイン（example.com）のDNSサーバーに、「example.comのメールはLincUpサーバーから送信されることがあります」という情報を登録しておく必要があります。
具体的には、LincUpから提供されるSPF・DKIM・DMARCの各レコードを、あなたの独自ドメインのDNSに追加します。これにより、受信側のサーバーは次のように判断できるようになります。
「LincUpサーバーから送られてきたけど、DNSに登録がある。ということは、このメールは正規のメールサーバーから送信されたものだな。」
図のように、XserverのDNSには、LincUpのSPF・DKIM・DMARC情報が追加登録され、受信者はDNSサーバーを参照することで「確かにLincUpからの正当な送信」と確認できるようになります。
Web自動化ツールでメール認証の設定が必要になる理由は、あなたのドメインを管理している業者とは別のサーバーからメールが送信されるからです。そこで、SPF・DKIM・DMARCの設定をDNSサーバーに追加することで、受信側のサーバーが「あなたが承認したサーバーから送られた正当なメール」だと判断できるようになるのです。
これにより、あなたのメールは「届くメール」になり、迷惑メール判定を大幅に減らすことができるのです。
まとめ
SPF・DKIM・DMARCは、どれも「本当に正しい送信元から届いたメールか」を確認するための仕組みです。Web自動化ツールを使うときに設定が必要になるのは、あなたのドメインを使っていても、実際の送信サーバーが別になるからです。
DNSにこれらの認証情報を登録しておけば、受信側のサーバーは「このツールから送られたメールは正当なものだ」と判断し、メールが正しく届くようになります。メール認証の設定はテクニカルな作業ではありますが、本質的には「あなたのビジネスの信頼性を担保すること」が目的です。
このように、顧客に安心してメールを届けるための「信頼の基盤」を構築することは、あなたのビジネスの信頼感にもつながる重要な要素とも言えるでしょう。
次回は、実際にSPF・DKIM・DMARCの具体的な設定方法について、テクニカルな観点から解説していきます。
「Web自動化ツール技術解説」記事一覧
▶ 第1回 SPF・DKIM・DMARCの考え方がわかる｜メール認証の仕組みを図解
（今後追加予定）
