コンテンツにスキップ
LevelUp101.net

メールセキュリティ：SPF・DKIM・DMARCの仕組みと設定・確認方法

Section titled “メールセキュリティ：SPF・DKIM・DMARCの仕組みと設定・確認方法”

メールに表示される差出人のアドレスは、それだけでは本物と判断できません。SPF・DKIM・DMARCは、ドメインのなりすましを見分けるための送信ドメイン認証です。

技術 読み方 確認すること ドメイン管理者が準備するもの
SPF エスピーエフ 接続してきた送信サーバーのIPアドレスが許可されているか 許可する送信元を記載したDNSのTXTレコード
DKIM ディーキム 署名ドメインの鍵による署名が正しく、署名対象が保たれているか 署名用の鍵、公開鍵を取得できるDNS設定、送信側の署名設定
DMARC ディーマーク SPFまたはDKIMの成功に加え、認証ドメインが表示上のFromと整合するか 失敗時の扱いとレポート送信先を指定するDNSのTXTレコード

DNSの例にあるドメイン・IPアドレス・鍵は説明用です。実際には利用サービスの管理画面と公式手順に従って置き換えてください。

まず、メールに登場する3つのドメインを区別する

Section titled “まず、メールに登場する3つのドメインを区別する”
種類 例 役割
ヘッダーFrom From: sales@example.com メールソフトが通常、差出人として表示するアドレス
エンベロープFrom（MAIL FROM） bounce@mail.example.com SMTPの配送に使う送信者アドレス。配送エラーの返送先になり、受信後は通常Return-Pathで確認できる
DKIM署名ドメイン DKIM-Signature内のd=example.com 署名に責任を持つドメイン

SPFが主に検証するのはMAIL FROMのドメインです。SPFが成功しても、表示上のFromが正しいとは限りません。 DMARCが、この違いをアラインメントというルールで結び付けます。MAIL FROMが空の配送エラー通知などでは、SPFはHELO/EHLOのドメインを使用します。

SPF

Section titled “SPF”

SPFとは

Section titled “SPFとは”

SPF（Sender Policy Framework）は、あるドメインをMAIL FROMなどに使って送信してよいサーバーをDNSで公開する仕組みです。

受信側は、接続元IPアドレスと、そのドメインのSPFレコードを照合します。本文の改ざんや、メールを操作した個人の本人確認は行いません。RFC 7208

設定方法

Section titled “設定方法”

まず、社員用メール、問い合わせフォーム、メール配信、監視通知など、ドメインを使う送信経路を洗い出します。各サービスが使うMAIL FROMドメインと、指定されたSPF設定を確認してください。

たとえば、Google Workspaceだけを使う場合の設定例は次のとおりです。GoogleのSPF設定手順

example.com. IN TXT "v=spf1 include:_spf.google.com ~all"
記述 意味
v=spf1 SPFのバージョン
include:_spf.google.com 指定先のSPF評価がpassとなる送信元を許可
~all それまでの条件に該当しない送信元をsoftfailにする
-all それまでの条件に該当しない送信元をfailにする

自社サーバーなら、たとえばip4:192.0.2.10でIPv4アドレスを指定できます。これは文書用アドレスであり、そのまま本番に使う値ではありません。~allや-allの選択は送信元の把握状況とサービスの手順に従います。どちらも、それだけで受信側の最終処理を強制するものではありません。

同じDNS名には、v=spf1から始まるレコードを複数作らず、許可条件を1つにまとめます。また、include・a・mxなどDNS参照を伴う仕組みには、評価中の合計10回という上限があります。ネストしたincludeも対象なので、サービス追加時は上限超過によるpermerrorに注意してください。RFC 7208 §4.6.4

確認方法

Section titled “確認方法”

対象のMAIL FROMドメインのTXTを検索します。次の3つは同じ問い合わせを行うコマンド例です。利用できるものを1つ実行してください。nslookupはWindowsでも使えます。dig・hostはmacOSやLinuxで使われ、環境によってはDNSツールの追加インストールが必要です。

ターミナルウィンドウ
dig example.com TXT
nslookup -type=TXT example.com
host -t TXT example.com

Windows PowerShellのResolve-DnsNameでも確認できます。

ターミナルウィンドウ
Resolve-DnsName -Name example.com -Type TXT

v=spf1の値と重複の有無を確認し、実際の送信メールでspf=passとsmtp.mailfromを確認します。Fromがexample.comでも、MAIL FROMがmail.example.comなら、調べるSPFは後者のレコードです。

転送では受信側から見た接続元IPアドレスが変わるため、SPFが失敗することがあります。これを補うためにもDKIMを併用します。

