📧

メールと配信技術ついて詳しくなる

に公開
mail
インフラ
tech

ことはじめ

こんにちは、みなさん。

メール、送ってますか。

私は最近メールを送ろうとして、Amazon SESの本番アクセス申請をしようとしたら、AWS先生こっぴどく怒られたりしていました。
AWSが結構強気に怒ってきたので、そもそもメールを取り巻く環境について思索を巡らせたいと思いました。

「日々受け取るメールはどのように信頼されているのか」。こちらをテーマに、ひたすら心の赴くままの疑問にQAしていく会になります。

TL;DR

おなまえ 概要 ひとこと
SPF 「受信メールサーバーにて受信したメールが、本当にそのドメインから送信していいサーバーからのメールなのか?」を確認する仕組み。 送信元サーバの身元確認マン。
DKIM 「受信メールサーバーにて受信したメールが、本当に送信者本人が書いたままの内容なのか?」を確認する仕組み。 メール内容の改ざん確認マン。
DMARC 「受信メールサーバにてSPFとDKIMの検査結果を使用して、信頼できないメールをどう扱うかをドメインの持ち主が決めるルール」 不審なメールは読み捨ててくれ紳士。
BIMI 「メールの公式性を視覚的に示す」仕組み。 X公式バッジ

踊り狂うメールたちを取り巻く環境の掘り下げ

SPFとは?

A. メールの「なりすまし(送信ドメイン偽装)」を防ぐための仕組み。

Sender Policy Framework であり、ドメインの所有者が「このドメインからのメールを出すサーバー/IPアドレスはここだよ~~~」とDNS上に公開して、受信メールサーバーがそれを確認する流れ。

背景・目的

  • メール送信プロトコル(SMTP)では、送信者ドメインを自由に書ける

    • → なりすまし卍

  • ドメイン所有者(ADMD: Administrative Management Domain)が、自分のドメインを使用してメールを送信するホストを明示して、受信者側がそれを検証できたらOKとすることで、迷惑メールやフィッシング対策となることが目的。

流れ

  1. ドメイン所有者がDNSTXTレコードに記載
    ひとこめ
     昔はSPFレコードタイプもあったとか

 https://www.cloudflare.com/ja-jp/learning/dns/dns-records/dns-spf-record/

    example.com. IN TXT "v=spf1 ip4:192.0.2.0/24 include:mail.example.net -all"
  2. 受信メールサーバー側で検証
    1. 受信SMTPサーバーがメールを受け取るプロセス中に、送信者MAIL FROMか HELO/EHLO 識別子からドメインを取得
    2. そのドメインのDNSのTXTレコードを検証
    3. 評価アルゴリズムで pass/fail/neutral/softfail/permerror/temperror の結果を出す。
    4. 結果をもとに受信者側ポリシーを適用

SPFの課題感

  1. メール転送に弱い
    • 転送されるとメール送信元IPアドレスが変わるのでSPF検証がfailになる…
  2. From:ヘッダとは無関係の検証
    • SPFが検証するのはSMTPプロトコルの内部情報のみで、メールクライアントで表示されるヘッダ情報は偽装されてもスルーされる…
  3. DNS依存が強く壊れやすい
    • サービスプロバイダを変更したりすると追加しないといけない
    • DNSが落ちたりレコードがうまく引けないとエラーになる
  4. IPベースだから大SaaS時代に合わない
    • 動的に送信元IPアドレスが分かると、IPで信頼判断する設計そのものが限界みを感じる
  5. 信頼性の担保は不十分
    • メールの内容自体の検証はできてない(伏線)

DKIMとは?

A. 電子署名によってメールが改ざんされていないこと、送信ドメインの正当性を保証する仕組み。

DomainKeys Identified Mail (DKIM) Signatures

https://datatracker.ietf.org/doc/html/rfc6376

背景・目的

