メールの問い合わせで一番多いのが、これです。でも「届かない」の中身は、エラーメールが返ってきた、何も返ってこない、迷惑メールフォルダーに入っていた、遅れて届いた……とさまざまです。

第11回では、第1回から第10回までの知識を使って、「届かない」を切り分ける手順と、よくあるエラーの読み方をまとめます。送った側から順にたどり、止まった場所を突き止めましょう。

「届かない」の切り分け

• バウンスがあれば、応答コードと拡張ステータスコード（第2回）で、どの段階で止まったかの見当が付く
• バウンスが無いのに届かないときは、送信側のログで相手が250で受け付けたかを確かめる。受け付けていれば、そこから先は受信側の迷惑メールの判定や振り分けを疑う

ポイント
相手が250を返したかどうかで、調べる場所が送信側と受信側に分かれる。

エラーは「どの段階で返ったか」で読む

エラーの文言を1つずつ覚えるより、SMTPのどの段階で返ったかを見るほうが、原因の見当が早く付きます（SMTPの流れは第2回）。

Postfixのログなら、(in reply to RCPT TO command)や(in reply to end of DATA command)が段階を教えてくれます（第8回）。1桁目が4なら送信側が再送し、5なら直すまで届きません。

よくあるエラー① 接続・認証・リレー

拡張ステータスコード（RFC 3463、登録簿はRFC 5248）は、事業者が独自の番号を追加しているため、文言と各社の説明で確かめます。

よくあるエラー② 送信ドメイン認証・送信者ガイドライン

Gmailは2025年11月から、ガイドラインを満たさない大量送信（1日5,000通以上）への一時的・恒久的な拒否を強めています。Microsoft（Outlook.com）は2025年5月から、要件を満たさない大量送信を550 5.7.515で拒否しています。要件は第5回・第6回と、連載「DNS入門」第6回を参照してください。

4xxの一時的な制限を放置すると、5xxの拒否に変わることがあります。一時エラーのうちに直しましょう。

vCenterの通知メールのエラー

第10回で扱ったvCenterの通知メールは、届かないときの調べ方にも癖があります。

• 送信の流れは、vpxd（アラームのアクション）→ 内部のSendmail（127.0.0.1）→ 社内リレーまたはメールサーバー。アクションが動いたかは/var/log/vmware/vpxd/vpxd.log、Sendmailが送れたかは/var/log/vmware/messagesで見る
• Sendmailは1通につきfrom=・STARTTLS=・to=の行を出す。relay=が外部のサーバーになっているto=の行のdsn=とstat=が本当の結果

（正常）  to=<ops@corp.example.jp>, … relay=mail.corp.example.jp. [192.0.2.25], dsn=2.0.0, stat=Sent (Ok: queued as 4cXyZ1abcd)
（一時）  to=<ops@corp.example.jp>, … dsn=4.0.0, stat=Deferred: Connection refused by [127.0.0.1]
（拒否）  to=<ops@example.com>, … relay=mail.corp.example.jp. [192.0.2.25], dsn=5.7.1, stat=Service unavailable
（相手のPostfix）NOQUEUE: reject: RCPT from unknown[192.0.2.20]: 554 5.7.1 <ops@example.com>: Relay access denied; from=<vcsa-alert@corp.example.jp> to=<ops@example.com> proto=ESMTP helo=<vcsa01.corp.example.jp>
（OAuth が必要な相手）AUTH=client, available mechanisms=LOGIN do not fulfill requirements
（抜粋）

• Deferredは再送されるが、5.x.xは再送されない
• 127.0.0.1へのConnection refusedは内部のSendmailの停止、リレー拒否はリレー側の許可の不足、最後の行は相手がBasic認証を受け付けない場合（Broadcom KB 428447）
• vCenter自身から、ncかcurl -v telnet://宛先:25で試す（第9回）

時刻とキューIDで、vCenterとリレーの両側のログを突き合わせます。

迷惑メールフォルダーに入る原因

エラーは返らないのに「届いていない」と言われたら、迷惑メールフォルダーを疑います。