DKIM

Section titled “DKIM”

DKIMとは

Section titled “DKIMとは”

DKIM（DomainKeys Identified Mail）は、送信側がメールに電子署名を付け、受信側がDNSから取得した公開鍵で検証する仕組みです。署名ドメインによる署名と、署名対象の本文・ヘッダーの完全性を確認します。

DKIMはメール本文を暗号化する仕組みではありません。 また、署名対象外のヘッダーまで保護するわけではなく、人間の差出人や内容の安全性を保証するものでもありません。鍵と電子署名の基礎はハッシュ化と暗号化の違いも参照してください。RFC 6376

準備と設定方法

Section titled “準備と設定方法”
  1. 送信サーバーまたはメールサービスで公開鍵・秘密鍵のペアを用意します。管理型サービスでは、通常サービス側が生成・管理します。秘密鍵をDNSへ登録してはいけません。
  2. 公開鍵を取得できるDNSレコードを設定します。TXTへ公開鍵を直接登録する方式と、サービス側の公開鍵へCNAMEで委任する方式があります。
  3. DNSでの確認後、サービス側で対象ドメインのDKIM署名を有効にします。DNS登録だけで作業を終えないでください。
サービス 一般的なDNS設定と有効化の流れ
Microsoft 365 管理画面などで取得した2つのCNAMEを登録し、対象ドメインの署名を有効化
Google Workspace 管理コンソールで鍵を生成し、表示された公開鍵をTXTに登録した後、認証を開始
Amazon SES Easy DKIM 通常3つのCNAMEを登録し、ドメインの検証とDKIM署名の状態を確認。Route 53との連携で自動登録できる場合もある

CNAMEの宛先やレコード数は方式・環境に依存します。独自に値を推測せず、各サービスの指定値を使います。MicrosoftのDKIM設定、GoogleのDKIM設定、Amazon SES Easy DKIM

TXT方式の構造は次のとおりです。PUBLIC_KEY_BASE64は説明用のプレースホルダーです。

selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=PUBLIC_KEY_BASE64"

selector1は、同じドメインで複数の鍵を区別するセレクターです。鍵の切り替えにも使います。RSAでは2048ビット以上が推奨されます。鍵の管理・更新はサービスの手順に従ってください。RFC 8301

送信時・受信時の動き

Section titled “送信時・受信時の動き”
  1. 送信側は、本文と選択したヘッダーを署名対象にし、秘密鍵で署名を作成します。
  2. DKIM-Signatureヘッダーに、署名値、署名ドメインd=、セレクターs=などを付けて送信します。
  3. 受信側は、s=selector1、d=example.comならselector1._domainkey.example.comをDNS検索します。CNAME方式では委任先をたどって公開鍵を取得します。
  4. 公開鍵で署名を検証します。署名の正規化ルールの範囲で、署名対象が署名時点から保たれているかを確認できます。

転送後も署名対象が変わらなければ検証できます。一方、メーリングリストなどが件名や本文に追記すると、DKIMが失敗することがあります。

確認方法

Section titled “確認方法”

実際のセレクターと署名ドメインを使って検索します。

ターミナルウィンドウ
dig selector1._domainkey.example.com TXT
nslookup -type=TXT selector1._domainkey.example.com
host -t TXT selector1._domainkey.example.com

CNAME方式では、委任先も確認します。

ターミナルウィンドウ
dig selector1._domainkey.example.com CNAME
nslookup -type=CNAME selector1._domainkey.example.com
host -t CNAME selector1._domainkey.example.com

Windows PowerShellの場合は次のとおりです。

ターミナルウィンドウ
Resolve-DnsName -Name selector1._domainkey.example.com -Type TXT
# CNAME方式の場合は委任先も確認する
Resolve-DnsName -Name selector1._domainkey.example.com -Type CNAME

TXT方式ならv=DKIM1やp=、CNAME方式なら指定された宛先と、その先の公開鍵を確認します。次に受信メールのDKIM-Signatureとdkim=passを確認します。署名ヘッダーが存在するだけでは、検証成功とは判断できません。

DMARC

Section titled “DMARC”

DMARCとは

Section titled “DMARCとは”

DMARC（Domain-based Message Authentication, Reporting, and Conformance）は、SPF・DKIMの結果とヘッダーFromのドメインを結び付け、失敗時に希望する処理とレポート送信先を公開する仕組みです。

DMARCは、次の どちらか一方が成立すればpass です。

  • SPFがpassし、MAIL FROMドメインがヘッダーFromとアラインメントを満たす。
  • DKIMがpassし、その署名のd=ドメインがヘッダーFromとアラインメントを満たす。

