【Gmail】会社ドメインのメールだけ受信できない時の管理者側確認項目

会社でGmailを利用している際に、特定の会社ドメインから送られたメールだけが受信できないというトラブルは、業務に大きな支障をきたします。送信元ドメインからのメールが届かない原因は、受信側の設定だけでなく、送信側のDNSレコードやメール認証の設定、さらにはGmailのフィルタや会社のネットワーク環境など多岐にわたります。本記事では、管理者が確認すべき項目を体系的に整理し、実際のトラブル事例や失敗パターンを交えながら、原因を特定する手順を詳しく解説します。この記事を読めば、メールが届かない問題に対して、どのレイヤーを確認すればよいかが明確になり、迅速な解決に役立てていただけます。

送信元ドメインのDNSレコード設定の確認

会社ドメインからのメールが受信できない場合、まず送信元ドメイン(メールを送っている側のドメイン)のDNSレコードに問題がないかを確認します。Gmailは厳格なメール認証ポリシーを採用しており、SPF、DKIM、DMARCのいずれかが正しく設定されていないと、メールが拒否されたり迷惑メールフォルダに振り分けられたりします。特に、送信元ドメインの管理者が自社ドメインのDNS設定を変更した直後や、メールサーバを移行したタイミングで発生しやすいトラブルです。

SPFレコードの確認手順

SPF(Sender Policy Framework)は、そのドメインからメールを送信してもよいサーバのIPアドレスを指定するレコードです。Gmail側でSPFチェックに失敗すると、メールがリジェクトされる原因になります。確認手順は以下の通りです。

1. ターミナルやコマンドプロンプトを開き、nslookup -type=txt 送信元ドメイン名を実行します。
2. 出力結果の中から、v=spf1で始まる文字列を探します。例:v=spf1 include:_spf.google.com ~all
3. SPFレコードに、送信元メールサーバのIPアドレスまたはinclude対象が記載されていることを確認します。
4. 末尾のメカニズムが-all(ハードフェイル)の場合、リスト外からの送信は厳格に拒否されます。~all(ソフトフェイル)の場合は受信されることもありますが、Gmailは~allでもスパム扱いにすることがあるため注意が必要です。
5. include:で他のドメインを参照している場合は、その先のレコードも同様に確認します。
6. SPFレコードが複数存在しないか(複数あるとエラーになる)、文字数が255文字を超えていないか(超過はDNSエラー)も併せてチェックします。

よくある失敗パターンとして、SPFレコードに自社のメールサーバのIPアドレスが含まれていないケースや、複数のSPFレコードが存在するケースがあります。また、クラウドサービス(例:Salesforce、SendGridなど)を利用している場合は、それらのサービスが正しくincludeされているかも確認する必要があります。

DKIM署名の確認

DKIM(DomainKeys Identified Mail)は、送信メールに電子署名を付与し、改ざんがないことを証明する仕組みです。GmailはDKIM署名がないメールや、署名が検証できないメールに対してペナルティを与えることがあります。確認手順としては、送信元ドメインのDNSにDKIMの公開鍵レコード(通常はselector._domainkeyという形式)が存在するかどうかをnslookup -type=txt selector._domainkey.送信元ドメインで確認します。また、実際に届かないメールのヘッダを入手して、Authentication-Resultsフィールドにdkim=passと表示されているか確認する方法も有効です。DKIMのselectorは、送信側のメールサーバ設定で指定された値であり、管理者がその値を把握していないと確認が難しくなります。トラブルが発生した場合、送信元ドメインの管理者にselector名を問い合わせてください。

DMARCポリシーの確認

DMARC(Domain-based Message Authentication, Reporting & Conformance)は、SPFとDKIMの結果に基づいて、ドメイン所有者が受信側にどのように対処するかを指示する仕組みです。DMARCレコードがp=rejectに設定されている場合、SPFやDKIMの認証に失敗したメールはGmailに受信されることなく完全に拒否されます。p=quarantineの場合は迷惑メールフォルダに格納される可能性が高くなります。p=noneの場合は監視のみで拒否はされません。Gmailで特定のドメインからのメールだけ受信できない場合、送信元ドメインのDMARCポリシーがp=rejectになっており、かつSPFやDKIMが適切にパスしていない可能性が高いです。DMARCレコードは_dmarc.送信元ドメインで確認します。

