本ページの位置づけ
「Gmailメールヘッダ解析」で確認した検証結果について、なぜPASSと判定されるのか、その仕組みを1つずつ解説する記事です。送信者名・メールアドレスは「ABC」に置き換えています。
目次
1. はじめに(今回の送信ルート)
今回のメール送信では、構築したメールサーバー(Postfix)から、外部の配信リレーサービス「Brevo(旧Sendinblue)」を経由してGmail宛てに送信しています。
| 項目 | 内容 |
|---|---|
| 送信元(From) | ABC@yama.mydns.jp |
| 宛先(To) | ABC@gmail.com |
| 配信ルート | BlueMail(クライアント)→ mail.yama.mydns.jp(自宅サーバー)→ Brevo(配信リレー)→ Gmail(受信サーバー) |
このようなリレー構成において、SPF・DKIM・DMARCが受信側(Gmail)でどのように検証され、すべて「PASS(合格)」となったのかを、実際のヘッダー情報を基に解説します。
2. 検証対象のメールヘッダー(抜粋)
受信したメールのヘッダー情報から、送信ドメイン認証に関連する重要な部分を抜粋したものです。全文は「Gmailメールヘッダ解析」をご参照ください。
Delivered-To: ABC@gmail.com
Return-Path: <bounces-454006426-1328618082@hb.d.sender-sib.com>
Authentication-Results: mx.google.com;
dkim=pass header.i=@yama.mydns.jp header.s=brevo2 header.b="m+Aj/ZSs";
spf=pass (google.com: domain of bounces-454006426-1328618082@hb.d.sender-sib.com designates 77.32.148.28 as permitted sender) smtp.mailfrom=bounces-454006426-1328618082@hb.d.sender-sib.com;
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=yama.mydns.jp
Received-SPF: pass (google.com: domain of bounces-454006426-1328618082@hb.d.sender-sib.com designates 77.32.148.28 as permitted sender) client-ip=77.32.148.28;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yama.mydns.jp; q=dns/txt; s=brevo2;
bh=WIxFeSAO3Q1hYik+nmBXpzosBrDTNfdEzJ1F/LtctFA=; ...
From: "ABC" <ABC@yama.mydns.jp>
To: <ABC@gmail.com>
Subject: テスト
3-1. SPF(Sender Policy Framework)の検証
| 項目 | 内容 |
|---|---|
| 認証結果 | PASS spf=pass |
| 検証対象ドメイン | hb.d.sender-sib.com(リレーサービス「Brevo」のドメイン) |
| 送信IPアドレス | 77.32.148.28 |
仕組みと解説
SPFは「送信元メールサーバーのIPアドレス」が、そのドメインの正規のサーバーであるかを、DNSに登録された「許可リスト(SPFレコード)」と照合する仕組みです。
今回のケースでは、メールの実質的な送信元(Return-Path)がリレーサービスのドメイン hb.d.sender-sib.com になっています。Gmailは、このドメインのDNS設定を確認し、「IPアドレス 77.32.148.28 は正規の送信サーバーである」と登録されていることを確認したため、spf=pass(合格)と判定しました。
3-2. DKIM(DomainKeys Identified Mail)の検証
| 項目 | 内容 |
|---|---|
| 認証結果 | PASS dkim=pass |
| 署名ドメイン(d=) | yama.mydns.jp |
| 公開鍵の場所(s=) | brevo2(セレクタ名) |
仕組みと解説
DKIMは、メールに電子署名を付与し、送信中にメールの内容が改ざんされていないこと、および送信元ドメインが詐称されていないことを数学的に証明する仕組みです。
ヘッダー内の DKIM-Signature には、送信時に作成された電子署名が記載されています。Gmailは、署名内に示されたドメイン yama.mydns.jp のDNSサーバーから、セレクタ(鍵の置き場所)である brevo2 に対応する公開鍵を取得し、署名の検証を行いました。
計算結果が一致したため、メールは「途中で改ざんされておらず、かつ yama.mydns.jp によって正しく送信されたものである」と確認され、dkim=pass となりました。
3-3. DMARC(Domain-based Message Authentication, Reporting, and Conformance)の検証
| 項目 | 内容 |
|---|---|
| 認証結果 | PASS dmarc=pass |
| 検証対象のFromドメイン | yama.mydns.jp |
| DMARCポリシー | p=NONE(受信側での処理方針:特に対処せず通す) |
仕組みと解説
DMARCは、SPFとDKIMの検証結果を利用し、メールのヘッダーに表示されている送信元(Fromヘッダーのドメイン)が、本当にSPFやDKIMで認証されたドメインと一致しているか(これを「アライメント」と呼びます)を検証します。
- 今回のSPFアライメント:Fromドメイン(
yama.mydns.jp)と SPF対象ドメイン(hb.d.sender-sib.com)が異なるため不一致(アライメントは失敗) - 今回のDKIMアライメント:Fromドメイン(
yama.mydns.jp)と DKIMの署名ドメイン(yama.mydns.jp)が一致(アライメント成功)
DMARCのルールでは、SPFまたはDKIMのどちらか一方のアライメントが成功し、かつ認証自体がPASSしていれば、DMARC全体として「PASS」と判定されます。今回はDKIM側のアライメントが成功したため、dmarc=pass となり、なりすましメールではないと判断されました。
4. その他の重要な技術:ARC(Authenticated Received Chain)
ヘッダー内にある ARC-Seal や ARC-Authentication-Results は、転送経路における認証情報を保護するための仕組みです。
メールが他のサーバーを経由して転送される際、SPFやDKIMの検証が途中で失敗してしまうことがあります。ARCは、各中継サーバーが検証した結果に署名を施して引き継ぐことで、最終的な受信サーバー(今回の場合はGmail)が「このメールは転送前の段階で確かに認証を通過していた」と確認できるようにする役割を持っています。
5. まとめ
送信ドメイン認証が正しく機能しているかどうかは、受信側が記録する Authentication-Results の1行を確認することで判断できます。
- SPF:送信元IPアドレス(77.32.148.28)が正規のものであることを確認 → PASS
- DKIM:電子署名(yama.mydns.jp)により、改ざんがないことを確認 → PASS
- DMARC:FromドメインとDKIM署名ドメインの一致を確認 → PASS
これらすべての確認が裏付けとなっているため、送信したメールは受信側の認証チェックを正常にクリアできています。
送信ドメイン認証3点セット、いずれも仕組みから確認完了 🎉
SPF・DKIM・DMARCがそれぞれ何を検証しているかを理解した上で、実際のヘッダーでPASSを確認できました。受信側の視点からの検証記録は「SPF/DKIM/DMARC検証記録(受信編)」もあわせてご参照ください。