独自ドメインのメールが届かない原因は？送信・受信を切り分けて確認する

独自ドメインのメールが届かないとき、原因は、いくつもの層に散らばっています。DNSの設定、送信元の認証、受信側の判定、DNSの反映状況。どこで止まっているかを特定しないまま設定を触ると直っていたはずの部分まで壊してしまうことがあります。

この記事ではまず自分の状況を切り分け、そのうえで原因ごとの確認方法と直し方を示します。

まず切り分ける — どの向きで届かないのか

「届かない」という一言には、まったく別の問題が3つ含まれています。最初にこれを分けないと関係のない設定を調べ続けることになります。

1. 独自ドメインから送ったメールが相手に届かない

info@example.jp から送ったメールが、Gmailなどの相手にまったく届かない状態です。確認する対象は、送信元の認証設定（SPF・DKIM・DMARC）で、この記事が主に扱うのはこちらです。

届いてはいるが、迷惑メールフォルダに入る、という場合は、原因の範囲が変わります。認証設定に加えて、送信元の評価や本文の内容も関係するためです。そちらは、独自ドメインのメールが迷惑メールに入る原因は？で扱っています。

2. 相手から送られたメールが独自ドメインに届かない

info@example.jp 宛のメールが受け取れない状態です。原因は、受信側にあり、MXレコードの設定やメールボックスの容量が関係します。認証設定とは別の問題なので、受信できない場合を先に確認してください。

3. Gmailで独自ドメインのメールをPOP受信している

Gmailの「他のアカウントのメールを確認する」機能（POP受信）は、2027年1月に終了します。新規の設定は、すでにできません。Gmailから独自ドメインのアドレスを差出人にして送信する「他のアカウントとして送信」も同じ時期に終了します。終了そのものは、設定の誤りではないため、認証設定を調べても解決しません。

終了する機能と時期・終わらない機能・自分が対象かどうかの確認方法は、Gmail POP受信終了はいつ？にGoogle公式の原文とあわせてまとめています。

2027年1月より前に受け取れなくなった場合は、この終了が原因ではありません。別の原因があるので、上の 2 を確認してください。

代替手段として、次の2つがあります。いずれも無料で使えます。

• サーバー側でGmailへの自動転送を設定する
• Gmailモバイルアプリに他のアカウントを追加する

設定の手順と選び方は、Gmail POP受信終了の代替方法にまとめています。転送では送信機能を代替できないので、送信も使っている場合は、そちらで選択肢を確認してください。

終了までに同期済みのメールは、Gmailに残ります。この記事の範囲外です。

以降は、1 の「送ったメールが届かない」を扱います。

設定を触る前に3つ確認する

DNSを変更する前に確認すべきことがあります。ここで判明すれば設定を触る必要がありません。

相手の迷惑メールフォルダを見てもらう

届いていないのか、迷惑メールフォルダに入っているのかで原因が変わります。前者は、受信拒否、後者は、評価の問題です。「届かない」と言われた時点ではまだどちらか分かりません。

エラーメール（バウンスメール）が返っていないか確認する

送信に失敗すると理由を含むエラーメールが返ります。550-5.7.26 のようなコードが書かれていればそれが原因を直接示しています。件名に「Undelivered Mail Returned to Sender」「Mail delivery failed」などが含まれるメールを探してください。

550-5.7.26 が返っている場合、同じコードでも一緒に書かれている英文によって、原因が3つに分かれます。どれに当たるかの見分け方と直し方は、Gmailの550-5.7.26で拒否されるときの直し方で扱っています。

返ってきたエラーメールは、バウンスメール解析に貼り付けるとコードの意味が分かります。自分のDNS設定で直せるものか宛先側の事情かも分けて表示します。貼り付けた内容は、ブラウザの中だけで処理され、送信されません。

エラーメールが返っておらず、相手の迷惑メールフォルダにもない場合は、送信自体が行われていない可能性があります。送信元の設定を確認してください。

特定の相手だけか、全員かを確認する

Gmail宛だけ届かないのであれば送信元の認証設定、すべての宛先に届かないのであればサーバーやドメイン自体の問題を疑います。1社だけであれば相手側の受信設定である可能性もあります。

Googleが求めている認証は送信量によって変わる

ここは、誤解が広がっている部分です。「SPFとDKIMとDMARCをすべて設定しないとGmailに届かない」と書かれている解説を見かけますが、Googleのメール送信者のガイドラインが必須としている内容は、送信量で分かれています。

この要件は、2024年2月1日以降に適用されています。個人や小規模事業者の通常の利用であればまずSPFかDKIMのどちらかが正しく設定されていることが出発点になります。

DMARCが未設定の状態で何ができないのかは、DMARCを設定していないリスクと最初に置く設定で説明しています。

ただし、注意が必要です。これは、最低要件であって、受信トレイに届くことの保証ではありません。 認証を満たしていても送信元IPの評価・過去の迷惑メール報告率・本文の内容などによって、迷惑メール判定されることがあります。認証は、「土台が整っているか」であり、それだけで到達が決まるわけではありません。

