SPF・DKIM・DMARCの違い ― 送信ドメイン認証

SPF・DKIM・DMARCの違いは、何を確かめるかです。SPFは送ってきたサーバのIPアドレスを、DKIMは電子署名を確かめます。DMARCは、その結果がFromのドメインと一致するかを見ます。

3つとも、取引先や銀行を名乗るなりすましメールを、受信側で見分けるための仕組みです。まとめて送信ドメイン認証と呼びます。どれも、送信側のドメインの持ち主がDNSに情報を置き、受信側がそれを引いて確かめます。Gmailに大量のメールを送る送信者には、3つすべての設定が求められています。

メールを運ぶSMTPには、差出人が本物かを確かめる決まりがありません。そのため、差出人に他人のドメインを書いたメールも送れてしまいます。メールには、差出人を書く場所が2つあります。

MAIL FROM:<bounce@example.com>
RCPT TO:<tanaka@example.net>
DATA
From: sato@example.com
To: tanaka@example.net
Subject: 打ち合わせの件

1行目のMAIL FROMは、SMTPのコマンドで伝える差出人です。SMTPのコマンドで運ぶ情報を、手紙の封筒にたとえてエンベロープと呼びます。そこで、この差出人をエンベロープFromと呼びます。

DATAの後ろにあるFrom:は、メールの本文側に書かれた差出人です。メールソフトが差出人として画面に出すのは、こちらのヘッダーFromです。エンベロープFromは、届かなかったときの知らせを返す宛先で、ヘッダーFromと同じとは限りません。

SPFが確かめるのはエンベロープFrom、利用者が目にするのはヘッダーFromです。この食い違いを埋めるのが、後で説明するDMARCです。

SPFはSender Policy Frameworkの略で、RFC 7208が定めています。ドメインの持ち主は、そのドメインからメールを送ってよいサーバを、DNSのTXTレコードに書いておきます。TXTレコードは、ドメイン名に文字列を結び付けるレコードです。

example.com.  IN  TXT  "v=spf1 ip4:203.0.113.25 mx -all"

v=spf1は、SPFのレコードであることを示します。ip4:203.0.113.25は、そのIPアドレスのサーバに送信を許すという意味です。mxは、MXレコードに載っているサーバにも送信を許します。

最後のallは、それより前のどれにも当たらなかったすべての送信元に当たります。前に付けた記号で、当たったときの結果が決まります。

受信サーバは、SMTPのMAIL FROMを受け取った時点で確かめます。エンベロープFromのドメインのSPFレコードを引き、接続してきたサーバのIPアドレスと照合します。レコードが無ければnone、DNSの一時的な失敗ならtemperror、レコードの誤りならpermerrorになります。

RFC 7208は、includeやmxのようにDNSを引く項を、合わせて10個までに制限しています。超えるとpermerrorになるので、外部のメール配信サービスを何社も足すときは数を確かめます。

SPFだけでは防げないこと

SPFは、ヘッダーFromのドメインが本物かを確かめません。攻撃者が自分のドメインをエンベロープFromに書き、そのドメインのSPFを用意すれば、SPFはpassします。RFC 7208も、ヘッダーFromなどの差出人が本物かは保証しないと注意しています。

転送にも弱点があります。SPFは、最後にメールを送ってきたサーバのIPアドレスで評価します。転送サービスがエンベロープFromを変えずに送り直すと、転送サービスのIPアドレスで照合されます。その結果、SPFは失敗します。

DKIMはDomainKeys Identified Mailの略で、RFC 6376が定めています。送信サーバが秘密鍵でメールに署名し、受信サーバがDNSに置かれた公開鍵で署名を確かめます。秘密鍵と公開鍵の関係は、公開鍵暗号のデジタル署名と同じです。

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=sel1;
    h=From:To:Subject:Date; bh=（本文のハッシュ値）;
    b=（署名の値）

d=は署名したドメイン、s=は鍵を選ぶための名前です。この名前を、セレクタと呼びます。h=は署名に含めたヘッダーの一覧で、RFC 6376はFromを必ず含めるよう定めています。

