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

エンジニアがハマりがちなメール送信の沼を抜けるために

Posted at 2025-12-03

エンジニアがハマりがちなメール送信の沼を抜けるために

SPF/DKIM/DMARC と運用ノウハウ、blastengine 体験談つき

この記事で伝えたいこと

「メール送信、なんとなく動いてるし後回しでいいか…」

── 正直、昔の自分はずっとこう思っていました。
ところが、

SPF / DKIM / DMARC の設定ミスで迷惑メール行き連発
SMTP サーバーが不正利用されかけて IP 評判がボロボロ
携帯キャリアだけなぜか届かない

……といった小さくないトラブルを経験し、
最終的に クラウド型のメール配信サービス（blastengine）に移行 したことで、
ようやく「メールの沼」から抜けつつあります。

この記事では、その過程で学んだ

メール送信の全体像（SMTP / 認証 / IP レピュテーション）
SPF / DKIM / DMARC を実務でどう押さえるか
迷惑メール判定を避ける運用ノウハウ
SMTP 不正利用のリアルなトラブル例
実際に blastengine を使ってみた体験談

を、初心者〜中級エンジニア向けに整理します。

「今はなんとなく動いてるけど、いつか炎上しそうで怖い」

という気持ちが少しでもあるなら、
この記事がチェックリスト代わりになるはずです。

なぜ 2025 年の今、メール送信をちゃんと学ぶべきか
メール配送の全体像をざっくり掴む
SPF / DKIM / DMARC を郵便でイメージする
エンジニアがハマりがちな落とし穴と対策
Gmail / Outlook の新ガイドラインをざっくり把握
実録：SMTP サーバーがほぼ乗っ取られた話
自前 SMTP から blastengine に寄せてみた
ユースケース別：メール設計のポイント
明日から使えるチェックリスト
まとめ
参考リンク

なぜ 2025 年の今、メール送信をちゃんと学ぶべきか

ここ数年で、Gmail や Outlook など大手プロバイダの「送信者に対する要求」が一気に厳しくなりました。

ざっくりいうと：

1 日あたり 5,000 通以上 送る送信者は
SPF・DKIM・DMARC の実装が必須クラス
配信停止リンクや迷惑メール報告率までかなり見られている
少量送信でも、認証なしメールは露骨に届きにくくなっている

そして、EC・予約・SaaS などの Web サービスは相変わらずメール依存です。

会員登録確認メール
パスワードリセット
注文・予約の確認
課金失敗のお知らせ

これらが届かないと、サービスが「壊れて見える」 ようになります。

「アプリ側のログは全部 OK」
なのに、ユーザーからは
「メールが来ないから登録できないんだけど？」

という問い合わせが来る、あの感じです。

メール配送の全体像をざっくり掴む

まずは全体の流れを 1 枚の図でイメージしておきます。

[アプリ / バックエンド]
        │  (SMTP or API)
        v
[メールサーバ / メール配信サービス]
        │  (インターネット)
        v
[受信プロバイダ (Gmail / Outlook / キャリア etc)]
        │
        v
[ユーザーの受信トレイ or 迷惑メール or 拒否]

各ポイントで起きていることをもう少し分解すると：

アプリ → メール配信基盤
- SMTP で送るか、メール配信サービスの API を叩く
メール配信基盤 → 受信プロバイダ
- SPF / DKIM / DMARC の検証
- IP レピュテーション評価
- コンテンツのスパムスコア
- バウンス（エラー）処理
受信プロバイダ
- 受信トレイ / 迷惑メール / 拒否に振り分ける

開発者としては

「SMTP で送れたら終わり」ではなく、
その先で何が起きているか をある程度イメージできると、
トラブルシュートが一気に楽になります。

SPF / DKIM / DMARC を郵便でイメージする

ここが本記事のメインどころです。
3 つの認証技術を、郵便に例えてざっくり整理します。

3 つの役割と郵便のたとえ

技術	何をしているか	郵便でのイメージ
SPF	どのサーバーが「正規の送り主」か宣言する	どの郵便局から出したら OK か
DKIM	メール内容が改ざんされていないか検証する	封印＋差出人の印鑑
DMARC	認証失敗メールをどう扱うか決める	受け取り側のルール

SPF（Sender Policy Framework）

