独自ドメインから送っているメールが、ある日突然Gmailに届かなくなる——中小企業でこの相談が2026年に入ってから急増しています。昨日まで普通に届いていたはずのメールが、問い合わせフォームの自動返信も、見積書の添付メールも、Gmail宛だけがバウンス。社内の別PCから試しても同じ。
そんな事象に遭遇したら、原因はほぼ間違いなく「SPF・DKIM・DMARC」と呼ばれるメール認証の失敗です。
この記事では、私自身がクライアントの独自ドメインメールで実際に遭遇した事例をもとに、なぜ「急に」届かなくなるのか、どう診断して、何を直せばいいのかを順を追って解説します。
メール設定はインフラ寄りで後回しにされがちですが、一度崖落ちすると商談も納品もすべて止まります。事故を起こす前の予防、起きてしまってからの復旧、どちらの視点でも参考になる内容にしました。
Gmailに急にメールが届かなくなる事象が2026年に急増している理由
まず背景から整理します。「急に届かなくなった」と感じるケースのほとんどは、設定を変えていないのに受信側の判定が厳しくなったことで顕在化しています。設定側は何も触っていないのに、ある日を境にバウンスが返り始めるのはこのためです。
2024年2月からGoogle・Yahooの送信者要件が段階的に必須化された
きっかけは、Googleと米国Yahooが共同で発表した送信者要件の強化です。ざっくり時系列でたどると次のようになります。
- 2024年2月〜：SPFまたはDKIMのどちらか必須、PTRレコード必須、迷惑メール率0.3%未満、RFC 5322準拠
- 2024年6月〜：1日5,000通以上送る事業者はDMARC必須、マーケメールはワンクリック配信停止必須
- 2025年11月〜：認証失敗メールを従来の「421 一時エラー」から「550 永続拒否」で運用開始（ハード拒否）
このうち、中小企業に直接影響したのが2025年11月からのハード拒否運用です。それまでは認証がギリギリ失敗していても、Gmail側が寛容に受信してくれていました。それが「即バウンス」に切り替わったため、設定不備のあったドメインが一斉に崖から落ちた、という構図です。
「昨日まで届いていた」は「寛容に許されていただけ」だった
私が相談を受けた事例もまさにこれでした。構築当時はmail-tester.comのスコアも十分で、Gmailにも問題なく届いていました。ところが2026年に入り、クライアントから「取引先のGmailに返信が届いていないと言われた」と連絡が入り、調べてみるとバウンスメールに5.7.26（送信認証失敗）のエラーコードが記録されていました。
「昨日まで動いていたのに急に」ではなく、「寛容モードで見逃されてきた不備が、厳格化によって露呈した」と捉えると構造が理解しやすくなります。逆に言えば、認証を正しく整えておけば、今後さらに基準が強化されても安心です。
実際にあった事例：送信サーバー構成の変更でSPFが失効した
匿名化した事例を具体的に紹介します。ある中小企業で、独自ドメインメールを構築した数か月後、Gmailだけに届かなくなる事象が発生しました。
発生した事象
- 構築時はSPFレコード設定済み、Gmail宛もOutlook宛も正常に届いていた
- 構築から数か月後、突然Gmail宛のみバウンス
- エラーコードは
550 5.7.26（認証失敗によるハード拒否） - Outlook・Yahoo・独自ドメイン宛は引き続き届いていた
判明した原因
バウンスメールのReceived:ヘッダで実際の送信IPを確認したところ、SPFレコードに書かれたinclude先の範囲に入っていませんでした。深掘りすると、契約していた国内のメール配信事業者が、送信サーバー群をfmx系からdc90系に切り替えていたのです。告知は特になく、管理画面にも明示の案内はありませんでした。
修正前のSPF（ドメインはexample.comに置換して掲載）は次のとおりです。
v=spf1 include:fmx.example-mail.jp include:sendgrid.net -all
送信IPは新しいdc90系に移っていたのに、SPFは旧fmx系しか許可していない。受信側からすれば「このIPはあなたのドメインからの正規の送信者じゃないですよね」と判定されてしまう状態でした。
取った対応
SPFレコードに新しいinclude先を追加しました。
v=spf1 include:fmx.example-mail.jp include:dc90.example-mail.jp include:sendgrid.net -all
DNS反映後、mail-tester.comで再測定すると認証がpassに戻り、Gmailへの配信も復旧しました。ここで終わらせずに、後述のDKIM設定とDMARCレポート受信設定も後付けで追加して、次の事故を防ぐ体制に組み直しています。
原因のほぼ全ては「3つのメール認証」に集約される
独自ドメインメールがGmailに弾かれるとき、原因はほぼ例外なくSPF・DKIM・DMARCのいずれかです。それぞれの役割を、最低限これだけ押さえておけばいいという粒度でまとめます。
SPF：このドメインを送信していいサーバーのリスト
SPF（Sender Policy Framework）は、DNSのTXTレコードに「自分のドメインを名乗って送信していいサーバーはこれ」と列挙しておく仕組みです。受信側は、届いたメールの送信元IPがこのリストに入っているかを確認し、入っていればSPF passと判定します。
SPFの典型的な落とし穴は3つあります。
- 配信事業者がサーバー構成を変更するとSPFが失効する（今回の事例）。告知されないケースも多い
- SPFは1ドメインに1レコードのみ。複数書くと全無効になる
- DNS lookupは最大10回まで。includeを重ねすぎると超過して全体が失敗する
DKIM：メール本文への電子署名
DKIM（DomainKeys Identified Mail）は、送信サーバーがメールに電子署名を付け、受信側がDNSから公開鍵を取得して署名を検証する仕組みです。改ざんされていないこと、そして本当にそのドメインの管理者が送ったことを証明します。
配信事業者によっては初期設定でDKIMが有効になっておらず、申請して初めて使えるケースもあります。私が対応した事例もこのパターンで、復旧作業の中でDKIMは後付けで設定しました。
ただし、DKIMは「後付けでもいいから必ず入れる」べき設定です。未設定のままだとGmailのスコアが常にギリギリになり、ちょっとしたきっかけ（共有IPの評判悪化、コンテンツのスパム判定など）で一気に崖落ちします。SPF一本足で立っているドメインはとても脆い、と覚えておいてください。
DMARC：認証失敗時の扱いを指示するポリシー
DMARC（Domain-based Message Authentication, Reporting & Conformance）は、SPFとDKIMの結果を受けて「失敗したらどう扱うか」を送信者側から明示する仕組みです。DNSの_dmarc.example.comにTXTレコードとして追加します。
ポリシーは3段階です。
p=none：失敗してもそのまま配信（監視モード）p=quarantine：失敗したら迷惑メールフォルダへp=reject：失敗したら受信拒否
最低限の推奨設定は次のような形になります。
v=DMARC1; p=none; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com; fo=1;
ポイントはrua=（集約レポートの送信先）です。これを設定しておくと、どのIPからあなたのドメインを名乗ったメールが送られ、どれが認証に成功・失敗したかを1日1回のレポートで把握できます。rua=を設定していないドメインは、認証が壊れていても気づく手段がほぼありません。
突然Gmailに届かなくなった時の診断手順
ここからは実務での診断手順です。私が事例で実際にたどった流れを、再現できる形でステップに落とし込んでいます。所要時間は合計30分程度です。
STEP 1：症状を特定する（5分）
- 誰から誰へのメールが届かないかを具体的に特定する
- 受信側のメールサービスを確認(Gmail／Outlook／Yahoo／独自ドメイン)
- 送信者の受信トレイにバウンスメール（エラー通知）が届いていないか確認
- あれば
5.7.26、5.7.1などのエラーコードを控える
「Gmail宛だけ」「特定の時期から」という切り分けができれば、ほぼ認証問題と断定できます。
STEP 2：DNS設定の現状を把握する（10分）
ターミナルでdigコマンドを叩きます。Windowsの場合はnslookupでも可ですが、digのほうが読みやすい出力です。
dig +short example.com TXT（SPF確認）dig +short _dmarc.example.com TXT（DMARC確認）dig +short example.com MX（MXサーバー確認）dig +short default._domainkey.example.com TXT（DKIM確認、セレクタは事業者ごとに異なる）
ここで「SPFが返ってこない」「DMARCが未設定」「DKIMのセレクタがわからない」といった事実が並ぶと、原因の見通しが一気に立ちます。
STEP 3：実際の送信IPとSPFの許可範囲を照合する（5分）
バウンスメールのReceived:ヘッダ、またはwith ip: [...]の記述から、実際に使われた送信IPを抜き出します。そのIPが現在のSPFで許可されているかを確認します。
SPFのinclude:先に書かれたドメインも、さらにdigで展開して確認してください。include先のSPFが変わっているのに自分のドメイン側で追従していないケース、今回の事例と同じ構図が意外と多く見つかります。
STEP 4：mail-tester.comでスコアを測定する（5分）
mail-tester.comは独自ドメインメールの健康診断ツールの決定版です。表示されたテスト用アドレスに実際にメールを送ると、10点満点でスコアと、赤・オレンジの問題点が一覧で出てきます。
目安として9点以上を合格ラインにしています。8点台だと「届くときは届くが、条件次第で崖落ちするリスクがある」状態です。
STEP 5：原因に応じた対応
ここまでの調査で、原因が次のどれかに絞られます。
- SPFのinclude先が実IPを含まない：正しいinclude先にSPFを修正
- DKIM未設定：配信事業者に設定依頼、または管理画面で有効化
- DMARCアライメント失敗：送信ヘッダの
FromドメインとDKIMのd=ドメインが一致しているか確認 - 共有IPのレピュテーション悪化：Google Postmaster Toolsで確認、事業者に相談
- コンテンツがスパム判定：HTMLを簡素化、怪しい短縮URLを避ける
独自ドメインメールを守るための3つのルール
対応しながら、「どうすれば次の事故を防げるか」を常にセットで考えてきました。私が現在すべての案件で適用しているルールは次の3つです。
ルール1：SPFは配信事業者の仕様変更に追従する
SPFは「設定したら終わり」のレコードではありません。配信事業者側の都合でサーバー構成が変わると、告知の有無にかかわらず失効する可能性があります。
- 半年に1回、mail-tester.comでスコアを再測定する
- 配信事業者の「仕様変更」「メンテナンス」告知は定期的にチェックする
- include先のSPFを
digで展開し、想定と乖離がないかを確認する
ルール2：DKIMは必ず設定する
繰り返しになりますが、DKIM未設定のドメインはGmailから見て「スコアがギリギリ」の状態です。今日届いていても、明日崖落ちする可能性があります。
配信事業者がDKIMに対応しているか、セレクタ名はなにか、公開鍵はTXTとCNAMEどちらで登録するのか——このあたりは初期構築時に必ず確認してください。対応していない事業者を選ばないことも選択肢のひとつです。
ルール3：DMARCは最低限p=none+rua=で設定する
DMARCはいきなりp=rejectにする必要はありません。まずは監視モードのp=noneで入れて、rua=でレポートだけ受け取る。これだけでも、認証が壊れたときに気づける仕組みができあがります。
1〜2か月レポートを観察して、自社ドメインを名乗った第三者からの送信がないこと、認証成功率が安定していることを確認してから、p=quarantineに昇格する、という段階運用が安全です。
新規でメール環境を構築する時のチェックリスト
予防側の話として、新規案件でメールまわりを触るときの着手チェックリストを共有します。私が実案件で使っているものをほぼそのまま持ってきました。
- 配信事業者を確認する（さくら／Xserver／Google Workspace／Microsoft 365など）
- 事業者の公式SPFレコードを調べて、include先を決定する
- 実際の送信IPとinclude先SPFが一致しているか
digで確認 - DKIM設定を有効化する（事業者側または管理画面で）
- DMARCを
p=none+rua=で最低限設定する - mail-tester.comでスコア測定し、9点以上を確認
- 自分のGmailにテスト送信し、ヘッダで
spf=pass、dkim=pass、dmarc=passを確認 - 技術ドキュメントに「配信事業者」「SPF include先」「DKIMセレクタ」を記録
- DMARCレポート受信用のメールボックスを用意（例：
dmarc@example.com） - Google Postmaster Toolsにドメインを登録
ここまでをリリース前に通しておくと、運用に入ってからの事故はかなり減らせます。
運用開始後も「届く」を守るための定期メンテナンス
メールは「納品して終わり」の領域ではありません。構築後も継続的な監視が必要です。私が案件ごとに回しているメンテナンス頻度は次のとおりです。
- 毎月：DMARCレポートをざっと確認（異常なIP・ドメインから送信されていないか）／Google Postmaster Toolsでレピュテーションを確認
- 半年に1回：mail-tester.comでスコアを再測定／配信事業者の仕様変更告知を確認／DNS設定の棚卸し
- 年1回：DMARCを
p=noneからp=quarantineへ昇格できる状態か判定／DKIMキーのローテーション
とくに半年に1回のmail-tester.com測定はコストゼロでできる健康診断なので、ぜひ運用に組み込んでください。
便利な診断ツール一覧
実務で使っている診断ツールを用途別に整理しておきます。
- mail-tester.com：10点満点の総合診断。赤・オレンジの項目を一つずつ潰すだけで改善できる
- MXToolbox：SPF／DKIM／DMARC／MXを一括チェック
- DMARCian：DMARCレコードの文法チェックとレポート可視化
- Google Postmaster Tools：Gmail視点から見た自社ドメインの評価
- DKIM Core Tool：DKIM公開鍵の検証
- digコマンド：ローカル環境から各種DNSレコードを直接確認
まとめ：メールは「届く」を継続的に守り続ける必要がある
独自ドメインのメールがGmailに急に届かなくなったとき、慌てずに次の順番で当たれば、ほとんどのケースは30分〜1時間で原因が特定できます。
- バウンスメールのエラーコードを確認する
digでSPF／DKIM／DMARCの現状を把握する- 実際の送信IPとSPFの許可範囲を照合する
- mail-tester.comでスコアを測定する
- 原因に応じてDNSを修正、再測定で確認
そしてより重要なのは、事故ってから直すのではなく、事故らない状態で運用し続けることです。SPF・DKIM・DMARCの3点セットを正しく入れて、DMARCレポートで兆候を監視し、半年ごとに健康診断をする。これだけで、ある日突然届かなくなるリスクはほぼゼロにできます。
メール設定は目立たない領域ですが、一度崖落ちすると商談も請求書も納品連絡もすべて止まります。ホームページ制作や業務システム構築を外注する際は、「メール認証まで面倒を見てくれるか」を確認しておくと安心です。
関連記事としては、ホームページ運用で見落とされがちな技術的トラブルを扱った次の記事もあわせて参考にしてください。
