会社でGmail(Google Workspace)を使用していると、送信したメールが相手の迷惑メールフォルダに振り分られてしまうケースが少なくありません。特に取引先や顧客への連絡が届いていないと、ビジネスに大きな支障をきたします。原因としては、送信元ドメインの認証設定不足やメール文面の特徴がスパム判定されるパターンが大半です。本記事では、差出人認証(SPF、DKIM、DMARC)の設定確認方法と、文面で注意すべきポイントを具体的に解説します。会社のIT管理者と連携して対策を進めるための手掛かりとしてご活用ください。
【要点】この記事で確認すること
- 最初に見る場所: Gmailの送信済みメールの「原文を表示」で受信側の迷惑メール判定理由を確認する。
- 切り分けの軸: 端末側(送信元のIPや設定)とアカウント側(ドメイン認証レコード)と文面内容(スパムワード・リンク・添付ファイル)の3点で原因を特定する。
- 注意点: 会社のDNS設定やメールサーバの認証レコードはIT管理者に依頼しないと変更できない。勝手に変更すると他のサービスに影響が出る可能性があるため、必ず管理者と相談すること。
ADVERTISEMENT
迷惑メール判定の主な原因:差出人認証と文面
Gmailのスパムフィルタは、送信元の信頼性を評価するために「送信者認証」と「メール内容」の両方をチェックします。認証が通っていないメールは、正当な送信元であっても疑わしいと見なされ迷惑メールに振り分けられることがあります。また、文面に特定のパターンがあると、認証が正しくてもスパム判定される可能性があります。
差出人認証の基本:SPF、DKIM、DMARC
SPF(Sender Policy Framework)は、送信元IPアドレスがドメインのDNSに登録されているかを検証します。DKIM(DomainKeys Identified Mail)は、メールに電子署名を付けて改ざんがないかを確認します。DMARC(Domain-based Message Authentication, Reporting & Conformance)は、SPFとDKIMの認証結果を基に、認証失敗時の処理を指定します。Gmailはこれら3つの認証をすべて推奨しており、特にDMARCポリシーが「none」以外(quarantine または reject)でなければ迷惑メール扱いになるリスクが低減されます。
| 認証方式 | 役割 | 確認ポイント |
|---|---|---|
| SPF | 送信元IPの許可リスト | DNSにTXTレコードとして登録。Google Workspaceの場合は「include:_spf.google.com」を含める |
| DKIM | 電子署名による改ざん防止 | Google Workspace管理コンソールで生成したCNAMEレコードをDNSに追加する |
| DMARC | 認証失敗時のポリシー指定 | DNSにTXTレコードで「v=DMARC1; p=quarantine」などを設定。運用開始はp=noneから |
文面がスパム判定されるパターン
認証が正しくても、以下のような文面の特徴があるとGmailのフィルタに引っかかります。例えば、すべて大文字の件名、過剰な感嘆符、無料・緊急といった単語の多用、受信者名が不明瞭な「様」の使用、HTMLメールで画像が多すぎる、リンクが短縮URLや不自然なドメイン、添付ファイルが実行形式(.exe)などです。また、送信頻度が急に増えた場合や、過去にスパム報告が多いドメインから送信した場合も判定が厳しくなります。
原因を切り分けるための具体的な確認手順
実際にメールが迷惑メールに入ってしまった場合、以下の手順で原因を調査します。自分でできる範囲と管理者に依頼すべき範囲を区別して進めてください。
- 送信済みメールの原文を確認する:Gmailで送信したメールを開き、右上の三点メニューから「原文を表示」を選択します。表示されたヘッダーに「Authentication-Results」の行があり、spf、dkim、dmarcの各認証結果が「pass」か「fail」か確認します。すべてpassになっていれば認証は問題ありません。failがある場合は、管理者にDNS設定を依頼する必要があります。
- 相手側でメールヘッダーを確認してもらう:受信者にメールの原文をコピーしてもらい、同様にAuthentication-Resultsを確認するとともに、スパム判定理由として「X-Gmail-Spam: true」や「X-Google-Smtp-Source:」などの行がないか調べます。これらの情報から具体的なブロック理由が読み取れます。
- 自社ドメインのDNSレコードを確認する:管理者に依頼して、SPF、DKIM、DMARCのTXTレコードが正しく設定されているか確認します。Google Workspaceの場合は、Google管理コンソールの「アプリ」→「Gmail」→「認証」から設定可能です。
- メールの文面を見直す:自分で作成したメールをレビューし、前述のスパム判定要素が含まれていないか確認します。特にリンク先が短縮URLになっていないか、添付ファイルの種類、件名や本文の単語選びに注意します。
- テスト送信を行う:個人のGmailアドレスなど、受信側で確認できるメールアドレスにテストメールを送り、迷惑メールフォルダに入るかどうかをチェックします。複数のパターン(テキストのみ、HTML、画像ありなど)で試すと原因が絞り込みやすいです。
失敗パターンとその対処法
実際に起こりやすい失敗例をいくつか挙げます。これらに当てはまらないか確認してください。
SPFレコードに複数サービスが混在している
会社でGoogle Workspaceと別のメール配信サービス(例えばSalesforceやMailchimp)を併用している場合、SPFレコードに両方を正しく記述しないと、片方の送信がSPF認証に失敗することがあります。SPFレコードは1ドメインにつき1つしか設定できませんので、includeやip4を適切に追加する必要があります。管理者に「include」や「ip4」の記述が重複していないか確認してもらいましょう。
DKIM署名がGoogle Workspace以外で生成されている
自社サーバーや別のSMTPリレー経由でメールを送信している場合、DKIM署名がGoogle管理コンソールで設定したものと異なる可能性があります。この場合、DKIM認証が「fail」となります。対処として、送信経路を統一するか、別途DKIMレコードを追加する必要があります。
DMARCポリシーがp=rejectで運用開始している
DMARCをいきなり「p=reject」に設定すると、認証に失敗した正規メールが相手に届かなくなるリスクがあります。初めは「p=none」で監視し、十分なデータが取れたら「p=quarantine」に上げるのが安全です。管理者がポリシーを急に変更していないか確認しましょう。
文面に「無料」「今すぐ」などのスパムワードが多い
ビジネスメールであっても、キャンペーンや案内のメールで「無料」「限定」「クリック」などの単語が頻出するとスパム判定されます。こうした単語は避けるか、使用頻度を抑える必要があります。
IT管理者に確認・依頼すべきこと
認証設定の変更は一般の社員では実施できないため、以下の項目を適切に管理者へ伝えてください。
- SPFレコードの確認と修正:Google Workspace利用の場合は「v=spf1 include:_spf.google.com ~all」が基本です。他のサービスを利用している場合はそのサービスが提供するSPF情報を追加します。
- DKIMの有効化:Google管理コンソールで「DKIM署名を有効にする」をオンにし、生成されたCNAMEレコードをDNSに追加するよう依頼します。
- DMARCレコードの設定:DNSにDMARCのTXTレコードを追加します。初期は「v=DMARC1; p=none; rua=mailto:admin@example.com」で監視を開始し、問題なければ「p=quarantine」に変更します。
- バウンスメッセージの確認:送信エラーが返ってくる場合、そのメッセージに認証エラーが含まれていることがあります。管理者にバウンス内容を転送して分析を依頼してください。
- Google Postmaster Toolsの利用:自社ドメインのスパム率や認証統計を確認するため、Google Postmaster Toolsに登録してもらうと便利です。管理者にドメイン所有者の確認を依頼してください。
よくある質問(Q&A)
Q1. テスト送信で自分宛てのGmailは迷惑メールに入らないのに、取引先だけ入る場合は?
受信者側のGmailのフィルタ設定や、受信者の過去の迷惑メール報告履歴が影響している可能性があります。また、取引先のメールプロバイダがGmail以外の場合、そちらのスパムフィルタの基準も関係します。原因を特定するには、取引先にメールヘッダーを提供してもらい、認証結果とスパム判定理由を確認してください。
Q2. SPF設定は正しいのに迷惑メールに入るのはなぜ?
SPFがpassでもDKIMやDMARCがfailだとスパム判定になる場合があります。すべての認証をパスさせることが理想的です。また、文面や送信傾向が問題である可能性も高いです。Google Postmaster Toolsでスパム率が高い場合は、文面の改善や送信量の調整が必要です。
Q3. 送信元名(Fromアドレス)が自社ドメインでも、認証が失敗するのはなぜ?
送信元が自社ドメインであっても、実際の送信サーバーがそのドメインのSPFで許可されていないIPの場合、SPF認証がfailになります。例えば、別のメール配信システムから自社ドメインをFromに指定して送信している場合などです。この場合、送信システムのIPをSPFに追加するか、DKIM署名を適切に行う必要があります。
Q4. 迷惑メールに入ったメールを、受信者に「迷惑メールではない」と報告してもらうには?
受信者がGmailの場合、迷惑メールフォルダからメールを選択し、「迷惑メールではない」ボタンをクリックすることで、今後の送信元の評価が改善されます。ただし、これはそのユーザー個人のフィルタに影響するだけで、グローバルな改善にはなりません。根本的には認証設定と文面改善が必要です。
まとめ
メールが相手の迷惑メールに入る原因は、差出人認証の不備とメール文面のスパム要素の2つに大別されます。まずは送信メールの原文を確認して認証結果を調べ、SPF・DKIM・DMARCの設定をIT管理者に依頼して整備してください。同時に、自身のメール文面を見直し、スパム判定されやすい表現を避けることも重要です。Google Workspaceの管理画面で認証状態を確認し、Google Postmaster Toolsでドメインの健全性をモニタリングすると、問題の早期発見につながります。これらの対策を組み合わせることで、ビジネスメールの到達率を大幅に改善できます。
ADVERTISEMENT
超解決 第一編集部
疑問解決ポータル「超解決」の編集チーム。正確な検証と、現場視点での伝わりやすい解説を心がけています。
Gmail・Googleアカウントの人気記事ランキング
- 【Googleアカウント】本人確認が必要ですと出る時の端末と場所の確認
- 【Gmail】Googleからの本物のセキュリティ通知か見分ける方法
- 【Googleアカウント】パスワードを忘れた時の再設定と注意点
- 【Googleアカウント】Google Playだけログインできない時のアカウント確認
- 【Gmail】なりすましメールを見分けたい時の送信元と認証情報確認
- 【Googleアカウント】確認コードが届かない時の電話番号とメール確認
- 【Googleアカウント】スマホを機種変更した後に認証できない時の確認
- 【Googleアカウント】パスキーでログインできない時の代替ログイン手順
- 【Googleアカウント】共有PCにログイン情報を残した時の削除手順
- 【Gmail】配信不能通知が返る時の宛先入力とドメイン確認