もともと以下の2つの技術が統合されて生まれたらしい。

  1. Yahoo!の DomainKeys

  2. Ciscoの Identified Internet Mail

→ ドメインの所有者が送信署名を行い、それを受信者が公開鍵で検証することでなりすましや改ざんの検出をする。

流れ

  1. 送信者サイド(送信)

  2. メールサーバーから送信時に 「 メール本文+一部ヘッダー(From: Subject: Date:)」などをハッシュ化

  3. そのハッシュに対して、所有ドメインの秘密鍵で署名を作成

  4. 署名データをメールヘッダに追加して送信

DKIM
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail2025;
    h=from:to:subject:date;
    bh=QmFzZTY0SGFzaFZhbHVlCg==;
    b=abcdef1234567890...

(RFCだとこのへん)

https://datatracker.ietf.org/doc/html/rfc6376#section-3.5

  1. 受信者サイド(検証)

  2. 受信メールサーバーは DKIM-Signetureヘッダーを読み取り d=署名ドメインと s=セレクタを使ってDNSに問い合わせ

  3. 公開鍵で署名を検証しハッシュの一致を確認

DKIM
mail2025._domainkey.example.com. IN TXT
    "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9..."

DKIMの課題感

  1. From:詐称そのものは防げない
    • 署名は通るけど詐欺メール、のようなことが通る。
  2. メールの改変に弱い
    • 「メール転送時に署名フッターが追加される」「文字コード変換」「改行コード変換」」メールゲートウェイが一部ヘッダを再フォーマット」などなど、正当な転送や加工でも署名がぶっ壊れる…
  3. DNS・鍵管理の運用が複雑
    • 秘密鍵+公開鍵で運用するのが辛い
    • TXTレコードの255文字制限を超えて鍵が途切れる
    • 鍵ローテーションせずに残る
    • セレクタの再利用で過去のメールの署名が再検証不能になる
    • 小噺
  4. 採用率自体が低い
    • DKIMがないからと言ってそのメールが不正であるとはいえん。
Ed25519-SHA256署名

昔のDKIM(RFC6376)では署名アルゴリズムは以下の通り

  1. rsa-sha1
    • 古い、脆弱らしい(掘り下げ不足)
  2. rsa-sha256
    • デファクト

だが、RSAには構造的に問題があったそうな。

  • 鍵が巨大
    • 安全性を保つのに2048bit以上必要とのこと(DNS TXTギリ)
  • 計算コストが高い
    • 鍵生成・署名・検証のすべてが重い
  • DNS制約に引っかかる
    • 1レコード255文字+長文鍵の分割が必要
  • 将来性
    • 量子暗号時代に非効率

そこで出てきたのが Ed25519-SHA256とのことです(Elliptic Curve Digital Signature Algorithm)

  • Ed25519-SHA256 とはなんぞ?
    • 楕円曲線署名アルゴリズムの一種で、楕円曲線 Curve25519をベースにしているそうな。
      • 掘り下げはまた別の機会に。
    • 特徴
      • セキュリティ
        • RSA2048相当の強度
      • 軽量高速
        • 署名・検証がRSAの数倍早いらしい
      • コンパクト
        • 公開鍵で32byte,署名で64byteでDNSサイズが小さい
      • 安定性
        • 定数時間演算?でタイミング攻撃耐性ありとのこと。
やるなら
DKIM-Signature: v=1; a=ed25519-sha256;
  d=example.com; s=mail2025;
  h=from:to:subject:date;
  bh=QmFzZTY0SGFzaFZhbHVlCg==;
  b=Vg0cJbZtT8FZ7uXw/8q12vFo...

https://datatracker.ietf.org/doc/html/rfc8463

DMARCとは?

A. SPFとDKIMの認証結果を統合し、さらにFrom:ヘッダのドメインと整合しているかを確認して、受信メールサーバーがどう扱うか(拒否・隔離・許可)を送信者側で指示できる仕組み。