DNS の TXT レコードに
このドメインのメールはこの IP / サービスから送ります
と宣言する仕組み。
例：v=spf1 include:_spf.example-service.com ip4:xxx.xxx.xxx.xxx ~all
受信側は、送信してきたサーバーの IP がこのリストに入っているか をチェックする。

よくあるミス

自前 SMTP だけ書いていて、外部のメルマガサービスや blastengine を書き忘れる
~all と -all の意味を理解せずとりあえず書いてしまう

DKIM（DomainKeys Identified Mail）

メールのヘッダに「電子署名」を仕込み、
受信側が DNS 上の公開鍵で検証することで
途中で改ざんされていないか を確かめる仕組み。
送信側は秘密鍵を持ち、受信側は公開鍵で検証するイメージ。

ポイント

鍵長は十分長く（1024bit 以上推奨）
DNS に公開鍵を登録するときの改行・スペースミスに注意
テスト送信して dkim=pass を必ず確認

DMARC（Domain-based Message Authentication, Reporting & Conformance）

「SPF / DKIM の結果を見て、認証失敗メールをどう扱うか」を決めるポリシー。
p=none / quarantine / reject の 3 つが基本。
さらに、認証失敗のレポートをメールで受け取ることもできる。

導入のコツ

最初は p=none（監視モード）で開始
レポートを見て、正当なメールまで失敗していないか確認
少しずつ quarantine（隔離）や reject（拒否）に寄せていく

図でざっくりまとめると

┌───────────────────────────┐
│   送信者(example.com)      │
│                           │
│ SPF: この IP から送る       │
│ DKIM: 署名はこれ          　│
│ DMARC: 失敗したらこうして　　 │
└───────────────────────────┘
            │
            ▼
┌───────────────────────────┐
│   受信プロバイダ(Gmail等)    │
│   1. SPF 検証         　   │
│   2. DKIM 検証          　 │
│   3. DMARC ポリシー確認     │
│   4. IP/コンテンツ評価　　   │
└───────────────────────────┘
            │
            ▼
   受信トレイ / 迷惑メール / 拒否

エンジニアがハマりがちな落とし穴と対策

ここからは、実務で「あるある」な失敗パターンを並べていきます。

落とし穴 1：SPF / DKIM の設定漏れ・ミス

あるある

外部サービスから送るメールを SPF に入れ忘れる
DKIM の公開鍵を DNS にコピペするときに改行が混ざり検証失敗
サブドメインや別ブランドのドメインの SPF を忘れる

対策

「このドメインからどのルートでメールが出ているか」を一度棚卸しする
新しいメール配信サービスを導入したら、SPF 更新をセットでタスク化
テスト送信して、受信したメールのヘッダで
spf=pass, dkim=pass, dmarc=pass を目視確認する

落とし穴 2：送信リストが汚い（バウンスだらけ）

存在しないアドレスや、ずっと使われていないアドレスに
送り続けると、こうなります。

バウンス（エラー）が増える
スパムトラップを踏む
IP / ドメインの評価が下がる

最低限やったほうがいいこと

新規登録時は ダブルオプトイン でメールアドレスを検証
長期間開封のないアドレスは「休眠」として配信頻度を落とす or 配信停止
バウンスしたアドレスは自動でリストから除外
→ メール配信サービスに任せるのが楽

落とし穴 3：コンテンツ・頻度がスパムっぽい

技術的には問題なくても、人間目線で「うざい」メール は
迷惑メール報告されやすくなり、結果として到達率を落とします。

NG パターン

毎日同じような広告メールを連射
すべて画像のみでテキストがほぼない HTML メール
件名が煽りタイトルだらけ
フッターに小さく「配信停止はこちら」と書いてあるだけ

おすすめ

1 通ごとに「誰に、何の価値を届けたいメールなのか」を明確にする
基本は週 1〜数回程度に抑える
（重要なお知らせ系以外）
フッターに目立つ形で 「配信停止はこちら」 を置く
List-Unsubscribe ヘッダも付けて、Gmail の「登録解除」ボタンを出す

落とし穴 4：`no-reply@` から送ってしまう

no-reply@example.com からのメールは、

ユーザーが「返信できない」ことにストレスを感じやすい
一部プロバイダからの評価も良くないと言われている

