SJ blog
Security-JAWS #41（10周年記念 Day1） #4

10サービス以上のメール到達率改善を地道に継続的に進めている話

30サービス×50ドメイン以上のメール送信基盤を運用するSREが、SPFインクルード制限・IPレピュテーション・DMARC段階的厳格化を継続改善している実践

🎤 ヘルスケア・介護領域SaaS企業 SRE

#DMARC #SPF #DKIM #メール認証 #IPレピュテーション #Postmaster-Tools #運用

キーテイクアウェイ

IPレピュテーションは一度下がると回復した実績がない。予防・早期介入が唯一の対策。『見るだけで終わらせない→対象特定→改善依頼→経過観察』の完全サイクルが必須

登壇者の背景

  • ヘルスケア・介護領域のSaaS企業のSRE
  • メール送信基盤の統括を担当
  • AWS認定ビルダー審判員
  • 管理規模: 30サービス以上 × 50ドメイン以上（CFP応募時は10サービス → スライド作成中に増加）

メール到達率改善が必要になったきっかけ

従来の運用

  • キャリアメールに届かない問題
  • 文字化け発生
  • メール配信遅延
  • バウンス率の一時的増加
  • → これらを個別障害対応・問い合わせ対応としてのみ処理していた

Googleガイドライン（2024年2月〜）による変化

1日5,000通以上送信する送信者への要件:

  • スパムメール率: 0.3%未満に抑えること
  • SPF・DKIM・DMARC対応が必須化
  • ワンクリック配信停止の実装

対応しないと「届きにくくなる」→ 実際には**「届かなくなる」**状態に。事業メール配信の最低限の前提条件が変わった。

認証技術の基本（SPF / DKIM / DMARC）

SPF  : 送信元IPが許可されているか確認（Return-Path/Envelope-Fromのドメイン）
DKIM : メール本文が改ざんされていないか電子署名で検証（DKIM-Signatureヘッダーのドメイン）
DMARC: SPF/DKIMの結果を踏まえて処理方針を決定（Fromヘッダーのドメイン）

アライメント（重要概念）

FromヘッダーのドメインとSPF/DKIMで認証されたドメインが一致しているかの確認。

  • SPFアライメント: FromドメインとReturn-Pathドメインの一致
  • DKIMアライメント: FromドメインとDKIM署名ドメインの一致
  • DMARCパス条件: SPFまたはDKIMのどちらか一方でアライメントを満たせばOK

注意: SPF・DKIMが単体でパスしていても、どちらもFromドメインと一致しなければDMARCはフェイル → メール届かず。

外部メール配信サービス利用時の落とし穴

SendGrid・Mailchimp等を使用する場合:

  • Return-Path = サービスのドメイン（SPFアライメント常に失敗）
  • From = 自社ドメイン
  • → DKIMアライメントを必ず通す設計が必須

SPFのインクルード制限問題

問題

SPFレコードのincludeは累計10回まで（直下だけでなく再帰的なincludeも含む）。

example.com TXT "v=spf1 include:_spf.google.com include:sendgrid.net include:... ~all"

複数事業部が異なるSaaSを使ってメール送信すると、すぐに上限に到達。

解決策: サブドメイン分割

  • 用途・部門ごとにサブドメインを切り出し
  • 各サブドメインごとにSPFレコードを設定
  • 再帰的インクルード数をカウントするサービスの利用を推奨

共有リレーサーバーの運用課題

アーキテクチャ

各サービス → [自社リレイサーバー(EC2)] → [外部メール配信サービス] → 受信サーバー
                    ↑ 共有IP

外部サービス採用理由:

  1. 自前構築より安価
  2. 大量送信に特化したチューニング環境
  3. IPレピュテーション低下時に業者の知見を借りられる

共有IPのリスク連鎖

サービスAがスパム判定される
  → 共有IPのレピュテーション低下
    → サービスB, C, D...全てに波及
      → 配送制限 → バックログ蓄積 → 最悪受信拒否

IPレピュテーション > ドメインレピュテーション（影響度の優先順位）

