先に要点
メールまわりの DNS 設定を触ると、MXレコード、SPF、DKIM、DMARC が一気に出てきます。
ただ、これらは全部同じ役割ではありません。メールの設定 とひとまとめにすると、受信の話と送信認証の話が混ざって分かりにくくなります。
この記事では、2026年10月時点で Google Workspace Admin Help、Microsoft Learn と Microsoft サポート、Yahoo Sender Hub、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 は大事ですが、これだけでは本文改ざんの確認や、認証失敗時の扱いまでは決まりません。
そこを補うのが DKIM と DMARC です。
DKIMとは: メールへ署名を付けて正規送信を確認しやすくする
DKIM は、送信メールへ電子署名を付け、受信側が DNS に公開された鍵情報を使って確認する仕組みです。
Google Workspace の DKIM 設定ガイドでも、DNS に公開鍵を追加したあと、管理画面で署名を有効化する流れになっています。2048-bit 鍵が使えるなら長い鍵がより安全という案内もあります。
ここで初心者がつまずきやすいところです。多くの送信サービスでは、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: 受信拒否を促す
- SPF / DKIM が整っていないのに、いきなり
p=rejectにする - 集計レポートの受信先を決めず、異常に気づけない
- 本番で使っていないと思っていた外部送信が実は残っている
- 親ドメインとサブドメインの扱いを整理していない
Google の送信者ガイドラインでは、個人の Gmail アカウントへ1日5,000通以上送る送信者に、SPF と DKIM の両方と DMARC（ポリシーは none でもよい）を求め、From のドメインが SPF か DKIM のどちらか一方と整合していればよいとしています。
実務では、まず 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 は 送信認証ポリシー です。
実務ではどの順番で確認するとよいか
設定やトラブル対応では、次の順番で見るとかなり整理しやすいです。
メール関連DNSを確認する順番
- 1まず何をしたいかを分ける
受信設定なのか、送信の信頼性改善なのかを分ける
- 2受信が目的なら MX を見る
どのメールサービスで受けるのか、優先度が正しいか、旧設定が残っていないかを見る
- 3送信が目的なら SPF と DKIM を見る
実際の送信元サービスが全部含まれているか、署名が有効かを確認する
- 4その後 DMARC を見る
いきなり reject せず、観測しながら厳しくする
- 5最後は実送信で確認する
管理画面の見た目ではなく、実際に送ったメールヘッダーや到達先で確認する
たとえば フォームからの通知が届かない なら、いきなり MX を疑うより、まず送信処理、次に送信サービス、そのあと SPF / DKIM / DMARC を見る方が早いです。
この順番は、お問い合わせフォームが届かないときの切り分け手順 とかなり共通しています。
よくある誤解
MX は受信先を決めるだけです。送信メールの信頼性や、迷惑メール判定の改善は、SPF / DKIM / DMARC 側の話です。
SPF は重要ですが、単体では弱いです。転送の影響もありますし、送信メールへの署名や認証失敗時の扱いは別で考える必要があります。
理想としては厳しくしたいですが、運用整理前に p=reject へ行くと、正規メールまで落ちやすいです。特にマーケティングツール、問い合わせ返信、社内通知、委託先サービスが混ざる組織では注意が必要です。
メール関連DNS設定のよくある質問
Q. MX、SPF、DKIM、DMARC の関係は？
A. MX は 受信先サーバーの指定、SPF は 送信元 IP の認証、DKIM は 本文の署名認証、DMARC は SPF / DKIM の結果をどう扱うか の宣言。受信は MX、送信は SPF+DKIM+DMARC、と分けて理解します。
Q. Gmail / Yahoo の 2024年新ガイドラインで何が変わりましたか？
A. 2024年2月から、Gmail と Yahoo が送信者の要件を強化しました。Gmail では、すべての送信者に SPF か DKIM、迷惑メール率 0.3% 未満 などを求め、個人の Gmail へ1日5,000通以上送る送信者には SPF + DKIM + DMARC とマーケティングメールの ワンクリック解除 も求めています。Gmail は2025年11月から要件を満たさないメールへの対応を強め、一時的・恒久的な拒否も起きるとしています。Microsoft も2025年5月から、Outlook.com などへ1日5,000通以上送るドメインに SPF・DKIM・DMARC を求めています。
Q. SPF のレコード書き方は？
A. v=spf1 ip4:1.2.3.4 include:_spf.google.com -all のような形式です。include で外部サービスの SPF を取り込み、最後の -all で これ以外は全部拒否 を宣言します。
Q. DKIM の設定方法は？
A. 送信サービス側(Gmail、SendGrid、Resend、SES など)で公開鍵を取得し、DNS に selector._domainkey.example.com の TXT レコードとして登録します。
Q. DMARC の p=none から p=reject への進め方は？
A. p=none + rua レポート受け取り → レポート分析で正規メールが全て認証通過するか確認 → p=quarantine(迷惑メール扱い) → p=reject(拒否)、の3段階で慎重に進めます。
Q. メール転送で SPF が壊れる問題は？
A. 一般的な転送(info@xxx.co.jp → 個人メール)では送信元 IP が変わるため、SPF 認証が失敗します。SRS(Sender Rewriting Scheme) 対応の転送サーバーを使うか、DKIM が通れば良し として運用するのが現実的です。
Q. SaaS 経由のメール送信(Gmail、Microsoft 365)の SPF/DKIM は？
A. 各サービスが提供する SPF include と DKIM 公開鍵を DNS に登録します。Google Workspace なら include:_spf.google.com、Microsoft 365 なら include:spf.protection.outlook.com です。
まとめ
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
- Google Workspace Admin Help: Email sender guidelines FAQ
- Yahoo Sender Hub: Sender Best Practices
- Microsoft サポート: Fix NDR error 550 5.7.515 in Outlook.com
- Microsoft Learn: Set up DMARC to validate the From address domain for cloud senders