現実的な落としどころ

From は「返信を受け取れるアドレス」にする
（専用の問い合わせ受付アドレスなど）
返信してほしくない場合も、本文中で
「このメールには返信できません。お問い合わせはこちらから」
と明示する

Gmail / Outlook の新ガイドラインをざっくり把握

ここでは細かい文言までは追わず、エンジニアが押さえておくべきポイントだけ ピックアップします。

Gmail の送信者ガイドライン（2024〜）

特に 1 日 5,000 通以上 Gmail に送る送信者向けに、ざっくり：

SPF と DKIM の設定は必須クラス
DMARC もちゃんと設定してね
List-Unsubscribe ヘッダを付けて 1 クリック解除できるように
迷惑メール報告率を一定以下に保つこと

少量送信でも、SPF / DKIM 未設定のメールはどんどん届きにくくなる 方向です。

Outlook.com / Hotmail などの要件（2025〜）

Outlook 系も 2025 年から、1 日 5,000 通以上の送信者に対して：

SPF
DKIM
DMARC（p=none 以上）

を必須とする動きになっています。

実録：SMTP サーバーがほぼ乗っ取られた話

ここからは、完全に体験談テイストの話です。

発覚のきっかけ

ある日の夕方、社内 Slack にこんなメッセージが飛びました。

「なんかサーバー重くないですか？」

監視ツールを開いてみると、SMTP サーバーの送信数グラフだけが異常に跳ね上がっている。

普段：1 分あたり数通程度
当日：1 分あたり数百通ペース

慌ててログを見たところ、

見覚えのない海外 IP からの SMTP 認証成功ログ
そこから同じ宛先ドメインに大量の送信

「これ完全にやられてるやつだ…」となりました。

原因

一部の SMTP アカウントのパスワードが弱すぎた
総当たり（ブルートフォース）で突破された
認証後、スパムメールの踏み台として使われていた

影響

一部 IP がスパム用ブラックリストに登録される
自社からの正規の通知メールまで届きづらくなる
一部ユーザーから「メールが来ない」と問い合わせが増える

そのとき取った対策

問題のアカウントを即無効化
SMTP アカウント全件のパスワードを強制変更
接続元 IP を制限（社内 VPN / 特定 IP のみ）
一定時間あたりの送信数上限を設けて、異常値でアラート
ブラックリストに登録された IP を調べ、解除申請
「そもそも自前 SMTP で全部やるのは限界では？」と気づく

この一件で改めて、

メールインフラは「止まると普通に事業インパクトがある」

という当たり前の事実を痛感しました。

自前 SMTP から blastengine に寄せてみた

ここからは、blastengine を実際に試してみた話です。
（Qiita の「blastengine 使ってみた賞」も狙いつつ）

何がつらくて移行を検討したか

Postfix ベースの自前 SMTP を運用
認証 / ブラックリスト / バウンス処理など、
「メール専用の知識」がないと追えないトラブルが多い
チーム全体で「誰もメールサーバーを触りたくない」空気

「ここは専門サービスに任せて、アプリ開発に集中したほうが良くない？」

という結論になりました。

トライアル登録と最初の構成

blastengine は公式サイトからトライアル申し込みができます。
まずは本番ではなく STG 環境の通知メールから移行 しました。

構成イメージはこんな感じです。

[アプリ (STG)]
   │
   │ HTTPS / API or SMTP
   ▼
[blastengine]
   │
   ▼
[Gmail / Outlook / 携帯キャリア etc]

From ドメインは本番と同じ（認証設定を本番と共有しやすい）
ただしアドレスは stg-notify@example.com のように分ける
SPF / DKIM / DMARC は blastengine のドキュメント通りに設定

API と SMTP の使い分け

blastengine は、

SMTP リレーとして既存の MTA から中継してもいいし
Web API / SDK で直接メールを投げてもいい

という柔軟な構成ができます。

今回は、

レガシーなバッチ系は SMTP リレーに乗せ替え
新規開発している Node.js のバックエンドからは Web API を利用

というハイブリッドにしました。

Node.js からのシンプルな送信例（イメージ）

import { BlastEngine, Transaction } from 'blastengine';

const be = new BlastEngine({
  userId: process.env.BE_USER_ID,
  apiKey: process.env.BE_API_KEY,
});

