レンタルサーバーのメール送信制限一覧と上限と超えたときの対処法｜主要6サービス

「昨日まで普通に送れていたのに、今日になって急にメールが送信できなくなった」
「メルマガを配信したはずなのに、一部の宛先にだけ届いていない」

レンタルサーバーのメール機能で一斉送信を行っている企業から、こうした相談が増加しています。その原因の多くは、サーバー側にあらかじめ設定されているメール送信制限です。

レンタルサーバーには、1時間あたり・1日あたりに送信できる通数の上限が設けられています。上限値は各社でまったく異なり、少ないサービスでは1日100通、多いサービスでも1日15,000通程度。しかも制限は通数だけではありません。契約直後やお試し期間中は、通常よりもさらに厳しい値が適用されるケースもあります。

本記事では、主要6サービスの送信制限を公式情報ベースで一覧にまとめ、制限に達したときに何が起こるのか、自分が制限に引っかかっているかをどう確認するのか、そして根本的な対処法までを解説します。自社の配信規模で「何時間かかるのか」を試算できるシミュレーション表も用意しました。送信制限に振り回されない配信環境を整えるための判断材料として活用してください。

この記事の結論

主要レンタルサーバーのメール送信上限は、1時間あたり50〜1,500通、1日あたり100〜15,000通の範囲に収まります。数百通を超える一斉配信を定期的に行うのであれば、レンタルサーバーのメール機能では運用が立ち行かなくなります。プラン変更や分割送信は応急処置にすぎず、根本的な解決策はメール配信システムへの切り替えです。

※本記事の送信制限に関する数値は、2026年9月10日時点で各社公式情報を確認したものです。仕様は予告なく変更される場合があるため、運用前には必ず契約中のサービスの公式ページで最新情報をご確認ください。

レンタルサーバーのメール送信制限とは

レンタルサーバーのメール送信制限とは、1つの契約アカウントから一定時間内に送信できるメールの通数に設けられた上限のことです。上限を超えると、それ以降のメールは送信できなくなるか、配信キューに滞留して大幅に遅延します。

重要なのは、この制限が「メールアドレス単位」ではなく「契約アカウント単位」で設定されている点です。メールアドレスを10個作っても、送信できる総量は変わりません。複数の担当者が同じサーバーからメールを送っている場合、その合計値がカウントされます。

送信制限は通数だけではない

送信制限というと通数の上限だけをイメージしがちですが、実際には複数の制限が同時に働いています。実務で問題になるのは、次の4種類です。

このうち見落とされやすいのが、宛先数の上限です。BCCで500人に一斉送信した場合、送信操作は1回でも、サーバーは500通としてカウントします。「1通しか送っていないのにエラーになる」という相談の大半は、この数え方の誤解が原因です。

なぜレンタルサーバーには送信制限があるのか

理由は大きく3つあります。

1つ目はスパム対策です。レンタルサーバーは低コストで契約でき、独自ドメインからメールを送れるため、スパム業者にとっても都合のよい環境です。無制限に送信できる状態を放置すれば、悪用は避けられません。

2つ目は共用サーバーの負荷分散です。レンタルサーバーは1台の物理サーバーを複数の契約者で共有しています。特定のユーザーが大量送信を行えば、同じサーバーを使う他のユーザーのメール送受信やWebサイトの表示にまで影響が及びます。

3つ目は、事業者にとってもっとも切実な理由であるIPアドレスのレピュテーション（送信者評価）の保護です。共用サーバーでは送信元IPアドレスも共有されているため、一人が質の低い配信を行っただけで、そのIPから送られるすべてのメールが迷惑メール判定を受けかねません。送信制限は、事業者が自社のIPを守るための防衛線でもあるのです。

【2026年版】主要レンタルサーバーのメール送信制限一覧

主要6サービスの送信制限を、各社の公式マニュアル・利用規約・サポートページをもとに整理しました。

※2026年9月時点で各社公式情報を確認した内容です。さくらのレンタルサーバ各プランの送信上限は、契約中のプランのサポートページでご確認ください。仕様は変更される可能性があるため、実際の運用前には必ず契約中のプランの公式ページをご確認ください。

エックスサーバー

