「メールが届かない」事態を避けるための送信要件の確認と送信用インフラ選定の注意点：意外と知らないメールサーバ構築・運用の基本（3）

メールの仕組みや基礎を再確認しながら、確実にメールを届けるために必要な設定や運用のポイントを解説する連載。今回は、送信要件の確認ポイントや、送信用インフラ選定時の注意点などについて解説する。

[菱沼憲司，株式会社リンク]

　問い合わせに対する自動返信メール、会員登録時の通知メール、対象者への一斉配信メールなど、開発したシステムにメール送信機能を付けるケースは多々あると思います。その際、どの程度のメール送信数が見込まれるのか、事前に送信要件をしっかり確認しておかないと「メールが届かない」事態を引き起こしかねません。また、システムを稼働させるインフラの環境によっても、メール送信に対する制限や注意事項が異なってきます。

　メールの仕組みや基礎を再確認しながら、確実にメールを届けるために必要な設定や運用のポイントを解説する本連載「意外と知らないメールサーバ構築・運用の基本」。第2回の前回は、なぜドメイン名がメールの到達率に影響するのかについて、基本となるメール送信における2種類のFromドメインの説明から、ドメインレピュテーション、「Gmail」の送信者ガイドラインなどを中心に解説しました。

　今回は、送信要件の確認ポイントや、送信用インフラについて、種類ごとの注意点と選定時のポイントなどを詳しく解説します。

送信要件の確認ポイント

　メール送信機能を実装する前に、まずはメールの送信要件を確認します。確認のポイントは大きく分けて、（1）一斉配信の有無と、配信通数（2）メール配信の遅延が許されるかどうか、の2点です。

（1）一斉配信の有無と、配信通数

　メール送信において「一斉配信を行うかどうか」や配信する通数は重要なポイントです。大量に配信する場合、きちんと準備していなければ、「迷惑メールを配信するスパマー」と疑われやすくなり、配信の遅延や受信拒否のリスクが高まります。

　大量配信で注意すべき点は、以下の通りです。

・サーバ負荷による遅延

　大量のメールを一斉に送信する場合、メールを処理するSMTP（Simple Mail Transfer Protocol）サーバの負荷が増大し、結果としてメールの遅延やエラーが発生する可能性があります。そのため、必要に応じて複数のサーバとIPアドレスを用意し、負荷を分散する対策が求められます。

・IPレピュテーションが低い場合、受信拒否の可能性

　受信側のメールサービスプロバイダーは、メールを受信する際に、送信元IPアドレスの信頼性の指標であるレピュテーション（IPレピュテーション）をチェックしています。IPレピュテーションについて詳しくは次回で解説する予定ですが、今までメール送信に利用したことがないIPアドレスのレピュテーションは低いものと考えてください。IPレピュテーションが十分に高くない場合、数千通程度の一斉配信であっても迷惑メールとしてブロックされる可能性があります。

　大量メールの一斉配信がない場合でも、総配信数が多いケースでは同様に送信元IPアドレスのレピュテーションが重要になります。例えばECサイトやSaaSといった注文確認メールやログイン通知メールなどのトランザクションメールの送信量が膨大になる場合は、配信の遅延や受信拒否のリスクがあるので注意が必要です。

　配信先のドメインに偏りがあるかどうかによって異なりますが、目安として、時間当たりの配信数が1000通以上見込まれる場合は、送信元IPアドレスのウォームアップを実施し、事前にしっかりとレピュテーションを高めておく必要があります。

※IPレピュテーションの詳細およびウォームアップの方法については、次回で解説する予定です。

・Gmailの送信者ガイドラインへの準拠の必要性

　Gmail宛てに1日5000通以上のメールを送信すると、「一括送信者」として見なされ、一括送信者向けの要件を満たす必要が生じます。一度でも基準を満たした場合、一括送信者のステータスは永続するので、同じドメイン名を使用するメールに広く影響を与えます。

　一括送信者に該当する場合、SPF（Sender Policy Framework）とDKIM（Domain Keys Identified Mail）に加え、DMARC（Domain-based Message Authentication, Reporting and Conformance）認証に合格すること、マーケティングメールの場合はList-Unsubscribeヘッダを用いたワンクリック登録解除への対応など、通常の送信者要件よりもさらに厳しい要件が課せられます。