対処法

  • 低下する前に介入（早期検知が重要）
  • 復帰不可能なIPは切り離し、事前に複数IPを割り当てておく

IPレピュテーション回復について

「回復した実績がない」

  • 落ち切らないようコントロールすることが唯一の運用
  • 回復見込めないIPは切り離した実績あり
  • 予防が全て

グループアドレスの複雑性

問題シナリオ

  1. 部門メールアドレスが自社サービスに登録
  2. 内部で転送設定あり
  3. 転職・部門異動で転送先が無効化
  4. バウンスが発生 → レピュテーション低下
  5. 原因は先方 → コントロール不可能

DMARCレポートの限界

  • 認証結果は見える
  • しかしメール本文の内容は不明
  • ユーザーが「迷惑メール」ボタンを押した理由は不明
  • どのメールが迷惑メール率上昇の原因かは特定不可
  • 用途: 認証異常の検知アラートとしてのみ有効

Postmaster Tools（Google提供）

確認可能な指標:

  • 迷惑メール率
  • IPレピュテーション
  • ドメインレピュテーション
  • 認証率

限界:

  • どのメール・どの受信者が原因かは不明
  • 迷惑メール率上昇の原因は特定不可
  • 用途: 異常検知トリガー、アプリケーションログとの連携分析

DMARC段階的移行

p=none（監視のみ）
  → 認証失敗パターンを分析、正規送信元を洗い出し
p=quarantine（迷惑メールフォルダ送り）
  → 比較的持っていきやすい。届かなくならない＋なりすまし防止
p=reject（受信拒否）
  → 顧客から要望があれば移行。全関係者の合意が必要

Noneのリスク: なりすましメールが送り放題の状態。放置は危険。

送信元の可視化（最重要基盤）

どのサービスが・どのドメイン・どのReturn-Path・どのDKIM署名で送信しているかを一元管理。

効果:

  • 迷惑メール率上昇時に「どこに連絡すればいいか」が即座にわかる
  • 影響範囲の確認が可能
  • Reject推進時の説得材料

運用体制

定例ミーティング（約5名体制 + 各事業部代表）

定例内容
GMスパム対策定例数字を見る場ではなく次アクション決定の場
メール関連定例DMARCレコード変更検討、送信元棚卸し、バウンス率共有
事業部連携窓口相談窓口を常設

問題発見時のフロー

検知 → 対象特定 → 認証結果・ログ確認 → 事業部連携
  → DNS変更必要時は影響範囲確認 → 設定変更 → 経過観察

最重要原則: 「見るだけで終わらせない」

Q&Aハイライト

Q: Amazon SESを使わない理由は？ A: IPレピュテーション低下時の解決を業者の知見に頼りたかった。自前で全て対応できるならSESも選択肢。

Q: IPレピュテーション悪化後のペナルティ対応は？ A: 回復した実績がない。落ち切らないようコントロール。回復見込めないIPは切り離し。

Q: DMARCレポート監視ツールは？ A: OSSツールを複数利用して可視化。

Q: BIMIの優先度は？ A: 安くないし大変。効果を見てから。List-Unsubscribeは推奨（使うべき）。

初心者向け補足

メールの「到達率」とは

送信したメールが受信者の受信トレイに実際に届く割合。迷惑メールフォルダに入る・受信サーバーに拒否される・配送途中で消えるなどの理由で100%にはならない。

IPレピュテーションとは

メール送信元のIPアドレスに対する「信用スコア」。大量のスパムを送ると下がり、下がると正規のメールも届かなくなる。クレジットスコアのメール版。

なぜSPFに「10回制限」があるのか

SPF検証はDNSルックアップを再帰的に行う。無制限にincludeを許すとDNS負荷が爆発するため、RFC 7208で10回に制限。これは「設計上の制約」であり変更不可。

バウンス率とは

送信したメールのうち、配送エラーで戻ってきた割合。バウンス率が高い = 「存在しないアドレスに大量送信している」= スパマーの特徴 → レピュテーション低下の原因になる。