迷惑メールフォルダーへの振り分けは、相手が250で受け付けた後の判定です。送信側のログは正常に見えるので、受信者から届いたメールのヘッダーを送ってもらって読むのが近道です（ヘッダーの見方は第3回、Authentication-Resultsの読み方は第6回）。

原因と確認コマンドの対応表

連載の早見表

困ったときに戻る場所を、連載全体でまとめておきます。

どの回も、「いま見ているのはエンベロープかヘッダーか」「誰が誰に、どの経路で渡しているか」を意識すると理解しやすくなります。

参考資料

• RFC：5321（SMTP）、5322（メッセージ形式）、5598（アーキテクチャ）、6409（サブミッション）、8314（465）、3207（STARTTLS）、4954（AUTH）、3463・5248・7372（拡張ステータスコード）、7208（SPF）、6376（DKIM）、9989・9990・9991（DMARC）、8617（ARC）、8461・8460（MTA-STS・TLS-RPT）、7672（DANE）、8058（ワンクリック登録解除）、6531（SMTPUTF8）
• 送信者ガイドライン：Gmailのメール送信者のガイドラインとFAQ、Yahoo Sender Hubのベストプラクティス、MicrosoftのOutlook.com大量送信者の要件（2025年）、M3AAWGのベストプラクティス、JPAAWGの資料
• 公式ドキュメント：Postfixのドキュメント（postfix.org）、Microsoft Learn（多機能デバイスやアプリからの送信、SMTP AUTH、High Volume Email、Exchange Onlineの制限、NDRの一覧）、Google Workspace管理者ヘルプ（SMTPリレー）、Amazon SES開発者ガイド、Broadcom TechDocs（vCenterのメール送信者の設定）とKB 428447

考えてみよう

1. 「メールが届かない」という問い合わせを受けたら、最初に利用者から何を聞き取りますか。この記事の「0 症状を固める」を、自分の言葉で質問のリストにしてみましょう。
2. 送信側のログはstatus=sentなのに、相手は「届いていない」と言います。次に何を確かめ、相手に何を頼みますか。
3. 自社の送信サーバーのログに421 4.7.27が出始めました。放置するとどうなりますか。何から直しますか。

ヒント：この記事の切り分けの図、エラーの段階の図、迷惑メールフォルダーのヘッダーの図、「よくあるエラー②」の表が手がかりです。まずはdig TXT _dmarc.自社のドメイン（WindowsはResolve-DnsName _dmarc.自社のドメイン -Type TXT）を実行してみてください。

まとめ

• 「届かない」は、まず症状を固める。誰から誰へ、いつから、バウンスの文言
• 送信側のキュー・ログ → DNS → 経路 → 受信側の順にたどる。相手が250を返したかで分かれる
• エラーはSMTPのどの段階で返ったかで読む。1桁目が4なら再送、5なら直すまで届かない
• 認証のエラー（5.7.26・5.7.509・5.7.515）はFromとそろえる。4xxの制限を放置しない
• vCenterはrelay=の行のdsn=とstat=が本当の結果
• 迷惑メールフォルダーは250の後の判定。受信者からヘッダーを送ってもらう

次回はいよいよ最終回。これまでの知識を使って、メールの経路・認証・移行を要件から決める設計演習に取り組みます。

連載「メール入門」全12回

1. メールが届くまで
2. SMTPのやり取り
3. メッセージの構造
4. ポートと暗号化・認証
5. 送信ドメイン認証 前編
6. 送信ドメイン認証 後編
7. 迷惑メール対策と配信
8. MTAの運用
9. コマンドで調べる
10. クラウドと現代のメール
11. メールのトラブルシュート（この記事）
12. メールの設計演習

メールボックスがクラウドに移った今、社内に残る悩みは、機器やアプリからの通知メールをどう届けるかです。複合機、vCenter、監視ツール、業務アプリ……それぞれに制約があり、正解は1つではありません。

第10回では、Microsoft 365・Google Workspace・Amazon SESの送り方を整理し、機器ごとに向く経路を考えます。

Microsoft 365へ機器・アプリから送る4つの方法

入口は3つ、方式は4つです。同じMXでも、コネクターで認証されるかどうかで送れる相手が変わります。