両方を満たす必要はありません。一方、単なるspf=passやdkim=passだけでは不十分です。MicrosoftのDMARC解説

既定のrelaxedモードでは、組織ドメインが同じなら整合とみなします。たとえばexample.comとmail.example.comです。strictモードでは完全一致が必要です。これは文字列の後方一致ではなく、example.com.attacker.exampleのような別ドメインは整合しません。RFC 7489 §3.1

ヘッダーFrom SPFの結果とMAIL FROMドメイン DKIMの結果とd= DMARC（relaxed）
example.com pass / mail.example.com fail pass：SPFが整合
example.com fail pass / example.com pass：DKIMが整合
example.com pass / vendor.example.net pass / vendor.example.net fail：どちらもFromと不整合

設定方法

Section titled “設定方法”

SPF・DKIMを整備し、レポート用の受信先を用意したうえで、Fromドメインの_dmarcにTXTを1つ公開します。最初は監視用のp=noneから始めます。

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"
設定 受信側への要求
p=none DMARC失敗を理由とする隔離・拒否を要求しない。監視に利用
p=quarantine DMARC失敗メールを疑わしいものとして扱う。迷惑メールへの振り分けなど
p=reject DMARC失敗メールの受信を拒否するよう要求
rua=mailto:... 集計レポートの送信先を指定

p=noneでも受信側の迷惑メール対策は動作します。また、隔離・拒否の最終判断は受信側が行い、ポリシーどおりの配送結果を保証するものではありません。RFC 7489

集計レポートで正規の送信元と認証結果を調べ、設定漏れを直してからquarantine、rejectへ段階的に移行します。レポートは通常XML形式で、全受信者から届くとは限りません。外部ドメインのサービスへ送る場合は、送信先側のDNSによる許可が必要になることがあります。サブドメインへの適用も確認してください。個別のDMARCレコードがないサブドメインには、組織ドメインのポリシーが適用され、sp=でサブドメイン用ポリシーを指定できます。GoogleのDMARC設定手順

確認方法

Section titled “確認方法”

Fromドメインの_dmarcに公開されたTXTを検索します。

ターミナルウィンドウ
dig _dmarc.example.com TXT
nslookup -type=TXT _dmarc.example.com
host -t TXT _dmarc.example.com

Windows PowerShellの場合は次のとおりです。

ターミナルウィンドウ
Resolve-DnsName -Name _dmarc.example.com -Type TXT

v=DMARC1、p=、rua=の値を確認します。続いて実際にメールを送り、受信側のdmarc=passとheader.from、SPF・DKIMそれぞれの認証ドメインを照合します。

実際の受信メールでまとめて確認する

Section titled “実際の受信メールでまとめて確認する”

DNS検索にはサイト内のDNS Lookupも使えます。ただし、DNSが正しくても、メールサービス側の署名設定や実際の送信経路が正しいとは限りません。

  1. 社員用メール、フォーム、配信サービスなど、送信経路ごとに外部のテスト用メールボックスへ送ります。
  2. GmailのWeb版では、受信メールの返信横のメニューから「メッセージのソースを表示」を開きます。他のメールソフトではヘッダーやメッセージソースを表示します。Gmailのヘッダー確認手順
  3. 受信サービス自身が付けたAuthentication-Resultsを確認します。送信側が書いた同名ヘッダーを無条件に信用しないでください。

次は認証結果の説明用の例です。

Authentication-Results: mx.receiver.example;
    spf=pass smtp.mailfrom=mail.example.com;
    dkim=pass header.d=example.com header.s=selector1;
    dmarc=pass header.from=example.com

この例ではSPF・DKIMともに成功し、relaxedモードではどちらもFromと整合します。設定変更直後はDNSキャッシュが残るため、TTLやサービスの案内を確認してから再試験します。

症状 最初に調べること
SPFがfail・softfail 実際のMAIL FROM、接続元IP、許可する送信サービスの漏れ
SPFがpermerror SPFレコードの重複、構文、DNS参照上限
DKIM署名がない サービス側の署名有効化、対象ドメイン、別の送信経路の利用
DKIMがfail d=・s=に対応する公開鍵、鍵の切り替え、途中での本文変更
SPFやDKIMはpassなのにDMARCがfail 認証ドメインとヘッダーFromのアラインメント

SPF・DKIM・DMARCはドメイン認証です。認証に成功したメールにも不正な内容はあり得ます。表示名だけの詐称、似た別ドメイン、正規アカウントの乗っ取りにも別の対策が必要で、passは受信トレイへの配信やリンク・添付ファイルの安全性を保証しません。Gmailの認証に関する説明

参考資料

Section titled “参考資料”