認証方式	確認場所	エラーの際の症状
SPF	送信元ドメインのTXTレコード	Gmailで「SPF check failed」として拒否、または迷惑メール
DKIM	selector._domainkey.送信元ドメインのTXTレコード	ヘッダにdkim=fail、Gmailが署名検証エラー
DMARC	_dmarc.送信元ドメインのTXTレコード	ポリシーがrejectの場合、SPF/DKIM失敗で完全拒否

Gmail側の受信設定とフィルタの確認

送信元ドメインの設定に問題がない場合は、受信側であるGmailの設定を確認します。Gmailには組織全体のポリシー(管理コンソール)と、ユーザー個人のフィルタ設定の2種類があります。管理者はまず管理コンソール側を確認し、次にエンドユーザーの設定も確認する必要があります。

管理コンソールのメールログ検索

Gmail管理コンソール(admin.google.com)の「メールログ検索」機能を使うと、特定のメールがどのように処理されたかを詳細に確認できます。管理者は、送信元ドメイン、送信者アドレス、受信者アドレスなどを指定して検索し、メールが「配信された」「拒否された」「迷惑メールとして分類された」などのステータスを確認します。拒否された場合、その理由(例えばSPF_FAILやDKIM_FAIL、DMARC_REJECT)が表示されるため、原因を特定できます。また、メールが「検疫」に送られた場合も同様に理由が表示されます。このログは、メールがシステムによってどのルールにマッチしたかを把握するのに非常に役立ちます。

コンテンツコンプライアンスルールの確認

Gmail管理コンソールの「コンプライアンス」→「コンテンツコンプライアンス」で設定されたルールが、特定のドメインからのメールをブロックしていないかを確認します。たとえば、添付ファイルの種類やキーワードでフィルタリングするルールが誤って適用されていると、該当のメールだけが拒否されることがあります。また、「送信者アドレスが特定ドメインと一致する場合に拒否する」といったルールが設定されていないかも確認してください。このルールは誤設定によるトラブルの原因となるため、過去に変更した履歴も合わせて確認することをおすすめします。

ユーザー個人のフィルタと迷惑メール設定

ユーザー自身がGmailの設定でフィルタを作成していたり、特定のアドレスをブロックリストに追加している可能性もあります。管理者は、該当ユーザーのGmail設定を直接確認するか、ユーザーに確認を依頼してください。特に、過去に迷惑メールとして報告したドメインが自動的にブロックされることはありませんが、手動でフィルタを作成した場合は影響します。また、Gmailの「迷惑メール」タブに振り分けられている場合は、ユーザーが「迷惑メールではない」と報告することで学習が進みますが、根本的な原因は別にあることが多いです。

ネットワークやプロキシ、セキュリティ機器の影響

会社のネットワーク環境が原因で、特定のドメインからのメールだけ受信できないケースもあります。プロキシサーバやUTM(統合脅威管理)機器が、特定の送信元IPアドレスやメールの内容をブロックしている可能性があります。また、会社が利用しているクラウドメールセキュリティサービス(例:Proofpoint、Mimecastなど)が、送信元ドメインを一時的にブロックしていることも考えられます。これらのサービスは、送信元の評判や送信量に基づいて動的にブロックリストを更新するため、突然トラブルが発生することがあります。

確認手順と切り分け方法

まず、同じGmailアカウントでも、社内ネットワーク経由と社外(スマホの4Gなど)で受信状況が異なるかどうかを確認します。社外では受信できるのに社内では受信できない場合、ネットワーク機器やセキュリティサービスが問題です。逆に、社内外ともに受信できない場合は、Gmail側または送信元ドメイン側の問題である可能性が高いです。また、他の社員も同じドメインからのメールを受信できていないかどうかを確認することで、問題の影響範囲を把握できます。影響範囲が一部のユーザーのみであれば、ユーザー個人の設定やクライアント環境が原因かもしれません。