　前回でも解説しましたが、Gmailの送信者ガイドラインは「同じプライマリドメインをヘッダFromに設定したメール」全てをカウントするので、使用するドメイン名の状況によっては、当該の環境から送信する通数が少ない場合でも一括送信者の要件を満たす必要がある可能性があります。反対に、新たに追加する環境から大量に送信することで一括送信者の要件に該当してしまう場合、既存環境を含めた送信環境の整備が必要となるので注意が必要です。

　Gmailの送信者ガイドラインは、2025年2月現在、Google Workspaceアカウント宛てのメールには適用されていません。そのため、B2B（Business to Business）のサービスなど企業ドメイン宛の配信が主となる場合は問題ないかもしれませんが、B2C（Business to Consumer）のサービスなどGmailアカウントを使用するユーザー宛ての配信が多く見込まれる場合は、あらかじめ一括送信者の要件を満たしておくことをお勧めします。

（2）配信遅延の許容度

　メールの配信要件として「どの程度の時間内に届けばよいのか」を確認することも重要です。例えば、その日中ぐらいに届けば問題ないのか、それとも数秒〜数分以内に即時到達する必要があるのかどうかを明確にする必要があります。

　例えば、OTP（ワンタイムパスワード）や決済通知などの緊急性の高いメールでは、リアルタイムでの配信が求められます。遅延が発生すると、ユーザーの利便性やセキュリティに悪影響を及ぼします。

　大量のメールを送信する場合、SMTPサーバのキューがたまり、遅延や送信失敗が発生することがあります。これを防ぐためには、複数のメールサーバを立てた負荷分散が有効です。特に、大量配信の際は、適切なキュー管理と一定間隔のメール送信で負荷を軽減できます。

　即時配信が求められ、大量のメールを送る場合は、高速配信や大量配信に特化したメール送信サービスや、メールリレーサービスを利用することも有効です。

インフラ選定の注意点

　送信要件が確認できたら、次はメールサーバを構築するインフラを検討します。もちろん、送信機能を実装したいシステムを載せているインフラが第一選択肢となると思いますが、レンタルサーバやパブリッククラウド（IaaS）などは基本的にメール送信に制限が設けられています。

　本章では、代表的なインフラの種類と、それぞれのメリット／デメリットや注意点について解説します。

（1）オンプレミスの場合

　オンプレミス環境では、自社でサーバを構築、管理するので、メール送信に関する制限は基本的に自社のポリシーや環境に依存します。

　注意点は、クラウドと比べて柔軟なスケールが難しいので、事前にリソースを確保しておく必要があることです。例えば、グローバルIPアドレスの追加に時間がかかる場合、IPアドレスがブラックリストに登録されたなどの有事の際に、すぐに切り替えられないリスクがあります。また、サーバの増強もリードタイムが長くなりがちなので、余裕を持ったサイジングや負荷分散などを考慮しておく必要があります。

（2）レンタルサーバの場合

　レンタルサーバでは、サーバの負荷軽減やスパム対策のためにメール送信に関する制限を設けていることが一般的です。具体的には、メール送信数やメーリングリスト数、マルチドメイン数などです。メール送信数については、「1時間当たり○通まで」「1日当たり○通まで」といった制限があります。1日ごとに数百通程度の配信なら問題ないケースがほとんどですが、数千通以上の配信を見込む場合は、送信制限を受ける可能性があります。

　2025年2月現在、主要なレンタルサーバにおける送信制限は以下の通りです。

	レンタルサーバ	プラン	送信件数制限
	さくらのレンタルサーバ（さくらインターネット）※1	ライト／スタンダード／プレミアム	15分ごとに約100通（1時間ごとに400通、1日ごとに9600通換算、ただし15分に100通程度を超えない範囲）
		ビジネス／ビジネスプロ	15分ごとに約250通（1時間ごとに1000通、1日ごとに2万4000通換算、ただし15分に250通程度を超えない範囲）
	Xserverレンタルサーバー（エックスサーバー）※2	全プラン	1時間ごとに1500通、1日ごとに1万5000通
	ロリポップ！レンタルサーバー（GMOペパボ）※3	エコノミープラン	1時間ごとに100件、24時間ごとに1000件
		ライトプラン	1時間ごとに300件、24時間ごとに3000件
		スタンダード／ハイスピード／エンタープライズプラン	1時間ごとに1000件、24時間ごとに1万件
※1：あくまで目安なので、サーバの負荷状況によって前後する可能性がある（参考：さくらインターネット「基本仕様を知りたい（さくらのレンタルサーバ）」） ※2：迷惑メールなどの配信が行われた際は、上記範囲でも制限がある（参考：XServer「仕様一覧」） ※3：お試し期間中は、全プランともに24時間当たり50件まで（参考：ロリポップ！レンタルサーバー「禁止事項」）

