会社の独自ドメイン（info@example.co.jp のようなアドレス）宛のメールが届かない——このトラブルは、原因が1つに決まっていません。メールボックスの空き容量のように5分で直るものから、DNS の MX レコードのように触ると被害が広がるものまで、まったく違う原因が同じ症状に見えます。
やみくもに設定を触る前に、切り分けだけ先に済ませてください。切り分けは2問だけです。「届かないのは自分宛か、相手宛か」と「全員からか、特定の相手からだけか」。この2問の答えで、見る場所は4分の1に絞れます。
まず切り分ける2点
次の表で、貴社の状況がどこに当てはまるかを決めてください。以降の章は、この4象限に対応しています。
全員から届かない | 特定の相手からだけ届かない | |
|---|---|---|
受信（自分に届かない） | メールボックスの容量、MX レコード、ドメインの更新切れ、サーバー移転の取り残し | 迷惑メール判定、フィルタ・振り分け、受信拒否リスト、相手側の送信エラー |
送信（相手に届かない） | 送信サーバーの設定、IP・ドメインの評価低下 | 相手のドメインの受信ポリシー（DMARC 判定）、SPF・DKIM の未設定 |
切り分けのいちばん確実な材料は、エラーメール（バウンスメール）です。「Mail Delivery Subsystem」「Undelivered Mail Returned to Sender」といった件名で戻ってくるあの英文メールに、原因のほぼすべてが書かれています。捨てずに全文を残しておいてください。
もう1つ、先に確認してほしいことがあります。Web サイトは表示できているかです。サイトも同時に見られなくなっているなら、メール個別の問題ではなくドメインそのものが止まっている可能性が高く、対処の順番が変わります（後述します）。
受信できない側：確認が軽い順に7つ
ここからは「自分宛のメールが届かない」ケースです。上から順に確認してください。上ほど自分で直せて、下ほど専門的で、間違えると被害が広がります。
1. メールボックスの容量がいっぱいになっている（所要5分）
いちばん多く、いちばん軽い原因です。容量が上限に達すると、そのアドレス宛のメールは受け取られず、送信者側にエラーとして返されます。Google の公式ヘルプにも、保存容量の上限に達すると「メールを送受信できなくなります」「あなた宛てに送信されたメールは送信者に返送されます」と明記されています。
確認する場所は、使っているメールの種類で違います。
- Google Workspace / Gmail：Google One の保存容量ページ、または管理コンソールのユーザー一覧で各ユーザーの使用量を見る
- レンタルサーバーのメール：サーバーの管理画面（コントロールパネル）にメールアカウントごとの使用量と割当（クォータ）がある
特に見落とされがちなのが、「サーバーにメールを残す」設定のまま何年もメールソフトで受信しているケースです。手元のパソコンでは受信できているように見えるのに、サーバー側には全期間分のメールが溜まり続け、ある日いっぱいになって止まります。ゴミ箱と迷惑メールフォルダを空にするのが、いちばん早く空きを作る方法です。
2. フィルタ・自動振り分け・アーカイブに吸い込まれている（所要10分）
「届かない」と言われたメールが、実は別のフォルダに入っているだけ、というのは実務でかなり多いパターンです。過去に誰かが作ったフィルタが、いまも動き続けています。
- 受信トレイではなく全メールを検索する：Gmail なら検索欄に in:anywhere と相手のアドレスを入れて検索すると、アーカイブ・迷惑メール・ゴミ箱まで含めて探せます
- フィルタ設定を全部見る：Gmail は「設定 → フィルタとブロック中のアドレス」。前任者が作った「受信トレイをスキップ」「削除する」フィルタが残っていないか
- ブロック中のアドレス：同じ画面で、相手のドメインごとブロックされていないかを確認します
組織全体で使っている場合は、管理者側のルール（コンプライアンス設定・添付ファイルの制限）でも止まります。Gmail はウイルスを拡散させる可能性がある形式の添付ファイルをブロックするため、実行形式のファイルが付いたメールだけ届かない、という現象も起きます。
3. 迷惑メール（スパム）と判定されている（所要10分）
「特定の相手からだけ届かない」なら、まずここを疑ってください。迷惑メールフォルダを開き、該当のメールがあれば「迷惑メールではない」を選び、あわせて相手のアドレスを受信フィルタで許可しておきます。
注意点として、迷惑メール判定は相手側の送信設定が原因で起きていることがあります。相手が SPF や DKIM を設定していない、あるいは転送を経由して送っている場合、こちらが何をしても弾かれ続けます。その場合は相手に伝えるしかありません。この仕組みは後半の送信編で説明します。
4. 転送設定・エイリアスが古いまま残っている（所要15分）
info@ 宛のメールを個人のアドレスへ転送している構成は珍しくありません。この転送先が退職者のアドレスだったり、すでに解約したサービスだったりすると、受け取ったメールがそのまま行方不明になります。
- 転送先アドレスがいまも生きているか（転送先の容量も上限に達していないか）
- 「転送してサーバーに残さない」設定になっていないか（残さない設定だと元のアドレスには何も残りません）
- エイリアス（別名アドレス）が本当に有効なメールボックスに紐づいているか
問い合わせフォームからのメールだけ届かない場合は、原因も対処も別系統です。問い合わせフォームのメールが届かないときの原因と確認手順にまとめてありますので、そちらを先にご覧ください。
5. MX レコードが正しくない（要注意・所要20分）
ここから DNS の話になります。MX レコードは「このドメイン宛のメールは、どのサーバーに届ければよいか」を示す道案内です。Google の公式ドキュメントも、MX レコードは「ドメインのメールを、ドメインのユーザー アカウントをホストしているサーバーに配信」するためのものと説明しています。これが間違っていると、世界中の送信者がメールを持っていく先を間違えます。
読むだけなら誰でもできます。Windows のコマンドプロンプト、または Mac のターミナルで次を実行してください。
- Windows：nslookup -type=mx example.co.jp
- Mac / Linux：dig mx example.co.jp +short（nslookup も同じように使えます）
example.co.jp の部分は貴社のドメイン（@ より後ろ）に置き換えてください。 返ってきた結果が、いま契約しているメールサービスの案内と一致していれば正常です。判断の目安は次のとおりです。
返ってきた値 | 意味 |
|---|---|
smtp.google.com が出る | Google Workspace（2023年以降に開始したアカウントの単一 MX レコード） |
aspmx で始まる値が複数出る | Google Workspace（2023年より前に開始したアカウント。そのままで問題ありません） |
契約中のレンタルサーバー名を含む値 | そのサーバーでメールを受けている |
何も返らない／覚えのない値 | 要調査。ここで手を止めてください |
読むのは安全ですが、書き換えは危険です。 MX レコードを書き換えると、その瞬間から全世界のメールの行き先が変わります。間違った値を入れれば、直るどころか一通も届かなくなります。値の意味が分からないまま触らず、契約中のメールサービスの案内どおりの値になっているかを確認するだけにとどめてください。
6. DNS 変更直後・サーバー移転の切り替え中である（待つのが正解）
サイトのリニューアルやサーバー移転をした直後なら、原因はほぼこれです。DNS の変更は世界中に一斉に反映されるのではなく、各プロバイダのキャッシュが切れた順に少しずつ広がります。TTL（キャッシュの保持時間）の設定によりますが、数時間から最大で数十時間、古い情報を見ている送信者が残ります。
この期間に起きるのが、「一部のメールだけ旧サーバーに届いている」という状態です。新サーバーの受信トレイを見ても何もないので消えたように見えますが、実際は旧サーバーのメールボックスに溜まっています。移転作業のあいだは旧サーバーの契約をすぐ解約せず、1〜2週間は残しておいて、旧サーバー側の Webメール（管理画面から入れる簡易メールソフト）も並行して確認するのが安全です。
また、メールとサイトを別々の会社に預けている場合、サイトの引っ越しに合わせてネームサーバーごと切り替えると、MX レコードの設定が新しい DNS に引き継がれずメールだけ止まります。これは実務でいちばん多い事故です。ネームサーバーを変更する前に、旧 DNS に登録されているレコード（MX・TXT・CNAME）を全部書き出して、新しい側に同じものを作ってから切り替えてください。
7. ドメインの有効期限が切れている（サイトも同時に止まる）
サイトも同時に見られないなら、ここです。ドメインの更新が止まると、サイトが表示されなくなるのと同時に、そのドメインのメールもすべて止まります。JPドメインの場合、有効期限を過ぎて廃止されるとサービスが一時停止（Suspended）状態になり、その後レジストリから削除されて第三者が登録できる状態になります。JPRS の説明では、この一時停止の期間中に月の1日から20日までの登録回復期間が設けられており、この間に手続きをすれば復旧できます。
期限や登録者名義の調べ方、復旧の考え方はドメイン更新忘れでサイトが消えたときの復旧の期限と原因で詳しく扱っています。そもそも誰がドメインとサーバーを管理しているのか分からない状態であれば、先にドメインとサーバーの管理会社がわからないときの調べ方で管理元を特定してください。制作会社と連絡が取れなくなっているなら、制作会社と連絡が取れないときにサイトとドメインを取り戻す手順もあわせてご覧ください。
エラーメールは捨てない：3つの数字で原因が分かる
送信者に返ってきたエラーメールには、原因を示すコードが入っています。全文を読む必要はなく、3桁の数字の先頭1桁だけ見れば方向が決まります。
- 4 で始まる（例 421, 450）：一時的な失敗。相手のサーバーが混んでいる、容量が一時的に足りない等。しばらく待つと自動で再送されることが多い
- 5 で始まる（例 550, 552）：恒久的な失敗。宛先が存在しない、受信を拒否された、容量超過。放っておいても届きません
そのあとに続く英文に、「Mailbox full」（容量超過）「User unknown」（宛先なし）「Message rejected due to DMARC policy」（送信認証の不備で拒否）のように理由が書かれています。ここまで読めれば、次に触るべき場所はほぼ確定します。制作会社やサーバー会社に相談するときも、このエラーメールを転送するだけで話が一気に早くなります。
送信が届かない側：SPF / DKIM / DMARC の3点
次は「こちらから送ったメールが相手に届かない」ケースです。原因はほぼ送信ドメイン認証の3点に集約されます。Gmail や Yahoo! のような大手のメールサービスは、この3つを手がかりに「そのメールが本当にそのドメインから出たものか」を判定し、条件を満たさないメールを迷惑メール送りにしたり、受け取らなかったりします。
3つの役割は次のとおりです。Google の公式ドキュメントの説明に沿って整理します。
仕組み | 役割 | 設定する場所 |
|---|---|---|
SPF | 「このドメインのメールは、このサーバーから出ます」と宣言する。なりすまし送信を防ぐ | DNS の TXT レコード |
DKIM | メールに電子署名を付け、転送中に内容が改ざんされていないことを示す | メールサービス側で鍵を発行し、DNS の TXT レコードに公開鍵を登録 |
DMARC | SPF や DKIM の検証に失敗したメールを、受信側にどう扱わせるかを指定する | DNS の TXT レコード（_dmarc.ドメイン名） |
設定の順番は SPF と DKIM を先に、DMARC は最後です。Google も「DKIM と SPF の両方を設定」したうえで DMARC を設定することを推奨しています。順番を逆にすると、自社の正規のメールまで自分で弾く設定になります。DMARC は「認証に失敗したら拒否せよ」と受信側に命じる仕組みなので、SPF・DKIM が整っていない状態でいきなり厳しいポリシー（p=quarantine / p=reject）にすると、自社の請求書メールが取引先に届かなくなります。まず p=none（何もしないが報告だけ受け取る）から始め、レポートで認証が通っていることを確認してから強めるのが実務の手順です。
いま設定されているかを確認する
これも読むだけなら安全です。
- SPF：nslookup -type=txt example.co.jp（Mac は dig txt example.co.jp +short）。v=spf1 で始まる行があれば設定済み
- DMARC：nslookup -type=txt _dmarc.example.co.jp。v=DMARC1 で始まる行があれば設定済み
- DKIM：セレクタ名（Google Workspace なら google など）が必要なため、管理画面側で「DKIM が有効か」を見るほうが確実です
設定されていない場合、追加するのは DNS の編集作業です。値を1文字間違えると認証が通らなくなるので、自信がなければ制作会社かサーバー会社に「SPF・DKIM・DMARC を設定してほしい」と依頼するのが確実です。依頼するときは、社内から送っているメールの経路（Google Workspace、レンタルサーバー、メール配信サービス、問い合わせフォーム）を全部伝えてください。1つでも漏れると、その経路から出たメールだけが認証に失敗します。
2024年から始まった Google と Yahoo の送信者ガイドライン
この話が急に厳しくなったのには理由があります。Google は 2024年2月から、メール送信者に対する要件の適用を開始しました（Yahoo Inc. も同時期に同様の基準の適用を開始しています）。要件は、送信量によって2段階に分かれます。
項目 | すべての送信者 | 1日5,000件以上を送る送信者 |
|---|---|---|
認証 | SPF または DKIM を設定 | SPF と DKIM と DMARC をすべて設定 |
迷惑メール率（Postmaster Tools で報告される値） | 0.3% 未満を維持 | 0.10% 未満を維持し、0.30% 以上にしない |
From ヘッダーの一致 | なりすましをしない | From のドメインが SPF または DKIM のドメインと一致していること |
登録解除 | — | ワンクリックで登録解除でき、本文に解除リンクを分かりやすく表示 |
その他 | 有効な正引き・逆引き DNS（PTR）レコード、TLS 接続、RFC 5322 準拠の形式 | |
ここで大事なのは、「1日5,000件」は同じプライマリドメインからの送信を合計してカウントされるという点です。Google の公式 FAQ では、サブドメインから送ったメールも同じプライマリドメインの数に合算されると説明されています。「うちは営業メールを1日100通しか送らないから関係ない」と思っていても、メール配信サービスや予約システム、通知メールを同じドメインで動かしていれば、合計が閾値を超えることはあります。
なお、DMARC は最低限 p=none でも要件を満たすとされています。いきなり厳しくする必要はありません。また、SPF と DKIM は両方設定する必要がありますが、From ヘッダーとの一致（アライメント）はどちらか一方が満たされていればよいとされています。
中小企業の実務としては、送信量が5,000件に届かなくても3つとも設定しておくのが結果的にいちばん安上がりです。設定していないと、日常の1通1通が「怪しいメール」として扱われ続け、しかも相手側の迷惑メールフォルダに入っていることに自社では気づけません。
制作会社やサーバー会社に頼むとき、何を伝えれば早いか
自分で切り分けきれない場合は、無理に触らず依頼してください。次の5点をまとめて渡すだけで、往復の回数が大きく減ります。「メールが届きません」の一言だけでは、相手も何から聞けばよいか分からず、確認のやりとりで数日消えます。
- 現象：受信できないのか、送信が届かないのか（この記事の切り分けの結果）
- いつから：最後に正常に届いた日時と、気づいた日時。直前に何か作業をしたか（サーバー移転、パスワード変更、リニューアル）
- 誰から／誰宛に：全員か、特定のドメインの相手だけか。届かない相手のドメイン名
- エラーメールの全文：転送するのではなく、ヘッダー込みで見られる形が理想。難しければ本文をコピーして貼り付ける
- 影響範囲：社内の何人が該当するか。1人だけならアカウント側、全員ならドメイン側の可能性が高い
あわせて、ドメインとサーバーの契約者・管理会社が誰なのかも先に確認しておくと話が早く進みます。ここが分からないと、依頼された側も設定を見ることすらできません。
まとめ
- 最初に切り分けるのは「受信か送信か」「全員か特定の相手か」の2点だけ。ここで見る場所が4分の1に絞れます。
- 受信できない側は、容量 → フィルタ → 迷惑メール → 転送 → MX レコード → 移転直後の切り替え → ドメイン更新切れ、の順に確認します。上ほど自分で直せます。
- MX レコードは nslookup -type=mx ドメイン名 で読むだけなら安全ですが、書き換えは全世界のメールの行き先を変えるので触らないでください。
- サイトも同時に見られないなら、ドメインの有効期限切れを最優先で疑います。
- 送信が届かない側は SPF・DKIM・DMARC の3点。設定は SPF と DKIM が先で、DMARC は p=none から始めます。
- Google は2024年2月から送信者への要件の適用を開始しています。全送信者に SPF または DKIM と迷惑メール率0.3%未満、1日5,000件以上の送信者にはSPF・DKIM・DMARC全部とワンクリック登録解除、迷惑メール率0.10%未満が求められます。
- 依頼するときは、現象・いつから・誰から届かないか・エラーメール全文・影響範囲の5点を先に渡します。
よくある質問
独自ドメインのメールが急に受信できなくなりました。何から確認すればよいですか？
まず「受信できないのか、送信が届かないのか」「全員からなのか特定の相手からだけか」の2点を切り分けてください。そのうえで受信側は、メールボックスの容量、フィルタや自動振り分け、迷惑メール判定、転送設定、MXレコード、DNS変更直後の切り替え、ドメインの有効期限切れ、の順に確認するのが安全です。上ほど自分で直せて、下ほど触ると被害が広がります。
MXレコードが正しいかどうか、自分で確認できますか？
確認だけなら自分でできます。Windowsのコマンドプロンプトで nslookup -type=mx ドメイン名、Macのターミナルで dig mx ドメイン名 +short を実行すると、そのドメインのメールを受け取るサーバーが表示されます。Google Workspaceであれば smtp.google.com、または aspmx で始まる値が返ります。ただし書き換えると全世界のメールの行き先が変わるため、値の意味が分からないまま変更しないでください。
サイトもメールも同時に止まりました。原因は何でしょうか？
ドメインの有効期限切れの可能性が高いです。ドメインの更新が止まると、サイトの表示と独自ドメインのメールが同時に停止します。JPドメインの場合、有効期限を過ぎて廃止されると一時停止状態になり、その期間中の月の1日から20日までが登録回復期間として設けられています。まずWHOISで有効期限と管理元を確認してください。
こちらから送ったメールが相手に届きません。何を設定すればよいですか？
送信ドメイン認証のSPF・DKIM・DMARCの3点を確認してください。SPFは送信元サーバーを宣言し、DKIMは電子署名で改ざんされていないことを示し、DMARCは認証に失敗したメールの扱いを受信側に指示します。設定はSPFとDKIMが先で、DMARCは最後です。DMARCはまず p=none から始め、レポートで認証が通っていることを確認してから強めてください。
1日5,000件も送っていませんが、SPF・DKIM・DMARCは必要ですか？
Googleのガイドラインでは、すべての送信者にSPFまたはDKIMの設定と、迷惑メール率0.3%未満の維持が求められます。1日5,000件以上の送信者には、SPF・DKIM・DMARCすべてとワンクリックでの登録解除、迷惑メール率0.10%未満が加わります。なお5,000件は同じプライマリドメインからの送信を合算してカウントされるため、配信サービスや通知メールを含めると超えることがあります。実務上は送信量にかかわらず3つとも設定しておくのが安全です。
制作会社に相談するとき、何を伝えれば早く解決しますか？
現象（受信できないのか送信が届かないのか）、いつから起きているか（最後に正常に届いた日時と直前に行った作業）、誰から誰宛に届かないか、エラーメールの全文、社内の何人が該当するかの5点をまとめて渡してください。特にエラーメールの全文には原因を示すコードが含まれているため、これがあるだけで確認の往復が大きく減ります。