Amazon SESの「疑似ドメイン設定」で起きたNHK ONEの障害 – MAIL FROM(Return-Path)ドメインの仕組みと運用リスク
2025年10月、NHKが運営する動画配信サービス「NHK ONE」で、会員登録メールが届かず新規ユーザーが登録できないという障害が発生しました。
原因はAmazon Simple Email Service(Amazon SES)を使った「カスタム MAIL FROM ドメイン(疑似ドメイン)」の扱い(?)に問題がありました。
※2025年11月時点ではドメイン情報をDNSサーバーで確認できます
メールの送信そのものは正常に完了しており、SPF・DKIM・DMARCもすべて認証PASS。しかし、実際にはGmailやMicrosoftの受信サーバー側で信頼評価が得られず、結果としてアカウント登録用のメールを届けられませんでした。
今回はこの「疑似ドメイン」が引き起こしたトラブルをもとに、Amazon SESの仕組みと運用リスクを見ていきたいと思います。
なお、Amazon SESでは「カスタム MAIL FROM ドメイン」という表現を使っていますが、この「MAIL FROM」は SMTP 通信上の差出人(エンベロープFrom)を指しており、メールの受信ヘッダー上では「Return-Path」として記録されます。
つまり、「MAIL FROM = Return-Path」と理解して問題ありません。
SMTPプロトコル上では「MAIL FROM」というコマンドで送信元アドレスを指定し、これは「エンベロープFrom」と呼ばれ、配送のための技術的な送信者情報です。受信後にこの情報は「Return-Path」としてメールヘッダーに保存されます。
AWSが提供するメール送信基盤、Amazon SESとは
Amazon SESは、AWSが提供する大規模なメール送信サービスです。システムから自動送信される通知メールや、ECサイトの注文確認、パスワードリセットなどを確実に届けるために設計されています。
SESは高い送信到達率とスケーラビリティを誇り、Amazon自身のサービス(AWSやKindleなど)も内部的に利用しています。企業にとっては
「サーバーを持たずに認証済みの環境から送信できる」
ことが最大の利点です。ただし、初期設定のままでは送信ドメインが「amazonses.com」となるため、自社ブランドのドメインから送られたように見せたい場合には「カスタム MAIL FROM ドメイン」を設定する必要があります。
MAIL FROMドメインの役割とは?
SMTPでメールを送る際、送信者情報には「From」と「MAIL FROM(Return-Path)」という2つのドメインが使われます。
- From:ユーザーに表示される送信者(例:info@example.jp)
- MAIL FROM(Return-Path): バウンスメール(エラーメール)の返信先。SPF認証に使用される
たとえば、次のように設定すると、受信者には「info@example.jp」から届いたように見えます。
From: info@example.jp
Return-Path: bounce@mail.example.jp
このMAIL FROMドメイン(ここでは mail.example.jp)は、SPF認証に使用されます。つまり、送信元IPアドレスがこのドメインのSPFレコードで許可されているかどうかで、正当性が判断されます。
詳しくはこちらの記事でも紹介しておりますのでご覧ください。
「カスタム MAIL FROM ドメイン」とは
Amazon SESでは、Return-Pathを自社ブランドに合わせたい場合に「カスタム MAIL FROM ドメイン」を設定できます。 デフォルトでは「amazonses.com」を使うため、メールヘッダー上に以下のような形で表示されます。
Return-Path: 01010189abcd@amazonses.com
これを変更して、自社のドメインに置き換えることが可能です。
Return-Path: 01010189abcd@mail.example.jp
このとき、DNSに「mail.example.jp」というサブドメインを定義し、SPFレコードを設定する必要があります。しかし、実際にはDNSに登録せず、見た目だけのドメイン(疑似ドメイン)として使うケースが多く見られます。
疑似ドメインとは何か?
「疑似ドメイン」とは、DNS上に存在しないドメイン名を一時的に
- MAIL FROM(Return-Path)
- DKIM署名
で使う設定のことを指します。 つまり、DNS上では解決できないが、メール送信システム内部では利用できる“仮想的なドメイン”です。
Amazon SESでは、バウンス処理や内部転送をAWS内部で完結させる設計のため、DNS上に存在しないMAIL FROM(Return-Path)ドメインを指定しても送信自体は可能です。
しかし、この「存在しない」ことが、後述するように重大な問題を引き起こすことがあります。
セキュリティを高める疑似ドメインの利用メリット:運用の分離とセキュリティの確保
「疑似ドメイン」は、本質的にはメールシステムの運用上の利便性とセキュリティを高めるために利用されます。
| メリット | 具体的効果 | 解説 |
|---|---|---|
|
運用分離の徹底 |
送信システム固有のドメインとして機能するため、メインドメインへの影響を遮断できる。 | 通常のウェブサイト(example.jp)とメールシステム(mail.example.jp)を分けておくことで、メールシステムで障害が起きてもウェブサイトの信頼性には影響が出ない。 |
|
本番ドメインの保護 |
DNSレコードを公開する必要がないため、ドメイン構成情報や内部設定が外部に漏れにくい。 | 企業が最も大切にしているブランドドメイン(example.jp)のDNS設定を外部のメールサービスに紐づける必要がないため、セキュリティ上のリスクを減らせる。特に厳しいセキュリティポリシーを持つ大企業や官公庁で重視される。 |
|
設定の簡素化 |
SES側のバウンス処理などが内部で完結するため、自社DNSでの複雑なレコード設定(バウンス処理用など)を省略できる。 | バウンスメール(エラーメール)の受け取りや処理をすべてAmazon SESに任せられるため、自社でのDNS設定やサーバー運用が不要になり、初期設定の手間を最小限に抑えられる。 |
この手法は、受信者が限定的な社内テストや、特定システムからの通知など、「信頼性よりも運用上の都合」を優先したい場面では非常に有効です。
2025年10月に疑似ドメインが招いた「NHK ONE」の配信障害
NHK ONEでは、Amazon SES経由でメールを送信する際に「@mail.nhk」というMAIL FROMドメイン(Return-Path)を設定していました。
しかし、この「@mail.nhk」は2025年10月1日時点ではDNS上に存在を確認できず、実体のない疑似ドメインと考えられました。
受信メールのログを確認したところすべて認証がPASSとなっていました。
spf=pass dkim=pass dmarc=pass (policy=reject)
表面的には問題がないように見えますが、GmailやMicrosoftなどの受信システムは、ドメイン評価をDNS上で追跡します。
DNSに存在しないドメインは、
- Google Postmaster Tools
- Microsoft SNDS
といった配信評価ツールにも登録できず、到達率をモニタリングする手段を失いました。 つまり、
「認証が通っているのに@mail.nhkのドメイン評価が管理・信頼されない」
状態に陥ったのです。
この結果、NHK ONEでは会員登録メールが届かず、ユーザーがアカウントを作成できないという障害が発生。NHKは2025年10月1日、公式サイトで「ドメイン設定の不備によるメール不達」を発表しました。
疑似ドメインのデメリット
疑似ドメインの「DNSに存在しない」という性質は、メールの信頼性構築において決定的な弱点となります。これがNHK ONEの事例で発生した障害の核心です。
| デメリット | 発生する問題 | 解説 |
|---|---|---|
|
ドメインの追跡・評価が不可 |
GoogleやMicrosoftなどの受信サーバーがドメインの過去の送信履歴や評判を追跡・評価できない。 | 誰にも正体がわからない送信者からのメールは、内容が正しくても「信用できない」と判断され、迷惑メールフォルダに直行しやすい。 |
|
モニタリングツールの使用不可 |
Postmaster Tools(Google)やSNDS(Microsoft)などの配信評価ツールにドメインを登録できず、到達率やクレーム率をチェックできない。 | メールが届いているか、迷惑メールに振り分けられていないか、配信の健全性を客観的にチェックする手段を失うため、問題が発生しても気付きにくい。 |
|
DMARCの検証困難 |
DNSにDMARCやSPFレコードが存在しないか、不完全になるため、第三者が送信元の正当性を確認できず、悪用のリスクを判断できない。 | なりすまし対策に必要な情報が公開されていないため、受信サーバーはドメインが本当に正規のものか厳格に判断せざるを得ず、ブロックリスクが高まる。 |
疑似ドメインを使うべきケースと避けるべきケース
疑似ドメインはすべて悪ではありません。適切な環境で使えば、セキュリティと運用の両立が可能です。ただし、その使用目的を明確にしなければ、NHK ONEのような障害を引き起こす可能性があります。
使用が適切なケース
- 社内テスト
- 限定的なトランザクションメール
- 内部通知など、受信者が限定される場合
避けるべきケース
- 会員登録
- パスワードリセット
- キャンペーン通知など、一般ユーザー向けの重要メール
どうしても疑似ドメインを使う場合の対策
- DNS上に最低限のゾーンを作成し、TXTレコードで所有権を証明する。
- SPFとDMARCレコードを追加して、第三者検証を通せるようにする。
- バウンスメール処理でエラーの連鎖が起きない設計を確認する。
- 事前にドメインウォームアップを実施し、メールが受信BOXで受信できることを事前に検証する。
ドメインウォームアップは、新しい送信ドメインや疑似ドメインで特に重要です。配信を開始する前に段階的に送信量を増やし、配信率やドメイン評価を確認することで、「メールが届かない」という事故を未然に防ぐことができます。
最後に
Amazon SESのカスタムMAIL FROMドメインは強力な機能ですが、DNS上に存在しない“疑似ドメイン”を使うことには明確なリスクがあります。
なりすまし対策であるSPF、DKIM、DMARCがPASSしても、ドメイン評価が蓄積されなければ、メールは届かないのです。
今回のNHK ONEの障害は、クラウドメールサービスがどれほど高機能でも、DNSレベルでの信頼構築を怠ると意味をなさないことを示しています。
認証は通っていても、評価がゼロのドメインはインターネットの中で“存在しない”のと同じです。
もしあなたがAmazon SESやSendGridを利用しているなら、今すぐMAIL FROMドメイン(Return-Path)を確認してみてください。そのドメイン、DNS上に本当に存在していますか?