サーバー移転後にメールが届かなくなる事故を防ぐため、SPF・DKIM・DMARCの設定確認から引き継ぎ手順まで実践的に解説します。
サーバーを移転したら、お客さまへのメールが全部迷惑メールに...
こんな悩み、ありませんか？
- サーバー移転後、問い合わせフォームからのメールが届かないと連絡が来た
- 取引先から「あなたのメールが迷惑メールフォルダに入っていた」と言われた
- 移転作業はエンジニアに任せたが、メール設定の引き継ぎを誰も確認していなかった
Web制作の現場で、サーバー移転後のメール障害は非常に多いトラブルのひとつです。Fivenineでも過去に、クライアント企業のサーバー移転支援をした際、移転直後から受注メールが届かなくなるという事態に遭遇したことがあります。幸い早期に検知できましたが、気づかなければ数日分の問い合わせを丸ごと失っていたかもしれません。
この記事では、**サーバー移転前後に必ず確認すべきメール認証設定（SPF・DKIM・DMARC）**の意味と、実際の引き継ぎ手順をチェックリスト付きで解説します。Web担当者やエンジニアが「何を・どの順番で・どう確認するか」を迷わず実行できる内容を目指しています。
あわせて読みたい
なぜサーバー移転でメールが壊れるのか
サーバーを移転する際、多くの担当者がWebサイトの動作確認やデータベースの移行に注力します。しかしメール認証に関わるDNS設定は「別の作業」として見落とされやすいのです。
メールの信頼性を支える認証技術には主に以下の3つがあります。
SPF（Sender Policy Framework）
DNSに「このドメインからメールを送信できるサーバーはこれです」と宣言するレコードです。サーバーのIPアドレスが変わると、旧サーバーのIPしか許可されておらず、新サーバーから送ったメールがSPF失敗となります。
DKIM（DomainKeys Identified Mail）
メールに電子署名を付加し、改ざんされていないことを証明する仕組みです。メールサーバーごとに専用の秘密鍵・公開鍵ペアを持つため、新サーバーでは新たに鍵ペアを生成し、公開鍵をDNSに登録し直す必要があります。
DMARC（Domain-based Message Authentication, Reporting & Conformance）
SPFとDKIMの認証結果に基づき「認証失敗メールをどう扱うか」をポリシーとして定義します。none（監視のみ）・quarantine（隔離）・reject（拒否）の3段階があり、設定が適切でないと正規メールまで弾かれます。
これら3つはすべてDNSレコードで管理されるため、ドメインのDNS管理と、メールサーバーの設定変更を連動させることが不可欠です。サーバーだけ移転してDNSを触らないと、古い設定のまま残り、認証が通らなくなります。
flowchart TD
A[メール送信] --> B{SPF確認}
B -->|Pass| C{DKIM確認}
B -->|Fail| F[迷惑メール・拒否]
C -->|Pass| D{DMARC確認}
C -->|Fail| F
D -->|Pass| E[受信トレイへ配信]
D -->|Fail| G[ポリシーに従い処理]
G --> H[none: 通過してレポート]
G --> I[quarantine: 迷惑メール]
G --> J[reject: 完全拒否]移転前に現状を記録する｜既存設定の棚卸し手順
移転作業を始める前に、現在の設定を完全に記録しておくことが最初のステップです。移転後に「元の設定に戻せない」という事態を防ぐためです。
ターミナルで現状のDNSレコードを確認する
# SPFレコードの確認
dig TXT example.com +short
# DKIMレコードの確認（セレクタ名は環境によって異なる）
dig TXT default._domainkey.example.com +short
dig TXT mail._domainkey.example.com +short
# DMARCレコードの確認
dig TXT _dmarc.example.com +short
出力結果をスプレッドシートなどに記録しておきましょう。特に以下の値は必ずメモしてください。
- SPF:
v=spf1で始まるTXTレコード全体 - DKIM: セレクタ名（
defaultやmailなど）とp=以降の公開鍵文字列 - DMARC:
v=DMARC1で始まるTXTレコード全体（rua=のレポート送信先も含む）
新サーバー移転後の設定手順
Step 1：新サーバーのSPFレコードを更新する
新サーバーのIPアドレスまたはホスト名を確認し、SPFレコードに追加します。
; 旧設定（旧サーバーのIPのみ）
example.com. IN TXT "v=spf1 ip4:203.0.113.1 ~all"
; 新設定（新サーバーのIPに更新、または include で追加）
example.com. IN TXT "v=spf1 ip4:198.51.100.5 ~all"
; MailgunやSendGridなど外部サービスと併用する場合
example.com. IN TXT "v=spf1 ip4:198.51.100.5 include:sendgrid.net ~all"
注意点: SPFレコードはドメインにつき1件しか持てません。複数のTXTレコードをバラバラに作ると「SPF PermError」が発生します。必ず1行にまとめてください。
Step 2：新サーバーでDKIM鍵ペアを生成し、DNSに公開鍵を登録する
PostfixやExim、cPanelなど利用するメールサーバーによって操作が異なりますが、概念は共通です。
# OpenSSLでDKIM用の鍵ペアを手動生成する例
openssl genrsa -out dkim_private.key 2048
openssl rsa -in dkim_private.key -pubout -out dkim_public.key
# 公開鍵をDNS登録用の形式で確認
cat dkim_public.key | grep -v '^-' | tr -d '\n'
生成した公開鍵をDNSに登録します。セレクタ名は mail2025 のように年月を含めると、ローテーション管理がしやすくなります。
; DKIMのDNSレコード（TXTレコード）
mail2025._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq...(公開鍵の文字列)..."
Step 3：DMARCポリシーの見直し
移転直後は none ポリシーで様子を見るのが安全です。認証が安定したら段階的に強化します。
; 移転直後（監視のみ）
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"
; 安定確認後（隔離モード）
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]"
; 最終形（完全拒否）
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"
rua に指定したメールアドレスには各受信サーバーからXML形式のレポートが届きます。Google Postmaster Tools や DMARC Analyzer などを使うと、レポートを視覚的に確認できて便利です。
Step 4：移転後の動作確認ツール
設定変更後は以下のツールで正しく伝播・認証されているかを確認します。
- MXToolbox（https://mxtoolbox.com/）: SPF・DKIM・DMARCのレコード検証
- mail-tester.com: テストメールを送って認証スコアを確認
- Google Admin Toolbox: Gmailへの配信状況確認に有効
よくある失敗パターンと対処法
現場で何度も見てきた失敗をまとめました。
❌ 失敗1：「移転したのにDNSを変更し忘れた」
サーバー会社にドメイン管理もまとめて依頼しているケースで起きがちです。サーバーのIPは変わったのにDNSのAレコード・MXレコードが旧サーバーを向いたまま、という状態が続きます。移転作業前に「ドメインのDNS管理者は誰か」を必ず明確にしてください。
❌ 失敗2：「TTLを短くしないまま切り替えた」
DNSにはTTL（キャッシュ保持時間）があります。デフォルトが86400秒（24時間）のまま切り替えると、旧設定が最大24時間世界中のDNSサーバーにキャッシュされ続けます。移転の48〜72時間前にTTLを300〜600秒に下げておくのがセオリーです。
❌ 失敗3：「SPFレコードを2行に分けて作った」
前述の通り、SPFは1行のTXTレコードにまとめる必要があります。「includeを追加しよう」と思って既存レコードを残したまま新しいTXTレコードを作ると PermError になります。既存レコードを編集する形で更新してください。
❌ 失敗4：「旧サーバーを即日廃止してしまった」
DNS伝播が完全に終わるまでの間、旧サーバーへのメールが届く可能性があります。少なくとも移転後72時間は旧サーバーを残しておくか、旧サーバーから新サーバーへのメール転送を設定しておくと安全です。
まとめと次のステップ
サーバー移転でのメール障害は、事前の確認と手順の整備でほぼ100%防げます。特にSPF・DKIM・DMARCの3点セットは「移転後に設定する」ではなく「移転前に棚卸しし、移転と同時に引き継ぐ」という意識が重要です。
まず今すぐできることは、現在のDNSレコードを dig コマンドやMXToolboxで確認し、SPF・DKIM・DMARCの3つが正しく設定されているかをチェックすることです。移転の予定がある場合は、少なくとも1週間前から準備を始めることを強くお勧めします。
「設定を見たけれど正しいかどうか判断できない」「移転作業を安全に任せたい」という場合は、Fivenineにご相談ください。サーバー移転から認証設定の引き継ぎ、移転後の動作確認まで一括でサポートしています。
サーバー管理、丸ごとお任せください
サーバー保守・運用
監視・障害対応・パフォーマンス改善まで、安定稼働をサポートします
※ 通常1営業日以内にご返信します