つまりこれまでの2体の悪魔合体というわけですね(ちがう)

https://datatracker.ietf.org/doc/html/rfc7489

目的・方法

  1. From:ドメインのなりすまし防止‐目的
    • 表示されるFrom:ドメインとSPF/DKIMが整合しているかを検証
  2. 認証失敗時の扱いを送信側が指定(Policy)
    • none
      • 検証に失敗してもメールは送られはする。
      • レポートは送信側に届く。
    • quarantine
      • 検証に失敗したら当該メールは隔離する。
      • スパム的な。
    • reject
      • 検証に失敗したら当該メールの送信を拒否する。
  3. 結果を送信ドメインに報告
    • rua
      • 集計レポート
    • ruf
      • 失敗レポート

流れ

受信メールサーバ

  1. From:ドメインを抽出
  2. メールヘッダのFrom:に記載されたドメインを基準にする
  3. SPFとDKIMの評価
    • SPF
      • 送信元IPアドレスがFrom:ドメイン(サブドメイン)と整合しているか
    • DKIM
      • 署名ドメイン(d=)がFrom:ドメインと整合しているか
  4. 整合性判定
    • 2つのモードで判定し、SPF・DKIMのどちらか1つでも整合していればDMARC=pass 🎉
    • モード
      • strict(s)ドメイン完全一致
      • relaxed(r)サブドメイン許可
  5. ポリシー適用
    • none 何もしない、ログのみ記録する
    • quarantine 隔離、迷惑メール扱いにする
    • reject SMTPレベルで拒否する
  6. 集計レポート
    • XMLでレポートが送られる。詳細は下の通り。

https://datatracker.ietf.org/doc/html/rfc7489#section-3.1

https://datatracker.ietf.org/doc/html/rfc7489#section-7

ruaとは?

A. 受信メールサーバーが、所有するドメインを使用したメールを受け取った結果を1日単位でまとめて送ってくれる「集計レポート」(Aggregate Report)

中身はXML(ZIP圧縮付き)で送信元IPアドレスや認証結果がの統計情報があるらしい。

  • 用途
    • 監視
      • どのIPアドレスが偽装しているかの可視化
    • 偽装検出
      • 設定してないSaaSやスパムの検出
    • 移行
      • DMARCは一気にPolicyをrejectにするのではなく、段階的にnone→quarantine→rejectにするらしいので、その判断材料にするらしい
中身の例
xml
<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <report_id>123456789</report_id>
    <date_range>
      <begin>1734460800</begin> <!-- UNIX timestamp -->
      <end>1734547200</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <adkim>s</adkim>
    <aspf>s</aspf>
    <p>quarantine</p>
  </policy_published>
  <record>
    <row>
      <source_ip>203.0.113.10</source_ip>
      <count>150</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>example.com</domain>
        <result>pass</result>
      </dkim>
      <spf>
        <domain>mailer.example.net</domain>
        <result>fail</result>
      </spf>
    </auth_results>
  </record>
</feedback>

rufとは?

A. 受信メールサーバーにてDMARCのルールに従った検証に失敗したメールについて、その具体的なヘッダーや一部本文をサンプルとして受信メールサーバが送ってくれる仕組み。

こっちはXMLではなく、実際のメールメッセージ(RFC822)

しかも、プライバシー上の理由で対応してない受信メールサーバーが多い(Gmailなど)

もりもり

https://datatracker.ietf.org/doc/html/rfc822

Feedback-Type: auth-failure
User-Agent: DMARC-Reporter
Version: 1.0
Original-Mail-From: badguy@evil.com
Arrival-Date: Tue, 21 Oct 2025 06:40:00 -0000
Source-IP: 203.0.113.50
Authentication-Results: spf=fail smtp.mailfrom=evil.com; dkim=fail header.d=evil.com;
Original-Message-ID: <abc123@evil.com>