　レンタルサーバは多数のユーザーで環境を共有するので、IPアドレスも共有することになります。自分がスパム行為をしていなくても、もし他のユーザーがスパム行為や疑われる行為をした場合、そのレンタルサーバのIPアドレスがブラックリストに登録されたり、レピュテーションが低下したりする恐れがあります。ブラックリストやIPレピュテーションは、個別のIPアドレスだけでなくその近隣のIPアドレス、つまり問題のあるIPアドレスを含むネットワーク全体を評価する傾向があります。結果的に、そのレンタルサーバを利用するユーザー全体がブロックされるケースもあるので、そのリスクは把握しておきましょう。

（3）IaaSの場合

　Amazon Web Services（AWS）やGoogle Cloud、Microsoft AzureなどのIaaS（Infrastructure as a Service）は、スパム対策としてポート25（SMTP）を使用した外部への送信を制限しています。メールを送信するには、制限の解除を申請するか、ポート587やポート465を使用する必要があります。

　IaaSにはレンタルサーバのような送信制限は設けられていませんが、IPアドレスのレピュテーションについては注意が必要です。AWSであれば「Amazon EC2」、Google Cloudの「Compute Engine」、Microsoft Azureの「Azure VM」など、仮想マシンにSMTPサーバを立てる場合、サービスがプールするグローバルIPアドレスからIPを取得することになります。しかし、悪意を持つユーザーが一時的にスパムメールを送信するために使用し、ブラックリストに登録されたIPアドレスが割り当てられてしまう可能性があります。そのため、Microsoft AzureではVM（仮想マシン）上から直接メールを送信することを推奨せず、サポートにも対応していないと公表しています（※参考）。IaaSのVM上にSMTPサーバを構築する際は、取得したIPアドレスのIPレピュテーションに問題がないかどうかを必ず確認するようにしましょう。

※参考：Microsoft「Azure VMからのメール送信に関するアナウンス（2017年11月）」

　AWSが提供するメール送信サービス「Amazon Simple Email Service」（SES）を利用する場合は、バウンスの管理が重要です。バウンスとはメール送信時のエラーのことで、何らかの原因によって配信できなかった場合に送られてくるエラーメールを「バウンスメール」といいます。SESではバウンス率が5％以上になると「レビュー対象」となり、10％以上になるとサービスの利用が停止させられてしまいます（※参考）。AWSに限らず、バウンスを放置していると「スパマー」と誤解され、ブラックリストに登録される要因にもなるので、バウンス率はできるだけ低く保つように心掛けましょう。

※参考：AWS「Amazon SES送信レビュープロセスに関するよくある質問」

（4）メール送信サービス／メールリレーサービスという選択肢

　大量メールの一斉送信を予定している場合には、独自のSMTPサーバを運用するのではなく、メール送信サービス／メールリレーサービスを活用することも検討すべきです。

　メール送信サービスはスケーラブルな送信基盤を備え、多数のIPアドレスから分散してメールを配信するので、大量のメールも遅延なく配信することが可能です。また、IPレピュテーション管理も事業者に任せることができるので、手間をかけずに安定してメールを配信できます。

　ただし、サービスによっては送信数や送信レートに制限がある場合や、特定の業種や内容のメール送信が禁止されていることがあります。利用前にサービスの提供条件や制限事項を確認し、自社のニーズに適合するかどうかを判断することが重要です。

まとめ

　メール送信機能を実装する際には、送信要件を明確にした上で、適切な環境を選択することが重要です。少量のトランザクションメールを送信する場合は、レンタルサーバなどでも問題ないかもしれませんが、大量のメールを送信する場合やリアルタイム性が求められる場合は、メール送信サービスを活用することでコストや手間を削減できます。

　次回は、IPアドレスに関する注意点と、IPレピュテーションの向上方法（IPウォームアップ）について詳しく解説します。

筆者紹介

菱沼憲司

株式会社リンク　クラウド・ホスティング事業部　サービス企画部　部長

2011年からインフラエンジニアとして活動。数万人が利用する大手グループ企業のメールシステム基盤など、複数システムの設計、構築、運用を支援。その後、複数クラウドサービスの企画から運営までを手掛け、2017年にメール到達率を支援するサービス「ベアメール」の提供を開始