ホームページのリニューアルやサーバー移転のすぐ後から、社員の普段のメールが取引先で「迷惑メールに入っていた」「届いていない」と言われることがあります。移転時のDNSレコードの写し漏れや、送信元の変更に伴う認証設定の不整合などが原因になります。DNS は、サイトとメールの行き先を決める設定です。
当社のドメインでDNSの行を全部書き出したところ、58件のうち26件がメール関係でした。サイトのことだけを考えて移すと、半分近くが漏れかねません。この記事では、発注前に埋める4項目の確認表を先に示し、そのあとで仕組みと実例、切替後の確かめ方を説明します。
発注前に「ドメインの登録業者」「DNSを提供する会社」「DNSを変更する権限を持つ人」「メールサービスの設定担当」の4欄を埋め、制作会社に「メール用のDNSレコードも移行の対象に入れてほしい」と書面で伝えます。切替の前と後に、「会社→Gmail」「Gmail→会社」の往復でメールを送り、「メッセージのソースを表示」でSPF・DKIM・DMARCの結果を読みます。3つとも合格でも相手の迷惑メールに入るときは、相手に届いた日時・件名・ヘッダーを頼みつつ、送る側の評価や送信経路も並行して確かめます。
発注前に埋める確認表
4欄の確認表
リニューアルやサーバー移転を頼む前に、次の4欄を埋めます。全部が分からなくても構いません。空いた欄が、制作会社に最初に調べてもらうことになります。
| 欄 | 書くこと | 調べ方 |
|---|---|---|
| ドメインの登録業者 | 会社名と、契約しているアカウントの名義 | 登録業者から届く更新のお知らせメール。.jp はJPRSのWHOIS、.com などはICANN LookupのRDAP検索 |
| DNSを提供する会社 | ネームサーバーの持ち主 | WHOISやRDAPの「ネームサーバー」の欄を手掛かりにする。ns-○○.サーバー会社名 のような形で出ることが多い |
| 変更の権限を持つ人 | DNSの管理画面に入れる人の名前と、社内か社外か | 社内で管理画面のログイン情報を持っている人に聞く。前の制作会社だけが持っていることもある |
| メールサービスの設定担当 | メールの契約先と、SPF・DKIMの設定を誰が入れたか | 毎月の請求書、メールソフトのアカウント設定画面の受信・送信サーバー名 |
.com などのドメインの登録情報は、2025年1月から RDAP という仕組みが正式な提供手段になっています。ただし、ネームサーバーの名前で分かるのは「どの会社のDNSらしいか」までです。契約先と、実際に変更できる管理画面は、契約書・請求書・管理画面へのログインで確定させます。
登録業者とDNSの権限が前の制作会社の名義のままになっていると、移転の作業そのものが進みません。名義の考え方はホームページ制作でサーバー・ドメインは誰の名義にすべき？、制作会社を変えるときの引き継ぎ全体はホームページの制作会社を変更したい｜引き継ぎで確認する7つのことにまとめています。
制作会社へ渡す依頼文の例
確認表と一緒に、次のように書いて送ると、メールが作業の対象から外れにくくなります。
今回のリニューアル（またはサーバー移転）について、次の3点をお願いします。
1. DNSを変更する場合、変更前のDNSの全レコードを書き出して共有してください。メール関係（MX・SPF・DKIM・DMARC・メールサーバー用の行）も移行の対象に含めてください。
2. 新しいサーバーや問い合わせフォームから、当社のドメインでメールを送る場合は、SPFとDKIMへの追加が必要か確認してください。
3. 切替の日時を事前に教えてください。切替の前と後に、当社から社外へ、社外から当社へ（代表アドレスと転送の設定を含む）の送受信を確かめます。旧サーバーの解約は、その結果を見てから当社が判断します。
現在分かっている情報は、添付の確認表のとおりです。空欄の箇所は調べていただけると助かります。
3点目は特に大事です。旧サーバーにメールが付いていた場合、解約した日からメールが止まります。
なぜサーバー移転でメールが巻き込まれるのか
4つの役割は別の会社でも、設定は同じ管理画面に並ぶ
会社のドメイン（example.co.jp など）の周りには、少なくとも4つの役割があります。
| 役割 | 何を決めているか | 契約先の例 |
|---|---|---|
| ドメインの登録 | ドメインの持ち主と、DNSをどこに置くか | ドメインの登録業者 |
| DNS | サイトとメールの行き先 | 登録業者、サーバー会社、専用のDNSサービス |
| サイトのサーバー | ホームページの中身を置く場所 | レンタルサーバー、クラウド |
| メールサービス | 社員のメールボックスと送信 | サーバー付属のメール、Google Workspace、Microsoft 365 |
この4つが別々の会社でも、サイトとメールの設定を同じDNS管理画面で扱っていることがあります。そこに「サイトはこのサーバー」「メールはこのサービスで受ける」「このサーバーから送るメールは本物」という行が並んでいます。
巻き込まれる3つの形
- DNSごと引っ越すときの写し漏れ：新しいサーバー会社のDNSへ切り替える際、サイトの行だけを作り、メールの行（MX・SPF・DKIMなど）を作らない
- 旧サーバーの解約：メールが旧サーバーに付属していたのに、サイトの移転を終えたつもりで旧サーバーを解約する
- 送信元の追加漏れ：新しいサイトの問い合わせフォームが新しいサーバーから会社のドメインでメールを送るのに、SPFにそのサーバーが入っていない
1と2は社員の普段のメールに、3は主にフォームの通知メールに影響します。フォームについては問い合わせフォームのメールが届かない原因と直し方で詳しく扱っています。
実例：first-ch.com のDNSを移す計画で書き出した58件
当社のドメイン first-ch.com でも、DNSを別のサービスへ移す計画を立てた際（2026年10月18日時点）に、いまのDNSにある行を全部書き出しました。登録業者・サイトとメールの提供元・移行先の3社が異なる構成です。
| 役割 | 会社 |
|---|---|
| ドメインの登録 | お名前.com |
| DNS・サイトのサーバー・メール | ConoHa |
| DNSの移行先 | Cloudflare |
移すのはDNSだけで、サイトとメールのサーバーは動かさない計画です。それでも、DNSにあるメール関係の行は全部、移行先に同じ内容で作り直す必要があります。
| 種類 | 件数 | 役割 |
|---|---|---|
| MX | 5 | メールをどのサーバーで受けるか |
| メール用のA | 10 | メールサーバーの住所 |
| SPF | 5 | 送ってよいサーバーの一覧 |
| DKIM | 5 | 電子署名を確かめる公開鍵 |
| DMARC | 1 | 認証に失敗したメールの扱いの指示（p=none） |
| メール関係の合計 | 26 | |
| サイト・その他 | 32 | サイトのA、各サービスへのCNAME、所有確認など |
| 全体 | 58 |
件数は、2026年10月18日時点に書き出した一覧の行数です。SPFの5件は表の上での合計で、同じ名前にSPFを5行置いてよいという意味ではありません。SPFは1つの名前につき1行にします（2行以上あると、後で説明するPERMERRORの原因になります）。
58件のうち26件がメールの行でした。サイトのことだけを考えて行を作り直すと、この半分近くが漏れることになります。
もう1つ分かったのは、管理画面の表示と、実際に公開されているDNSが一致しない行があったことです。DKIMの行が1件、管理画面には残っているのに値が空で、外からDNSに問い合わせても応答がありませんでした。移行の前後で比べるときは、管理画面の一覧だけでなく、公開されたDNSの応答と照らし合わせる必要があります。
※ここに載せたのは、公開されたDNSで誰でも確かめられる範囲だけです。
切替の前後に確かめること
切替前に、同じ条件で一度試しておく
切替の前に、後で行うのと同じ送り方・同じ宛先でテストを1回済ませておきます。切替前の結果が手元にあれば、切替後に何かが変わったとき、移転で変わったのか、もともとそうだったのかを分けられます。
「会社→Gmail」と「Gmail→会社」を往復で試す
切替の当日と翌日に、次の組み合わせで送ります。送るだけのテストでは、MXの写し漏れのような「受け取れない」障害は見つかりません。
| 向き | 送り方 | 確かめること |
|---|---|---|
| 会社→Gmail | 社員が普段使っているメールソフトや送り方で、自分が管理する社外のGmailへ送る | 届くか、迷惑メールに入らないか、認証の結果（下の手順） |
| Gmail→会社（個人のアドレス） | そのGmailから社員のアドレスへ送る | 社員のメールボックスに届くか |
| Gmail→会社（代表アドレス） | info@ など、問い合わせ用の代表アドレスへ送る | 代表アドレスに届くか |
| Gmail→会社（転送） | 転送の設定があるアドレスへ送る | 転送先まで届くか |
社内のアドレスどうしで送っても、外から見た判定は分かりません。必ず社外のアドレスを片側に入れます。
届かなかったときは、返送されてきたエラーメールを全文のまま保存し、送った時刻と届かなかった宛先を書き留めます。返送メールの本文には、どのサーバーで何が起きたかが書かれているので、要約せずにそのまま制作会社やメールの設定担当へ渡します。
Gmailで認証の結果を見る
会社から送ったメールがGmailに届いたら、パソコンのGmailでそのメールを開き、返信アイコンの横にある「その他」から「メッセージのソースを表示」を選びます。新しい画面の上部に、SPF・DKIM・DMARCの結果が並びます。
結果の読み方
| 表示 | 意味 | 次にすること |
|---|---|---|
| PASS | その方式の確認に合格した | DKIMは括弧内のドメインが自社のドメインかも見る |
| FAIL・SOFTFAIL など | 確認したが合格しなかった | 送ったサーバーがSPFに入っているか、DKIMの鍵が移行先にあるかを制作会社とメールの設定担当に確かめてもらう |
| NONE など結果が無い | その方式の設定や署名が見つからない | DNSの写し漏れを疑う。切替前に書き出した一覧と比べる |
| TEMPERROR | DNSへの問い合わせなどで一時的な問題が起きた | 時間をおいて送り直し、もう一度確かめる。何度送っても続くときは、制作会社やメールの設定担当に問い合わせる |
| PERMERROR | 設定そのものに誤りがあり、確認できなかった | 書き方の崩れや、同じドメインにSPFの行が2行以上登録されていないかを見直してもらう |
DMARCは、SPFかDKIMのどちらかが合格し、しかもその合格したドメインが差出人（From）のドメインと一致したときに合格になります。たとえばDKIMが合格でも、署名しているのがメールサービス会社のドメインで、自社のドメインと違えば、DMARCの合格にはつながりません。
ここでいう「一致」は、完全に同じ文字列である必要はありません。特に指定しない既定の設定（緩和モード）では、同じ組織のドメインであれば一致とみなされます。たとえば差出人が example.co.jp で、DKIMの署名が mail.example.co.jp のようなサブドメインでも、一致として扱われます。括弧内のドメインがサブドメインになっていても、それだけで設定の誤りと考える必要はありません。
もう1つ混同しやすいのが、DMARCのポリシーです。DNSに書く p=none・p=quarantine・p=reject は、「DMARCに不合格だったメールを受け取った側がどう扱うか」の指示で、合否の結果とは別のものです。p=none は「不合格でも特別な扱いをしなくてよい」という指示であり、合格したという意味ではありません。p=none のままでも、結果の欄には FAIL が出ることがあります。
全部合格でも相手の迷惑メールに入るとき
自分のテストで分かるのはここまで
自分のGmailで3つとも合格していれば、今回テストした送信経路では認証に合格しています。ただし、それは送る側の問題がすべて無いという意味ではありません。また、取引先がどのメールサービスを使い、どんな振り分けの設定をしているかは、こちらからは見えません。
そのため、相手側への確認と、送る側の確認を並行して進めます。
相手に頼む項目
相手側で迷惑メールに入るときは、次の項目を頼んで、こちらの制作会社やメールの設定担当に渡します。
- 届いた日時（迷惑メールに入ったものと、正常に届いたものの両方があればなおよい）
- 件名と差出人のアドレス
- 迷惑メールに入ったメールのヘッダー（Gmailなら「メッセージのソースを表示」の内容）
- 相手が使っているメールサービスの名前（分かる範囲で）
相手側の振り分けで起きることとしては、たとえば次のようなものがあります。
- 相手の会社が、独自の振り分けの規則やセキュリティ製品を入れている
- 受け取った人が、以前に似たメールを迷惑メールとして報告している
- 本文のリンク先や添付ファイルが、相手側の基準で危険と判定された
ヘッダーがあれば、相手のサーバーがSPF・DKIM・DMARCをどう判定したかが分かり、送る側の問題か、相手側の振り分けかを絞れます。
送る側で確かめること
認証に合格していても、送る側の要因が残ることがあります。制作会社やメールの設定担当に、次の点を確かめてもらいます。
- 送信経路の違い：迷惑メールに入ったメールと、自分のテストのメールが、同じサーバー・同じ送り方で出ているか。たとえば、テストはメールソフトから、問題のメールはフォームや一斉配信の仕組みから、という違いがあれば、テストの合格は問題のメールには当てはまりません
- 共有IP・ドメインの評価：レンタルサーバーのメールは、ほかの契約者と同じ送信元のIPアドレスを使うことが多く、その評価の影響を受けます。Googleの案内でも、共有IPの評価が到達率に影響するとされています
- 拒否リスト：送信元のIPアドレスやドメインが、迷惑メールの拒否リストに載っていないか
- 送信量：切替の前後で、同じドメインから送る量が急に増えていないか
ヘッダーの判定と、この4点の結果を並べると、どちらの側から手を付けるかを決めやすくなります。
Gmail宛ての要件で押さえる点
個人用のGmail宛てには、Googleが送信者の要件を定めています。社員の普段のメールだけを送る会社なら、SPFかDKIMのどちらかを設定し、迷惑メールとして報告される率を低く保つことが中心です。上の往復テストでSPF・DKIM・DMARCの結果を確かめておけば、この点の確認も兼ねられます。送る量で変わる細かい要件は、末尾の補足にまとめました。
公開されているDNSの設定を確かめる
切替の前後に、自社のドメインでMX・SPF・DKIM・DMARCの行が公開されているかを見るには、メール設定チェッカーが使えます。ドメイン名を入れると、公開されたDNSから4種類の行を引き、SPFの書き方やDMARCのポリシーを読み解きます。
ただし、このチェッカーで分かるのは、DNSにどう書かれているかまでです。実際に送ったメールの署名が合格したか、相手に届いたかの証明にはなりません。DNSの書き出しとの照合はこのチェッカーで、送受信の確認は「切替の前後に確かめること」の往復テストで、と分けて使います。
補足：Googleの送信者の要件（2026年10月29日に確認）
個人用のGmailアカウント宛てに送るときの要件は、送る量で分かれています。ここでいう大量送信者は、同じ主ドメインから個人用Gmail宛てに24時間で約5,000通以上を送る送信者です。
| 項目 | すべての送信者 | 大量送信者（24時間で約5,000通以上） |
|---|---|---|
| SPF・DKIM | どちらか一方を設定 | 両方を設定 |
| DMARC | 要件に無い | 設定が必要 |
| Fromのドメインと、SPFかDKIMのドメインの一致 | 要件に無い | 必要 |
| ワンクリックの登録解除 | 要件に無い | マーケティングのメールなどで必要 |
| 共通 | 正しいPTRレコード、TLSでの送信、迷惑メール率0.3%未満、RFC 5322に沿った形式、GmailのFromのなりすましをしない | 同左 |
表の注意点は3つです。
- 対象は、個人用のGmailアカウント宛てのメールです
- 1日の送信数は、同じ主ドメインのサブドメインから送った分も合算します。社員の普段のメールは少なくても、news.example.co.jp のようなサブドメインからメールマガジンを大量に送っていれば、合わせて数えます
- 一度でも大量送信者に分類されると、その後に送る量を減らしても分類は続きます
社員の普段のメールだけで、ほかに大量の配信をしていない会社なら、「すべての送信者」の側に入ります。ただし、切替の確認でDMARCまで合格しておけば、送る量が増えたときに慌てずに済みます。出典はGoogle Workspace 管理者ヘルプ「メール送信者のガイドライン」と、英語版のよくある質問です。英語版のよくある質問では、適用範囲と送信数の数え方のほか、2025年11月から要件を満たさないメールへの対応を強めることが書かれています。
冒頭の4欄の確認表を埋めたうえで、ホームページ制作のサービスでは、メールのDNSを含めた移転の範囲からご相談いただけます。
