Go to Qiita Advent Calendar Top
LoginSignup
9
11

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Day 24

エンジニアが知っておくべき メール送信・運用ノウハウ、メールの認証技術やセキュリティについて投稿しよう！ by blastengine Advent Calendar 2025

@Sumire02

2025年のメール送信は『DNS設定だけ』では終わらない：SPF/DKIM/DMARC＋運用設計で“届く”を作る実戦ガイド

Posted at

この記事は「エンジニアが知っておくべき メール送信・運用ノウハウ、メールの認証技術やセキュリティについて投稿しよう！ by blastengine Advent Calendar 2025」の記事として、メール送信の“実装”と“運用”を一体で設計するための実戦ノウハウをまとめています。

先に結論

メール送信の成功は「SMTPで投げた」ではなく、受信側で“通る条件”を満たし、運用で“崩れない状態”を維持できるかで決まります。

最低限、次を“設計→実装→運用”で揃えると、到達率もセキュリティも一気に安定します。

  • SPF / DKIM / DMARC を揃える（ただし「設定した」だけで終わらせない）
  • DMARC alignment（FromドメインとSPF/DKIMの整合）を最初から設計する
  • Bulk送信の世界では ワンクリック配信停止（List-Unsubscribe + List-Unsubscribe-Post） が前提
  • スパム率／苦情率／バウンス率を監視し、リスト衛生と抑止（suppression）を自動化
  • 認証・レピュテーション・セキュリティ（資格情報漏洩等） を「事故対応」ではなく「予防設計」にする

なぜ「届く／届かない」が難しいのか

メールは、HTTPのように「1リクエスト＝1結果」ではありません。
アプリが送ったあとに、受信側が複数の観点で評価します。

  • 認証（SPF / DKIM / DMARC）
  • インフラ健全性（TLS、逆引きDNS、HELO整合など）
  • レピュテーション（IP / ドメイン）
  • コンテンツ・振る舞い（苦情率、配信停止のしやすさ、宛先品質）

そして落とし穴の代表が、“エンベロープ（SMTP）”と“ヘッダ（メール本文）”が別物なことです。

┌─────────────────────────────────────┐
│ アプリが作るメール（RFC 5322ヘッダ＋本文）            │
│  From:  support@example.com                               │  ← DMARCの基準はここ（Header From）
│  To:    user@example.net                                  │
│  Subject: ...                                              │
│  ...                                                       │
└─────────────────────────────────────┘
                ▲
                │（SMTPで包む）
                ▼
┌─────────────────────────────────────┐
│ SMTPエンベロープ（配送用の外袋）                           │
│  MAIL FROM:<bounce@bounces.example.com>   ← SPFの評価対象になりやすい（Return-Path）
│  RCPT TO:<user@example.net>                               │
└─────────────────────────────────────┘

ここが理解できると、次の“事故あるある”が消えます。

  • SPFは通っているのにDMARCに落ちる
  • 送信サービスを変えたら突然迷惑メール判定が増えた
  • メルマガとトランザクションが同じドメインで燃えた

メール認証は「通す」より「運用する」が9割

SPF：正しく“送信元を列挙”できていますか

SPFは「このドメインから送っていい送信元（IPやinclude）をDNSで宣言する」仕組みです。

SPFの設計で守るべき原則

  • “送る可能性がある全て”を列挙する （一部が漏れると、その経路が迷惑メール化しやすい）
  • -all（Fail）か ~all（SoftFail）を選ぶ
    最初は ~all で始め、全送信元が揃ったら -all へ、が堅実です
  • SPFはDNS参照回数に制限があるため、include: を増やしすぎない（運用で破綻しがち）

例：基本形（※そのまま使わず、自社の送信元に合わせてください）

example.com. TXT "v=spf1 ip4:203.0.113.10 include:_spf.provider.example ~all"

ポイント：“どの送信”がこのSPFで担保されるかを一覧化し、SaaS追加や経路追加のたびに更新する運用を作ることが重要です。

DKIM：署名できても“壊れた署名”は意味がない

DKIMは「メールの一部（ヘッダ＋本文）に署名して、改ざんされていないことを示す」仕組みです。

DKIMが運用で壊れる典型

  • 中継やゲートウェイが 本文末尾にフッタを付ける（署名が壊れる）
  • List-Unsubscribe 等のヘッダが 後から追加される（署名対象に入っていない）
  • 署名鍵の更新（selector変更）で DNS反映漏れ が起きる