--Original Message Headers--
From: "Fake CEO" <ceo@example.com>
To: employee@example.com
Subject: Urgent Payment
ARCとか…

ARCとは?

A. メールが「正規送信者→中継(メーリングリスト・転送サービスなど)→受信者」という経路をたどる中で、元の送信の認証結果が中継で改変されたときに認証に失敗する課題の解決のために設計された仕組み。RFC8617。

https://datatracker.ietf.org/doc/html/rfc8617

背景

ここまででだいたい分かるが、転送・中継の過程で送信元のIPアドレスが分かる/ヘッダーや本文が修正されることが多い。

→ そのため、中継を行うサービスは送信者ドメインを知っていて信頼しているのにこれが認証チェーンに反映されない問題を解消したいモチベーション。

ちょっとした仕組み

ARCヘッダー

  • AAR(ARC-Authentication-Results)
    • 中継に入った時点で元の、「SPF,DKIM,DMARC」の認証結果を記録
  • AMS(ARC-Message-Signature)
    • 中継サーバがその時点のメールに対してDKIM五感の署名を実施。
    • この中継サーバーがこのメールを署名しました卍をやる
  • AS(ARC-Seal)
    • 署名したAMS+前段のARCセット全体を中継サーバーが封印。
    • Chainのチェック用

流れ(中継サーバー)

  1. メールを受け取る(SPF,DKIM,DMARCの結果を取得)

  2. AARヘッダを付与して認証状態を記録。

  3. メールに何らかしらの修正(件名やフッター)

  4. AMSでその状態のメールを署名

  5. ASで今回のARC セット+\既存チェーンを封印

  6. メールを次のホップへGo

流れ2(受信メールサーバー)

  1. メール受信(SPF,DKIM,DMARCを通常通り評価)

  2. ARCヘッダー群をチェック

    • チェーンがつながっているか(i=1,i=2...)、書くARC-Sealなどを確認

  3. もし「オリジナルがSPF,DKIMを通過していた」+「中継が信用できる」+「中継後の処理でSPF,DKIMが壊れただけ」というケースならARCを信用して最終的にメールの正当性を許可する

???ARCチェーンって???

ARCセット(AAR+AMS+AS)の綴。

封印ってなんだろう。

ARC-Authentication-Results: i=1; mx.intermediate.com;
 spf=pass smtp.mfrom=sender@example.com;
 dkim=pass header.d=example.com;
 dmarc=pass header.from=example.com
ARC-Seal: i=1; s=selector; d=intermediate.com; cv=none; ...
b=Base64Signature

BIMIとは?

A. 認証済みのメール送信者のブランドロゴを受信者のメールクライアントに表示する仕組み。

https://bimigroup.org/

https://datatracker.ietf.org/doc/draft-brand-indicators-for-message-identification/

背景・目的

  • 目的
    • メールの送信ドメインなどをの検証技術は前述の通り高まっているが、受信者側で視覚的に認知できる情報がメールクライアント上にあると信頼度が上がる。
    • なりすまされないブランド表示と、インボックス上でのブランド体験向上。
  • 背景課題
    • 多くのメールアドレスが差出人のアイコンやプロフィールを表示していたが、必ずしも認証済み・ドメイン所有者管理という保証がなかった。

BIMIはあくまで表示層の仕様であることに注意。

フロー

  1. 受信メールが到着

  2. ドメイン所有者がDNSでBIMIレコードを出していれば、MTAが _bimi サブドメインのTXTのDNS照会

  3. レコード上のロゴからSVGを取得。プションで証明書を検証

  4. 認証に成功し、レコードの形式・ロゴが仕様に準拠していればメールクライアントがロゴを表示する

BIMI DNS
default._bimi.example.com. IN TXT "v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/vmc.pem;"

SVG Tiny P/Sとは?

A. XMLたるSVGを軽量+安全性を強めたプロファイル。BIMIでブランドロゴを配信する際に使用される。