Microsoftは、社内宛てだけならHVE、社外にも大量に送るならAzure Communication Services Emailを勧めています。どの方式でも、送信元のアドレスはテナントの承認済みドメインにし、SPF・DKIM・DMARCをそろえます（第5回・第6回）。

SMTP AUTHとBasic認証の廃止

SMTP AUTHクライアント送信は、機器やアプリがMicrosoft 365のメールボックスにサインインして送る方式です。問題は、ユーザー名とパスワードをそのまま送るBasic認証です。

• Exchange OnlineはPOP・IMAPなどのBasic認証を2022年に止めたが、SMTP AUTHは例外として残してきた
• 2026年1月に更新された日程では、2026年12月末に既存のテナントでも既定で無効になり（管理者は再び有効にできる）、以降に作るテナントでは既定で使えない。最終の廃止日は2027年後半に発表される予定
• 移行先はOAuth 2.0（第4回）。ただし、機器がトークンの取得と更新に対応している必要があり、古い複合機やvCenterのように対応しない製品も残る

まず、Basic認証で送っている機器・アプリを洗い出します。OAuthに対応しない機器は、この後のコネクターか社内リレーへ移します。

ダイレクト送信の現状と無効化

ダイレクト送信は、機器が自社のMX（…mail.protection.outlook.com）に25番で直接つなぎ、認証なしで送る方式です。外部のメールサーバーから届くメールと同じ扱いで、送れるのは自テナントのメールボックス宛てだけです。

• 認証がないため、第三者も同じMXに自社のドメインを名乗って送れる。2025年には、この経路を使うなりすましのフィッシングが報告された
• 対策として、受信コネクターで認証されない、自社ドメインを名乗る匿名メールを拒否する設定（RejectDirectSend）が追加された

PS> Connect-ExchangeOnline
PS> Get-OrganizationConfig | Format-List RejectDirectSend
PS> Set-OrganizationConfig -RejectDirectSend $true

（拒否された送信側に返る応答の例）
550 5.7.68 TenantInboundAttribution; Direct Send not allowed for this organization from unauthorized sources

有効にする前に、ダイレクト送信を使っている複合機や外部サービスを洗い出し、受信コネクター（証明書またはIP）で認証させるか、別の方式へ移します。Microsoftの手順書は「多くの顧客にダイレクト送信は不要」とし、既定で無効にする選択肢を準備中としています。

コネクターを使うSMTPリレー

SMTPリレーは、機器やオンプレのメールサーバーが「組織のメールサーバー」としてMicrosoft 365に送り、Microsoft 365が社内外へ配送する方式です。

• Exchange管理センターで、接続元を「組織のメールサーバー」とする受信コネクターを作り、送信元の確かめ方を選ぶ
• 推奨は、TLSの証明書のSubjectかSANに承認済みドメインが入っていることで確かめる方法。できなければ、他の組織と共有しない固定のグローバルIPを使う（動的IPは不可）
• 機器の送信先は自社のMXの25番で、TLS 1.2以上を使う。メールボックスは不要で、承認済みドメインの任意のアドレスから送れる。ただし、Azureなど他社のクラウドからは使えない
• IPや証明書が変わると550 5.7.64 TenantAttributionで止まる。証明書の更新手順にコネクターの確認を入れておく

Exchange Onlineの送信の上限とHigh Volume Email

通知メールは1日の量が少なくても、障害のときに一斉に出ると毎分30通に当たります。監視の通知を1つのメールボックスに集めている場合は注意が必要です。社内への大量配信はHVE、社外への大量配信はAzure Communication Services EmailやAmazon SESに分けます。

Google Workspaceから送る

• SMTPリレーサービス：管理コンソールのGmail ＞ ルーティングで設定し、機器はsmtp-relay.gmail.comへ送る。ポートは25・465・587
• 送信元の確かめ方は、許可するIPアドレスかSMTP認証（TLSが必須）から選ぶ。「TLS暗号化を必須にする」も選べる
• 送信者は「ドメインの登録済みユーザーのみ」「ドメイン内のアドレス」「すべてのアドレス（非推奨）」から選ぶ。機器の送信元が自社ドメインでないと拒否される
• 上限は1ユーザーあたり1日10,000宛先、1回のトランザクションで100宛先。Gmailの通常の送信上限とは別に数える
• EHLOにはlocalhostではなく、機器ごとに一意な名前を名乗らせる
• 安全性の低いアプリ（パスワードだけのアクセス）は、2025年3月14日から段階的に止まり、5月1日で対応を終えた（Google の告知）。smtp.gmail.comへSMTP AUTHで送るには、OAuth 2.0か、2段階認証プロセスを有効にしたアカウントのアプリ パスワードが必要