全プラン共通で1,500通/時間、15,000通/日が目安として設定されています。主要サービスのなかではもっとも上限が緩く、数千通規模の配信を扱うなら現実的な選択肢になります。

ただし公式マニュアルには、迷惑メールと判断される配信が行われた場合は、この範囲内であっても制限をかける旨が明記されています。数値はあくまで目安であり、「1,499通なら必ず送れる」という保証ではない点は理解しておく必要があります。

公式サイト：https://www.xserver.ne.jp/manual/man_mail_spec.php

さくらのレンタルサーバ

さくらインターネットの制限は、「15分あたり」という短い単位で設定されているのが特徴です。さくらのメールボックスは15分毎に100通程度、さくらのビジネスメールは15分毎に250通程度が上限とされています。

1日換算では9,600通・24,000通となりますが、注意すべきは「15分あたりの上限を超えない範囲」という条件が付いている点です。1日の総量に余裕があっても、短時間に集中して送れば制限に抵触します。深夜にまとめて配信するといった運用は成立しません。

なお、さくらのレンタルサーバの各プランについても同様に15分単位での制限が案内されています。契約中のプランの正確な値は、さくらのサポートサイトで確認してください。

公式サイト：https://help.sakura.ad.jp/rs/2250/

ロリポップ！

プランごとに上限が明確に分かれており、エコノミーで100件/時間、ライトで300件/時間、スタンダード以上で1,000件/時間となっています。公式サイトでは利用規約の「禁止事項」ページに記載されており、上限超過は規約違反として扱われる位置づけです。

また、複数のメールアドレスがある場合は全アドレスの送信件数の合計が対象になると明記されています。部署ごとにアドレスを分けても、上限が増えるわけではありません。

公式サイト：https://lolipop.jp/terms/prohibition/

ヘテムル

全プラン共通で1,000件/時間、10,000件/日です。ヘテムルも利用規約の禁止事項として明記しており、CGI・PHPなどのスクリプトからのメール大量送信そのものを禁止しています（同社提供のメーリングリスト機能・メールマガジン機能は除く）。

問い合わせフォームの自動返信が悪用されて上限に達し、正常なメールまで送れなくなるケースについても、公式に注意喚起が出されています。

公式サイト：https://heteml.jp/ordermenu/prohibition/

mixhost

1日あたりの上限は主要サービスのなかで低く設定されており、ライト以外のプランで1日1,000通、ライトプランは1日100通です。公正使用ポリシーには、制限値以下であってもスパム防止のために送信制限を実施する場合があること、別途MailChannelsによる送信制限が発生する場合があることも記載されています。

メール送信制限は仕様変更が入りやすい領域です。運用開始前には、必ず契約中のプランの公式情報で最新値をご確認ください。

公式サイト：https://mixhost.jp/fair-use-policy/

ConoHa WING

ConoHa WINGは、具体的な送信通数の上限を公開していません。サポートページでは、同一IPから大量送信を行った際に「too many recipients」というエラーが返ることと、共用サーバーの仕様上、大量送信を行う運用は控えてほしい旨が案内されています。

数値が公開されていない＝制限が緩い、ではありません。むしろ運用状況に応じて判断される分、予測が立てにくいと考えるべきです。一斉配信を前提とする場合は、上限が明示されているサービスを選ぶほうが運用計画を立てやすくなります。

公式サイト：https://support.conoha.jp/w/mailerror/

契約直後・お試し期間中はさらに厳しい制限がかかる

見落とされがちですが、通常の上限とは別に、契約初期だけに適用される制限があります。

さくらインターネットでは、不正利用防止のため、申し込みから15日間が経過していない、または会員IDの電話番号認証が完了していないアカウントに対して、1日のメール送信数を制限しています。この制限は料金を支払った後でも適用され、電話番号認証を行うか、契約から15日経過することで解除されます。

ロリポップ！ではお試し期間中、全プラン共通で24時間あたり50件まで。ヘテムルもお試し期間中は1日100件で配信制限がかかります。

「導入テストで少量を送ってみたら問題なかったので本番配信したら止まった」という失敗は、この初期制限を知らずに検証したことが原因であるケースが少なくありません。テスト送信は必ず、初期制限が解除された状態で行ってください。