export async function sendWelcomeMail(to, name) {
  const tx = new Transaction();

  tx.setFrom('no-reply@example.com', 'Example App');
  tx.setTo(to, name);
  tx.setSubject('会員登録ありがとうございます');
  tx.setText(
    `${name} 様\n\n` +
    'Example App にご登録いただきありがとうございます。\n' +
    '下記リンクからメールアドレスを認証してください。\n\n' +
    'https://example.com/verify?token=xxxxx\n'
  );

  const res = await tx.send();
  console.log('blastengine response:', res);
}

SDK を入れて API キーを設定すれば、
数十行でトランザクションメールが飛ぶ のは素直に快適でした。

管理コンソールで「これは助かる」と思った点

自前 SMTP と比べて一番インパクトがあったのは、管理画面の情報量です。

いつ・どのアドレスに・どんな件名で送ったか
成功 / 失敗
失敗ならどのプロバイダから、どんなエラーコードか

が、ブラウザからパッと一覧できる。

さらに、特定メールの詳細画面では

件名
差出人 / 宛先
本文（プレビュー）

まで確認できるので、

「ユーザーが “変なメールが来た” と言っているが、
実際どんな内容で飛んでいるんだろう？」

というときも、SSH でログを漁らなくて済むようになりました。

到達率と運用コストの変化

STG → 一部本番と段階的に移行してみて、肌感としては：

携帯キャリア宛のエラーが目に見えて減った
SPF / DKIM / DMARC の設定が「公式ドキュメントに従えば済む」レベルに整理された
バウンス処理・ブラックリスト監視など
メール特有の運用がほぼサービス側にオフロード された

そして何より、

「メール配信がまたおかしくなるのでは…」

という不安がかなり減りました。

もちろん、コンテンツや配信頻度を雑にすると
迷惑メール報告はされてしまうので、
その部分は引き続き我々の責任です。

それでも、技術的な “足場” をプロに任せられた のは大きかったです。

ユースケース別：メール設計のポイント

次に、ユースケースごとに「何を送って」「どう設計するか」を軽く整理します。

1. EC サイト

送る代表的なメール：

会員登録確認（ダブルオプトイン）
注文確認
発送完了（追跡番号つき）
パスワードリセット
セール・クーポン案内（メルマガ）

設計のポイント：

トランザクション系（注文確認など）とメルマガ系は
件名と文体を分ける
メルマガは必ずオプトイン（チェックボックスなど）で同意を取る
配信停止リンクをしっかり目立たせる

2. 予約システム

送る代表的なメール：

予約完了
リマインド（前日 / 当日）
キャンセル完了

設計のポイント：

件名に「日時」と「店舗名 / サービス名」を必ず入れる
→ ユーザーが見つけやすい
リマインドの頻度はユーザー目線で
（前日＋数時間前くらいが多い）

3. SaaS / Web アプリ

送る代表的なメール：

アカウント登録 / メール認証
ログイン通知 / パスワードリセット
請求書・支払い失敗
機能アップデートやお知らせ

設計のポイント：

セキュリティ系（パスワードリセットなど）は テキストを中心に素直に
派手なデザインよりも「内容が一目でわかる」ことを優先
アップデート情報はアプリ内バナーやお知らせとも組み合わせて、
メールに頼りすぎない設計にする

明日から使えるチェックリスト

「全部やろうと思うとしんどいので、とりあえずここから」

という観点で、最低限のチェックリストを作ってみました。

認証まわり

SPF レコードが設定されている（すべての送信元を含めている）
DKIM で署名を付けている（dkim=pass を確認した）
DMARC レコードを設定済み（まずは p=none でも OK）
テスト送信したメールの Authentication-Results を実際に目で見た

運用まわり

新規登録時にメールアドレスの有効性を確認している（ダブルオプトインなど）
バウンス（エラー）したアドレスはリストから自動除外される
配信停止リンクがフッターに分かりやすく置いてある
no-reply@ ではなく返信可能な From アドレスを使っている
配信頻度の上限（例：週 1〜3 通）を決めている

セキュリティまわり

SMTP / メール配信サービスの認証情報を安全に管理している
（環境変数・シークレットマネージャなど）
パスワードは長く複雑で、使い回していない
異常な送信数があった場合にアラートが飛ぶ仕組みがある
メール配信サービスの管理画面に 2 段階認証を設定している