bh=には本文のハッシュ値が、b=にはヘッダーと本文から計算した署名が入ります。ハッシュ値は、元のデータが少しでも変わると大きく変わる値です。この値を計算するのがハッシュ関数です。

受信サーバは、s=とd=から名前を作り、DNSのTXTレコードを引いて公開鍵を手に入れます。

sel1._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A…"

署名が確かめられると、d=のドメインが署名したことと、署名した部分が署名後に変わっていないことが分かります。セレクタを変えれば、1つのドメインに複数の公開鍵を置けます。新しい鍵に入れ替えるときも、古い鍵と並べて置いておけます。

DKIMの公開鍵は、認証局が発行する証明書には入っていません。ドメインの持ち主がDNSに直接置くので、電子証明書の証明書チェーンは使いません。RFC 8301は、署名にrsa-sha256を使うよう定めています。RSAの鍵は1024ビット以上、できれば2048ビット以上にします。

DKIMの署名は、中身が変わらなければ転送されても確かめられます。その一方で、メーリングリストが件名に文字を足すと、署名は合わなくなります。また、d=にはどのドメインでも書けるので、DKIMだけではFromのドメインが本物かは分かりません。

DMARCは、SPFとDKIMの結果を、利用者が目にするヘッダーFromに結び付ける仕組みです。SPFかDKIMで確かめたドメインが、Fromのドメインと一致するかを見ます。この一致を、アライメントと呼びます。

SPFかDKIMのどちらか1つでも、passしてFromと一致すれば、DMARCはpassします。どちらも一致しなければ、failです。DKIMの署名が複数あるときは、どれか1つが一致すれば足ります。

緩い一致と厳しい一致

一致の見方は2つあります。既定は緩い一致です。mail.example.comとexample.comのように、組織のドメインが同じなら一致とします。厳しい一致では、ドメインがまったく同じときだけ一致とします。

example.netとexample.comは、組織のドメインが違うので、緩い一致でも一致しません。攻撃者は自分のドメインでSPFとDKIMをpassさせられるので、DMARCはこの一致を必ず求めます。

DMARCのレコード

DMARCのレコードは、_dmarcを頭に付けた名前のTXTレコードに置きます。次の例は、RFC 9989の付録に載っている、扱いを変えずにレポートだけを受け取る設定です。

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com"

DMARCは、2015年に情報提供のための文書であるRFC 7489として公開されました。2026年5月には、標準化団体IETFの標準化の過程に乗ったRFC 9989が公開されました。これにより、RFC 7489は廃止されました。

RFC 9989では、割合を指定するpctタグがなくなり、テスト用のtタグなどが加わりました。組織のドメインを決める方法も、公開された一覧を使う方法から、DNSを上の階層へたどる方法に変わりました。レポートの形式は、RFC 9990とRFC 9991に分かれました。

次の図では、3つのことを選べます。SPFとDKIMの結果、それぞれのドメインがFromと同じ組織か、DMARCのポリシーです。よくある場面のボタンを押すと、その場面の選び方に切り替わります。

転送の場面では、SPFが失敗してもDKIMでpassします。攻撃者のドメインで認証した場面では、SPFもDKIMもpassしても、Fromと一致しないのでfailになります。

p=に書くポリシーは、DMARCがfailしたメールの扱いについての、送信側の希望です。値は、none・quarantine・rejectの3つです。

• none：扱いの希望を示さない。受信側は、このポリシーを理由に扱いを変えない
• quarantine：疑わしいメールとして扱ってほしい。迷惑メールのフォルダに入れるのが、その例
• reject：受け取りを拒否してほしい。拒否はSMTPのやり取りの中で行う

ポリシーは送信側の希望で、最後に扱いを決めるのは受信側です。RFC 9989は、受信側がp=rejectだけを理由に拒否してはならないと定めています。ほかに判断の材料が無いときは、quarantineとして扱います。DMARCがpassしても、受信側がほかの検査で迷惑メールと判断することもあります。

