運用・保守 一覧へ戻る トップ運用・保守 / SPF/DKIM/DMARC検証記録(送信編)
運用・保守 ・ Mail Operation

SPF / DKIM / DMARC検証記録(送信編:サーバー→Gmail)

Brevo経由でGmail宛に送信したメールが、なぜSPF・DKIM・DMARCすべてでPASSと判定されたのか、実際のヘッダー情報をもとに仕組みから解説します

SPF PASS DKIM PASS DMARC PASS

本ページの位置づけ

「Gmailメールヘッダ解析」で確認した検証結果について、なぜPASSと判定されるのか、その仕組みを1つずつ解説する記事です。送信者名・メールアドレスは「ABC」に置き換えています。

目次

  1. 1. はじめに(今回の送信ルート)
  2. 2. 検証対象のメールヘッダー(抜粋)
  3. 3-1. SPFの検証
  4. 3-2. DKIMの検証
  5. 3-3. DMARCの検証
  6. 4. その他の重要な技術:ARC
  7. 5. まとめ

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(合格)」となったのかを、実際のヘッダー情報を基に解説します。

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で認証されたドメインと一致しているか(これを「アライメント」と呼びます)を検証します。

DMARCのルールでは、SPFまたはDKIMのどちらか一方のアライメントが成功し、かつ認証自体がPASSしていれば、DMARC全体として「PASS」と判定されます。今回はDKIM側のアライメントが成功したため、dmarc=pass となり、なりすましメールではないと判断されました。

4. その他の重要な技術:ARC(Authenticated Received Chain)

ヘッダー内にある ARC-SealARC-Authentication-Results は、転送経路における認証情報を保護するための仕組みです。

メールが他のサーバーを経由して転送される際、SPFやDKIMの検証が途中で失敗してしまうことがあります。ARCは、各中継サーバーが検証した結果に署名を施して引き継ぐことで、最終的な受信サーバー(今回の場合はGmail)が「このメールは転送前の段階で確かに認証を通過していた」と確認できるようにする役割を持っています。

5. まとめ

送信ドメイン認証が正しく機能しているかどうかは、受信側が記録する Authentication-Results の1行を確認することで判断できます。

これらすべての確認が裏付けとなっているため、送信したメールは受信側の認証チェックを正常にクリアできています。

送信ドメイン認証3点セット、いずれも仕組みから確認完了 🎉

SPF・DKIM・DMARCがそれぞれ何を検証しているかを理解した上で、実際のヘッダーでPASSを確認できました。受信側の視点からの検証記録は「SPF/DKIM/DMARC検証記録(受信編)」もあわせてご参照ください。

運用・保守 一覧へ戻る