Googleは、機器を買い替えるときはOAuthで送れる機種を選ぶよう勧めています。アプリ パスワードは、Basic認証と同じく機器に保存される長期の秘密なので、使う場合は専用のアカウントに限り、SMTPリレーサービス（IPで許可）を優先します。

Amazon SESの基本

Amazon SESは、AWSのメール送信サービスです。利用者のメールボックスは持たない、送るだけの部品です。

APIでもSMTPでも送れるので、アプリはAPI、既存の機器やPostfixはSMTP、と使い分けます（Postfixの設定例は第8回）。AWS全体での位置づけは、連載「クラウド入門」第14回を参照してください。

バウンス・苦情の処理とVirtual Deliverability Manager

• SESはアカウントごとに、バウンス率（ハードバウンスの割合）と苦情率（受信者が迷惑メールと報告した割合）を見ている
• バウンス率5%以上か苦情率0.1%以上で審査中になり、10%以上か0.5%以上で送信が一時停止されることがある。共有のIPの評判を守るための措置
• 設定セット（configuration set）のイベントの送信先（SNS、EventBridge、CloudWatch、Data Firehose）で、バウンス・苦情・配信を受け取り、アプリの宛先リストから外す
• アカウントレベルの抑制リストを有効にすると、ハードバウンスや苦情のあったアドレスが登録され、以後は送られない
• Virtual Deliverability Manager（VDM）は、ISPごとの到達率や開封率のダッシュボードと、DKIM・DMARCなどの設定の改善を勧める「アドバイザー」を提供する（月額の有料の機能）
• 大量に送る場合は、専用IP（マネージド型を含む）と、送信量を少しずつ増やすウォームアップも検討する（第7回）

Gmail・Yahooの送信者ガイドラインは迷惑メール率0.3%未満を求めていますが（第6回）、SESの基準はそれより厳しいため、バウンスと苦情を自動で処理する仕組みは、送り始める前に作っておきます。

EC2の25番の制限と解除申請

• EC2インスタンスと、VPCに接続したLambdaからの外向きの25番は、既定で制限されている（2020年1月から）
• 解除は「Request to remove email sending limitations」のフォームで、リージョンごとに申請する。用途と、迷惑メールを出さないための対策を書く。処理には最大48時間ほどかかる
• 同じフォームでEIPの逆引き（PTR）も依頼できる。先に正引きのAレコード（例：mail.example.jp → そのEIP）を登録しておく
• SESのSMTPへは、587・465・2587・2465を使えば申請なしで送れる。VPCエンドポイントでもSESのSMTPに接続できる
• Azureも、Enterprise Agreement（MCA-Eを含む）以外の多くのサブスクリプションで、仮想マシンから外向きの25番を遮断している

$ nc -vz -w 5 mx.example.com 25                          # 制限中はタイムアウトする
$ nc -vz -w 5 email-smtp.ap-northeast-1.amazonaws.com 587
PS> Test-NetConnection email-smtp.ap-northeast-1.amazonaws.com -Port 587
（TcpTestSucceeded : True なら TCP の接続まではできている）

アプリ・機器からの通知メールの送り方

ここまでを踏まえて、送り手ごとに向く経路を整理します。

機器は「メールを作る」ことはできても、配送のやり直しやキューの管理は苦手です。社内リレーに集めると、機器の設定は宛先を変えるだけで済み、ログも1か所で追えます。Microsoftも、オンプレにメールサーバーがあればリレーに使うよう勧めています。ただし、Windows ServerのIISのSMTPサービスは、Microsoft 365へのリレーには使えません（第8回）。

vCenterのメール通知の設定

冒頭の「vCenterのアラームメール」の答えです。