noneから始めて、レポートを見て強める

ruaに宛先を書くと、受信側から集計レポートが届きます。集計レポートはXMLのファイルです。送信元のIPアドレスごとの通数や、SPF・DKIMの結果が入ります。RFC 9989は、少なくとも24時間に1回は送るよう受信側に勧めています。

rufに宛先を書くと、失敗したメール1通ごとの失敗レポートを求められます。ただし、利用者のプライバシーを守るため、送らない受信側も多いです。

いきなりrejectにすると、SPFやDKIMを設定し忘れた自社の正しいメールまで拒否されます。そこで、まずnoneでレポートを集め、正しいメールがすべてpassするのを確かめてから強めます。RFC 9989は、メーリングリストに投稿する利用者がいるドメインには、rejectを出さないよう勧めています。それでもrejectにするなら、noneとquarantineをそれぞれ1か月以上出し、結果を比べてからにします。

Gmailの送信者ガイドライン

Googleは2024年2月1日から、Gmailの個人アカウントに送るすべての送信者にSPFかDKIMの設定を求めています。1日に5,000通を超えて送る送信者には、SPFとDKIMとDMARCの3つを求めています。この場合のDMARCのポリシーは、noneで構いません。Fromのドメインは、SPFかDKIMのドメインと一致させます。

ここまでの3つは、届いたメールを受信側で確かめる仕組みです。迷惑メールを送らせない対策は、送る側のネットワークにもあります。

OP25Bは、ISPが、利用者の回線から外部のメールサーバの25番ポートへ送る通信を止める対策です。Outbound Port 25 Blockingの略です。ISPは、インターネット接続事業者のことです。総務省は、ISPなどのメールサーバを通らないメール送信を防ぐ対策として紹介しています。

OP25Bの下でも、正しい利用者は送れます。契約しているメールサーバの587番ポートに接続して送ります。587番では、ユーザー名とパスワードで利用者を確かめてから受け付けます。この確かめ方を、SMTP-AUTHと呼びます。

RFC 5068は、アクセス事業者が587番への通信を止めてはならないと定めています。587番とSMTP認証の流れは、メールを送る流れで説明しています。

ベイジアンフィルタリングは、受信したメールの文面から、迷惑メールかを確率で判定する方法です。利用者が迷惑メールと判断したメールと、ふつうのメールから、語ごとの出やすさを学びます。差出人のドメインを確かめる送信ドメイン認証とは、見るものが違います。

S/MIMEとPGPは、利用者個人の鍵で、メールの中身を暗号化したり署名したりする規格です。送信者のメールソフトが暗号化や署名をし、受信者のメールソフトが復号や署名の確認をします。DKIMは、送信側のサーバがドメインの鍵で署名し、受信側のサーバが確かめる点が違います。

• RFC 7208 Sender Policy Framework (SPF)（SPFレコード、限定子、DNSを引く回数の上限、転送での失敗）
• RFC 6376 DomainKeys Identified Mail (DKIM) Signatures（署名のタグ、セレクタ、公開鍵のレコード）
• RFC 8301 Cryptographic Algorithm and Key Usage Update to DKIM（署名の方式と鍵の長さ）
• RFC 9989 Domain-Based Message Authentication, Reporting, and Conformance (DMARC)（アライメント、ポリシー、タグ、RFC 7489からの変更）
• RFC 9990 DMARC Aggregate Reporting（集計レポートの形式）
• RFC 7489 Domain-based Message Authentication, Reporting, and Conformance (DMARC)（RFC 9989の前の版）
• IETF Datatracker draft-ietf-dmarc-dmarcbis（RFC 9989として公開された状態。2026年10月29日に確認）
• RFC 5068 Email Submission Operations（587番への通信を止めない決まり）
• 総務省 迷惑メール対策（送信ドメイン認証技術とOP25B）
• Google メール送信者のガイドライン（Gmailに送る送信者への要件）