DKIM運用のコツ（現場で効きます）

  • selectorをローテーション前提で設計する（s=2025a → s=2025b のように）
  • 「後から変わる可能性があるヘッダ」を、署名の対象に入れる／入れないを決める
    Bulk運用では List-Unsubscribe 系ヘッダを署名対象に含める設計が安全です（後述）
  • 鍵長は“要件を満たす”だけでなく、将来の運用変更を見越して選ぶ

例：DKIM DNSレコード（公開鍵）

2025a._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq...（省略）"

DMARC：alignment（整合）を理解すると事故が減る

DMARCは「Fromに書かれたドメインを、受信側が信頼してよいか」を判断する“まとめ役”です。

DMARCの肝は、次の2点です。

  1. SPFまたはDKIMのどちらか（または両方）がPassする
  2. そのうえで、Header From のドメインと“整合（alignment）”している

alignment を一枚絵で理解する

Header From:   support@example.com
SPF domain:    bounces.example.com   ← MAIL FROM / Return-Path のドメイン
DKIM d=:       example.com           ← DKIM署名のドメイン

DMARC Pass には、
- SPF Pass か DKIM Pass が必要
- さらに Header From（example.com）と SPF domain または DKIM d= が整合している必要がある

ここを曖昧にしたまま送信基盤を変えると、突然DMARC落ちします。

DMARCは「段階的に強くする」が基本

いきなり p=reject にすると、正規メールまで落ちる事故が起きます。
おすすめはこの順番です。

  1. p=none（レポート収集）
  2. p=quarantine（徐々に隔離）
  3. p=reject（なりすましを強く拒否）

例：最初のDMARC（レポート収集）

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-rua@example.com; adkim=r; aspf=r; pct=100"

rua（集計レポート）を受け取れる体制を作ると、“自社を騙る送信” も早期に見つけられます。

2025年の送信要件：Bulk Sender前提で設計する

受信側の要件は年々厳しくなっています。特に大きいのは「一定量以上送る送信者（Bulk Sender）」の扱いです。

  • 一定以上の送信量があると、認証・配信停止・スパム率などが強く求められます
  • 送信量の定義が“ドメイン単位”で集計されるケースがあるため、サブドメイン分割の設計が重要です

重要：要件は変更され得ます。必ず各社の最新ガイドラインを確認してください（リンクは末尾にまとめます）。

ワンクリック配信停止（RFC 8058）を“実装で”落とさない

Bulk運用で見落としやすいのが、 List-Unsubscribe の“形式要件” です。

ポイントは2つです。

  • List-Unsubscribe に HTTPS URL を含める
  • List-Unsubscribe-Post: List-Unsubscribe=One-Click を付ける（ワンクリックの合図）
  • そして実務上は、この2つのヘッダがDKIM署名で保護される設計が安全です（途中で書き換わると壊れるため）

例：ヘッダ実装（購読型・メルマガ向け）

List-Unsubscribe: <https://example.com/unsub?token=...>, <mailto:unsubscribe@example.com>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

「ワンクリックURL」のサーバ実装で守ること

  • トークンは 受信者と配信リストを一意に特定 できること
  • URLは ログイン不要で完結 すること（クリック→完了が理想）
  • CSRFや推測耐性のために、トークンは 十分に長いランダム値 にすること
  • 受信側がPOSTしてくるケースがあるため、POSTを受けられる こと

バウンス／苦情／配信停止を“プロダクト品質”にする

「届かない」には必ず理由があります。運用で重要なのは、理由を分類し、再発防止の仕組みに落とすことです。

まずイベントを正しく分ける

  • Deferred（4xx）：一時的失敗（混雑・レート制限など）
  • Bounced（5xx）：恒久的失敗（宛先不明など）
  • Complaint：ユーザが迷惑メール報告
  • Unsubscribe：配信停止（List-Unsubscribe等）

この4つを混ぜると、やるべき対処が分からなくなります。

DSNコード（例）と“基本アクション”

代表例 意味（ざっくり） 推奨アクション
5.1.1 ユーザ不明 即サプレッション（以後送らない）
5.2.2 容量不足 しばらく待って再送／回数制限
4.xx 一時失敗 リトライ（指数バックオフ）＋監視
5.7.x ポリシー・認証系 認証・整合・内容・レピュテーションの点検

“一時失敗”を延々と再送し続けると、レピュテーションを落とします。リトライ上限と抑止ルールが必要です。

セキュリティ事故を防ぐ：漏洩・なりすまし・改ざんの現実的対策

メール送信は便利ですが、攻撃者にも便利です。現場で多い事故はこの3つです。

1) SMTP/API資格情報の漏洩（最も多い）