セキュリティ機器のログ確認

会社でメールゲートウェイやプロキシを利用している場合、それらのログを確認して、特定の送信元IPアドレスからの接続が拒否されていないか調べます。また、TLS接続の要件が厳しく設定されていると、暗号化に対応していないメールサーバからのメールが拒否されることがあります。送信元のメールサーバがTLS 1.0など古いプロトコルしかサポートしていない場合、Gmail側もしくは中間機器でブロックされる可能性があります。これらの情報は、ネットワーク管理者やセキュリティチームに問い合わせて確認する必要があります。

トラブル事例と解決ステップ

ここでは、実際に発生しやすいトラブル事例を挙げ、解決までのステップを紹介します。

事例1:SPFレコードのinclude先が存在しない

ある会社で、取引先のドメインexample.comからのメールが届かなくなりました。調査の結果、example.comのSPFレコードにinclude:spf.example.netと記述されていましたが、spf.example.netのDNSレコードが削除されていました。そのため、SPFチェックがエラーとなり、DMARCポリシーがp=rejectだったため、Gmailがメールを完全拒否していました。解決策として、example.comの管理者にSPFレコードの修正を依頼し、正しいinclude先を設定してもらいました。

事例2:Gmail管理コンソールで「送信者認証チェック」が厳格に設定されていた

別のケースでは、Gmail管理コンソールの「メールの配信」→「送信者認証チェック」で、SPF、DKIM、DMARCのすべてを必須とする設定が有効になっていました。ところが、送信元ドメインのDKIM署名が一時的に失効していたため、メールがすべて拒否されました。この設定は組織全体に適用されるため、管理者は設定を緩和するか、該当ドメインを許可リストに追加することで対処しました。

よくある質問

Q. 送信元ドメインのSPFレコードに問題があると、Gmailはどのようにエラーを表示しますか?
A. Gmail管理コンソールのメールログ検索で、拒否理由としてSPF_FAILやDMARC_REJECTが表示されます。また、メールヘッダのAuthentication-Resultsフィールドにも同様の情報が記録されます。

Q. 送信元が大手のサービス(Google WorkspaceやMicrosoft 365)の場合でも、同様の確認が必要ですか?
A. はい、必要です。大手サービスであっても、送信元管理者がDNS設定を誤っている場合や、DMARCポリシーを変更した場合に影響が出ることがあります。ただし、多くの場合、サービス側で適切に設定されているため、まずは送信元ドメインのDNSレコードを確認することをおすすめします。

Q. 会社のGmailで特定のドメインからのメールだけが迷惑メールフォルダに入ってしまいます。どのように対処すればよいですか?
A. まず、そのメールがなぜ迷惑メールと判定されたのかをGmail管理コンソールのメールログで確認します。SPFやDKIMの認証に失敗している場合は、送信元ドメインの管理者に連絡して設定を修正してもらう必要があります。認証が通っているのに迷惑メール扱いされる場合は、Gmailのフィルタ学習が影響している可能性があるため、ユーザーが「迷惑メールではない」と報告することで徐々に改善します。

まとめ

会社ドメインのメールだけ受信できない問題は、原因の切り分けが重要です。まずは送信元ドメインのSPF、DKIM、DMARCレコードを確認し、次にGmail管理コンソールのメールログ検索で実際の処理状況を調べます。ネットワーク機器やセキュリティサービスが影響している可能性も考慮し、社内外での受信差異を確認することで原因を絞り込めます。管理者が一貫した手順で確認することで、迅速な解決が可能になります。適切な設定と定期的な監視により、再発を防止することができるでしょう。

✉️

Gmail・Googleアカウントトラブル完全解決データベース 送受信エラー/迷惑メール対策/容量整理/ラベル・自動振り分け/アカウント復旧/2段階認証/スマホ同期/転送・複数アカウントのトラブルを即解消。GmailとGoogleアカウントの実務リファレンスとしてご活用ください。