自分のドメインの現状を確認する

原因の候補を1つずつ手作業で調べるより現在の設定状態をまとめて確認したほうが早く進みます。ドメイン名を入力するとSPF・DKIM・DMARC・MX・DNSの反映状況を確認できます。

ドメインの設定を診断する

確認できる内容は、次のとおりです。

• SPFレコードの有無とDNS参照回数が上限を超えていないか
• DKIMの公開鍵が公開されているか。セレクタ名が分からない場合も利用中のメールサービスから推定を試みます
• DMARCのポリシーとレポートの送信先が正しく届く設定になっているか
• MXレコードのホスト名が実際に解決できるか（解決できないと出たときの直し方はMXの参照先が解決できない原因と直し方）
• ネームサーバーに設定した内容が外から見える状態になっているか

以降は、確認結果ごとの対処を説明します。

SPFレコードが設定されていない

SPFは、「このドメインのメールは、どのサーバーから送られるか」をDNSに公開する仕組みです。受信側は、これを見て送信元が正規かどうかを判断します。

未設定の場合、受信側は、正規のメールか判断できません。迷惑メール判定されやすくなるほか、第三者があなたのドメインを名乗ってメールを送れる状態になります。

設定は、TXTレコードとして、追加します。値は、利用しているメールサービスによって、変わります。

レンタルサーバーのメール機能を使っている場合、指定される値は、契約しているサーバーごとに異なります。サーバーの管理画面かマニュアルに記載されている値を確認してください。推測で書くと正規のメールが送れなくなります。

Google Workspaceを使っている場合の例です。

v=spf1 include:_spf.google.com ~all

末尾の ~all は、「記載外の送信元は、疑わしい」という、指定です。-all にすると記載外を明確に拒否しますが、洗い出せていない送信元があるとそこからのメールが即座に届かなくなります。まず ~all で運用し、漏れがないことを確認してから -all に変更するのが安全です。この2つの違いや +all を選んではいけない理由はSPFレコードのall修飾子の違いで扱っています。

SPFがPermErrorになっている

SPFレコードはあるのに認証が失敗している場合、その原因の1つがPermErrorです。SPFの評価中にDNS参照を起こす機構と修飾子は、合計10個までと定められており（RFC 7208 セクション4.6.4）、これを超えると受信側は、SPFの評価を打ち切り、結果はpermerrorになります。

見落としやすいのはこの10回がレコードに書かれた行数ではなく、評価時に発生するDNS参照の回数だという点です。include の中でさらに include が使われていればその分も加算されます。自分では何も変更していないのに突然届かなくなった場合、参照先のサービスが内部構成を変えて参照回数が増えた可能性があります。

数え方の詳細、どの項が回数を消費するか、安全な直し方は、SPFのDNS参照回数が10回を超える原因と直し方で扱っています。

DKIMが設定されていない、またはセレクタが分からない

DKIMは、ドメイン名をメールに結び付けて責任を主張し、それを電子署名で検証できるようにする仕組みです（RFC 6376 セクション1）。SPFと違って署名は、メールに付いたまま運ばれるため、転送された先でも検証できることが多くなります（RFC 9989 セクション7.4は、「DKIM signatures will generally remain valid in these relay situations」と書いています。generallyであって常にではなく、署名の対象になっている部分が途中で書き換われば検証は通らなくなります）。

DKIMの設定は、メールサービスの管理画面で行い、発行された公開鍵をDNSに登録します。登録先は、セレクタ名._domainkey.ドメイン名 という形式です。SPFは、設定済みでDKIMだけが無い状態を直すべきかどうかは、送り方によって、変わります。判断は、SPFだけで足りるのかにまとめてあります。

ここで知っておきたいのはセレクタ名は、自由に決められるため、よく使われる名前を試して見つからないことが、未設定の証明にはならないという、点です。日付を使ったセレクタ名を採用しているサービスもあります。

自分のドメインのセレクタを調べる手順、サービス別の確認済みセレクタ、見つからないときの対処は、DKIMセレクタの確認方法で扱っています。

DMARCのポリシーが強すぎる

DMARCは、SPFやDKIMの認証に失敗したメールを受信側にどう扱わせるかを指示する仕組みです。p=reject を設定していると認証に失敗したメールは、受信側で拒否されます。

ここで理解しておきたいのはDMARCが要求するのはSPFとDKIMの両方ではなく、どちらか一方が通ることだという点です。正確には Fromアドレスのドメインと整合した形でSPFまたはDKIMが成功していればDMARCは、通ります。

問題が起きやすいのは次の場合です。

• SPFもDKIMも整えないまま p=reject を設定した。すべてのメールが拒否されます
• 送信元を追加したが、SPFに追加し忘れた。その送信元からのメールだけが拒否されます

段階的に強めるのが安全です。

v=DMARC1; p=none; rua=mailto:dmarc@example.jp

