Xserverでメールが届かない原因と対処法｜送信・受信別のチェック手順と確実に届ける方法

「取引先にメールを送ったはずなのに、届いていないと連絡が来た」「問い合わせフォームからの自動返信が一部のお客様にだけ届かない」。Xserver（エックスサーバー）を利用している企業のWeb担当者から、こうした相談は後を絶ちません。

やっかいなのは、Xserverのメールトラブルが「原因の異なる複数の問題」がひとまとめに「届かない」と表現されている点です。送信側の問題なのか受信側の問題なのか、サーバー起因なのか設定起因なのかを切り分けないまま設定を変更すると、復旧が遅れるだけでなく、新たな不達要因を作り込んでしまうこともあります。

本記事では、Xserverのメールが届かないときの切り分け手順を、送信側・受信側の両面から整理します。そのうえで、Xserver公式マニュアルに記載された送信数の上限やメールマガジン機能の仕様といった一次情報をもとに、業務メールやメルマガを確実に届けるための現実的な打ち手まで踏み込んで解説します。読み終わるころには、自社のケースがどのパターンに該当し、次に何をすべきかが判断できる状態になっているはずです。

なお、実際にトラブルが発生した際は、まずXserver公式マニュアルを確認し、必要に応じてサポートへ問い合わせる対応が基本となります。

Xserver公式マニュアル：https://www.xserver.ne.jp/manual/

Xserverでメールが届かないときに最初にやるべき切り分け

結論から言えば、最初にやるべきことは設定変更ではなく「切り分け」です。原因の当たりを付けずに設定をいじると、復旧が遅れるだけでなく、SPFレコードの書き換えミスなど新たな不達要因を作り込んでしまいます。

切り分けは、次の3つの質問に順番に答えるだけで大半が完了します。

「送れていない」のか「届いていない」のかを分ける

まず確認すべきは、問題が発生している方向です。

ここを混同したまま調査を始めると、まったく関係のない設定画面を何時間も眺めることになります。「誰から誰へのメールが、いつから、どのくらいの頻度で失敗しているのか」を先に書き出してください。

特定の宛先ドメイン（Gmail宛だけ、@docomo.ne.jp宛だけ）で失敗しているのか、すべての宛先で失敗しているのかも重要な情報です。特定ドメインだけ失敗している場合は、受信側のフィルタリングポリシーかレピュテーションの問題である可能性が高くなります。

エラーメールが返ってきているかを確認する

送信側の問題である場合、次に見るべきはエラーメール（バウンスメール）の有無です。

「MAILER-DAEMON」や「Mail Delivery System」からの自動返信が届いていれば、メールは受信サーバーに拒否されています。この場合、エラー本文に含まれるステータスコードが原因をほぼ特定してくれます。

一方、エラーメールが返ってきていないのに届いていない場合は、受信側で迷惑メールフォルダに振り分けられている可能性が高いと考えてください。受信サーバーはメールを受け取ったうえで、受信トレイに入れない判断をしています。この状態はエラーとして観測できないため、送信側は気づきにくく、放置されがちです。

まずは相手先に迷惑メールフォルダの確認を依頼するか、自社で用意したGmail・Outlookのテストアカウント宛に同じ文面を送り、どこに着地するかを確かめましょう。

エラーコードから原因を絞り込む

エラーメールが手元にある場合は、以下の早見表で原因を特定できます。

※上記はSMTPステータスコードの一般的な意味です。実際に返される文言や判定基準は、受信側のメールサーバーによって異なります。

550 5.7.1 が返ってきている場合は、送信元IPアドレスのブラックリスト掲載を疑います。Xserverの共用サーバーでは、送信元IPは自社専用ではありません。掲載状況は無料ツールで確認できます。

※いずれも第三者が提供するツールです。利用にあたっては各サービスの規約をご確認ください。

送信元IPアドレスは、Xserverの管理画面から確認するか、送信済みメールのヘッダー情報にある「Received:」フィールドから把握できます。

Xserverから送ったメールが届かない主な原因

切り分けの結果が「送信側の問題」だった場合、原因は次の5つのいずれかに収束します。

共用IPアドレスがブラックリストに登録されている

Xserverの共用サーバーでは、1つのIPアドレスを多数の契約者が共有しています。同じIPを使う他の利用者が大量配信を行ったり、サイトの改ざん被害で踏み台にされたりすると、自社にまったく非がなくてもIPアドレス全体がブロックリストに掲載される可能性があります。

掲載されると、次のような症状が現れます。

