この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。SPFのRFC 7208、DKIMのRFC 6376、2026年に公開されたDMARCのRFC 9989、およびMicrosoft 365の最新Email認証資料を確認して整理しています。検証ステータス：📘 現行RFC・Microsoft 365公式情報確認済み・PowerShell DNS確認サンプル実装済み・実行確認は未実施
SPF・DKIM・DMARCはどこで効く？ ― メール1通の流れに3つを重ねて理解する
SPF、DKIM、DMARCは同じ認証を3回しているわけではありません。SPFは主に送信元IPとMAIL FROM側のドメイン、DKIMは署名したドメインとメッセージ、DMARCは利用者に見えるFromドメインとSPF/DKIMの認証結果のalignmentを結び付ける役割があります。
2026年時点でDMARCを調べるときは、旧RFC 7489ではなくRFC 9989を基準にします。RFC 9989はRFC 7489とRFC 9091をobsoleteにしています。
1通のメールに重ねる
sequenceDiagram
participant S as Sending server
participant D as DNS
participant R as Receiving server
participant U as User
S->>R: SMTP message
R->>D: SPF: MAIL FROM側ドメインの許可情報を確認
D-->>R: SPF policy
R->>D: DKIM: d=署名ドメインの公開鍵を確認
D-->>R: DKIM public key
R->>R: SPF/DKIMの認証結果を評価
R->>D: DMARC policyを確認
D-->>R: DMARC policy
R->>R: Fromドメインとのalignmentを評価
R-->>U: 最終的な配送・処理
SPFは「From欄そのもの」を認証しない
SPFは、受信したSMTP接続元が、対象ドメインのメールを送ることを許可されているかをDNSのSPFレコードで確認します。RFC 7208では、チェック対象となるidentityとしてMAIL FROMやHELOが扱われます。
ここで重要なのは、メールソフトに表示される From: ヘッダーとは別の層だということです。Microsoft 365の公式説明でも、SPF単体ではMAIL FROMドメインとFromドメインのalignmentを確認しない点が説明されています。
DKIMはメッセージへ署名する
DKIMでは送信側がメッセージへ暗号学的署名を付け、受信側はDNSで公開鍵を取得して検証します。署名には d= で署名ドメインが示されます。
これにより、署名対象となったヘッダーや本文が署名後に不正に変更されていないかを確認できます。ただし、DKIMに通っただけでは、その d= ドメインが利用者に見えるFromドメインと同じとは限りません。
DMARCはFromドメインとのalignmentを見る
DMARCでは、RFC 5322の From: ドメインを中心に、SPFまたはDKIMで認証されたドメインとのalignmentを評価します。
ざっくり整理すると次の関係です。
| 仕組み | 主に見るもの | DMARCとの関係 |
|---|---|---|
| SPF | SMTP送信元とSPF identity | 認証済みSPFドメインがFromドメインとalignmentするか |
| DKIM | 署名と d= ドメイン | 認証済みDKIM署名ドメインがFromドメインとalignmentするか |
| DMARC | Fromドメイン、SPF/DKIM結果、policy | alignmentを含めてDMARC pass/failを判断 |
DMARCはさらに、ドメイン所有者が公開したpolicyやreportingの仕組みを持ちます。
すぐ試す：自分のドメインのDNSを読んでみる
仕組みを読むだけでなく、公開DNSに何が載っているかをPowerShellで確認できます。以下は参照だけで、DNS設定は変更しません。
SPF候補となるドメイン直下のTXT:
Resolve-DnsName -Name example.com -Type TXT
DMARC:
Resolve-DnsName -Name _dmarc.example.com -Type TXT
DKIMはselectorが必要です。たとえば selector1 を使う環境なら、Microsoft 365のようにCNAME委任されている場合も考えて、まずCNAMEを確認できます。
Resolve-DnsName -Name selector1._domainkey.example.com -Type CNAME Resolve-DnsName -Name selector1._domainkey.example.com -Type TXT
example.com と selector1 は自分の環境へ置き換えてください。selector名はサービスや設定によって異なります。
ここで見ているのは公開DNSレコードです。この結果だけで、実際の1通のメールがSPF/DKIM/DMARCをpassしたとは判断できません。実メールでは Authentication-Results などのヘッダーと、MAIL FROM、DKIMの d=、表示Fromのalignmentを合わせて確認します。
複数の問い合わせをまとめたPowerShell版もGitHubに置いてあります。
2026年に古い記事を読むときの注意
DMARCの解説記事では長年RFC 7489が引用されてきました。しかし現在のRFC EditorではRFC 9989がProposed Standardとして公開され、RFC 7489とRFC 9091をobsoleteにしています。
したがって、「RFC 7489にこう書いてあるから現在もこれが正本」と扱わず、現行RFCを確認する必要があります。これは、古い技術記事をAIでリライトするときにも見落としやすいポイントです。
Microsoft 365では3つを別々に終わらせない
Microsoft 365の公式資料もSPF、DKIM、DMARCを連携する構成要素として説明しています。実運用では、自社の送信元、SaaSからの代理送信、転送、サブドメインなどが絡むため、サンプルDNSレコードをそのままコピーするのではなく、自分のメール経路を先に棚卸しします。
仕組みの位置関係に絞り、具体的な p=reject などの運用値を一律には推奨しません。