まとめ

この記事では、

メール送信の全体像
SPF / DKIM / DMARC の役割とざっくりした設定の流れ
到達率を落とす「あるある」ポイントと対策
SMTP 不正利用の体験談
blastengine を使ってみたときの感想

を、初心者〜中級エンジニア目線でまとめました。

メールは、

壊れるとユーザーに直撃するのに
ちゃんと触れる人が少ない

という、地味だけど「おいしい」スキルセット だと思っています。

今はまだ「とりあえず SMTP 叩いてるだけ」だったとしても、
この記事のチェックリストを 1 つずつ潰していけば、
着実に「メール強いエンジニア」に近づけます。

もし「自前 SMTP の運用もう限界かも…」と思い始めているなら、
今回紹介した blastengine のようなサービスを一度試して、
専門家に任せられるところは任せてしまうのもアリです。

メールは「止まってから慌てる」のが一番つらいので、
ぜひ余裕のあるうちに、少しずつ手を入れてみてください。

参考リンク

実際に運用する際は、必ず公式ドキュメント・一次情報も確認してください。

SPF / DKIM / DMARC の基礎

DMARC / DKIM / SPF の概要と図解解説
https://www.xdomain.ne.jp/column/dmarc-dkim-spf/
送信ドメイン認証技術の総務省資料（SPF/DKIM/DMARC）
https://www.soumu.go.jp/main_sosiki/joho_tsusin/security/

Gmail / Outlook 送信者ガイドライン

Gmail ヘルプ: メール送信者のガイドライン
https://support.google.com/a/answer/81126?hl=ja
Outlook.com / Hotmail 向け送信ベストプラクティス
https://sendersupport.olc.protection.outlook.com/pm/

メール配信・IP レピュテーション・ブラックリスト

メールというインターネットの闇と IP レピュテーション（Qiita）
https://qiita.com/
ブラックリスト登録の原因と対応を解説したブログ（各種ベンダーの記事が参考になります）

blastengine 関連

blastengine 公式サイト
https://blastengine.jp/
blastengine API ドキュメント
https://blastengine.jp/documents/
Qiita: 「blastengine はじめました」系の導入記事
https://qiita.com/search?q=blastengine

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

エンジニアがハマりがちなメール送信の沼を抜けるために

エンジニアがハマりがちなメール送信の沼を抜けるために

この記事で伝えたいこと

目次

なぜ 2025 年の今、メール送信をちゃんと学ぶべきか

メール配送の全体像をざっくり掴む

SPF / DKIM / DMARC を郵便でイメージする

3 つの役割と郵便のたとえ

SPF（Sender Policy Framework）

DKIM（DomainKeys Identified Mail）

DMARC（Domain-based Message Authentication, Reporting & Conformance）

図でざっくりまとめると

エンジニアがハマりがちな落とし穴と対策

落とし穴 1：SPF / DKIM の設定漏れ・ミス

落とし穴 2：送信リストが汚い（バウンスだらけ）

落とし穴 3：コンテンツ・頻度がスパムっぽい

落とし穴 4：no-reply@ から送ってしまう

Gmail / Outlook の新ガイドラインをざっくり把握

Gmail の送信者ガイドライン（2024〜）

Outlook.com / Hotmail などの要件（2025〜）

実録：SMTP サーバーがほぼ乗っ取られた話

発覚のきっかけ

原因

影響

そのとき取った対策

自前 SMTP から blastengine に寄せてみた

何がつらくて移行を検討したか

トライアル登録と最初の構成

API と SMTP の使い分け

Node.js からのシンプルな送信例（イメージ）

管理コンソールで「これは助かる」と思った点

到達率と運用コストの変化

ユースケース別：メール設計のポイント

1. EC サイト

2. 予約システム

3. SaaS / Web アプリ

明日から使えるチェックリスト

認証まわり

運用まわり

セキュリティまわり

まとめ

参考リンク

SPF / DKIM / DMARC の基礎

Gmail / Outlook 送信者ガイドライン

メール配信・IP レピュテーション・ブラックリスト

blastengine 関連

落とし穴 4：`no-reply@` から送ってしまう