この記事のポイント

  • SPF（RFC 7208）: エンベロープ送信者（Return-Path）にお使いのドメインを使ってメールを送信することが許可された IP アドレスや送信サービスの一覧を公開する仕組みです。
  • DKIM（RFC 6376）: 非対称鍵ペアを用いて各メッセージに暗号署名を付与し、署名ドメインによって承認されたメールであること、そして転送中に改ざんされていないことを証明します。
  • DMARC（RFC 7489）: SPF と DKIM のアライメントに失敗したメールを受信サーバーがどう扱うか（none、quarantine、reject）と、集計レポートの送付先を指定します。
  • 2024 年 2 月以降、Gmail と Yahoo は大量送信者（Gmail の定義では、個人の Gmail アカウント宛てに 1 日 5,000 通以上を送信する送信者）に対し、SPF と DKIM の両方による認証、DMARC レコードの公開（少なくとも p=none）、そして From ドメインと SPF または DKIM のアライメントを必須としています。

Google Workspace、Microsoft 365、Yahoo Mail などの受信メールサーバーが contact@yourcompany.com からのメッセージを受け取ると、そのフィルタリング基盤は一連の技術的なチェックを実行し、メッセージが本当にそのドメインの正当な所有者から送られたものなのか、それともなりすましやフィッシングの試みなのかを判定します。

ドメインの DNS（Domain Name System）に必要な認証レコードが設定されていない場合、そのメッセージは高リスクとして扱われます。迷惑メールフォルダに振り分けられるか、SMTP レベルで受信を拒否される可能性が高く、送信プラットフォーム上ではバウンスとして記録されます。

1. メール認証を支える 3 つの基本メカニズム

メールのセキュリティの仕組みがどのように連携しているかを理解するには、それぞれのプロトコルが担う、異なりながらも互いを補完する役割を見ていくとわかりやすくなります。

SPF（Sender Policy Framework）

SPF は、DNS 上に公開する「許可リスト」のような役割を果たします。このレコードでは、お使いのドメインに代わってメールを送信してよいサーバーを、IP アドレス、または Amazon SES、SendGrid、Mailgun などのプロバイダーを指す include メカニズムによって宣言します。受信側は SPF を、画面に表示される From アドレスではなく、エンベロープ送信者（MAIL FROM / Return-Path）のドメインに対して照合します。

DKIM（DomainKeys Identified Mail）

DKIM はメッセージの完全性を検証します。メッセージが送信サーバーを出る際に秘密鍵でデジタル署名が生成され、DKIM-Signature ヘッダーとしてメッセージに付与されます。受信サーバーは対応する公開鍵をお使いの DNS から取得して署名を検証し、署名されたヘッダーと本文が途中で偽造・改変されていないことを確認します。

DMARC（Domain-based Message Authentication, Reporting, and Conformance）

DMARC は SPF と DKIM を結び付ける役割を担うレイヤーです。受信サーバーに対し、表示上の送信者アドレス（Header From）のドメインが、SPF または DKIM で認証されたドメインと一致しているかを確認するよう求めます。この確認をアライメントと呼びます。2 つのうち少なくとも一方が認証に成功し、かつアライメントが取れていれば、そのメッセージは DMARC に合格します。DMARC はさらに、認証に失敗した場合に受信側が取るべき対応を定め、集計レポート（RUA）を受け取るための経路も提供します。

2. SPF レコードの構造と構文

SPF レコードは、エンベロープ送信者に使われるドメインに TXT レコードとして公開します。自社サーバーや Google Workspace から送信する場合、通常はルートドメインが対象になります。

Record Type: TXT
Host / Name: @ (or yourcompany.com)
Value / Content: v=spf1 include:amazonses.com ~all

