送信ドメイン認証を体系的に理解するSPF・DKIM・DMARCは何が違う？

1. Gmailに届くメールは、どこから来る？

例えば、取引先から「請求書を送ります」と届いたメール。画面には「経理部 <billing@example.com>」と見えていても、誰がその文字列を書いたのかは、それだけでは分かりません。メールは手紙の封筒と便箋のように、配送に使う情報と画面で見える情報が別々だからです。

SMTPは Simple Mail Transfer Protocol の略で、メールをリレーして配送するプロトコルです。受信メールをユーザーの端末へ取得するIMAPやPOP3とは役割が異なります。MX（Mail Exchanger）は配送先メールサーバーを示すDNSレコード、TXTはSPFやDMARC等のポリシー文字列を公開するためのレコードです。

2. なぜ差出人を偽装できるのか：FromとMAIL FROM

メールには、画面に表示される From: ヘッダーと、配送エラーの返送先などに使うSMTPの MAIL FROM（Envelope From）が存在します。後者は Return-Path として配送結果に残ることがあります。これらは同じとは限りません。

MAIL FROM:<bounce@mailer.example.net>     # SMTPの封筒側
RCPT TO:<staff@recipient.test>          # 配送先
DATA
From: "経理部" <billing@example.com>     # 画面で見える差出人
To: staff@recipient.test
Subject: 請求書のご連絡

3. SPF：どのメールサーバーから送信してよいか

SPFは Sender Policy Framework の略。受信サーバーが接続元IPと、SMTPのMAIL FROM（空の場合はHELO/EHLO側）に結び付くドメインのDNS設定を照合します。送信者が許可したサーバーから来たかどうかを判定します。

example.com. IN TXT "v=spf1 ip4:203.0.113.10 include:_spf.mail-provider.example -all"

v=spf1                 SPFレコードであることを示す
ip4:203.0.113.10       この送信元IPv4を許可
include:...            外部配信サービスのSPFも参照
-all                   どれにも一致しなければFail

正規のメールでも転送によって送信元IPが転送サーバーへ変わるため、SPFが失敗することがあります。~all はSoftfail、-all はFailという判定です。単純に「受信側が必ず拒否する命令」ではありません。

4. DKIM：メールに署名して検証する

DKIMは DomainKeys Identified Mail の略。送信側がヘッダーや本文から署名を生成し、受信側がDNSに公開された公開鍵で署名を検証します。改ざんの検知と、署名ドメインが管理する秘密鍵で署名されたことの確認に役立ちます。

DKIM-Signature: v=1; a=rsa-sha256; d=example.com;
 s=mail2026; h=from:to:subject:date; bh=...; b=...

mail2026._domainkey.example.com. IN TXT
 "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

5. DMARC：失敗したメールをどう扱ってほしいか

DMARCは Domain-based Message Authentication, Reporting and Conformance の略。SPFかDKIMの少なくとも一方が成功し、さらにその認証ドメインが表示Fromドメインと整合すればDMARCは成功します。両方の認証が単にPASSというだけでは不足する場合があります。

_dmarc.example.com. IN TXT
 "v=DMARC1; p=reject; rua=mailto:dmarc-report@example.com; pct=100"

v=DMARC1           DMARCレコード
p=reject           認証不整合メールの拒否を要求
rua=mailto:...     集約レポートの送信先
pct=100            対象とする割合（RFC 7489）

Alignment（整合性）は重要なキーワードです。SPFの認証対象ドメイン（MAIL FROM）またはDKIMの署名ドメイン（d=）と、画面上のFromのドメインが整合しているかを見ます。実際のDMARCでは親子関係を認める緩和整合と完全一致を要求する厳格整合があり、設定次第です。

6. 操作して確認：SPFもDKIMもPASSなのにDMARCはFAIL？

攻撃者が attacker.net の正規メールサーバーを使い、そのドメインでDKIM署名を付けたメールの表示Fromだけ billing@example.com に偽装した場面を考えます。SPFとDKIMは「attacker.netとして」成功しても、example.comの正当性は証明されません。

7. SMTP-AUTH・SPF・DKIM・DMARCを混同しない

SMTP-AUTHで正規ユーザーとしてログインしたからといって、受信先でSPF・DKIM・DMARCが必ずPASSするわけではありません。また、メールの暗号化を行うTLSやS/MIMEも送信ドメイン認証とは別の技術です。

8. メールの安全を支える関連技術

また、DMARCは詐称Fromへの対策であり、正規ドメインを装う似た綴りのドメイン、乗っ取られた正規アカウント、悪意ある本文や添付ファイルを自動的に無害化するものではありません。認証の成功とメール本文の安全性は別です。

9. 実務でDNSを設定するときの進め方

自社ドメインでメールを運用するなら、最初に送信経路を棚卸しします。社員のメール、問い合わせフォーム、請求書発行システム、メールマガジン、CRMなど、どこから自社ドメインを名乗るかを把握します。

1. 送信サービスと利用ドメインを一覧化し、SPFの許可元とDKIM署名設定を確認する。
2. DMARCはまず集約レポートを分析できる構成から始め、正規メールが認証を通るか検証する。
3. 転送、配信代行、複数のサブドメインによる不整合を修正する。
4. 正規送信に問題がないことを確かめ、隔離・拒否などの厳格な方針を検討する。
5. 新しい外部サービスを追加した際も、送信経路の変更を継続して確認する。

10. 覚えておきたい判断のポイント

仕様・公式資料

詳細な定義はIETFの RFC 7208（SPF）、RFC 6376（DKIM）、RFC 7489（DMARC） を参照してください。