これは共用サーバー特有のリスクであり、Xserverに限らず多くのレンタルサーバーの共用プランで起こり得る事象です。

送信数の上限を超えている

Xserverには、全プラン共通のメール送信数の目安が設定されています。公式マニュアルには次のように記載されています。

この数値はあくまで目安であり、多少の超過は許容範囲とされています。ただし注意すべきは、迷惑メールと判断される配信が行われた場合は、この範囲内であっても制限がかかると明記されている点です。つまり「上限さえ守っていれば安全」ではありません。

参照：Xserver／メール関連の仕様一覧

主要なレンタルサーバーの送信制限はサービスごとに大きく異なります。制限値やカウント方法は変更されることがあるため、運用前に必ず各社の公式マニュアルで最新情報を確認してください。

SPF・DKIM・DMARCの設定が不十分

送信ドメイン認証が正しく設定されていないメールは、受信側で「なりすましの疑いがある」と判断されます。それぞれの役割は次のとおりです。

XserverではサーバーパネルからSPF設定・DKIM設定・DMARC設定がそれぞれ提供されています。実際に設定できるかどうかは契約中のプランの管理画面で確認できますので、3つすべてが有効になっているかを一度チェックしてください。

見落とされがちなのが、外部サービスを併用している場合のSPFレコードの不備です。Xserverのメールに加えてMAツールや問い合わせフォームのサービスからも同じドメインで送信している場合、それぞれの送信元をSPFレコードに含めなければ認証に失敗します。

Gmail・Yahoo!メールの送信者要件を満たしていない

2024年2月以降、Gmailは送信者に対する要件を明文化しています。すべての送信者に対しては、SPFまたはDKIMの設定、正引き・逆引きDNSレコードの設定、TLS接続の利用、迷惑メール率を0.3%未満に維持することなどが求められます。

さらに、Gmail宛に1日5,000通以上を送信する送信者には、SPFとDKIMの両方の設定、DMARCの設定、DMARCアライメントの合格、マーケティングメールへのワンクリック登録解除の実装が追加要件として課されます。

見過ごせないのが迷惑メール率です。Googleは0.10%未満を維持し、0.30%以上にならないようにすることを求めており、0.3%を超えている間は配信に関する緩和の申し立てができません。迷惑メール率はGoogle Postmaster Toolsで日次で確認できます。

Yahoo!メールも同時期に送信者向けの要件を公表しており、送信ドメイン認証への対応、ワンクリックでの配信解除、迷惑メール報告率を低く保つことなど、求められる内容はGmailとおおむね共通しています。主要プロバイダの要件は横並びで厳格化していると捉え、Gmail基準で対応しておくのが現実的です。

参照：Google／メール送信者のガイドラインに関するよくある質問

国外アクセス制限やポート設定でSMTP認証が通らない

「そもそもメールソフトから送信できない」という場合は、認証周りを疑います。

Xserverの送信時の認証方式はSMTP AUTHで、国内ネットワークからの接続のみが利用可能です。海外出張中や海外VPNを経由している環境から送信しようとすると認証に失敗します。この場合は「SMTP認証セキュリティ設定」から「国外アクセス制限設定」を無効にすることで、国外ネットワークからの利用が可能になります。

また、プロバイダが迷惑メール対策として25番ポートをブロック（OP25B）している環境では、ポート25が使えません。Xserverではポート25の代替としてサブミッションポート587が利用できます。送信できない場合は、メールソフトの送信ポートを587または465に変更して再度試してください。

Xserver宛のメールが受信できない原因

「自社宛のメールが届かない」パターンは、送信側とはまったく別の原因群になります。

DNSの反映待ちとMXレコードの設定不備

サーバー移転やドメイン移管の直後に発生しやすいのがこのケースです。ネームサーバーの変更が全世界のDNSに反映されるまでには時間がかかり、その間は旧サーバーと新サーバーのどちらにメールが届くかが安定しません。

移転直後であれば、まず反映完了を待ち、旧サーバー側のメールボックスも並行して確認してください。数日経っても解決しない場合は、DNS設定画面でMXレコードがXserver指定の値になっているかを確認します。

なお、Google Workspaceなど外部のメールサーバーを併用している場合、MXレコードを外部サービス側に向ける必要があります。WebサイトだけをXserverで運用しているつもりでも、MXレコードがXserverを指したままだと、メールがXserver側のメールボックスに配送されてしまいます。

メールボックスの容量オーバー