• 設定の場所は、vSphere ClientのvCenter ＞ 構成 ＞ 設定 ＞ 全般 ＞ 編集の「メール」。メールサーバー（名前またはIP）と、メール送信者（ドメインを含む完全なアドレス）を入れる
• SMTP認証はvSphere 7.0 Update 1以降で、詳細設定のmail.smtp.username・mail.smtp.password・mail.smtp.port（587）に入れる。対象はMicrosoft 365（旧Office 365）のメールボックスで、サーバーはIPではなくsmtp.office365.comと名前で指定する。パスワードは詳細設定の画面に見えるため、専用のアカウントを使う
• OAuth 2.0には非対応（vCenter 8.x・9.x、Broadcom KB 428447）。Microsoft 365のBasic認証が無効になると送れなくなる
• 送信は内部のSendmailが担う。相手がSTARTTLSを示せば暗号化し、証明書の検証に失敗しても送信は続ける（ログは第11回）

（詳細設定の例：Microsoft 365 へ SMTP 認証で送る場合）
mail.smtp.server   = smtp.office365.com
mail.smtp.port     = 587
mail.smtp.username = vcsa-alert@example.jp
mail.smtp.password = ********
mail.sender        = vcsa-alert@example.jp

推奨は、社内リレーへ認証なしで送り、リレー側でvCenterのIPだけを許可する構成です。vCenterは宛先を変えるだけで、認証の問題はリレー側で引き受けます。

メール基盤の冗長（要点）

• 受信（25番）は、MXに複数のサーバーを登録すれば、送信側が順に試し、つながらなければキューに残して再送するため、MXだけでも冗長にできる
• 利用者のメールソフトや機器は、設定した1つのサーバー名にしか接続せず、失敗しても別のサーバーを試さない。そのため、投稿（587番）や社内リレーには、ロードバランサー（TCPのまま転送）や仮想IPで、1つの名前の後ろに複数台を置く仕組みが要る
• SPFとPTRに登録するのは、実際に外へ送るIP（NATの出口など）
• 自前で持つ範囲が広すぎるなら、送信はSES、メールボックスはSaaSに任せる

考えてみよう

1. 職場で通知メールを送っている機器やアプリを挙げてください。それぞれ、どの方式（SMTP AUTH、コネクター、ダイレクト送信、社内リレー）で送っていて、Basic認証を使っていませんか。
2. Microsoft 365でダイレクト送信を拒否する設定を有効にすると、何が止まる可能性がありますか。有効にする前に何を確かめますか。
3. EC2上のアプリから会員へメールを送ることになりました。EC2から直接送る場合とSESを使う場合で、事前に必要な申請とDNSの設定を比べてください。

ヒント：問1は4つの方法の表と送り手ごとの表、問2は「MXに認証なしで送っているもの」をダイレクト送信の図の考え方で探す、問3はSESの基本とEC2の25番の制限（サンドボックス、25番、PTR、DKIM、MAIL FROM）から考えてみてください。

まとめ

• Microsoft 365への送り方はSMTP AUTH・コネクター・ダイレクト送信・HVEの4つ。送れる相手が違う
• SMTP AUTHのBasic認証は2026年12月末に既定で無効。まず使っている機器を棚卸しする
• ダイレクト送信はなりすましの経路にもなる。RejectDirectSendの前に利用者を洗い出す
• コネクターは証明書（推奨）か固定IPで認証。変わると550 5.7.64で止まる
• GoogleもパスワードだけのSMTPは終了。SMTPリレーサービスかOAuth
• SESはサンドボックスの解除・DKIM・MAIL FROMをそろえ、バウンスと苦情を自動で処理する
• OAuthに対応しない機器は社内リレーに集める。vCenterもリレーへ匿名で

次回は、「メールが届かない」ときの切り分けの手順と、よくあるエラーをまとめます。

連載「メール入門」全12回

1. メールが届くまで
2. SMTPのやり取り
3. メッセージの構造
4. ポートと暗号化・認証
5. 送信ドメイン認証 前編
6. 送信ドメイン認証 後編
7. 迷惑メール対策と配信
8. MTAの運用
9. コマンドで調べる
10. クラウドと現代のメール（この記事）
11. メールのトラブルシュート
12. メールの設計演習