会社メールが届かない原因は、アドレス入力ミスだけではありません。DNS、送信サーバー、受信側の迷惑メール判定、容量、転送、SPF・DKIM・DMARCなど複数の要素が関係します。
特にホームページやサーバーを変更した直後は、Webだけでなくメール設定も確認する必要があります。原因を切り分け、安全に改善する基礎を解説します。
最初に「送れない」と「受け取れない」を分ける
送れない
自社から相手へ送信できない、エラーで戻る、迷惑メールへ入る状態です。
受け取れない
相手から自社へ届かない、遅延する、特定アドレスだけ受信できない状態です。
方向と対象を分けると調査しやすくなります。
最初に集める情報
- 送信者と受信者のアドレス
- 送信日時
- 件名
- エラーメール全文
- 届く相手・届かない相手
- 迷惑メールフォルダー
- Webメールでも再現するか
- 直前のDNS・サーバー・メール変更
- 添付ファイルの種類と容量
- メールヘッダー
本文に機密情報がある場合は安全な方法で共有します。
原因1：アドレス・容量・端末設定
宛先の入力ミス、存在しないアカウント、メールボックス容量超過、送受信設定、パスワード変更が原因になります。まずWebメールや管理画面でアカウント自体が正常か確認します。
一つの端末だけなら、サーバー設定より端末側の可能性が高くなります。
原因2：DNS・MXレコード
MXレコードは、そのドメイン宛てメールをどのサーバーへ届けるか指定します。DNS変更でMXを削除・変更すると、受信できなくなります。
Webサーバー移転時にも、既存のMX・TXTレコードを維持する必要があります。
原因3：送信元IP・ドメインの評価
大量送信、苦情、乗っ取り、共有サーバーの影響などで送信元の評価が下がると、迷惑判定や拒否が増えます。
短期間に急増させず、配信同意、解除、エラー処理、アカウント保護を整えます。
SPFとは
SPFは、そのドメインからメール送信を許可するサーバーをDNSのTXTレコードで示す仕組みです。受信側は、実際の送信元が許可リストに含まれるかを確認します。
会社メールだけでなく、フォーム、請求、CRM、メール配信など自社ドメインで送るすべてのサービスを把握する必要があります。
SPFのよくある問題
- 新しい送信サービスを追加していない
- 複数のSPFレコードを作っている
- 古いサービスが残っている
- 記述ミス
- DNS参照回数の上限を超える
- From表示とSPF判定ドメインが一致しない
一つのTXTレコードへ正しく統合し、変更後に認証結果を確認します。
DKIMとは
DKIMは、送信メールへ電子署名を付け、受信側がDNS上の公開鍵で検証する仕組みです。メールが正当な送信元から送られ、署名対象部分が途中で改変されていないことを確認します。
メールサービス側で鍵を発行し、DNSへ指定レコードを登録して有効化します。
DKIMのよくある問題
- DNSレコードを登録しただけでサービス側を有効化していない
- セレクターが違う
- 古い鍵が残る
- 転送・中継で署名対象が変更される
- 実際の送信サービスが署名していない
受信メールのヘッダーでdkim=passなどの結果を確認します。
DMARCとは
DMARCは、見た目のFromドメインとSPFまたはDKIMで認証されたドメインの整合（アライメント）を確認し、失敗メールをどう扱うか受信側へ示す仕組みです。集計レポートの送信先も指定できます。
ドメインのなりすまし対策と、正規送信の把握に役立ちます。
DMARCポリシー
p=none：監視中心p=quarantine：迷惑扱いを求めるp=reject：拒否を求める
いきなり厳しいポリシーにすると、把握していない正規サービスまで届かなくなる可能性があります。SPF・DKIMを整え、レポートを確認して段階的に強化します。
SPF・DKIM・DMARCの関係
SPFは送信元サーバー、DKIMは署名、DMARCはFromドメインとの整合と失敗時方針を扱います。一つだけでは十分ではなく、組み合わせてなりすましと到達性を改善します。
Microsoftも、SPF・DKIM・DMARCを相互に関係する認証要素として公式資料で説明しています。
Gmailの送信者要件
Googleの現行ガイドラインでは、Gmail宛てのすべての送信者にSPFまたはDKIMなどを求め、大量送信者にはSPF・DKIM・DMARC、Fromドメインとの整合、解除手段など追加要件を示しています。
大量配信をしていない企業でも、3つを正しく設定することが推奨されます。
フォーム通知が届かない理由
WordPressフォームで、入力者のメールアドレスをFromにすると、自社サーバーから他社ドメインを名乗る形になり、認証に失敗しやすくなります。
Fromは認証済みの自社ドメインにし、入力者アドレスはReply-Toへ設定する方法を検討します。
WordPressからの送信
サーバーの簡易送信機能だけでは、送信元認証、エラー処理、ログが不十分な場合があります。認証済みSMTPやメール送信サービスを使い、SPF・DKIMを設定します。
プラグインを入れるだけでなく、実際のヘッダーと受信を確認します。
転送メールの注意
転送により、SPFが元の送信元と合わなくなる場合があります。DKIMやARCなどが認証維持に関係します。単純転送だけでなく、グループ・ルーティング・受信サービスの方法を確認します。
転送先で届かない場合は、元メールボックスとヘッダーを調べます。
PTR・逆引きDNS
受信側は、送信元IPの逆引きDNSやホスト名の整合も確認します。共有サーバー・専用送信サービスでは提供元が管理する場合があります。
自社で変更できない場合は、メール事業者へ確認します。
TLSと通信
メール配送でもTLSによる暗号化が使われます。Googleの送信者ガイドラインはTLS接続を要件に含めています。
ただしTLSは送信者の正当性すべてを保証するものではなく、SPF・DKIM・DMARCと組み合わせます。
迷惑メール判定は認証だけではない
認証が通っても、内容、リンク、添付、送信量、苦情率、過去の評価、受信者との関係で迷惑判定されることがあります。
件名の誇張、短縮URL、不審な添付、購入リストへの送信を避けます。
原因切り分けの手順
- 送受信方向・対象・時刻を記録する
- エラー全文とヘッダーを取得する
- Webメールと別宛先で再現確認する
- DNSのMX・TXTを確認する
- SPF・DKIM・DMARC結果を見る
- 送信サービス・フォーム設定を確認する
- 容量・アカウント・転送を確認する
- 迷惑判定・送信評価を確認する
- 一つずつ修正して再テストする
- 設定と結果を台帳へ残す
サーバー移転時のチェック
- 現在のDNS全レコードを保存
- MXを維持または計画的に変更
- SPFへ新送信元を追加
- DKIMを新サービスで発行・有効化
- DMARCレポートで失敗を監視
- 新旧メールを並行確認
- 社内外から送受信テスト
- Webフォームと自動返信をテスト
- 旧メール契約をすぐ解約しない
制作会社・メール会社へ伝える情報
- 対象ドメイン
- 送信元・宛先
- 発生日時
- エラー全文
- メールヘッダー
- 利用サービス
- 直前のDNS変更
- SPF・DKIM・DMARC設定
- 影響人数と業務影響
パスワードをメールでそのまま送らないようにします。
公式情報の確認先
Googleのメール送信者ガイドラインでは、SPF・DKIM・DMARC、DNS、TLS、迷惑メール率などの要件が説明されています。Microsoftのメール認証の公式解説でも、3方式が連携する仕組みを確認できます。
まとめ
会社メールが届かないときは、送信・受信のどちらか、誰に・いつ・どの経路で起きるかを分け、エラーとヘッダーを確認します。
DNSのMX、SPF、DKIM、DMARC、送信元評価、フォーム設定を順に切り分けましょう。認証を段階的に整え、サーバー変更後も実際の送受信とヘッダーまで確認することが、到達性となりすまし防止の両方につながります。