自社の配信規模だと何時間かかる？送信所要時間シミュレーション

送信制限の数値だけを見ても、実務上のインパクトはつかみにくいものです。そこで、10,000通のメールを送りきるのに何時間かかるかを、各サービスの上限値から試算しました。

※各社公表の上限値から単純計算した理論値です。実際にはサーバー負荷や受信側の受け取り速度により、さらに時間がかかります。

配信完了まで半日かかることのビジネス上の損失

この試算で本当に問題なのは、時間の長さそのものではありません。読者に届く時刻がバラバラになることです。

朝9時に配信を開始したとして、最後の1通が届くのは同日の夕方や翌日。セール告知やイベント案内であれば、リストの後半に登録されている顧客は、告知を読んだ時点ですでに機会を逃しているかもしれません。開封率が高くなる時間帯を狙って配信設計をしても、その狙いは成立しなくなります。

さらに、日次上限ちょうどで送りきる運用は、トラブル発生時のリカバリー余地がゼロという意味でもあります。配信ミスに気づいて再送しようにも、その日はもう1通も送れません。

「分割して送れば大丈夫」が危険な理由

「上限に当たらないよう、スクリプトで間隔を空けて送ればいい」と考える担当者は少なくありません。しかし、この運用には3つの問題があります。

第一に、時間あたりの制限を回避できても、日次の制限は回避できません。間隔を空けて24時間送り続けても、1日の上限には必ず到達します。

第二に、スクリプトからの大量送信そのものを禁止しているサーバーがあります。ヘテムルのように、CGI・PHPからのメール大量送信を利用規約で明確に禁止している事業者では、上限内に収まっていても規約違反です。

第三に、送信パターンが受信側から不自然に見えます。長時間にわたって同一IPから同一ドメインへ機械的な間隔で送り続ける挙動は、受信側のフィルタにとってスパム送信の典型的なパターンです。制限を回避しようとした結果、迷惑メール判定を招くという本末転倒が起こります。

送信制限に引っかかるとどうなるのか

制限を超えたときにサーバーが取る挙動は、大きく3段階に分かれます。

メールが送信できずエラーが返る

もっとも分かりやすい症状です。メールソフトやWebメールから送信した瞬間、あるいは数分後に、送信エラーの通知が返ってきます。

エラーメッセージの文言はサーバーによって異なりますが、代表的なものは次のとおりです。

エラーメールが返ってきたら、まず応答コードの先頭の数字を確認してください。4で始まるなら待てば解消する可能性がありますが、5で始まる場合は運用そのものを変える必要があります。

配信が遅延し、届く時刻がバラバラになる

エラーが返らないケースのほうが、実は厄介です。上限を超えたメールがサーバーの配信キューに溜まり、少しずつ処理される状態になります。

送信者側の画面では「送信済み」と表示されるため、問題が起きていることに気づけません。数時間後に「メールが届いていない」と顧客から連絡を受けて、はじめて発覚します。遅延は失敗として記録されないため、発見が遅れるのです。

アカウント停止・利用制限に発展する

もっとも深刻なケースです。上限の超過が常態化したり、迷惑メールと判断される配信が続いたりすると、事業者側の判断でメール機能が停止されます。ロリポップ！やヘテムルは、上限超過を利用規約の禁止事項として明記しています。ヘテムルではさらに、大量配信の違反時に損害賠償請求を行う場合があると記載されています。

さらに深刻なのは、メール機能の停止がWebサイトの停止に連鎖するケースです。同じ契約でWebサイトも運用していれば、アカウント単位の措置によってサイトまで閲覧できなくなります。メール配信のトラブルが、企業の顔であるWebサイトの停止を引き起こすのです。

自分が制限に引っかかっているかを確認する方法

「メールが届かない」と一口に言っても、原因は送信制限とは限りません。切り分けの手順を押さえておきましょう。

送信通数の数え方を正しく理解する

まず、自社が実際に何通送っているのかを正確に把握します。カウントの考え方は次のとおりです。