Xserverのメールボックス容量は、メールアカウントごとに1〜20,000MBの範囲で設定できます。初期値のまま長年運用していると、上限に達して新規メールを受信できなくなることがあります。

この状態では送信者側に容量超過のエラーが返るため、「送ったのに届かない」と言われる典型的な原因になります。サーバーパネルの「メールアカウントの容量変更」から上限を引き上げるか、不要なメールを削除してください。

POP接続でメールを受信していて「サーバーにメールを残す」設定になっている場合、受信済みメールがサーバー上に蓄積し続けます。定期的な棚卸しを運用ルールに組み込んでおくと安全です。

迷惑メールフィルタと振り分け設定

Xserverでは迷惑メールフィルタや振り分け設定が利用できます。過去に設定した条件が意図せず正規のメールを弾いているケースは、実務上かなり多く見られます。

確認すべきポイントは次のとおりです。

メールソフト側の設定ミス

WEBメールでは受信できているのにメールソフトで受信できない場合、原因はクライアント側にあります。サーバー名、ポート番号、SSL設定、パスワードのいずれかが古い情報のままになっていないかを確認してください。パスワードはサーバーパネルのログインパスワードとは別物である点にも注意が必要です。

Xserverのメルマガ・一斉配信で起きやすい落とし穴

ここからは、一般的なトラブルシューティング記事があまり触れない領域です。Xserverでメルマガや一斉配信を運用している場合、日常のメール以上に不達リスクが高まります。

メールマガジン機能には登録数の上限がある

Xserverにはサーバーパネルから利用できるメールマガジン機能が備わっています。ただし、公式マニュアルには明確な制約が記載されています。

参照：Xserver／メールマガジンについて

注目すべきは1つのメールマガジンあたり1,000件という登録上限です。リストが3,000件に成長した時点で、3つのメールマガジンに分割して管理する必要が生じます。配信のたびに3回同じ作業を繰り返し、配信停止の反映も3箇所で行うことになり、運用ミスが起きやすい構造になります。

送信通数は「宛先の数」でカウントされる

もうひとつ見落としやすいのが、送信通数のカウント方法です。マニュアルには、10人のユーザーに1通のメールを配信した場合は10通としてカウントすると明記されています。

これを1時間1,500通・1日15,000通の目安と重ね合わせると、現実的な上限が見えてきます。

シミュレーション：リスト3,000件へメルマガを配信する場合

つまり、3,000件のリストに1通配信するだけで、1時間あたりの目安を超過する計算になります。ここに問い合わせフォームの自動返信、注文確認メール、社内の通常業務メールが加わることを考えれば、余裕はほとんど残りません。

さらに前述のとおり、迷惑メールと判断される配信については、目安の範囲内であっても制限の対象となります。「まだ上限に達していないから大丈夫」という判断は成り立ちません。

バウンスメールの放置がレピュテーションを削る

Xserverのメールマガジン機能には配信エラーの自動削除機能があり、初期設定では有効になっています。マニュアルには、この機能を無効にすると配信できないアドレス宛に送信を試みる頻度が増加し、他の利用者にも影響を及ぼす可能性が高くなると明記されています。

無効なアドレスへの配信を繰り返すことは、受信側から見れば「リスト管理をしていない送信者」のシグナルです。これがレピュテーションの低下につながり、最終的には有効なアドレスへの到達率まで押し下げます。

なお、携帯キャリアのメールアドレスで「なりすましメール対策」が設定されている場合、メールマガジンからの配信を受信できないことがある点もマニュアルに注記されています。キャリアメールを多く含むリストを扱う場合は、事前の受信許可の案内が必要になります。

Xserverでメールが届かないときの対処法

原因が特定できたら、対処に移ります。即効性のある応急処置から、再発を防ぐ根本対策まで順に見ていきます。

ブラックリストの掲載状況を確認して解除申請を出す

550 5.7.1 のエラーが返っている場合、まず自分で掲載状況を確認します。MXToolboxで送信元IPアドレスを入力し、どのブロックリストに掲載されているかを特定してください。

そのうえで、Xserverのサポートへ次の情報を添えて問い合わせます。

ただし、この方法には構造的な限界があります。解除の手続きと反映には時間を要するうえ、同じIPを共有する他の利用者が再びスパム行為を行えば、再掲載されるリスクが残るという点です。解除申請は応急処置であって、再発防止策ではありません。

送信ドメイン認証を正しく設定する

SPF・DKIM・DMARCは、設定していること自体よりも「正しく設定されていること」が重要です。以下の順で確認してください。

