コーポレートサイトのお問い合わせフォームから、管理者宛に通知メールが飛ぶ想定なのに、受信箱に届かない——。よしあきは案件でこの切り分けを何度か見た。表面は「フォームの不具合」に見えるが、原因のひとつとして次のケースがある。
受信箱に見える差出人（会社のドメイン）と、実際にメールを送り出している場所（サイトを置いているサーバー）が違う。
本稿では固有のドメイン名・サーバー名・IPは伏せ、その構図を見分けるための基礎と、事前確認・対処の型だけを書く。
説明をシンプルにするため、サイト・DNS・会社メールの設定をよしあき側で見られる（必要なら直せる） と仮定して話を進める。実案件では担当が分かれることが多いが、構図そのものは同じだ（末尾で一言触れる）。
まず結論：こういうケースがある
よくあるのは次のような状態だ。
- サイトはレンタルサーバー上にある
- お問い合わせの通知は、そのサーバー上のプログラムから送っている
- 会社のメール（
@example.com）は Microsoft 365 など、別のサービスで受け取っている - なのに、通知の差出人も見た目は
@example.comにしてある
受信側から見ると、「ふだんこのドメインのメールは M365 側から来るのに、いま来ようとしているメールの送り元はサイト側のサーバーだ」となる。
そのとき「このドメイン名義で、そのサーバーから送ってよい」とあらかじめ宣言されていなければ、なりすましや正規でない送信とみなされやすい。
結果として、外部の個人宛には届くのに、自社ドメイン宛の管理者通知だけ届かない、といった非対称も起きうる。自動返信が外部ユーザーに届いているなら、フォーム自体は動いていて、受信側の判定や経路の問題を疑う材料になる。
以下では、このケースを理解するための基礎を先に置く。
基礎1：サイトとメール受信が別サービス、という状態
「Web サーバーとメールサーバーが別」とは、ざっくり次の意味だ。
ドメインの向き先（ネームサーバー配下の DNS レコード）は、用途ごとに別の場所を指せる。
| 用途 | だいたい何を見ているか | よくある例 |
|---|---|---|
| サイトを開く | サイト用の向き先（A レコードなど） | レンタルサーバー |
| そのドメイン宛のメールを受け取る | MX レコード | Microsoft 365 など |
つまり、「MX だけ別サービスを向いている」というのはよくある正しい理解で、サイトの置き場と、メールの受け取り口が同じ会社・同じサーバーである必要はない。
ただし、今回の届かない話の要点は「受信の MX がどこか」だけではない。
フォームの通知は、サイト側のサーバーから外へ出ていくことが多い。受信は M365、送信は Web 側、という分かれ方が、差出人の見た目（会社ドメイン）と実際の送り元のずれを生む。
基礎2：サイトと無関係に、会社ドメインでメールを送るとき
対比のために、フォームを経由しない「ふつうの会社メール」の送り方を押さえる。
人が Outlook や Web メールで @example.com から送るとき、ざっくり次のルートになる。
- メールソフト／Web メールで本文を書く（差出人は
@example.com） - 送信は 会社メール側のサービス（例: Microsoft 365）にログインして行う
- インターネットへ出すのも そのサービスの送信サーバー
- 相手側は、宛先ドメインの MX を見て受け取る
このとき、差出人のドメインと「送ってよい送り元の名簿（後述の SPF）」は、ふつう 同じエコシステム（M365 なら M365 向けの記載など）に揃っている。だから「会社ドメインのメール」としては自然で、なりすまし扱いになりにくい。
MX は「誰が @example.com 宛を受け取るか」の話であり、自分が @example.com から送るルートそのものではない。
送る側の正規ルートは、「会社メールの送信サーバー経由」と覚えると整理しやすい。
フォーム通知で起きやすいのは、差出人だけ @example.com に見せて、出口だけサイト側サーバーになることだ。見た目と実際の送信元がここでずれる。
基礎3：ここで使う言葉（4つだけ）
混乱しやすいので、役割だけ固定する。専門用語より先に、何を指すかを書く。
| 呼び方 | 意味 |
|---|---|
| 差出人（From） | 受信箱に表示される「誰から来たか」。見た目のドメイン |
| 実際の送信元 | メールが外へ出ていくときの送り元。ふつうの会社メールなら会社メール側。フォーム通知なら、多くの場合サイトを置いているサーバー側 |
| MX | 「そのドメイン宛てのメールをどこが受け取るか」。送信元の話ではない |
| SPF | 後述。「このドメイン名義で送ってよい送り元はどこか」を DNS で宣言する仕組み |
（制作現場では、サイト側からの送信に PHP の mail() などが使われることが多い。仕組みの名前より、「サイトと同じサーバーから出ている」と押さえておけば足りる。）
基礎4：SPF とは何か
SPF をひとことで言うと、「このドメイン名義でメールを送ってよい送り元の名簿」を、DNS に書いておく仕組みだ。
たとえ話にすると、会社名入りの封筒を使ってよい配達員のリストを、会社が公開しているイメージに近い。
名簿に載っていない場所から「会社ドメインの差出人」で届いたメールは、受信側が怪しみやすい。
ふつうの会社メールだけなら、名簿には会社メール側の送り元が入っていることが多い。
フォーム通知のようにサイト側からも同じドメイン名義で送るなら、名簿にサイト側も足す必要がある——入っていなければ、「会社ドメインの見た目なのに、知らない送り元から来た」と判断されやすい。
よしあき／AI（助手）
よしあき: 差出人を会社ドメインにして、送信はサイト側のまま、というのはよくあるよね。
AI（助手）: よくある。問題は「よくある」こと自体ではなく、SPF や受信側のポリシーがその前提を知らないときに拒否・隔離される点です。
よしあき: 対処は「サイト側を正規の送り元として認める」か、「送る経路を会社メール側に寄せる」かのどちらか、だな。
よくある構成（もう一度整理）
基礎を踏まえると、問題が起きやすい並びは次のとおりだ。
- サイトはレンタルサーバー（共用・ビジネス向けなど）に置いてある。
- お問い合わせの通知は、そのサーバー上のプログラムから送る。
- 会社のメール（
@example.com）は Microsoft 365 など別サービスで受信する。MX もそちらを向いている。 - フォームの差出人も、見た目は
@example.comにしてある。
事前に確認しておくこと
構図を見分けるために、先に次を押さえる（本稿の仮定どおり、よしあき側で DNS／メール設定も見られる前提）。
| # | 確認すること | わかること |
|---|---|---|
| 1 | サイトはどのサーバー／契約か | フォーム処理が動く場所 |
| 2 | フォーム通知の送り方（サイト上のプログラムから送るか、会社メール側の送信に乗せるか） | 実際の送信元がサイト側か、会社メール側か |
| 3 | 通知の差出人（From）は何か | 見た目のドメイン |
| 4 | @example.com の MX はどこか | メールの受け取り口 |
| 5 | 同じドメインの SPF に、いま何が書いてあるか（サイト側が入っているか） | 名簿に Web 送信元があるか |
| 6 | 完了画面まで進むか／外部宛の自動返信は届くか／管理者（自社ドメイン）宛だけ欠けるか | フォーム故障か、本稿の構図かの目安 |
SPF や許可リストに載せる対象は、多くの場合 MX（受け取り口）ではなく、上表の 2 で特定した実際の送信元の IP（またはホスト） だ。
症状の切り分けだけ抜き出すと、次の順でもよい。
- フォーム送信後、完了画面まで進むか（アプリ側）
- 自動返信が 外部宛 に届くか
- 管理者宛だけ未着か、全員未着か
- DNS: MX はどこか／SPF にサイト側の送り元が入っているか
- 届いた別経路のメール情報で、実際の送信ホストを確認する
1〜2 が問題なく、3 が「自社ドメイン宛だけ」なら、本稿の構図を第一候補にしてよい。
対処の型（短く）
完璧な一択はない。状況で選ぶ。
1. SPF にサイト側の送り元を足す（根本に近い）
DNS の SPF（名簿）に、フォームが動いているサーバー（IP またはホスティングが案内する書き方）を追加する。
「このドメイン名義で、このサイト側からも送ってよい」と宣言する、という意味になる。
注意点:
- 共用サーバーは、サイト用の向き先と、外向きメールの IP がずれることがある。厳密には届いたメールの経路情報や、ホスティングのドキュメントを見る。
- SPF だけでは足りず、受信側（M365 のポリシー・迷惑メール）が別途弾く場合もある。
2. 受信側（M365 など）で許可リストを付ける
送信元 IP や差出人を「信頼する／検疫しない」側に寄せる。DNS をすぐ触れないときの暫定や、SPF 後も届かないときの補完として使われる。
3. 送信経路を変える（恒久策の候補）
フォームから 会社メール側が認める送り方 で送るようにする。差出人と実際の送信元が揃いやすくなる（ふつうの会社メールに近いルート）一方、認証情報の扱い・実装の手間・サーバー設定が増える。
4. 届くまでをつなぐ暫定運用
制作側でよくやるのは、いったん届くことが確認できている別アドレスを宛先に足し、そこから本来の宛先へ転送する、といった迂回だ。原因解消までのつなぎであり、恒久策の代わりにはしない方がよい。
現場では担当が分かれることが多い
本稿は理解のため、設定をよしあき側で見られると仮定した。
実案件では、サイトは制作側・DNS や M365 は先方、と分かれることが多い。そのときは事前確認の結果（特に実際の送信元のホストや IP）をメール担当に渡し、「MX を変えてほしい話ではない／SPF や許可リストの対象は送信元側」と添えるとすれ違いが減る。構図の説明自体は、本稿と同じでよい。
まとめ
- 届かない原因のひとつとして、会社ドメインの見た目（差出人）と、実際に送っているサイト側サーバーのずれがあり、なりすまし扱いになりうること。
- サイトと無関係に会社ドメインで送るときは、ふつう 会社メール側の送信サーバー 経由で、差出人と送り元が揃いやすい。
- サイトの置き場とメールの受け取り口（MX）は別サービスでもよく、今回の論点はそれに加えて フォーム送信がサイト側から出ていること。
- 見分けるには、サイト／送り方／差出人／MX／SPF／症状を事前に確認する。
- 「このサイト側から送った場合は正規／通してよい」と伝える手段が、SPF への追加や 受信側の許可リストである。
記事の内容の正確さと判断についての責任はよしあきが負う。