見落とされやすいのが、メルマガ以外の自動送信メールです。メルマガを3,000通送った日に、たまたま問い合わせやEC注文が集中していれば、合計値は簡単に上限を超えます。「メルマガの通数だけ」で見積もると、実態と乖離しやすくなります。

エラーメールの本文を最後まで読む

エラーメールは件名だけを見て捨ててしまいがちですが、本文には原因を特定するための情報が含まれています。確認すべきポイントは3つです。

どのサーバーが返したエラーか。自社が契約しているレンタルサーバーが返したものなら送信制限の可能性が高く、受信側（Gmailやキャリア）が返したものなら到達性の問題です。

応答コード。前述のとおり、4xx系か5xx系かで対応が変わります。

エラーが発生した時刻の分布。特定の時間帯に集中していれば時間あたりの制限、一日の後半に集中していれば日次の制限が疑われます。

制限以外の原因と切り分ける

送信制限が原因ではないケースも珍しくありません。次のような場合は、別の原因を疑ってください。

送信制限とこれらの問題は同時に起きていることも多いため、片方だけを解消しても症状が改善しないことがあります。

送信制限を超えてしまうときの対処法

原因が送信制限だと確認できたら、次の順で対処を検討します。

上位プランへ変更する

もっとも手軽な方法ですが、効果は限定的です。ロリポップ！であればライト（300件/時間）からスタンダード（1,000件/時間）へ上げることで3倍以上になりますが、それでも1日10,000件が天井です。エックスサーバーに至っては全プラン共通の数値なので、プランを上げても上限は1通も増えません。

配信規模が今後も増えていく想定なら、プラン変更は時間稼ぎにしかならないと考えたほうが現実的です。

配信を分割する

数千通規模で、かつ配信頻度が月1回程度であれば、複数日に分けて送るという選択肢はあります。ただし前述のとおり、リストの後半に登録されている読者ほど情報が古くなるという問題は解消できません。

また、分割送信は運用の属人化を招きます。「今日は3,000通まで」「明日は残りを送る」という手作業の管理は、担当者の交代時に引き継ぎ漏れが起きやすくなります。応急処置と割り切るべきです。

メール配信システム・メールリレーサービスに切り替える

根本的な解決策はこれです。メール配信の部分だけを専用のサービスに切り出すことで、レンタルサーバーの送信制限から完全に解放されます。

重要なのは、レンタルサーバーを解約する必要はないという点です。Webサイトの運用と日常の業務メールはこれまでどおりレンタルサーバーを使い、一斉配信だけを専用サービスに任せる。この役割分担が、コストと安全性のバランスがもっともよい構成です。

独自ドメインはメール配信システム側でもそのまま使えるため、送信元アドレスを変える必要もありません。

やってはいけないNG対処

制限を回避しようとして、かえって状況を悪化させる対処があります。以下は避けてください。

いずれも「上限に当たらないようにする」ことだけを目的にした対処であり、到達率という本来の目的を犠牲にしています。

送信制限をクリアしても「届く」とは限らない

ここまで送信制限を中心に解説してきましたが、押さえておくべき重要な前提があります。送信制限をクリアすることと、メールが受信ボックスに届くことは別問題です。

Gmail・Yahoo!メールの送信者ガイドライン

Googleは2023年10月に「メール送信者のガイドライン」の改定を発表し、2024年2月から適用を開始しました。同一ドメインから1日5,000通以上をGmail宛に送信する送信者に対して、SPF・DKIM・DMARCによる送信ドメイン認証、ワンクリックでの配信登録解除（List-Unsubscribe）、迷惑メール率を0.10%未満に維持し0.30%に到達させないことなどが求められています。米国Yahoo!も同時期に同等の要件を導入しており、国内の主要プロバイダも順次対応を進めています。

Outlookも2025年5月から要件を厳格化

さらにMicrosoftは、2025年5月5日から、outlook.com・hotmail.com・live.com宛に1日5,000通以上を送信するドメインに対して、SPF・DKIM・DMARCの設定を必須としました。要件を満たさないメールは迷惑メールフォルダに振り分けられ、将来的には受信拒否の可能性もあるとされています。

主要な受信側事業者が足並みを揃えて認証を必須化したというのが、現在の状況です。