もともとSVGにはプロファイル(baseProfile属性で指定)があり、機能を絞ったりできる。
→ SVG Tiny 1.2はモバイルなどのリソース制約がある利用向けに展開される)

仕様

  1. SVG Tiny 1.2をベースにして、こちらで定義された要素・属性のうち「使用可能・禁止・必須を明示」を指定する形式。

必須・禁止の例

  • ルート <svg> 要素において、xmlns="http://www.w3.org/2000/svg", version="1.2", baseProfile="tiny-ps"を設定すること

  • スクリプト、アニメーション、外部リソース参照、インタラクティブな機能などは禁止または制限。

  • ファイルサイズ制限の指針：未圧縮状態で “32キロバイト以下” を目安とすべき

https://www.ietf.org/archive/id/draft-svg-tiny-ps-abrotman-04.html

VMCとは?

A. メールの送信ドメイン所有者が、所有するブランドロゴがそのドメインと正当に関係していることをデジタル証明書(CA発行)によって保証する仕組み。

背景・目的

  • 背景課題
    • 通常のメール認証では送信ドメインや改ざんは検証できてもロゴがそのブランドのものであるかの証明までは含まれない。
    • そのためブランドロゴが悪意ある第三者に無断使用されることを防止するなどの課題感。
  • 目的
    • 送信先で自社のロゴが正しく安心して閲覧できるようにすることが目的。

VMC登録の前提条件

  1. DMARCのポリシーがQuarantineかReject(更に厳しいとptc=100→認証失敗は100%Reject)

  2. 認証ロゴが商標登録されていること

  3. 認証ロゴのSVGが SVG Tiny P/Sに準拠すること

  4. CAによって組織の実在証明がされること

→ 認定されたらPEM形式などで証明書を発行。

メーラーに表示されるアイコンにいくらかかってるかと思うと、ありがたみを感じますね。

いくらぐらいかかるの

全部自力でだと30万はくだらなそう…

  1. 商標登録

  2. 500ドルぐらい?

  3. ロゴ準備

  4. 300ドルぐらい

  5. メール認証

  6. 200ドルぐらい

  7. VMC

  8. 900~1500ドル

https://www.sectigo.com/ssl-certificates-tls/verified-mark-certificates

(さくらがVMCやってたり)

https://ssl.sakura.ad.jp/symantec/vmc/

備考: MTA

Mail Transfer Agent

→ 電子メールを送信者から受信者へ転送・配送するプログラムのこと。

  • MUA(Mail User Agent)
    • メールクライアント。Gmailとか。
  • MSA(Mail Submission Agent)
    • ユーザーからメールを受け取る。Port587。Postfixなど。
  • MTA(Mail Transfer Agent)
    • SMTPでサーバー間の転送をする。Postfixなど。
  • MDA(Mail Delivery Agent)
    • 受信者側のユーザーのメールボックスに配信。Devecotなど。

力尽きたので深堀りはまた今度。

https://datatracker.ietf.org/doc/html/rfc5321#section-2.3.10

おまとめ

メールはむずいですね。
横文字だらけで嫌厭していましたが、腰を据えてちょっとだけ理解に務めました。

毎度のこと、本記事は温かみのある手書きで執筆しました。
誤字脱字や誤っている表現・理解がありましたら優しくコメントいただけますと幸いです。

追記
今回執筆に際してこちらのOSSを利用させていただきました!執筆体験がとても良くなりハッピーです。
記事のネタはたくさん溜まっているので、あとはやる気だけ…。

https://zenn.dev/karintou/articles/zenn-cli-wysiwyg

https://github.com/karintou8710/zenn-editor-wysiwyg

参考文献など

https://www.proofpoint.com/jp/threat-reference/dmarc

https://bimigroup.org/resources/VMC_Requirements_latest.pdf

https://jp.globalsign.com/vmc/about_vmc.html

Discussion