p=none は、監視のみで、受信側の扱いを変えません。ただし、レポートは、届くため、どの送信元が認証に失敗しているかを把握できます。正規の送信元すべてが認証を通るようになってから quarantine、次に reject へ上げます。

レポートの送信先を別のドメインにする場合は、注意が必要です。組織ドメインが異なる宛先は、受け取る側のドメインに認可レコードがないと無視され、そこへはレポートが送られません（RFC 9990 セクション4）。設定する値と実際にどれくらいのドメインで欠けているかは、DMARCレポートが届かない原因で扱っています。

設定したのに反映されていない

DNSを正しく設定したのに確認ツールで「未設定」と表示されることがあります。設定が間違っているのではなく、まだ行き渡っていない状態です。

DNSの問い合わせは、あなたのネームサーバーへ毎回届くわけではありません。設定を追加する前に問い合わせが行われていると「存在しない」という答えが一定時間記憶され、その記憶が消えるまで新しい設定は、見えません。

反映されないからといって設定を何度も変更しないでください。 正しい値を上書きしてしまい、原因の切り分けが難しくなります。ネームサーバー上の値と外から見える値を分けて確認すれば待てば済む状態なのかどうかが分かります。

確認の手順と待つ以外にすることがない場合の見分け方は、DNSが反映されないときの確認方法で扱っています。

反映されていないと感じたとき、もう1つ確認すべきことがあります。設定した画面が実際に使われているネームサーバーのものかどうかです。お名前.comでドメインを取得し、エックスサーバーで運用している場合、DNSの実体がどちらにあるかは、設定によって、変わります。ネームサーバーがサーバー会社のものになっているのにドメイン取得業者側の画面でレコードを追加しても効果はありません。

メールを転送している場合

独自ドメインのメールをGmailに転送している場合、転送によって、SPFの認証が失敗します。転送元のサーバーから送られる形になるため、元の送信者のSPFレコードに転送サーバーが含まれていないためです。

これは、SPFの仕組み上の制約で、設定の誤りではありません。対処としては、次があります。

• DKIMを設定する。署名は、メールに付いたまま運ばれるため、転送された先でもDMARCの判定に使える経路が残ります。ただし途中で本文が書き換えられると署名は、成立しません。判断の材料は、SPFだけで足りるのかにあります
• 転送ではなく、Gmail側から直接受信する方式に変更する
• 転送先で迷惑メール判定されたものをフィルタで受信トレイに入れる設定にする

受信できない場合はMXレコードと容量を見る

冒頭の切り分けで「相手から送られたメールが届かない」に該当した場合、確認する場所が変わります。SPFやDKIMは、送信側の仕組みなので、受信できない問題には関係しません。

• MXレコードが設定されているか。ホスト名が実際に解決できるか
• 解決できる場合でもそのホスト名がCNAMEになっていないか。解決できることと正しいことは別です（MXの参照先がCNAMEではいけない理由）
• MXレコードがIPアドレスを直接指していないか。ホスト名である必要があります
• 本数と優先度が利用中のメールサービスの案内どおりか。1本だけという状態も同じ数字が並んだ状態も、それ自体は問題ではありません（MXレコードの優先度と本数）
• メールボックスの容量が上限に達していないか
• サーバー側の受信フィルタで拒否していないか

MXレコードが設定されていない場合、送信側は、AレコードのIPアドレス宛に配送を試みます。Webサーバーがメールを受け取れなければ、そこで失敗します。

なお、そのドメインでメールを使わない場合は、受け取らないことをDNSで明示する方法が定められています。ほかのMXレコードを置かず、優先度0でホスト名を . としたMXレコード（Null MX、RFC 7505 セクション3）だけを設定するとそのドメイン宛の配送の試みをすぐに失敗させられます（同 セクション1）。設定してよいドメインの見分け方と設定値は、Null MXとは？で説明しています。

修正したら、反映を確認する

DNSを変更したあと、実際に反映されたかを確認してください。設定画面で保存できたことは、外から見えることを保証しません。事業者によっては、追加ボタンを押しただけでは保存されず、確認画面まで進む必要があります。設定画面で保存できたことは、外から見えることを保証しません。

修正後の反映状況を確認する

反映を待っている状態と設定が入っていない状態は、区別して表示されます。前者であれば設定を触る必要は、ありません。

それでも解決しない場合

認証設定を整えても改善しない場合、次の可能性があります。

• 送信元IPアドレスの評価が低い。共用サーバーでは、同じIPを使う他の利用者の影響を受けることがあります。サーバー会社に相談してください
• ドメインまたはIPがブラックリストに登録されている。これは、認証設定とは別の問題です。認証を整えたうえで確認してください
• 相手側の受信設定で拒否されている。1社だけ届かない場合は、この可能性があります。相手の管理者に確認してもらってください
• 過去に大量の迷惑メール報告を受けている。改善には時間がかかります

いずれの場合もまず認証設定が正しいことを確認してから次に進んでください。土台が整っていない状態で評価の問題を追っても切り分けができません。