レンタルサーバーではガイドライン対応が難しい

問題は、レンタルサーバーのメール機能がこれらの要件に対応しきれないことです。

DKIM署名に対応していないサーバーやプランは依然として存在します。メールヘッダーを書き換える機能がないため、ワンクリック解除（List-Unsubscribe）を実装できないケースもあります。そして最大の壁が共用IPアドレスです。

共用サーバーでは送信元IPを他の契約者と共有しているため、自社が健全な配信を行っていても、同居するユーザーのスパム行為によってIPの評価が下がります。迷惑メール率の基準を、自社の努力だけでは守りきれないのです。

送信制限に収まる規模であっても、レンタルサーバーからの配信は届かないリスクを構造的に抱えている。これが、送信制限とあわせて理解しておくべき本質です。

メール送信制限に悩まないならメール配信システムを活用する

レンタルサーバーの送信制限は、プラン変更や分割送信では根本的に解決できません。配信規模が数百通を超え、かつ定期的に配信を行うのであれば、メール配信の機能そのものを専用のサービスに切り出すのが、もっとも確実で運用コストの低い選択です。

メール配信システムを使うメリット

メール配信システムは、大量のメールを確実に届けることに特化して設計されています。レンタルサーバーのメール機能と比較したとき、実務上の差がもっとも大きく出るのは次の3点です。

加えて、BCCの設定ミスによる情報漏洩リスクを構造的に排除できる点も見逃せません。宛先の管理をシステムに任せることで、人為的な誤送信そのものが起こらなくなります。

おすすめのメール配信システム「blastengine」

blastengine（ブラストエンジン）は、自社のシステムとSMTPリレーやAPIで連携することで、一斉配信やトランザクションメールを送信できるメール配信サービスです。ECサイトの注文確認メールや会員登録通知など、Webアプリケーションから自動送信されるメールが送信制限を圧迫しているケースに適しています。

レンタルサーバー上のプログラムから送信していたメールの送信経路をblastengineに切り替えることで、送信制限とIPレピュテーションの問題を同時に解消できます。初期費用は無料で、メールアドレスの入力のみで無料トライアルを開始できます。

ブラストエンジン公式サイト：https://blastengine.jp/

おすすめのメール配信システム「ブラストメール」

ブラストメール（blastmail）は、15年連続で導入社数シェアNo.1を獲得している国内最大級のメール配信システムです。導入実績は27,000社以上。専門知識がなくても直感的に操作できるシンプルな管理画面と、業界最安クラスの料金設定が支持されています。レンタルサーバーの送信制限に悩んでいる担当者が、はじめて配信システムに移行する際の選択肢として扱いやすいサービスです。

Webサイトはこれまでどおりレンタルサーバーで運用しながら、一斉配信だけをブラストメールに切り出す。この構成にすれば、送信制限を気にすることなく配信設計に集中できます。無料お試しが用意されているので、まずは実際の操作感を確認してみてください。

公式サイト：シェア1位のメール配信システム「ブラストメール」

まとめ

レンタルサーバーのメール送信制限について、主要6サービスの上限値と対処法を解説しました。要点は次のとおりです。

主要サービスの上限は、1時間あたり50〜1,500通、1日あたり100〜15,000通の範囲です。制限は契約アカウント単位でかかり、BCCやメーリングリストは宛先数分がカウントされます。契約直後やお試し期間中は、さらに厳しい制限が別途適用されます。

上限に達すると、エラー・遅延・アカウント停止という3段階の症状が起こります。特に遅延は「送信済み」と表示されるため発見が遅れやすく、注意が必要です。

そして、送信制限をクリアしても届くとは限りません。Gmail・Yahoo!・Outlookが送信ドメイン認証を必須化した現在、共用IPを使うレンタルサーバーからの配信は、構造的に到達率のリスクを抱えています。

まず取り組むべきアクションは、自社が1日に何通のメールを送信しているかを正確に数えることです。メルマガだけでなく、問い合わせフォームの自動返信、EC・予約システムからの通知メール、転送設定の分まで含めて合計してください。その数値が契約中のプランの上限の半分を超えているなら、メール配信システムへの切り替えを具体的に検討する段階にあります。