1つのドメインに対して、Webの表示を担当するサーバーとメールを担当するサーバーは、DNSの別々のレコードで指定されています。ブラウザがアクセスする先を決めるのがAレコード、そのドメイン宛のメールを受け取る先を決めるのがMXレコード、そのドメインを名乗って送信してよいサーバーを宣言するのがTXTレコード（SPF・DMARC）です。同じレンタルサーバー契約であっても、この3つは独立して別のサーバーへ向けられます。
この構造を知らないと、トラブルのときに見る場所を間違えます。「サイトは普通に見えているのにメールだけ届かない」という報告を受けてWebサーバーのログを掘っても、原因はそこにありません。Webの向き先とメールの向き先は別のレコードで決まっているので、症状ごとに見るべきレコードが決まっているからです。
この記事は、書体のように「どのサーバーが偉いか」を並べるカタログではありません。いま担当しているドメインのWebとメールが、実際にどのサーバーへ振り分けられているかをDNSから読み取り、障害が起きたときにWeb側・メール送信側・メール受信側のどこを見に行けばよいかを切り分けられるようになることをゴールにしています。記事の後半には、ターミナルで4回コマンドを打つだけで判定できる検証手順と、合否ラインの表を用意しました。
なお、SPF・DKIM・DMARCの設定方法とPHPからのSMTP送信の実装は、この記事では扱いません。専用の記事に分けてあるので、切り分けの結果「認証レコードが原因」と分かった時点でそちらへ進んでください。本記事は「レコードが引けているか・揃っているか」の判定までを担当します。
本記事に記載した仕様・数値・ブランド名は、すべて2026年8月1日時点で提供元の一次資料を直接確認した内容です。該当箇所には出典へのリンクを置いています。メールの受信要件は各社が随時更新しているため、実務で判断する前には必ず最新の表示を確認してください。
1つのドメインに、サーバーは何台ぶら下がっているのか
DNS（Domain Name System）は、ドメイン名から「行き先」を引くための対応表です。重要なのは、この対応表が1行ではないことです。同じ example.com というドメインに対して、用途ごとに別々のレコードが並んでおり、それぞれが違うサーバーを指せます。
レコードの種類と、それが決めていること
Web制作の実務で押さえておくべきレコードは5種類です。「症状」の列がそのまま、あとで使う切り分け表の入口になります。
| レコード | 決めていること | 壊れたときに出る症状 |
|---|---|---|
| A / AAAA | ブラウザがアクセスするWebサーバーのIPアドレス | サイトが表示されない・古いサーバーが表示される |
| MX | そのドメイン宛のメールを受け取るサーバー | 自社ドメイン宛のメールが届かない |
TXT（v=spf1） | そのドメインを名乗って送信してよいサーバー（SPF） | 送ったメールが迷惑メールに入る・拒否される |
TXT（_dmarc） | 認証に失敗したメールをどう扱うかの方針（DMARC） | Gmail・Outlook.com宛だけ届かない |
| CNAME | 別名の割り当て（DKIMの公開鍵配布などに使われる） | DKIM署名の検証が通らない |
この表からすでに1つの結論が出ます。Webサイトが正常に見えていることは、メールが正常であることの証拠にならないということです。AレコードとMXレコードは互いに独立していて、片方が正しくてももう片方が空でも、DNSとしては何のエラーにもなりません。
Webとメールが分かれる4つの典型パターン
制作案件で遭遇する構成は、だいたい次の4パターンに収まります。自分が担当しているサイトがどれに当たるかを言えるようにしておくと、障害時の初動が速くなります。
| パターン | Aレコードの向き先 | MXレコードの向き先 | よくある場面 |
|---|---|---|---|
| 同居型 | レンタルサーバー | 同じレンタルサーバー | ConoHa WING・エックスサーバーの標準構成 |
| Web分離型 | 静的ホスティング（Vercel・Netlify・Cloudflare Pagesなど） | メール専用の別サービス | フロントを静的化した企業サイト |
| メール分離型 | レンタルサーバー | Google Workspaceなどのクラウドメール | 社内メールをGmailに寄せた会社のコーポレートサイト |
| 送信専用型 | レンタルサーバーまたは静的ホスティング | MXレコードなし（受信しない） | フォーム通知だけを外部へ飛ばすLP・キャンペーンサイト |
ここで大事なのは、4つのうちどれが正しいかではなく、自分の案件がどれなのかを即答できることです。「メール分離型なのに、レンタルサーバー側のメール設定を見に行った」という時間の使い方が、切り分けでいちばんよく起きるロスです。
「受け取るサーバー」と「送り出すサーバー」も別物
MXレコードは受信の宛先だけを決めています。送信には一切関与しません。自分のドメインからメールを送り出すサーバーがどれであるかは、MXではなくSPFレコード（TXT）の中身が示しています。
この非対称を押さえておかないと、「MXはGoogle Workspaceに向いているから送信もGoogle経由のはず」という誤った前提で調べ始めてしまいます。実際には、MXはGoogle Workspaceに向けつつ、WordPressの通知メールだけはレンタルサーバーから直接出ている、という構成がごく普通に存在します。この場合、SPFにレンタルサーバー側の送信元が含まれていなければ、その通知メールだけが落ちます。
▶ Web側（HTTP・データベース・API）の全体像はこちらで整理しています
HTMLサイトのサーバー｜静的配信が担当する範囲
HTML・CSS・JavaScriptだけで構成された静的サイトは、サーバーに「置いてあるファイルをそのまま返す」ことしか求めません。データベースもPHPも不要なので、必要な機能はAレコードが指すWebサーバー1台で完結します。
代表的なWebサーバーと静的ホスティング
| 名前 | 種別 | 2026年8月時点の位置づけ |
|---|---|---|
| Apache | Webサーバーソフト | モジュール構成が柔軟。.htaccess でディレクトリ単位の設定ができる |
| Nginx | Webサーバーソフト | イベント駆動で同時接続に強い。リバースプロキシとしても使われる |
| Vercel | ホスティングプラットフォーム | 公式サイトの見出しは「Agentic Infrastructure」。静的配信に加えてサーバーレス関数・SSR・AI向け基盤を含む |
| Netlify | ホスティングプラットフォーム | 公式サイトの見出しは「Push your ideas to the web」。Functions・Database・Edge networkを備えたアプリ基盤 |
| Cloudflare Pages / GitHub Pages | ホスティングサービス | Gitリポジトリと連携して静的成果物を配信する |
ここは古い解説が残りやすい箇所です。VercelとNetlifyを「Jamstack専用の静的ホスティング」と説明している記事は多いのですが、2026年8月1日時点でNetlify公式トップページに「Jamstack」という語は1件も出てきません（見出しは「Push your ideas to the web」で、Functions・Database・Observabilityが機能として並んでいます）。Vercelのトップページのタイトルも「Agentic Infrastructure」です。どちらもサーバーレス関数とSSRを備えたアプリケーション基盤であり、静的配信はその一部という位置づけになっています。出典はNetlify公式サイトおよびVercel公式サイトです。
静的ホスティングには、メールの受信機能が付いてこない
経路の話に戻すと、静的ホスティングを選んだ時点で構成は自動的に「Web分離型」になります。Aレコードをホスティング側へ向けても、MXレコードは何も設定されません。独自ドメインのメールを受け取りたければ、メール側は別のサービスを契約してMXを向ける必要があります。
レンタルサーバーからの移行でよく起きるのが、この取りこぼしです。「サイトをVercelに移した翌日から問い合わせメールが来なくなった」という事故は、Aレコードだけ書き換えてMXレコードを元のサーバーに残し忘れた（あるいは新しいDNSゾーンにMXを転記し忘れた）ことが原因です。移行時は必ずAとMXを別々に確認してください。
また、静的サイトのフォームには、送信を担当するプログラムがありません。ホスティング側のフォーム機能を使うか、サーバーレス関数から外部のメール送信サービスのAPIを叩くか、外部フォームサービスに預けるかのいずれかになります。いずれの場合も送信元は自分のドメイン以外のサーバーになるため、後述のSPFに影響します。
WordPressのサーバー｜LAMP・LEMPと公式の動作要件
WordPressは、リクエストを受けるたびにPHPを実行してデータベースから記事を組み立てます。したがって静的サイトと違い、Webサーバー・PHP・データベースの3つがそろっていないと動きません。
LAMPとLEMPは、何を使っているかの呼び分け
「LAMP構成」という言い方は広く使われていますが、頭文字の意味を取り違えたまま説明されていることがあります。LAMPの「A」はApacheです。したがって、LAMPの表に「Apache / Nginx」と並べて書くのは矛盾しています。
| 頭文字 | LAMP | LEMP |
|---|---|---|
| L | Linux（OS） | Linux（OS） |
| A / E | Apache（Webサーバー） | Nginx（Engine-x の「E」） |
| M | MySQL または MariaDB（データベース） | MySQL または MariaDB（データベース） |
| P | PHP（実行環境） | PHP（実行環境。PHP-FPM経由で動かすのが一般的） |
呼び分けを気にする実益は、.htaccess の有無にあります。ApacheはディレクトリごとにApache設定を読み込みますが、Nginxは .htaccess を読みません。「パーマリンクを変えたら404になった」「リダイレクトを書いたのに効かない」という症状に当たったとき、まず自分の環境がLAMPなのかLEMPなのかを確認すると原因に早く着けます。
WordPress公式が求める動作要件
サーバーを選ぶときは、WordPress.orgが公開している要件と照らすのがいちばん確実です。以下はWordPress.org「Requirements」ページを2026年8月1日に確認した内容です。
| 項目 | 推奨（公式が示すベースライン） | レガシー環境での動作 |
|---|---|---|
| PHP | バージョン 8.3 以上 | PHP 7.4 以上でも動作するが、公式にサポート終了（EOL）済み |
| データベース | MariaDB 10.11 以上 または MySQL 8.0 以上 | MySQL 5.5.5 以上でも動作するが、同じくEOL済み |
| HTTPS | すべてのインストールで必須 | — |
| Webサーバー | Apache または Nginx を推奨 | PHPとMySQLが動くサーバーであれば動作する |
実務上のポイントはHTTPSが「推奨」ではなく「必須（Required for every install）」と書かれていることと、レガシー版で動くこと自体は公式も認めているが「セキュリティ脆弱性にさらされる可能性があるためアップグレードを強く推奨」と明記されていることです。サーバー選定でPHPバージョンを確認するときは、8.3以上を出せるかどうかを最低ラインにしてください。
開発環境と本番環境の使い分け
| 環境 | 代表例 | 経路の観点で注意すること |
|---|---|---|
| ローカル開発 | Local / MAMP / XAMPP / wp-env | DNSを経由しないため、メール送信は基本的に飛ばない（送信内容を捕捉する仕組みを併用する） |
| レンタルサーバー | ConoHa WING / エックスサーバー / さくらのレンタルサーバ | Webとメールが同居する構成が既定。メールだけ他社へ移すならMXの向き先を明示的に変える |
| クラウド（IaaS） | AWS EC2 / Lightsail など | メール送信ポートが既定で制限されることがあり、外部のメール送信サービスを併用するのが一般的 |
案件でサーバーを契約するところから納品までの手順は、別の記事にまとめてあります。
▶ 案件でのサーバー契約・DNS・SSL・納品チェックの実務手順はこちら
サーバー別のインストール手順は、以下の記事で画面つきに解説しています。
WordPressのメールは「Webサーバーから出ていく」
ここがWeb側とメール側の接点です。WordPressの通知メール（パスワードリセット、コメント通知、問い合わせフォームの送信など）は、すべて wp_mail() という関数を通ります。この関数の実体を正確に押さえておくと、後の切り分けが一段速くなります。
よく「wp_mail() はPHPの mail() 関数を使っている」と説明されますが、これは正確ではありません。wp_mail() はWordPressに同梱されているPHPMailerを必ず利用します。そのうえで、既定では $phpmailer->isMail(); が呼ばれ、PHPMailerが「PHPの mail() を使うモード」に設定されているだけです。WordPressコアの wp-includes/pluggable.php には、この行の直前に // Set to use PHP's mail(). というコメントが置かれています。
この違いは言葉の細かさの問題ではなく、切り分けの手順を変えます。「PHPMailerを導入すればSMTPになる」のではなく、PHPMailerは最初から動いていて、そのモードを切り替えるだけだからです。切り替えは phpmailer_init フックで同じPHPMailerインスタンスを受け取り、isSMTP() を呼んでSMTPの接続情報を渡すことで行います。世の中のSMTPプラグインが内部でやっているのは、まさにこの処理です。
| 状態 | 実際に動いているもの | メールの送信元になるサーバー |
|---|---|---|
| WordPress既定 | PHPMailer（isMail() モード＝PHPの mail() 経由） | WordPressが動いているWebサーバー |
SMTPプラグイン導入後 / phpmailer_init で切替 | 同じPHPMailer（isSMTP() モード） | 指定したSMTPサーバー（Google Workspace・メール配信サービスなど） |
したがって、既定構成のWordPressではWebサーバーがそのままメールの送信元になります。ここでSPFレコードに「レンタルサーバーの送信元」が含まれていないと、認証に失敗して迷惑メール扱いになります。「MXはGoogle Workspaceに向いているのに、WordPressの通知だけ届かない」という典型的な症状は、この食い違いから生まれます。出典はWordPress公式の wp_mail() 関数リファレンスとphpmailer_init フックのリファレンスです。
▶ SMTP送信への切り替えとSPF・DKIM・DMARCの設定手順はこちら
メールのサーバー｜送信・受信・認証の3層に分けて見る
メールまわりが分かりにくいのは、1つの「メールサーバー」という言葉が3つの別々の役割を指してしまうからです。送信（SMTP）・受信（POP3 / IMAP）・認証（SPF / DKIM / DMARC）の3層に分けると、どこで詰まっているかを言葉にできるようになります。
プロトコルとポート番号の対応
メールソフトやSMTPプラグインの設定画面で必ず聞かれるのがポート番号です。番号の意味を覚えておくと、設定値が正しいかどうかを自分で判断できます。
| 用途 | プロトコル | 暗号化なし / STARTTLS | 暗黙TLS（接続直後にTLS） |
|---|---|---|---|
| メールサーバー同士の配送 | SMTP | 25 | — |
| メールソフト → 送信サーバー | Submission | 587 | 465（submissions） |
| 受信（サーバー上でメールを管理） | IMAP | 143 | 993（imaps） |
| 受信（端末へダウンロード） | POP3 | 110 | 995（pop3s） |
465・993・995 という「暗黙TLS」のポート番号は、RFC 8314 でIANA登録が更新され、メールソフトと送信・受信サーバーの間ではこの暗黙TLSの利用が推奨されています。587はメールソフトからの送信専用ポート（RFC 6409 のMessage Submission）で、多くのプロバイダが迷惑メール対策として25番ポートの外向き通信をブロックしているため、実務ではこちらを使います。
MXレコードが受信の宛先を決める
MXレコード（Mail eXchanger）は、そのドメイン宛のメールをどのホストへ配送すればよいかを外部のメールサーバーに知らせるレコードです。値はホスト名と優先度の数字の組で表され、数字が小さいほど優先されます。複数書けるので、1台目が応答しない場合に2台目へ回す冗長構成が作れます。
MXレコードが1件も設定されていないドメインは、外部からのメールを受け取れません。ただしこれは必ずしも異常ではなく、送信専用型（フォーム通知だけ飛ばす構成）では正常な状態です。「MXが空だから壊れている」と即断せず、そのドメインが受信する必要があるかどうかを先に確認してください。
SPF・DKIM・DMARCは「送信の正当性」を示す
3つとも「そのドメインを名乗ったメールが本物かどうか」を受信側が判定するための仕組みです。この記事では役割の理解と引けているかどうかの判定までを扱い、書き方の設計と設定手順は扱いません。
| 仕組み | 置き場所 | 証明していること | この記事での扱い |
|---|---|---|---|
| SPF | ドメイン直下のTXTレコード（v=spf1 で始まる） | そのIPアドレスから送ってよいと管理者が認めていること | 件数と有無を判定する |
| DKIM | セレクタ._domainkey.example.com のTXTまたはCNAME | 署名によって本文とヘッダーが改ざんされていないこと | 判定対象外（セレクタ名が分からないと引けないため） |
| DMARC | _dmarc.example.com のTXTレコード | SPF・DKIMに失敗したメールをどう扱ってほしいかの方針 | 存在とポリシーを判定する |
SPFで見落とされがちな仕様が1つあります。1つのドメインに v=spf1 で始まるTXTレコードを2件以上置いてはいけません。SPFの仕様であるRFC 7208 の4.5節には「取得したレコード集合に複数のレコードが含まれる場合、check_host() は permerror を返す」と明記されています。permerror はSPF評価そのものの恒久的エラーで、片方が正しく書けていてもSPF全体が無効と判定されます。
これは、レンタルサーバー側が自動で入れたSPFと、あとからメール配信サービスの案内どおりに追加したSPFが並んでしまう形でよく起きます。送信元を増やすときは新しい行を足すのではなく、既存の1行の中に include: を追加して1件にまとめます。具体的な書き方は設定側の記事に譲ります。
代表的なメールサービスと、押さえておく制限
サービス名だけを並べても選定の役には立ちません。経路を組むときに実際に効いてくる制限を添えて整理します。数値・ブランド名はいずれも2026年8月1日に提供元の公式ページで確認したものです。
| サービス | 位置づけ | 経路設計で効く仕様 |
|---|---|---|
| Google Workspace（Gmail） | 受信・送信ともクラウドで完結 | 2025年3月14日以降、IMAP / SMTP / POP / CalDAV / CardDAV でパスワードだけの基本認証が使えない。OAuth 2.0 かアプリパスワードが必要 |
| Twilio SendGrid | 通知メール・一斉配信のAPI / SMTP | sendgrid.com は twilio.com/en-us/sendgrid へ転送される。表記は「Twilio SendGrid」 |
| Mailgun | 同上（開発者向けの送信API） | 現在はSinchのメール事業（Sinch Email）の一員として提供されている |
| さくらのメールボックス | メール専用のレンタルプラン | 月額88円〜／SSD 20GB／メールアドレス数無制限／マルチドメイン20個／SPF・DKIM・ARC・DMARC対応。Webホスティング機能は付かない |
| エックスサーバー | Webとメールが同居するレンタルサーバー | MTAはPostfix。SMTP / POP3 / IMAP（over SSLに対応）。送信数の目安は1,500通/時間・15,000通/日。25番ポートブロック環境では587を利用 |
| Postfix / Dovecot / Exim | VPS等で自前運用するソフト | Postfix・Eximが送信（MTA）、Dovecotが受信（POP3 / IMAP）を担当。IP評判の管理まで自分の責任になる |
出典はGoogle Workspace「安全性の低いアプリからOAuthへの移行」、Twilio SendGrid公式ページ、Mailgun公式サイト、さくらのレンタルサーバ メール機能（メールボックス）、エックスサーバー メール関連の仕様一覧です。
さくらのメールボックスに「Webホスティング機能なし」と書かれている点は、経路の観点で見ると重要です。このプランを契約してもAレコードの向き先にはならないので、Webは別途どこかに置くことになります。つまり最初から「メール分離型」の構成を作るプランだということです。
2024〜2025年に変わった「メールが届く条件」
ここ数年で、メールの前提が大きく変わりました。かつては「とりあえず送れば届く」ものでしたが、主要な受信事業者が送信ドメイン認証の設定を受信の条件として要求するようになっています。古いサーバー解説を読んで構成を組むと、この部分だけが丸ごと抜け落ちます。
Gmail｜2024年2月1日から一括送信者に必須化
Googleは2024年2月1日から、個人向けGmailアカウント宛に1日5,000通以上を送る一括送信者に対して、SPFとDKIMの両方の設定、送信元ドメインへのDMARC設定（ポリシーは p=none でも可）、正引き・逆引きの有効なDNSレコード、TLSでの送信を求めています。マーケティングメールと購読メールにはワンクリックでの登録解除が必要で、迷惑メール率は0.3%未満を維持することとされています（0.1%未満が望ましいとも記載されています）。
出典はGoogle「メール送信者のガイドライン」です。制作会社が扱う規模のサイトでは5,000通/日に届かないことが多いのですが、要件そのものは小規模でも満たしておくべき内容で、Google自身も一般の送信者向け要件としてSPFまたはDKIMの設定を求めています。
Yahoo（Yahoo Inc.）｜Bulk Sender要件はGmailとほぼ同等
米Yahoo Inc.も同時期に同等の要件を出しています。Yahoo Sender Hub「Best Practices」を2026年8月1日に確認したところ、Bulk Sender向けにSPFとDKIMの両方、p=none 以上の有効なDMARCポリシーとDMARCの合格、RFC 8058に対応したワンクリック登録解除、迷惑メール率0.3%未満、送信IPの正引き・逆引きDNSレコードが挙げられていました。すべての送信者向けにも、SPFまたはDKIMの実装と0.3%未満の迷惑メール率が求められています。
なお、このページはYahoo Inc.（yahoo.com 等）の要件であり、Yahoo! JAPANの受信ポリシーとは別物です。日本国内向けの案件では、Yahoo! JAPAN側の案内も併せて確認してください。
Microsoft Outlook.com｜2025年5月5日から適用開始
Microsoftも、コンシューマー向けメールサービス（outlook.com / hotmail.com / live.com / MSN など）宛の大量送信者に同等の要件を課しました。Microsoft Community Hubの告知（2025年4月2日公開・4月29日更新）には、対象を「1日5,000通を超えるドメイン」とし、2025年5月5日から適用すると書かれています。
ここは経緯を正確に押さえておく必要があります。この告知では「まず迷惑メールフォルダへ振り分け、問題が解消されなければ最終的に拒否する」という二段階が示されており、拒否の開始日は「後日発表」とされていました。一方、現在Microsoftが公開しているエラー「550 5.7.515」のサポート文書は、このエラーを実際に発生する拒否として案内しています。全文は 550 5.7.515 Access denied, sending domain [ドメイン] does not meet the required authentication level. です。
同サポート文書では、対象となる「大量送信者」を「Microsoftのコンシューマー向けメールサービス宛に5,000通以上を送信し、そのすべてが同一の 5322.From ドメインである」状態と定義し、SPFとDKIMの両方の合格、v=DMARC1; p=none 以上のDMARCレコードの公開、SPFまたはDKIMの少なくとも一方が 5322.From のドメインとアラインしていることを求めています。つまり実務上は「振り分けで済む」と考えず、拒否されうる前提で組むのが安全です。
3社の要件を並べて見る
| 項目 | Google（Gmail） | Yahoo Inc. | Microsoft（Outlook.com） |
|---|---|---|---|
| 適用開始 | 2024年2月1日 | 2024年前半に段階適用 | 2025年5月5日 |
| 対象 | 1日5,000通以上の一括送信者 | Bulk Sender | コンシューマー宛5,000通以上・同一の 5322.From ドメイン |
| SPF | 必須 | 必須 | 必須（合格が条件） |
| DKIM | 必須 | 必須 | 必須（合格が条件） |
| DMARC | 必須（p=none 可） | 必須（p=none 以上・合格が条件） | 必須（p=none 可・アラインが条件） |
| ワンクリック登録解除 | 必須（マーケティング・購読メール） | 必須（RFC 8058のPOST方式を強く推奨） | 機能する登録解除リンクを推奨事項として提示 |
| 迷惑メール率 | 0.3%未満 | 0.3%未満 | 明示の数値基準は示していない |
| 非準拠時の扱い | 配信への悪影響 | 配信への悪影響 | 迷惑メール振り分け、および 550 5.7.515 による拒否 |
3社を並べると、共通の最低ラインは「SPF・DKIM・DMARCの3つがそろっていること」だと分かります。ここが、この記事の検証パートで「揃っているか」を確認する理由です。
Google Workspaceのメールソフト接続はOAuth必須になった
受信側の変更も1つ押さえておきます。Googleは2025年3月14日以降、すべてのGoogleアカウントで「安全性の低いアプリ」（ID・パスワードだけの基本認証）を無効化しました。公式文書には「CalDAV、CardDAV、IMAP、SMTP、POP で従来のパスワード（基本認証）を使用できなくなります」と明記されており、対応方法としてOAuthを使うようデバイスを設定するかアプリパスワードを設定するかのいずれかが示されています。
これは、古いメールソフトや自作スクリプトからGmailのSMTPを叩いている構成を直撃します。「昨日まで動いていた送信スクリプトが認証エラーになった」という症状に当たったら、まずこの変更を疑ってください。
【検証】自分のドメインの経路を4つのコマンドで読み取る
ここまでの内容は、担当しているドメインで4回コマンドを打てば実際に確認できます。サーバーへのログインも管理画面へのログインも不要で、必要なのは手元のターミナル（Windowsの場合はPowerShell）だけです。他人のドメインでも同じように引けるので、既存サイトの引き継ぎ調査にもそのまま使えます。
手順｜4つのレコードを順に引く
example.com の部分を自分のドメインに読み替えて実行してください。
| # | 何を見るか | macOS / Linux | Windows（PowerShell） |
|---|---|---|---|
| 1 | Webがどのサーバーに向いているか | dig +short example.com A | Resolve-DnsName example.com -Type A |
| 2 | メールがどのサーバーに届くか | dig +short example.com MX | Resolve-DnsName example.com -Type MX |
| 3 | 送信を許可されたサーバー（SPF） | dig +short example.com TXT | Resolve-DnsName example.com -Type TXT |
| 4 | 認証ポリシー（DMARC） | dig +short _dmarc.example.com TXT | Resolve-DnsName _dmarc.example.com -Type TXT |
実際に、この記事を配信している codequest.work で4つを引いた結果が次のものです（2026年8月に実行）。
$ dig +short codequest.work A
118.27.122.218
$ dig +short codequest.work MX
10 mail76.conoha.ne.jp.
$ dig +short codequest.work TXT
"v=spf1 include:_spf.conoha.ne.jp ~all"
$ dig +short _dmarc.codequest.work TXT
"v=DMARC1; p=quarantine;"この4行から読み取れることを言葉にすると、「Webは 118.27.122.218、メールの受信は mail76.conoha.ne.jp（優先度10）、送信を許可されているのは _spf.conoha.ne.jp に含まれるサーバー、認証に失敗したメールは隔離（p=quarantine）」となります。同じ事業者の中でも、Webの向き先とメールの向き先はホストが別であることが実物で確認できます。
合否ライン｜返ってきた結果をどう判定するか
コマンドを打っただけでは検証になりません。返ってきた内容が合格かどうかを、次の基準で判定してください。
| # | 合格ライン | 外れている状態 |
|---|---|---|
| 1（A） | IPアドレスが1つ以上返る | 何も返らない／意図しない旧サーバーのIPが返る |
| 2（MX） | ホスト名が1つ以上返り、優先度の数字が付いている | 受信するはずのドメインなのに0件（送信専用型なら0件でも正常） |
| 1と2の関係 | 向き先が一致していても分かれていても可。ただし「どちらか」を自分の言葉で言えること | どちらか分からないまま作業を始めている |
| 3（SPF） | v=spf1 で始まるTXTがちょうど1件 | 0件（送信元が保証されない）／2件以上（RFC 7208違反でSPF全体が無効判定） |
| 4（DMARC） | v=DMARC1; p=none 以上が返る | 何も返らない（Gmail・Outlook.comの一括送信要件を満たせない） |
3のSPFは、dig +short example.com TXT の結果にサイト認証用のTXTなどが混ざって返ってくるので、v=spf1 で始まる行だけを数えてください。ここが2件以上あれば、それだけで原因が確定します。
DKIMは意図的に判定対象から外しています。DKIMの公開鍵は セレクタ._domainkey.example.com に置かれており、セレクタ名を知らないとそもそも引けないためです。セレクタ名は送信サービスごとに異なるので、確認は設定側の作業と一体で行います。
切り分け｜症状から見るべきレコードへ
実際にトラブルが起きたときは、症状から逆に引きます。次の表の「次の1手」に「設定側の記事へ」と出たら、この記事の役割はそこで終わりです。
| 症状 | 見るレコード | 疑う原因 | 次の1手 |
|---|---|---|---|
| サイトは見えるがメールが届かない | MX | MXが未設定・旧サーバーのまま | MXの向き先を現在の受信サービスへ直す |
| メールは届くがサイトが見えない | A / AAAA | Aが旧サーバーのまま・未設定 | Aの向き先を現在のWebサーバーへ直す |
| 送ったメールが迷惑メールに入る | TXT（SPF）・_dmarc | SPFに送信元が含まれていない・DMARC未設定 | 設定側の記事へ |
| SPFが2件返る | TXT（SPF） | RFC 7208違反でSPF全体が permerror | include: で1件に統合する。設定側の記事へ |
| Gmail宛だけ届かない | _dmarc | DMARC未設定またはアライメント不成立 | 設定側の記事へ |
Outlook.com宛が 550 5.7.515 で戻る | TXT（SPF）・_dmarc・DKIM | SPF・DKIM・DMARCのいずれかが未達 | 設定側の記事へ |
| WordPressからのメールだけ飛ばない | —（アプリ側） | wp_mail() が既定の isMail() モードのまま、SPFにWebサーバーが含まれていない | 設定側の記事へ |
上の2行（MXとA）は、この記事の中で完結します。DNSの向き先を直すだけで解決するからです。それ以外の5行は、いずれも認証レコードの設計と設定の話になるので、この記事では原因の特定までで止めます。ここで無理に設定手順まで書くと、同じ内容が2つの記事に散らばって、どちらが最新か分からなくなるためです。
▶ SPF・DKIM・DMARCの設定とSMTP送信の実装はこちら（切り分けの続き）
PHPの問い合わせフォームを自作していて、送信処理そのものを見直したい場合は次の記事も併せて確認してください。
まとめ｜経路が言えれば、切り分けは半分終わっている
HTML・WordPress・メールは、それぞれ別の種類のサーバーが担当しています。しかしWeb制作者にとって本当に必要なのは、サーバーの種類を暗記することではなく、担当しているドメインのAとMXとSPFがどこを指しているかを、その場で言えることです。
- Aレコード＝Webの向き先、MXレコード＝メールの受信先。この2つは互いに独立している
- MXは受信だけを決める。送信元の正当性はSPF（TXT）が示す
- 静的ホスティングにMXは付いてこない。Web移行時はAとMXを別々に確認する
- LAMPの「A」はApache。Nginxを使う構成はLEMPと呼び分ける
- WordPressは公式にPHP 8.3以上・MariaDB 10.11以上またはMySQL 8.0以上・全インストールでHTTPS必須
wp_mail()は常にPHPMailerを使い、既定はisMail()モード。SMTP化はphpmailer_initでの切り替え- Gmail・Yahoo・Outlook.comはいずれもSPF・DKIM・DMARCを要求する。Outlook.comは
550 5.7.515で拒否されうる - SPFは
v=spf1のTXTがちょうど1件。2件以上はRFC 7208違反で全体が無効判定
まずは、いま担当しているドメインで4つのコマンドを打ってみてください。合否ライン表と突き合わせるだけで、次に読むべき記事が決まります。
よくある質問（FAQ）
Q. MXレコードとAレコードは何が違いますか？
役割が違います。AレコードはWebブラウザがアクセスするサーバーのIPアドレスを指定し、MXレコードはそのドメイン宛のメールを受け取るサーバーのホスト名を指定します。両者は独立していて、片方だけ設定されていてもDNSとしてはエラーになりません。したがって「サイトが正常に表示されている」ことは、メールが正常に届いている証拠にはなりません。障害の切り分けでは、症状がWeb側かメール側かを先に決めて、対応するレコードを引き分けてください。
Q. Webサイトとメールを別々のサーバーに分けられますか？
分けられます。むしろ実務では分かれている構成のほうが多いくらいです。Aレコードを静的ホスティングやレンタルサーバーへ、MXレコードをGoogle Workspaceなどのクラウドメールへ向ければ、Webとメールは別々の事業者で運用できます。ただし送信の正当性を示すSPFレコードはドメイン単位で1件しか持てないため、送信元が複数になる場合はその1件の中に include: でまとめる必要があります。分けること自体は問題ではなく、SPFの管理を1本化できているかが分かれ目です。
Q. SPFレコードは2つ書いてもよいですか？
書いてはいけません。SPFの仕様であるRFC 7208の4.5節には、取得したレコード集合に v=spf1 で始まるレコードが複数含まれる場合、評価関数 check_host() は permerror を返すと明記されています。permerror はSPF評価そのものの恒久的エラーなので、2件のうち片方が正しく書けていてもSPF全体が無効と判定されます。送信元を追加するときは行を増やさず、既存の1行に include: を足して1件にまとめてください。
Q. MXレコードが1件も返らないドメインは異常ですか？
異常とは限りません。MXレコードは受信の宛先を決めるものなので、そのドメインで独自ドメインのメールを受け取らない構成（フォーム通知だけを外部へ送る送信専用型など）では0件が正常です。判定するときは「このドメイン宛にメールが届く必要があるか」を先に確認してください。届く必要があるのに0件なら、そこが原因です。なお、MXが0件でも送信自体は行えるため、SPFやDMARCの設定は別途必要になります。
Q. メールソフトの送信ポートは587と465のどちらを使いますか？
どちらもメールソフトから送信サーバーへ送るためのポートで、暗号化の始まり方が違います。587はSTARTTLSで途中から暗号化する方式、465は接続直後にTLSハンドシェイクを始める暗黙TLS方式（サービス名 submissions）です。RFC 8314ではIANA登録が更新され、暗黙TLSの利用が推奨されています。実際にどちらを設定するかは契約しているメールサービスの案内に従ってください。なお25番はサーバー同士の配送用で、多くのプロバイダが外向き通信をブロックしているため、メールソフトからの送信には使いません。
Q. 独自ドメインのメールアドレスはどこで作るのが早いですか？
Webも同じ契約で運用するなら、レンタルサーバーの管理画面でメールアカウントを作るのがいちばん手数が少ない方法です。ConoHa WINGやエックスサーバーではメールアドレス数が無制限で、MXレコードも契約時に自動で設定されます。メールだけを分けたい場合は、さくらのメールボックスのようなメール専用プラン（月額88円〜、Webホスティング機能なし）やGoogle Workspaceを契約し、MXレコードをそちらへ向けます。どの方法でも、作成後に必ずMXとSPFを引いて意図どおりの向き先になっているか確認してください。
Q. WordPressから送ったメールだけ届かないのはなぜですか？
既定のWordPressでは、メールの送信元がWordPressの動いているWebサーバーそのものになるためです。wp_mail() は同梱のPHPMailerを isMail() モード（PHPの mail() 経由）で使うのが既定なので、MXをGoogle Workspaceへ向けていても、通知メールだけはレンタルサーバーから直接出ていきます。SPFレコードにそのWebサーバーの送信元が含まれていなければ認証に失敗し、その通知だけが迷惑メール扱いになります。対処は phpmailer_init フックで isSMTP() に切り替えて送信元をそろえるか、SPFに送信元を追加するかのどちらかです。