先に要点
メールまわりの DNS 設定を触ると、MXレコード、SPF、DKIM、DMARC が一気に出てきます。
ただ、これらは全部同じ役割ではありません。メールの設定 とひとまとめにすると、受信の話と送信認証の話が混ざって分かりにくくなります。
この記事では、2026年4月22日時点で Google Workspace Admin Help、Microsoft Learn、Cloudflare Learning Center の一次情報を確認しながら、それぞれの違いを初心者向けに整理します。
問い合わせフォームの不達、独自ドメインメールの導入、DNS 切り替え、メール送信サービス導入で何を見ればよいかまでつなげます。
結論だけ先に言うと、
MX は受信先、SPF / DKIM / DMARC は送信ドメインの信頼性です。まずこの分け方が入ると、かなり迷いにくくなります。
まず結論: 4つの違いはこう見ると迷いにくい
| 項目 | 主な役割 | 何に効くか | ありがちな誤解 |
|---|---|---|---|
| MXレコード | 受信先メールサーバーを決める | 独自ドメイン宛てメールの受信 | MX を入れれば送信の信頼性も上がるわけではない |
| SPF | 送信を許可するサーバーを示す | なりすまし抑止、送信元の正当性確認 | SPF だけでメール認証が完成するわけではない |
| DKIM | 送信メールへ署名を付ける | 改ざん検知、正規送信の確認 | DNS にレコードを入れただけでは足りず、送信側で署名有効化も必要 |
| DMARC | SPF / DKIM の結果をどう扱うか示す | 認証失敗メールの扱い、集計レポート | DMARC だけ先に厳しくすると正規メールも落としやすい |
特に混ざりやすいのは、MX は受信の設定 なのに、届きやすさ全般 の話として扱ってしまうことです。
実際には、受信先を正しく向ける話と、送信メールが信頼される話は別です。
MXレコードとは: どこで受信するかを決める設定
MXレコード は、独自ドメイン宛てのメールをどのメールサーバーで受け取るかを決める設定です。
Cloudflare の説明でも、MX は メールをどのサーバーへルーティングするか を示し、優先度の低い数字が先に使われます。
たとえば example.com のメールを Google Workspace で受けるのか、Microsoft 365 で受けるのか、あるいは別のメールサービスで受けるのかは、MXレコードで決まります。
MXレコードが関係する場面
- 独自ドメインメールを導入するとき
- メールサービスを乗り換えるとき
- DNS 切り替え後に
メールだけ届かないとき - セキュリティ製品やゲートウェイ導入で受信経路が変わるとき
MXレコードで見落としやすいこと
- 優先度の数字を理解しないまま設定する
- 旧メールサービスの MX を残したままにする
- Web 移転だけ見て、メール系レコードを移し忘れる
- MX が正しくても、送信側認証は別に必要なことを見落とす
DNS切り替え後に確認すること｜Web・メール・SSLのチェックリスト でも触れている通り、サーバー移転時は Web だけでなく MX も必ず確認対象です。
SPFとは: そのドメインから送ってよい送信元を示す
SPF は、そのドメインを名乗ってメールを送ってよい送信元 を DNS の TXT レコードで示す仕組みです。
Google Workspace のヘルプでも、SPF は送信メールが迷惑メール扱いされにくくするために役立ち、たとえば Google Workspace のみなら v=spf1 include:_spf.google.com ~all のような形式を案内しています。
実務で大事なのは、実際に送っているサービスを全部 SPF に反映できているか です。
問い合わせフォーム、会員登録メール、メルマガ、CRM、外部SaaSが混ざると、思ったより送信元が増えます。
SPFでよくある失敗
- メール送信サービスを追加したのに SPF を更新していない
- 送信元が複数あるのに、一部しか include していない
- SPF レコードを複数作ってしまう
- 受信設定の MX と、送信設定の SPF を同じものだと思っている
SPF は大事ですが、これだけでは本文改ざんの確認や、認証失敗時の扱いまでは決まりません。
そこを補うのが DKIM と DMARC です。
DKIMとは: メールへ署名を付けて正規送信を確認しやすくする
DKIM は、送信メールへ電子署名を付け、受信側が DNS に公開された鍵情報を使って確認する仕組みです。
Google Workspace の DKIM 設定ガイドでも、DNS に公開鍵を追加したあと、管理画面で署名を有効化する流れになっています。2048-bit 鍵が使えるなら長い鍵がより安全という案内もあります。
ここで初心者がつまずきやすいのは、DNS レコードを入れたら終わりではない ことです。
多くの送信サービスでは、DNS に DKIM 用レコードを追加したうえで、そのサービス側で署名を有効化しないと実送信で pass しません。
DKIMで見たいポイント
- DNS に案内されたレコードが正しく入っているか
- 送信サービス側で DKIM 署名が有効になっているか
- 実際に送ったメールヘッダーで DKIM が pass しているか
- 複数ドメインやサブドメインで送る場合、署名ドメインが想定どおりか
DMARCとは: 認証失敗メールをどう扱うか決める
DMARC は、SPF と DKIM の結果を使って、認証に失敗したメールをどう扱ってほしいかを示す仕組みです。
Microsoft Learn でも、DMARC は SPF と DKIM の結果に加えて From ドメインとの整合を見て、どちらか一方でも整合して pass すれば DMARC を通せると説明しています。
DMARC の大事な点は、ただの判定 ではなく 運用方針 だということです。
代表的には次の3つがあります。
p=none: まずは観測するp=quarantine: 迷惑メール扱いを促すp=reject: 受信拒否を促す
DMARCでよくある失敗
- SPF / DKIM が整っていないのに、いきなり
p=rejectにする - 集計レポートの受信先を決めず、異常に気づけない
- 本番で使っていないと思っていた外部送信が実は残っている
- 親ドメインとサブドメインの扱いを整理していない
Google の送信者ガイドライン FAQ でも、送信者には SPF と DKIM の両方設定を求めつつ、DMARC 整合は少なくともどちらか一方で満たす形を案内しています。
実務では、まず p=none で観測し、正規送信が漏れていないか見てから厳しくする方が安全です。
4つは DNS 上ではどう置かれるのか
初心者向けにかなり雑に分けると、配置イメージはこうです。
| 項目 | レコード種別 | よく置く場所 |
|---|---|---|
| MXレコード | MX | `example.com` 直下 |
| SPF | TXT | `example.com` 直下 |
| DKIM | TXT またはサービス案内に従う形式 | `selector._domainkey.example.com` のような名前 |
| DMARC | TXT | `_dmarc.example.com` |
この配置を見ると、MX だけ別の役割だと分かりやすいです。
MX は 受信先ルーティング、SPF / DKIM / DMARC は 送信認証ポリシー です。
実務ではどの順番で確認するとよいか
設定やトラブル対応では、次の順番で見るとかなり整理しやすいです。
-
まず何をしたいかを分ける
受信設定なのか、送信の信頼性改善なのかを分ける -
受信が目的なら MX を見る
どのメールサービスで受けるのか、優先度が正しいか、旧設定が残っていないかを見る -
送信が目的なら SPF と DKIM を見る
実際の送信元サービスが全部含まれているか、署名が有効かを確認する -
その後 DMARC を見る
いきなり reject せず、観測しながら厳しくする -
最後は実送信で確認する
管理画面の見た目ではなく、実際に送ったメールヘッダーや到達先で確認する
たとえば フォームからの通知が届かない なら、いきなり MX を疑うより、まず送信処理、次に送信サービス、そのあと SPF / DKIM / DMARC を見る方が早いです。
この順番は、お問い合わせフォームが届かないときの切り分け手順 とかなり共通しています。
よくある誤解
誤解1: MX を設定すればメール全体が安定する
MX は受信先を決めるだけです。
送信メールの信頼性や、迷惑メール判定の改善は、SPF / DKIM / DMARC 側の話です。
誤解2: SPF だけ入れれば十分
SPF は重要ですが、単体では弱いです。
転送の影響もありますし、送信メールへの署名や認証失敗時の扱いは別で考える必要があります。
誤解3: DMARC は最初から reject が正解
理想としては厳しくしたいですが、運用整理前に p=reject へ行くと、正規メールまで落ちやすいです。
特にマーケティングツール、問い合わせ返信、社内通知、委託先サービスが混ざる組織では注意が必要です。
まとめ
MXレコード、SPF、DKIM、DMARC は、全部 メール関連DNS ではありますが、役割は同じではありません。
整理すると、次の4行で押さえられます。
メール設定で迷ったときは、受信の話か 送信認証の話か を先に分けるとかなり楽になります。
そのうえで、管理画面の設定だけで終わらせず、実際に送受信してヘッダーや到達先まで確認するのがいちばん確実です。
参考リンク
- Cloudflare Learning Center: What is a DNS MX record?
- Google Workspace Admin Help: Set up SPF
- Google Workspace Admin Help: Set up DKIM
- Google Workspace Admin Help: Email sender guidelines FAQ
- Microsoft Learn: Set up DMARC to validate the From address domain for cloud senders