DMARCをいきなりp=rejectに設定すると、認証設定が漏れているシステムからのメールがすべてブロックされます。段階的に引き上げるのが実務上の鉄則です。

配信リストを整理して迷惑メール率を下げる

迷惑メール率は、受信者が「迷惑メールとして報告」した割合で決まります。数値を下げるために有効なのは、技術対策ではなくリスト運用の見直しです。

「解除しづらいメルマガ」は、解除の代わりに迷惑メール報告をされてしまいます。解除のしやすさは、到達率を守るための投資と捉えるべきです。

送信経路そのものを分離する

ここまでの対策は、いずれも有効です。ただし共用IPを使い続ける限り、他の利用者の影響を完全に避けることはできません。また、送信数の目安を大きく超える配信は、共用サーバーが本来想定している用途から外れます。

そこで有効なのが、Webサイトの運用はXserverのまま、メールの送信経路だけを外部のメール配信システムに分離するという考え方です。サーバーを移転する必要はなく、送信の出口を差し替えることで、共用IPのリスクと送信数の制約の両方に対処できます。対策ごとの特性を整理すると、次のようになります。

コストは発生します。メールが届かないことによる商談の停滞や問い合わせ対応の工数と比較したうえで、判断することをおすすめします。

Xserverから確実にメールを届けるならメール配信システムを活用する

Xserverは国内でも有数のシェアを持つレンタルサーバーで、Webサイトの表示速度や安定性、WordPressの運用環境については高い評価を得ています。サイト運用の基盤として乗り換える理由はほとんどありません。

一方で、共用サーバーは多数の利用者でリソースを共有する設計であり、メールの大量配信はもともと想定されている使い方とは異なります。サイトはXserver、メール配信は専用の基盤というように、用途に合わせて使い分けるのが現実的な解決策です。

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

メール配信システムは、メールを「届ける」ことに特化して設計された基盤です。共用サーバーからの配信では実現できない要素が、標準で備わっています。

重要なのは、これらを自社で実現しようとすると、専用のインフラ構築と継続的な運用工数が必要になるという点です。メール配信システムを使うということは、その運用を専門事業者に委ねるということでもあります。

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

blastengine（ブラストエンジン）は、既存のシステムとSMTPリレーまたはAPIで連携することで、一斉配信もトランザクションメールも同じ基盤から送信できるメール配信システムです。Xserver上で動作しているWordPressや業務システムの送信経路は、SMTP設定の変更またはAPI連携によって差し替えられます。サーバーを移転することなく、共用IPのリスクと送信数の制約に対処できるのが特徴です。

初期費用は無料、月額3,000円から利用でき、日本語での電話・メールによるテクニカルサポートにも対応しています。Xserverの送信数の目安を超える配信が必要な企業や、共用IPのレピュテーションに左右されたくない企業にとって、有力な選択肢のひとつです。メールアドレスの入力のみで無料トライアルを開始できますので、まずは実際の配信環境で到達率を確かめてみてください。

blastengine公式サイト：https://blastengine.jp/

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

システム連携ではなく、管理画面からメルマガを作成・配信したいという場合は、ブラストメールが適しています。15年連続で導入社数シェアNo.1を獲得しており、導入実績は27,000社以上。専門知識がなくても直感的に操作できる管理画面が特徴です。

Xserverのメールマガジン機能のように1,000件という登録上限を気にする必要がなく、リストの成長に合わせて同じ運用のまま拡張できる点が大きな違いです。

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

まとめ

Xserverでメールが届かない問題は、原因が一つではありません。送信側のブラックリスト掲載や送信制限、ドメイン認証の不備もあれば、受信側のDNS設定やメールボックス容量、フィルタ設定が原因のこともあります。だからこそ、設定をいじる前の切り分けが決定的に重要です。

そして、切り分けの結果が「共用IPのレピュテーション」や「送信数の目安」に行き着いた場合、設定の見直しだけで解決することは難しくなります。共用サーバーは多数の利用者でリソースを共有する設計であり、メールの大量配信は本来の想定用途と異なるためです。

次に取るべきアクションは、次の3つです。

3の時点で余裕がないと判断できるなら、メールの送信経路を分離することを検討するタイミングです。blastengineであれば、Xserverの環境をそのまま活かしながら、SMTPリレーまたはAPI連携で送信経路を切り替えられます（所要期間は設定内容により異なります）。まずは無料トライアルで、自社のメールがどこまで届くようになるかを確かめてみてください。