対策は「精神論」ではなく、設計で事故の半径を小さくすることです。

  • 資格情報を 環境別（dev/stg/prod） に分ける
  • アプリごとにキーを分け、権限を最小化する
  • 送信元（From / Return-Path）を 許可リストで縛る（可能なら）
  • 送信数の急増を検知する（1分あたり・1時間あたり）
  • 漏洩を疑ったら 即ローテーションできる運用を作る（手順化）

2) ヘッダインジェクション（改行混入）

ユーザ入力をSubjectやFrom表示名に入れるとき、改行 \r\n が混ざるとヘッダが壊れたり、悪用されます。

  • メール生成は 信頼できるライブラリを使う
  • ヘッダに入れる文字列は 改行や制御文字を除去する

例：最低限のサニタイズ（概念例）

function sanitizeHeaderValue(s) {
  return String(s).replace(/[\r\n\0]/g, " ").trim();
}

3) なりすまし（自社ドメインが騙られる）

ここで効くのが DMARCを段階的に強化して最終的にrejectへ です。
「自社から送っていないのにFromが自社」を減らせると、フィッシング被害も問い合わせも減ります。

監視とインシデント対応：落ちたときに最短で戻す手順

メールは「落ちてから」だと原因が多すぎて迷子になります。
最初から、最低限この監視を入れると復旧が速くなります。

監視ダッシュボード（最小セット）

  • 送信数（分・時・日）
  • 成功（accepted / delivered）
  • 失敗（deferred / bounced）
    • 4xx と 5xx を分ける
  • 苦情（complaint）
  • 配信停止（unsubscribe）
  • DMARCレポートの異常（未知の送信元増加など）

まず見るべき「Authentication-Results」

到達が落ちたら、まず受信メールのヘッダでこれを見ます。

  • SPF / DKIM / DMARC が pass しているか
  • Header From と整合しているか

例：ヘッダ（イメージ）

Authentication-Results: mx.example.net;
  spf=pass smtp.mailfrom=bounces.example.com;
  dkim=pass header.d=example.com;
  dmarc=pass header.from=example.com

これが dmarc=fail のとき、ほぼ必ず alignmentの設計漏れか 送信経路追加の反映漏れです。

自前運用 vs 配信サービス：どこまで持つべきか

メール配信は、やることが多いわりに 本業の差別化になりにくい領域でもあります。

判断を楽にするため、責務を分けて考えます。

自前で持つと重い責務（代表例）

  • IPレピュテーション管理
  • バウンス処理・抑止リスト運用
  • 受信側仕様変更への追従（要件強化）
  • ブラックリスト監視
  • レート制限・スパム率監視と改善

このあたりを、SMTPリレーやメール配信APIを提供するサービスに委譲できると、アプリ側は「誰に何を送るか」へ集中できます。

blastengineのようなメール配信基盤は、SMTPリレーやAPI連携に加え、運用負荷の高い領域（バウンス処理や監視など）をサービス側で担う選択肢になり得ます（採用の可否は要件次第です）。

チェックリスト（そのまま使える）

リリース前チェック（必須）

  • Fromドメインの設計（トランザクションとメルマガを分けるか）
  • SPF：全送信経路が含まれている（漏れがない）
  • DKIM：署名が壊れない経路になっている（中継の改変有無）
  • DMARC：p=none でまずレポート収集できる
  • DMARC alignment：Header From と SPF/DKIM の整合が設計されている
  • TLS：送信経路でTLSが有効（可能なら強制も検討）
  • 配信停止：メルマガはワンクリック配信停止（List-Unsubscribe / Post）
  • バウンス：5xxは抑止、4xxは上限付きリトライ
  • 送信爆発：急増アラート（資格情報漏洩の早期検知）
  • ログ：Message-ID と送信イベントが追える

月次運用チェック（おすすめ）

  • SPF/DKIM/DMARCレコードに変更がないか（SaaS追加時に破綻しやすい）
  • DMARCレポートで未知の送信元が増えていないか
  • バウンス率・苦情率の悪化がないか
  • 配信停止の導線が壊れていないか（リンク切れなど）
  • 送信量の増減（キャンペーン時に温めが必要なケースあり）

参考リンク

仕様・要件は更新され得ます。必ず最新の公式情報をご確認ください。

おわりに

メールは「送れたら終わり」ではなく、届くまでがプロダクトです。
SPF/DKIM/DMARCはスタートラインで、勝負はその後の 運用設計（監視・抑止・変更追従・事故対応） で決まります。

9
11
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
9
11

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?