「お問い合わせの返信を送ったのに届いていないと言われた」「営業メールがGmail宛だけ全部迷惑フォルダに入っていた」。こうした相談がここ1〜2年で急増しています。原因のほぼすべては、SPF・DKIM・DMARCと呼ばれる送信ドメイン認証の設定不備です。2024年2月にGoogleが「メール送信者のガイドライン」を強化して以降、この3点が設定されていないドメインからのメールは、Gmailで容赦なく迷惑メール扱いされるようになりました。この記事では、迷惑メール扱いされる原因と、SPF・DKIM・DMARCの設定手順を、運用保守の現場視点で解説します。
Gmailで迷惑メール扱いされる原因の8割は送信ドメイン認証の不備
自社ドメインから送ったメールがGmailで迷惑メール扱いされる場合、原因の大半は送信ドメイン認証（SPF・DKIM・DMARC）の設定不備です。本文の中身や送信頻度ではなく、「そもそも送信元として信頼されていない」という根本的な問題が起きています。
2024年2月からGmailはSPF・DKIMの設定を事実上必須化した
Googleは2024年2月以降、Gmailアカウント宛にメールを送るすべての送信者に対して、SPFまたはDKIMのいずれかの設定を必須としました。さらに、なりすましを防ぐための認証強化が要件に組み込まれています（出典 Google Workspace ヘルプ メール送信者のガイドライン）。
このガイドライン改定以前は、SPF・DKIMが未設定でもGmailに届くことが多くありました。しかし2024年以降は、未設定のドメインから送られたメールは、エラーで弾かれるか、迷惑メールフォルダに自動振り分けされる確率が大幅に上がっています。弊社が引き継いだ中小企業のサイトを調査すると、独自ドメインメール運用の約7割でSPF・DKIMのいずれかが未設定でした。（つまり、相手のGmailに「会社からのメールが届かない」状態が常態化しています）
1日5,000通以上の送信者はDMARCまで必須になった
同じGmailのガイドラインでは、Gmailアカウント宛に1日5,000通以上送信する「大量送信者」に対して、DMARCの設定を必須にしました。中小企業の通常業務では1日5,000通に達することは稀ですが、メルマガ配信・予約通知・ECサイトの自動メールなどを運用している場合は容易に超えます。MAツールを導入しているBtoB企業も、配信件数の上限を超えてDMARC必須対象になるケースが増えています。
大量送信者でなくても、DMARCを設定しているドメインのほうが受信側の信頼度評価が高くなります。「うちは小規模だからDMARCは不要」と判断するのは、現在の運用実態に合っていません。SPF・DKIMを設定したら、DMARCもセットで入れるのが2026年時点の標準です。
認証以外の原因（IPレピュテーション・本文・件名）は2割程度
認証3点を設定しても迷惑メール扱いされる場合は、別の要因を疑う必要があります。代表的なのが、共用サーバーのIPアドレスが過去に大量送信に使われて評価が落ちているケース、本文中のURLや画像が多すぎてスパム判定されるケース、件名に強調記号や英数字の羅列が含まれるケースです。ただし、これらは認証が正しく設定された前提の話です。SPF・DKIM・DMARCを整える前に本文や件名を疑っても、原因の特定は進みません。
「メールが届かない」と相談を受けたとき、最初に確認すべきはSPF・DKIM・DMARCの設定状況です。本文の表現や送信タイミングを変えても、認証が通っていなければ根本解決にはなりません。
SPFは「このIPアドレスからの送信を許可する」宣言
SPF（Sender Policy Framework）は、自社ドメインからメールを送るサーバーのIPアドレスを、DNSレコードに登録する仕組みです。受信側は、メールヘッダーの送信元IPと、ドメインに登録されたSPFレコードを照合し、一致しなければ「なりすまし」と判定します。
SPFレコードが設定されているかを確認する手順
SPFの設定状況は、無料の確認ツールで簡単にチェックできます。総務省と業界団体が運営する迷惑メール対策推進協議会では、送信ドメイン認証技術の解説と確認手順を公開しています（出典 迷惑メール対策推進協議会 送信ドメイン認証技術）。
確認方法はシンプルです。コマンドプロンプトまたはターミナルで以下を実行します。
- Windowsの場合 nslookup -type=txt 自社ドメイン
- Macの場合 dig txt 自社ドメイン
- 結果に「v=spf1 〜」で始まる行があればSPF設定済み
「v=spf1」で始まる行が表示されない場合、SPFは未設定です。レンタルサーバーの管理画面から「SPFレコード設定」のメニューを開き、有効化してください。エックスサーバー、さくらインターネット、ConoHa WINGなど主要な国内レンタルサーバーは、ボタン1つでSPFを有効化できる機能を提供しています。
SPFでよくある設定ミスと対処（複数レコード重複・include漏れ）
SPFは設定したつもりでも、書き方を間違えると無効になります。実務でよく見かけるのが以下のパターンです。
| ミスのパターン | 具体的な内容と影響 |
|---|---|
| SPFレコードが複数存在 | 1ドメインにSPFレコードを複数行登録すると、すべて無効と判定される |
| include漏れ | Google Workspace、Microsoft 365などを併用しているのに、SPFにincludeを書き忘れる |
| ~all を +all にしている | 「すべて許可」になり、なりすまし対策として機能しなくなる |
| 10回以上のlookup | SPFはincludeの参照を10回までしか許可されず、超えると失敗扱いになる |
特に注意したいのが、メール配信サービスやMAツールを導入したときに新しいincludeを追加した結果、lookup回数が10回を超えてSPFが機能しなくなるパターンです。「ある日突然メールが届かなくなった」という相談の多くがこのケースに該当します。SPFレコードを変更したら、必ず確認ツールで通っているかを再チェックしてください。
DKIMは電子署名で「なりすましでない」ことを証明する仕組み
DKIM（DomainKeys Identified Mail）は、送信側が秘密鍵でメールに電子署名を付け、受信側がDNSに公開された公開鍵で署名を検証する仕組みです。SPFが「送信元IP」を確認するのに対し、DKIMは「メール本文が改ざんされていないか」「本当にそのドメインが送ったか」を検証します。
DKIM署名の有無をGmailの「メッセージのソースを表示」で確認する
受信したメールのDKIMが通っているかは、Gmailで簡単に確認できます。受信メールを開き、右上の「︙」メニューから「メッセージのソースを表示」を選択すると、ヘッダーに「Authentication-Results」という行があります。ここに「dkim=pass」と書かれていれば成功、「dkim=fail」または「dkim=none」なら失敗または未設定です。
同じヘッダーで「spf=pass」「dmarc=pass」もあわせて確認できます。3つすべてが「pass」になっていれば、認証は問題ありません。1つでも「fail」「none」がある場合は、その項目の設定を見直す必要があります。
レンタルサーバー別DKIM設定の有効化手順
DKIMはサーバー側で秘密鍵を生成し、対応する公開鍵をDNSに登録する必要があります。手動で設定するには技術知識が必要ですが、主要なレンタルサーバーは管理画面でワンクリック設定できる機能を提供しています。
| レンタルサーバー | DKIM設定の有効化方法 |
|---|---|
| エックスサーバー | サーバーパネルの「DKIM設定」から対象ドメインを選び「ONにする」をクリック |
| さくらインターネット | コントロールパネルの「ドメイン／SSL」→「ゾーン編集」でDKIMレコードを自動追加 |
| ConoHa WING | WINGコントロールパネルの「メール管理」→「DKIM設定」でドメインごとに切替 |
| ロリポップ | ユーザー専用ページの「メール設定」→「メール認証設定」から有効化 |
Google WorkspaceやMicrosoft 365を使っている場合は、各サービスの管理画面から専用のDKIMキーを生成し、ドメインのDNS（ムームードメイン、お名前.com、Cloudflareなど）にTXTレコードとして追加します。設定後、反映までに数時間〜24時間程度かかる点に注意してください。
DMARCはSPF・DKIMの結果を受けた処理方針を宣言する
DMARC（Domain-based Message Authentication, Reporting and Conformance）は、SPF・DKIMの認証に失敗したメールを受信側にどう扱ってほしいかを宣言する仕組みです。「迷惑メールフォルダに入れる」「破棄する」「そのまま届ける」など、ドメイン所有者が処理方針を指定できます。
DMARCポリシーは「none → quarantine → reject」の段階で運用する
DMARCには3段階のポリシーがあり、運用は段階的に進めます。いきなり厳しい設定にすると、自社の正規メールまで弾かれてしまうため、必ず緩い設定から始めて段階的に強化します。
| ポリシー | 受信側の処理 | 運用上の位置づけ |
|---|---|---|
| p=none | 認証失敗でも通常通り配信、レポートだけ送信 | 導入初期。設定の問題を洗い出す段階 |
| p=quarantine | 認証失敗のメールを迷惑メールフォルダに振り分け | 運用中盤。なりすまし対策の本格運用 |
| p=reject | 認証失敗のメールを完全に拒否 | 最終形。自社ドメインの完全保護 |
JPAAWG（Japan Anti-Abuse Working Group）の公開資料でも、DMARCはまずp=noneから開始し、レポートで認証状況を確認してから段階的に厳しくする運用が推奨されています（出典 一般財団法人 日本データ通信協会 JPAAWG）。最初からp=rejectにしてしまうと、SPFの設定ミスや外部メール配信サービスの設定漏れで、自社からの正規メールまで届かなくなります。
DMARCレコードの最小構成と運用上の注意点
DMARCの最小レコード例は次の通りです。DNSのTXTレコードとして「_dmarc.自社ドメイン」に登録します。
- v=DMARC1 が必須の冒頭宣言
- p=none で初期運用、認証失敗でも配信を維持
- rua=mailto:dmarc@自社ドメイン で集計レポートの送信先を指定
- pct=100 で全メールにポリシー適用
レポート送信先（rua）を設定すると、Google・Microsoft・Yahoo!などの主要メールプロバイダから、毎日XML形式の集計レポートが届きます。このレポートを読むと、自社ドメインを名乗って送られているメールの実態（正規送信か、なりすましか）が把握できます。レポートはXMLのままだと読みにくいため、Postmark DMARC monitoringなどの可視化ツールに取り込むのが実用的です。
3つの認証を設定済みなのに迷惑メールに入る時の確認ポイント
SPF・DKIM・DMARCを正しく設定しても、迷惑メールに入るケースがあります。残り2割の原因を順番に確認していきます。
送信元IPのレピュテーション（共用サーバーで隣の利用者が原因のケース）
レンタルサーバーは1つのIPアドレスを複数の利用者で共有している場合があります。同じIPを使う他の利用者が大量送信やスパム配信を行うと、IP全体の評価（レピュテーション）が下がり、自社の正規メールまで巻き添えで迷惑メール扱いされます。自分が悪くないのに、隣人のせいで送達率が落ちるのが共用サーバーの宿命です。
送信元IPがブラックリストに登録されているかは、MXToolboxなどの無料チェックツールで確認できます。複数のブラックリストに登録されている場合は、レンタルサーバー会社にIP変更を依頼するか、専用の送信用サーバー（SendGrid、Amazon SESなど）を経由する運用に切り替えるのが現実的な対処です。
本文と件名のスパムスコア（HTML比率・URL多数・大文字連発）
受信側のスパムフィルタは、本文や件名からスパムの可能性をスコアリングしています。実務でよく引っかかるのは以下のパターンです。
- 件名に「【無料】」「キャンペーン」「割引」などを多用している
- 本文に外部URLが10件以上含まれている
- HTMLメールでテキスト部分がほぼない（画像だけのメール）
- 添付ファイルが大きい、または実行可能形式（exe、scrなど）を含む
- 送信先メールアドレスが大量で、宛先が「BCC」に集中している
テキストメインで、外部URLは必要最小限、件名は誇張表現を避ける。これだけでスパム判定の確率は大きく下がります。営業メールやメルマガで送達率が低い場合は、本文のスパムスコアをMail-Tester.comなどで確認するのが手早い改善策です。
受信側で連絡先登録・「迷惑メールではない」操作をしてもらう
取引先がGmailを使っていて、自社からのメールが毎回迷惑フォルダに入る場合、受信側で「迷惑メールではない」のボタンを押してもらうか、連絡先に登録してもらうと、その後の判定が改善します。Googleは受信者ごとの操作履歴を学習するため、一度「迷惑メールではない」と判定された送信元は、次回以降通常配信に戻りやすくなります。
取引先や顧客への連絡時に「迷惑メールフォルダに入っていないかご確認ください。入っていた場合はメールを開いて『迷惑メールではない』をクリックしていただけると助かります」と一文添えるだけで、送達率の改善につながります。（送信側の対策と受信側の協力はセットです）
自社で設定が難しい場合の現実的な選択肢
SPF・DKIM・DMARCの設定は、DNSレコードの編集が必要です。ムームードメインやお名前.com、Cloudflareなどのドメイン管理画面でTXTレコードを追加・編集する作業になりますが、この作業を「自社で安心してできる」という中小企業はほとんどありません。レコードの書き間違いが1文字あるだけで、メールが全件止まるリスクがあるからです。
現実的な選択肢は3つです。1つ目はレンタルサーバー会社のサポートに依頼する方法。エックスサーバーやさくらインターネットは、SPF・DKIMの有効化までは管理画面で対応していますが、DMARCの段階的運用や、Google Workspace併用時のincludeチューニングまではサポート範囲外です。2つ目はメール配信専用サービス（SendGrid、Amazon SESなど）に切り替える方法。3つ目が、Web運用保守の一環として外部に委託する方法です。
弊社の運用代行では、SPF・DKIM・DMARCの新規設定から、Google Workspace・Microsoft 365併用時のレコード調整、DMARCレポートの読み解きまで、月額1万円のベーシック運用プランの範囲内で対応しています。「メールが届かないと取引先から言われて困っている」という状況なら、設定の現状確認だけでも数日で完了します。
最後に
自社ドメインからのメールがGmailで迷惑メール扱いされる原因の8割は、SPF・DKIM・DMARCの設定不備です。2024年2月以降、Gmail宛てのメール送達は認証3点が事実上の必須要件になりました。設定はDNSレコードの編集が中心で、ボタン1つで終わる場合もあれば、Google Workspaceやメール配信サービスとの併用で複雑化する場合もあります。重要なのは、本文や件名を変える前に、まず認証3点が通っているかを確認することです。
Web管理では、月額1万円からホームページの運用保守と合わせて、メール送達周りのDNSレコード調整・Gmail送達確認・DMARCレポート読み解きまで対応しています。「お問い合わせの返信が届かないと言われた」「営業メールがGmailだけ全部弾かれている」という状況は、放置すると商機を逃し続けます。現状の設定確認だけのご相談でも構いませんので、お気軽にお問い合わせください。
