会社のメールが取引先の迷惑メールフォルダに入るとき、原因のほとんどは文面ではなく設定側にあります。文章を書き直しても件名の記号を消しても直らないのは、判定しているのが人間ではなく受信側の認証チェックだからです。どこが壊れているかを1分で切り分け、DNSレコードを1つずつ直すまでの手順を、Mihata が自社ドメインで実際に到達率を落としたときの記録とあわせてまとめます。
先に結論：ほぼ全部が送信ドメイン認証か、送信元の使い分け
原因はほぼ「送信ドメイン認証（SPF・DKIM・DMARC）の設定漏れ」か「送信元の使い分けミス」のどちらかです。前者はDNSレコードが無い・古い・食い違っている状態、後者は普段のメールは問題ないのにフォームや配信ツールから出る分だけ落ちている状態です。
これは推測ではなく受信側が公表している要件です。Google は2024年2月1日から、個人の Gmail 宛に24時間で5,000件近く以上を送る「一括送信者」に SPF・DKIM・DMARC の3点すべてを必須とし、すべての送信者にも SPF または DKIM のどちらかの設定、有効な正引き・逆引きDNS、TLS接続、迷惑メール報告率を0.3%未満（目標0.10%未満）に保つことを求めています（Google「メール送信者のガイドライン」）。認証が無い状態は「設定が甘い」ではなく「要件を満たしていない」と考えたほうが実態に近いです。
直す順番も決まっています。SPF → DKIM → DMARC（まず p=none）→ フォーム・配信ツールなど別経路の認証 → 最後に文面。上から潰すのが最短です。いきなり DMARC を厳しくするのが実務で一番多い自爆パターンなので、後述の注意点まで読んでから触ってください。
まず1分で切り分ける：相手側か、自分のドメイン側か
最初にやるのは原因探しではなく切り分けです。相手のフィルタが厳しいだけなのか、自分のドメインが疑われているのかで打つ手が正反対になります。
症状 | どちら側か | 最初にやること |
|---|---|---|
特定の1社だけ。他社は届く | 相手側の可能性が高い | 相手の情報システム担当に許可リスト登録を依頼 |
複数の会社で同時に入りはじめた | 自分のドメイン側 | SPF・DKIM・DMARC をDNSで確認 |
Gmail 宛だけ入る | 自分のドメイン側 | Google の送信者要件を満たしているか確認 |
フォームの通知だけ入る | 自分のドメイン側（別経路） | フォーム・配信ツールの送信元と認証を確認 |
サーバー移転・DNS移行の直後から | 自分のドメイン側（ほぼ確定） | 移行前のDNSレコードと突き合わせる |
自分が受け取れない | 受信側の設定 | MXレコードと転送設定を確認 |
最後の行だけは別の話です。この記事は送信側の問題を扱っているので、受け取れない側で困っている場合は独自ドメインのメールが受信できない時の切り分けを先に読んでください。見るレコードも確認の順番も違います。
土台として、3つの認証が何をしているのかを押さえておくと迷いません。
仕組み | 何を証明するか | 無いと何が起きるか |
|---|---|---|
SPF | そのサーバーから送る許可があること | 正規の送信元と見なされず、スパム判定の材料になる |
DKIM | 本文とヘッダーがドメインの鍵で署名され、改ざんされていないこと | 転送されると検証できず、なりすましと区別が付かない |
DMARC | From: のドメインが SPF か DKIM と一致していること＋失敗時の扱い | 一括送信者の要件を満たさない。レポートも受け取れず何が失敗しているか分からない |
原因1：SPFレコードが無い、apexに付いていない
一番多いのがこれです。SPFは「このドメインのメールはこのサーバーから出ます」とDNSのTXTレコードで宣言する仕組みで、書き忘れ・書き間違いがそのまま到達率に出ます。Google Workspace なら「v=spf1 include:_spf.google.com ~all」のような1行を、サブドメインではなくドメインそのもの（apex／ルート）に置くのが基本です。
SPFで踏みやすい2つの落とし穴
1つ目はレコードを2つ書いてしまうことです。仕様上、1つのドメインが複数のSPFレコードを持ってはならないと定められ、複数見つかった場合の評価結果は permerror（恒久的エラー）になります（RFC 7208 3.2 / 4.5）。配信サービスを追加したときに既存の行を直さず新しい行を足す事故が典型です。正解は1行にまとめ、include を並べることです。
2つ目はDNSルックアップ10回の上限です。include・a・mx・ptr・exists・redirect といったDNS問い合わせを伴う要素の合計は10回までに制限され、超えた場合も permerror を返さなければならないと規定されています（同 RFC 7208 4.6.4）。ツールを足し続けているうちに静かに上限を超え、ある日から全部落ちる形で表面化します。SPFは足せば足すほど安全、ではありません。
原因2：DKIM署名が無効（Google Workspace は自分で有効化しないと署名されない）
Google Workspace だから自動でDKIMが付いている、というのは誤解です。自社ドメインの鍵で署名させるには、管理者が管理コンソールで鍵を生成し、DNSにTXTレコードを登録したうえで、最後に「認証を開始」を明示的にクリックする必要があります。公式手順にも、DNSレコードを入れるまで認証を開始をクリックしないよう注意書きが入っています（Google Workspace「DKIM を設定する」）。鍵長は1024と2048が選べ、DNSプロバイダが対応していれば2048が推奨、プレフィックスセレクタの既定値は google です。
つまり「鍵は作った」「DNSには入れた」で止まっている組織はかなりあります。DNSに google._domainkey が見えているのに管理コンソールのステータスが有効になっていない状態は外から気づきにくいので、コンソール側の表示を必ず目で確認してください。
原因3：DMARCが無い、または設定が食い違っている
DMARCは、From: に書かれたドメインが SPF か DKIM のどちらかと一致（アラインメント）しているかを見て、失敗したメールをどう扱うかをドメイン所有者側から指定する仕組みです。p= タグには3つの値があり、none は特別な措置を求めない、quarantine は受信者に疑わしいものとして扱うよう求める、reject は受信段階での拒否を求める、と定義されています。あわせて rua タグで集約レポートの送信先を指定でき、受信側は mailto: 形式のサポートが必須とされています（RFC 7489）。
Gmail 以外も同じ方向に揃いました。Yahoo は大量送信者に SPF と DKIM の両方、最低 p=none の有効なDMARCポリシーと From: のアラインメントを求め、迷惑メール率は0.3%未満としています（Yahoo Sender Best Practices）。Microsoft も2025年5月5日から、Outlook.com・Hotmail.com・Live.com 宛に1日5,000通以上送る送信者に SPF・DKIM・DMARC（最低 p=none、SPFかDKIMとのアラインメント）を必須にしました（Microsoft Tech Community）。主要3社が同じ土俵に乗ったので、DMARCが無いドメインは今後さらに不利になります。
ただし、いきなり p=quarantine や p=reject にするのは危険です。自社の正規メールに認証が通っていない経路（フォーム、請求書ツール、転送されたメールなど）があると、それが丸ごと隔離・拒否されます。まず p=none と rua だけを置いてレポートを読み、すべての経路で SPF/DKIM が通っているのを確認してから上げてください。
原因4：フォームやツールからの送信だけ落ちている
「自分が Gmail から出す分は届くのに、サイトのお問い合わせフォームの通知だけ迷惑メールに入る」。これは認証の対象が別だから起きます。フォームやアプリからのメールは Google Workspace ではなく配信サービスやレンタルサーバーのメール関数から出ていることが多く、その経路ぶんの SPF と DKIM を別に登録しない限り認証は通りません。
送信専用サブドメインを使うときの注意
配信サービスは send.example.com のような送信専用サブドメインを使わせる構成が一般的です。この場合、SPFはそのサブドメインに、DKIMはサービス指定のセレクタに置くことになり、apexのレコードを直しても一切反映されません。ドメイン全体では認証が通っているのにフォームの通知だけ落ち続けるのはこのパターンです。通知が丸ごと来ない場合はメール以前の問題である可能性もあるので、問い合わせフォームのメールが届かない原因も併せて確認してください。
原因5：文面・リンク・添付が引っかかっている
認証を全部通しても一定数は迷惑メール側に入ります。ここで効くのは派手な言い換えではなく地味な要素です。実務で見つかる頻度が高いのは次のあたりです。
- 短縮URL・リダイレクタを本文に入れている。リンク先が隠れるため評価が下がる。素のURLを使う。
- ドメインと無関係な差出人名や、無料メールアドレスを Reply-To にしている。
- HTMLだけで本文テキストが無い、画像1枚だけのメール。
- 暗号化ZIPの添付。ウイルススキャンができないため単独で弾く企業が多い。
- 一斉配信に配信停止手段が無い。Google・Yahoo はどちらもマーケティング系メールにワンクリック配信停止（List-Unsubscribe）を求めている。
- 過去の配信で迷惑メール報告率が0.3%を超えた。Google の説明では、7日間連続で0.3%未満に戻るまで緩和の申し立ての対象にならないとされています（Google 送信者ガイドラインFAQ）。
ここを疑うのは認証3点を確認し終わったあとにしてください。順番を逆にすると、文面を何度書き直しても結果が変わらない時間を延々と過ごします。
直し方の順番：確認コマンドと無料ツール
1. DNSレコードを自分の目で見る
Mac・Linux なら dig、Windows なら nslookup で、管理画面を経由せず生のレコードを確認します。ドメイン名は自社のものに置き換えてください。
- SPF：dig +short TXT example.com（v=spf1 で始まる行がちょうど1つあるか）
- DKIM：dig +short TXT google._domainkey.example.com（配信サービス側は指定のセレクタで）
- DMARC：dig +short TXT _dmarc.example.com（v=DMARC1; p=none; rua=mailto:… があるか）
- Windows：nslookup -type=TXT example.com / nslookup -type=TXT _dmarc.example.com
2. 実際に送って採点させる
レコードが揃ったら実際のメールで検証します。表示される使い捨てアドレス宛に普段と同じ経路で送ると、SPF・DKIM・DMARC・逆引きDNS・ブラックリストまで含めた採点が返ってきます。認証が通っていない経路をあぶり出すのに向いています。
3. Gmail 側からの評価を継続して見る
自ドメインが Gmail からどう評価されているかは Google Postmaster Tools で確認します。現行は2024年に公開された新インターフェース（v2）で、URLは postmaster.google.com/v2/ です。旧インターフェースは廃止予定とされつつ、フィードバックを受けてサポート終了が延期されている状態です（Gmail ヘルプ）。DNSにTXTレコードを置いてドメインを登録すると、迷惑メール報告率や認証の成功率が日次で見えます。
4. DMARCのレポートを読んでから厳しくする
rua に指定したアドレスへ、受信側から集約レポート（XML）が届きはじめます。数週間ぶん見て、自社の正規メールがすべて SPF か DKIM で通っていることを確認できてから p=quarantine へ上げます。ここを飛ばさないことが、この記事で一番お伝えしたい注意点です。
ここまでの確認はすべて無料でできますが、DNSの管理画面にたどり着けない、誰が管理しているのか分からない、という段階で止まることもよくあります。その場合はドメインとサーバーの管理会社がわからない時の調べ方から先に進めてください。
Mihata では、こうしたDNS・メール周りの調査と復旧も、ホームページ制作・保守のなかで引き受けています。記事の途中で恐縮ですが、自社で触るのが怖い・管理画面が分からないという段階で止まっている方には役に立つかもしれません。よろしければ合わせてご覧いただけたら嬉しいです。
Mihata のサイトで実際に起きたこと
ここは自社の失敗の記録です。mihata.jp は2026年8月19日にDNSを移行しましたが、そのときapex の SPF レコードと、Google Workspace の DKIM（google._domainkey）が写し漏れていました。本文も送信サーバーも何も変えていないのに、認証だけが欠けた状態でメールを送り続けていたことになります。
厄介なのは、この事故がまったく音を立てないことです。サイトは普通に表示され、メールも送信エラーにはならず、送信済みフォルダにはちゃんと残ります。相手の迷惑メールフォルダに入っているかどうかは、相手が教えてくれるまで分かりません。
2026年8月26日に、次の5点を揃えて復旧しました。
- apex の SPF レコード
- Google Workspace の DKIM（2048bit）
- DMARC（p=none ＋ rua でレポートを受け取る形）
- 送信専用サブドメイン send.mihata.jp の SPF
- メール配信サービス（Resend）の DKIM（resend._domainkey）
このとき p=none のままにしたのは意図的です。レポートで各経路の SPF/DKIM が通っているのを確認する前に p=quarantine 以上へ上げると、自社の正規メールまで隔離されます。急いで厳しくしたい気持ちが一番危ないところでした。
教訓は1つです。ホームページのリニューアル・サーバー移転・DNS移行の直後は、サイトが正常に見えていてもメールだけが静かに壊れていることがある。移行のチェックリストに「SPF・DKIM・DMARCを移行前後で突き合わせる」を必ず入れてください。移行そのものでメールが止まる話はサーバー移転でメールが止まる原因と手順に分けて書いています。
自分で直せる線と、頼んだほうがいい線
自分で直せる範囲：dig や nslookup でレコードを確認する、DMARCの p=none と rua を新規に1行足す、Google Workspace の管理コンソールでDKIMの鍵を生成して「認証を開始」を押す、mail-tester で採点する、Postmaster Tools に登録する。ここまでは追加費用なしで、失敗しても戻せます。
頼んだほうがいい範囲：既存のSPFレコードを1行に統合する（既存の include を消すと他のツールのメールが落ちる）、10回上限に当たっているSPFを整理する、DMARCのレポートを読んで p=quarantine 以上へ上げる判断、複数の配信サービスが混在している環境の全経路の棚卸し。間違えたときの影響が「自社のメールが全部隔離される」なので、一度は第三者に見てもらう価値があります。
そして正直に書いておくと、設定を直しても体感はすぐには変わりません。DNSの変更はキャッシュの都合で反映に時間がかかり、ドメインの評価はさらに遅れて回復します。直した直後に「変わらないから設定が間違っている」と判断して触り戻すのが最もよくない対処なので、レコードが正しいと確認できたら数日から数週間の単位で数字を見てください。
よくある質問
ここまでの内容で、特に質問をいただくところをまとめます。
よくある質問
設定を直したら、迷惑メール判定はすぐ戻りますか？
すぐには戻りません。DNSの変更自体はキャッシュが切れれば反映されますが、ドメインの評価が回復するにはさらに時間がかかります。レコードが正しいことを確認したうえで、数日から数週間の単位で Google Postmaster Tools の迷惑メール報告率と認証成功率を見てください。直した直後に変化がないからといって設定を触り戻すのが一番よくない対処です。
SPFレコードは複数書いてもいいですか？
いけません。RFC 7208 では1つのドメインが複数のSPFレコードを持ってはならないと定められており、複数見つかると評価結果は permerror になります。配信サービスを追加するときは新しい行を足すのではなく、既存の1行に include を並べて統合してください。DNS問い合わせを伴う要素の合計が10回を超えるのも同じく permerror になるので、足し続けるのも危険です。
DMARCは最初から p=reject にすべきですか？
やめてください。自社の正規メールで認証が通っていない経路（フォーム、請求書ツール、転送されるメールなど）があると、それが丸ごと拒否されます。まず p=none と rua だけを置いて集約レポートを受け取り、すべての経路で SPF か DKIM が通っていることを確認してから quarantine へ上げるのが正しい順番です。
Google Workspace なら DKIM は自動で有効になっていますか？
なっていません。自社ドメインの鍵で署名させるには、管理者が管理コンソールで鍵を生成し、DNSにTXTレコードを登録したうえで、最後に「認証を開始」を明示的にクリックする必要があります。DNSにレコードが見えているのにステータスが有効になっていない状態はよくあるので、管理コンソール側の表示を必ず目で確認してください。
社内では届くのに社外の宛先だけ迷惑メールに入るのはなぜですか？
同じドメイン内のやりとりは外部の受信サーバーを通らないため、送信ドメイン認証の成否がそのまま結果に出ないからです。社内テストで問題がないことは SPF・DKIM・DMARC が正しい証拠にはなりません。確認は必ず社外のアドレス、特に Gmail など要件を公表している宛先に対して行ってください。