レコードの各要素の意味:

  • v=spf1: 使用する SPF のバージョンを宣言します。レコードの先頭に記述する必要があります。
  • include:amazonses.com: Amazon Simple Email Service（SES）の送信 IP 範囲に、このドメインのメール送信を許可します。SendGrid も併用している場合は、include:sendgrid.net が同等の記述になります。なお Amazon SES では、カスタム MAIL FROM サブドメイン（例: bounce.yourcompany.com）を設定し、SES が指定する MX レコードとあわせてこのレコードをそのサブドメインに公開した場合にのみ、SPF が DMARC のアライメントを満たします。SendGrid では、ドメイン認証と自動セキュリティ（automated security）を有効にすると、SendGrid が CNAME を通じて自社の Return-Path サブドメインの SPF を管理するため、ルートドメインへの include は不要です。
  • ~all（SoftFail）: リストにないサーバーからのメールは疑わしいものとして扱うものの、通常は受信を許可することを示します。特に送信元の洗い出しがまだ完了していない段階では、最も一般的な選択肢です。
  • -all（HardFail）: 許可されていない送信元からのメールを明確な失敗として扱うことを示します。受信側が拒否する場合もありますが、現在では多くの大手メールボックスプロバイダーが SPF の結果だけで拒否するのではなく、DMARC の結果を重視して判断しています。
技術的な重要ポイント: RFC 7208 では、1 つのドメインに公開できる SPF レコードは1 つだけと定められており、複数存在すると恒久的エラー（permerror）になります。また評価時の DNS ルックアップは最大 10 回までに制限されています（include、a、mx、ptr、exists、redirect が対象で、ネストされたルックアップも含みます）。同じドメインから複数のサービスで送信する場合（例: Google Workspace と Amazon SES）は、1 つのレコードにまとめてください: v=spf1 include:_spf.google.com include:amazonses.com ~all

3. DKIM の設定

DKIM の設定では通常、RSA 鍵ペアを生成します。現在の推奨は最低 2048 ビットの鍵です。eMailBase を通じて送信プロバイダーを接続する場合の流れは次のとおりです。

  1. プロバイダーが DKIM セレクター用の DNS レコードを生成します。Amazon SES の Easy DKIM では <token>._domainkey.yourcompany.com 形式の CNAME レコードが 3 つ発行されます。SendGrid では DKIM 用の CNAME レコード 2 つ（s1._domainkey と s2._domainkey）に加え、Return-Path サブドメイン用のレコードが 1 つ発行されます。Mailgun では通常、公開鍵を含む TXT レコードが提供されます。
  2. DNS プロバイダーの管理画面にログインし、発行されたとおりに各レコードを正確に作成します。
  3. レコードが反映されると、eMailBase が自動的に DNS を照会し、有効化を確認します。

4. DMARC ポリシーを安全に強化する手順

初日から厳格な DMARC ポリシーを公開すると、SPF や DKIM で十分にカバーされていない送信元がある場合に、正当なメールまで拒否されるおそれがあります。DMARC レコードは _dmarc.yourcompany.com に TXT レコードとして公開し、標準的には次の 3 つのフェーズで導入します。

フェーズ ポリシーの構文 運用上の目的
フェーズ 1: モニタリング v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com 配信に影響を与えずに集計レポートを収集し、正当な送信元をすべて特定します。
フェーズ 2: 隔離（quarantine） v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourcompany.com 認証に失敗したメッセージの 25% に隔離ポリシー（通常は迷惑メールフォルダへの配信）を適用し、正当なメールが合格していることをレポートで確認しながら割合を引き上げます。pct への対応状況は受信側によって異なり、標準の改訂版である DMARCbis ではこのタグが廃止されています。
フェーズ 3: 拒否（reject） v=DMARC1; p=reject; rua=mailto:dmarc@yourcompany.com DMARC に失敗したすべてのメールを拒否するよう受信側に指示し、ドメインの不正利用を防ぎます。

5. DNS レコードの検証とトラブルシューティング

レコードを設定したら、標準的なコマンドラインツールで確認できます。

# Check the SPF record
dig +short TXT yourcompany.com

# Check a DKIM record (replace the selector with your own)
dig +short CNAME selector._domainkey.yourcompany.com

# Check the DMARC record
dig +short TXT _dmarc.yourcompany.com

eMailBase のワークスペースでは、これらのチェックが DNS & Deliverability Manager によって自動で実行され、構文の競合やレコードの不足が発生するとすぐに警告が表示されます。

適切な送信のあり方については、eMailBase 迷惑メール防止ポリシーをご覧ください。