会社メールが相手の迷惑メールに入るときは、文面を変える前に、問題が起きた一通の送信日時・宛先・送信方法・受信結果を揃えます。送信側の認証設定だけでなく、送信サービスや受信側のルールも関係するため、「SPFを設定すれば必ず直る」とは言えません。
この記事では、独自ドメインの会社メールについて、担当者が集める情報、管理者に頼む確認、変更後の合格判断を整理します。通常の業務メールと、フォーム・請求書・一斉配信を分け、2026年10月時点の公式案内をもとに説明します。
まず受信結果を分ける
「相手に届いていない」という申告だけでは、原因は決まりません。迷惑メールフォルダにあるのか、受信側で隔離されているのか、送信エラーなのかを確かめます。送信済みフォルダにあることは、相手が読める場所へ届いた証拠ではありません。
| 分かった状態 | 次に確認すること |
|---|---|
| 迷惑メールに入った | 問題のメール原文・受信日時・認証結果を保存 |
| 受信側で隔離された | 相手の管理者へ差出人・日時・件名を渡し、隔離理由を確認 |
| エラー通知が戻った | 通知全文とコードを保存し、送信サービスへ調査を依頼 |
| どこにも見当たらない | 宛先、送信処理の記録、受信側の振分け・隔離を照合 |
見積書や支払に関わる連絡が止まっているなら、まず既知の電話番号など別の連絡手段で受領を確認します。同じメールを大量に送り直すより、相手と合意した方法で業務を続け、その間に調査します。
移転直後から送受信全体が止まった場合は、ホームページ移転後のメール停止の確認手順も参照してください。本記事では、特に外部へ送ったメールの迷惑判定を扱います。
問題の一通を記録する
まず「いつ、誰が、どの方法で、誰に送ったか」を記録します。日時にはタイムゾーンも添え、手動返信・フォーム自動返信・請求サービスなど、送信方法を区別します。件名、添付の有無、受信場所、エラー、直前の設定変更も並べると比較できます。
迷惑メールに入った原文は、受信者の協力を得て保存します。受信したメールの詳しいヘッダーには、通過したサーバーや認証結果が含まれます。Gmailなら、ブラウザで対象メールを開き、返信アイコン横のメニューから「メッセージのソースを表示」を選びます。Googleの詳細ヘッダー確認手順で操作を確認できます。
SPF・DKIM・DMARCの結果と認証したドメインを、管理者に読んでもらいます。自分で分からなければ「原文を確保済み」と伝えれば十分です。ヘッダーにもメールアドレス等が含まれるため、公開掲示板へ貼らず、共有先と方法を決めて渡します。最初の相談にパスワードや顧客の本文全体は不要です。
送信経路を洗い出す
同じ会社名や差出人アドレスでも、実際に送るサーバーは同じとは限りません。普段のメールが届く一方で、自動返信だけ迷惑メールになるなら、フォームの送信設定も確認が必要です。送信方法を無理に一本化する前に、現在使う経路を一覧にします。
| 送信するメール | 確認先と依頼内容 |
|---|---|
| 担当者の業務メール | メール管理者へ、利用アプリ・差出人・対象メールを共有 |
| フォームの通知・自動返信 | Web担当へ、フォームと送信サービス、実際の受付記録を共有 |
| 請求書・EC・一斉配信 | 各サービス担当へ、送信ドメイン設定と配信記録を確認依頼 |
例えば、手動返信とフォーム自動返信が別のサーバーから出る会社を考えます。手動返信だけ認証に合格しても、フォーム側の設定が正しいとは判断できません。これは説明用の架空例です。受信先を揃え、各経路から届いた一通を比較することで、調べる範囲を絞ります。
フォームを調べる際は、受付通知と利用者向け自動返信を分けます。受付画面の完了だけでは、二通とも届いたとは分かりません。差出人には送信サービスが認証できる設定を使い、入力された利用者のアドレスを差出人として無条件に使わないよう、Web担当と確認します。Googleのフォームメールの問題確認案内でも、フォーム側の送信・認証方式を調べる手順が示されています。
認証の結果を確認する
SPFは送信サーバーの許可を確認する仕組み、DKIMは電子署名を検証する仕組みです。DMARCでは、SPFまたはDKIMの認証と、画面に表示される差出人ドメインとの対応も確認します。「DNSに登録がある」と「その一通が認証に合格した」は分けて考えます。
SPFを変更するなら、まず現在の設定と全送信元を確認します。GoogleのSPF設定案内も、Webサーバーや外部サービスを含めた送信元調査を求めています。ネット上の例をそのまま追加すると、現在のサービスを外してしまったり、同じ名前にSPFレコードを重複させたりする恐れがあります。SPFの問題確認案内を、契約先の手順と合わせて確認します。
DMARCの拒否方針を急に強めると、正当なフォームや請求書まで届かなくなる場合があります。Googleの段階導入案内に沿って、認証とレポートを確認してから適用範囲を決めます。既存の方針を弱める判断も、影響と承認を確認して行います。
認証以外も調べる
認証に合格しても、受信トレイへ必ず届く保証はありません。送信量の急増、望まれていない配信、リンクや差出人の不自然さ、共有送信サーバーの評価、受信企業のルールなども調査対象です。
Googleのメール送信者ガイドラインでは、個人のGmail宛への要件が示されています。全送信者と一括送信者では要件が異なり、認証以外の条件もあります。普段の業務メールと大量配信を同じ条件として扱わず、現在の送信実態と照合します。
添付やリンクが関係しそうなら、相手と合意したテスト宛先で、一つの条件ずつ変えて比較します。添付なしで届いても、容量だけが原因と即断せず、受信側の検査結果も確認します。共有リンクを使う場合は閲覧権限を限定し、機密書類を公開状態にしないようにします。
特定の取引先だけで起きるなら、その会社の管理者に対象の一通を探してもらいます。Microsoft 365のExchange Onlineでは、メッセージ追跡で受信・拒否・保留・配信の状態を調べられます。利用権限と環境によるため、自社の担当者だけで相手の記録を確認できるわけではありません。
変更後の結果を残す
変更前の設定、変更理由、担当、日時、戻す条件を残してから作業します。受信先を決めるMXやWeb用の設定まで一緒に変更せず、原因に関係する箇所を管理者と絞ります。
合格確認は、問題が出た送信方法から、合意した外部宛先へ送り、認証結果と実際の受信場所を記録することです。手動返信だけでなく、フォーム通知・自動返信・請求サービスも対象に含めます。一つのGmailへ届いたことを、全取引先での解消として扱いません。
写真は調査・引継ぎの場面を表す生成イメージで、実際の顧客や解決実績ではありません。
取引先からの申告件数だけでは、見落とされたメール全体の割合は分かりません。対象経路、テスト通数、宛先、受信場所、エラーを同じ条件で記録し、残る症状と次の確認日を管理します。すぐに全件解消したと判断せず、通常業務での結果も追います。
相談する範囲を決める
外部へ頼むなら、現状調査、DNS・メール設定、フォーム確認、相手先への調査依頼、変更後の試験と記録のうち、どこまでを含むか決めます。費用や所要時間は、送信経路数と管理権限、調査できる記録によって変わります。「全メールが必ず届く」という成果保証を前提にしないことが大切です。
最初は「自動返信だけ、特定の会社の迷惑メールに入る。開始日は○月○日、メール契約先は○○、Web側の送信方法は未確認。手動返信との差を調べ、変更と再試験まで相談したい」とまとめれば、次の確認を決めやすくなります。これは架空の依頼文です。設定や移行自体を頼みたい場合は、会社メール設定の依頼と準備で範囲を整理できます。
みやあじよのホームページ保守・運用では、現在の契約・環境と管理範囲を確認し、関係先との連携や引継ぎを整理します。対応可否、必要な権限、作業範囲と費用は個別に確認します。原因が分からない段階でも、確認できた症状を添えてお問い合わせください。
