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

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

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

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

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

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

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

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

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

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

3. Gmailで独自ドメインのメールを受信していたが、できなくなった

Gmailの「他のアカウントのメールを確認する」機能でPOP受信していた場合、この機能自体が終了しています。設定の誤りではないため、サーバー側でGmailへの転送を設定するなどの対応が必要です。この記事の範囲外です。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

末尾の ~all は「記載外の送信元は疑わしい」という指定です。-all にすると記載外を明確に拒否しますが、洗い出せていない送信元があると、そこからのメールが即座に届かなくなります。まず ~all で運用し、漏れがないことを確認してから -all に変更するのが安全です。

SPFがPermErrorになっている

SPFレコードはあるのに認証が失敗している場合、その原因の1つがPermErrorです。SPFの評価中に許されるDNS参照は10回までと定められており（RFC 7208 §4.6.4）、これを超えると受信側はSPFの評価を打ち切り、認証は失敗した扱いになります。

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

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

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

DKIMはメールに電子署名を付け、改ざんされていないことと送信元を証明する仕組みです。SPFと違って転送されても認証が維持されるため、メーリングリストや転送を経由する場合に効果があります。

DKIMの設定はメールサービスの管理画面で行い、発行された公開鍵をDNSに登録します。登録先は セレクタ名._domainkey.ドメイン名 という形式です。

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

自分のドメインのセレクタを調べる手順、サービス別の確認済みセレクタ、見つからないときの対処は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 7489 §7.1）。DMARC監視サービスを契約したのにレポートが届かないときは、この認可レコードが設定されているかを確認してください。

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

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

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

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

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

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

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

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

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

• DKIMを設定する。DKIMは転送されても署名が維持されるため、DMARCの判定を通せます
• 転送ではなく、Gmail側から直接受信する方式に変更する
• 転送先で迷惑メール判定されたものを、フィルタで受信トレイに入れる設定にする

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

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

• MXレコードが設定されているか。ホスト名が実際に解決できるか
• 解決できる場合でも、そのホスト名がCNAMEになっていないか。解決できることと正しいことは別です（MXの参照先がCNAMEではいけない理由）
• MXレコードがIPアドレスを直接指していないか。ホスト名である必要があります
• メールボックスの容量が上限に達していないか
• サーバー側の受信フィルタで拒否していないか

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

なお、そのドメインでメールを使わない場合は、受け取らないことをDNSで明示するのが推奨されています。優先度0でホスト名を . としたMXレコード（Null MX、RFC 7505）を設定すると、送信側がすぐに配送不能と判断できます。設定してよいドメインの見分け方と設定値はNull MXとは？で説明しています。

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

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

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

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

それでも解決しない場合

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

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

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