メール認証DNSDMARC

メールと DNS の関係｜SPF DKIM DMARC 入門

2026年5月22日ドメイン番人約 6 分で読めます

この記事でわかること

メール配送において DNS が果たす 4 つの役割
MX / SPF / DKIM / DMARC が DNS のどこに書かれているか
受信側メールサーバーが DNS を引く順序
メール認証を学ぶ前に押さえるべき DNS の前提知識

メールは DNS なしには 1 通も届かない

「メールが届かない」の相談で最も多い原因は、SMTP サーバーの不具合でも回線でもなく DNS 設定の漏れや誤りです。差出人のメールアドレスが yamada@example.co.jp のとき、受信側は「example.co.jp の DNS を引く」ところから処理を始めます。DNS が間違っていれば、メール本体がどれだけ正しく書かれていても 1 通も届きません。

メール認証（SPF / DKIM / DMARC）の解説記事はたくさんありますが、その前提として「メールと DNS がどう絡み合っているか」を 1 枚で俯瞰する記事は意外と少ないです。本記事はその入口として、DNS の 4 つの役割を整理します。

個別の用語解説は DMARC とは / SPF / DKIM / DMARC の違い / DNS レコードの種類を参照してください。本記事はそれらを束ねるハブとして機能します。

メールと DNS の 4 つの接点

役割 1：MX レコードで「どこに送るか」を決める

メール送信側がまず DNS に問い合わせるのが MX（Mail eXchanger）レコードです。example.co.jp 宛のメールは、example.co.jp. の MX レコードに書かれたホスト名（実体は別の A / AAAA レコード）へ届けられます。

$ dig MX example.co.jp +short
10 aspmx.l.google.com.
20 alt1.aspmx.l.google.com.

先頭の数字は優先度（preference）で、小さいほど優先。一番優先度の低い MX が落ちていれば次に低い MX へとフェイルオーバーします。Gmail / Microsoft 365 / 自社運用サーバー、どれを使っているかは MX を見れば即わかります。

MX が間違っていると、メールはまず物理的に届きません。受信側でなく送信側が引くレコードであることに注意してください。

役割 2：SPF / DKIM / DMARC で「正規の送信者か」を検証する

ここからが認証パートです。受信側 MTA は届いたメールの差出人ドメイン（From や Return-Path）に対して、以下の TXT レコードを順に引きます。

認証	引く DNS 名	DNS レコード型	役割
SPF	`example.co.jp.`	TXT（`v=spf1` 始まり）	送信元 IP が許可されているか
DKIM	`<selector>._domainkey.example.co.jp.`	TXT（`v=DKIM1` 始まり）	署名検証用の公開鍵
DMARC	`_dmarc.example.co.jp.`	TXT（`v=DMARC1` 始まり）	SPF / DKIM の判定方針

3 つすべてが DNS の TXT レコードに格納されていることに注目してください。DNS が更新できなければ、メール認証は 1 ミリも動きません。

SPF の参照経路

v=spf1 include:_spf.google.com include:amazonses.com -all のような値が返ります。include: で別ドメインを参照すると、受信側はそのドメインの SPF も再帰的に引きます。RFC 7208 で DNS lookup は 10 回までと制限されているのは有名な落とし穴で、超過すると Permerror になります。詳細は SPF lookup 10 個制限を参照。

DKIM の参照経路

DKIM は「セレクタ」という DNS ラベルで複数の公開鍵を切り替えます。メール本文に DKIM-Signature: ... d=example.co.jp; s=selector1; と書かれていれば、受信側は selector1._domainkey.example.co.jp を引いて公開鍵を取得し、署名を検証します。セレクタ名はメールプロバイダごとに異なるため、推測ではなく dig での確認が必要です。

DMARC の参照経路

_dmarc.example.co.jp の TXT を引き、p=none / quarantine / reject の方針と、rua=mailto:... のレポート送信先を読み取ります。SPF か DKIM のどちらか一方でもアライメント込みで pass すれば DMARC pass、両方落ちれば DMARC fail で、ポリシーに従って配送 / 隔離 / 拒否を決めます。

役割 3：PTR（逆引き）で「送信元 IP が偽装されていないか」見る

受信側 MTA は、接続してきた送信元 IP の逆引き（PTR レコード）も確認します。203.0.113.5 から接続があれば、5.113.0.203.in-addr.arpa の PTR を引き、ホスト名を取得します。

逆引きが設定されていない、または unknown → 怪しい送信元と判定される
逆引きの結果が SMTP HELO で名乗ったホスト名と一致しない → ペナルティスコア

正規のメールサーバーは逆引きが必ず設定されています。自社で MTA を運用するなら、ホスティング業者に逆引き設定を依頼するのが必須です。

役割 4：BIMI / MTA-STS / TLS-RPT（オプション）

近年は DNS でメール周りの追加情報を提供する仕組みが増えています。

BIMI：default._bimi.example.co.jp で会社ロゴを Gmail 等の受信箱に表示。前提として DMARC p=quarantine 以上が必要
MTA-STS：_mta-sts.example.co.jp の TXT + HTTPS で取得するポリシーで、メール送信時の TLS 強制
TLS-RPT：_smtp._tls.example.co.jp で TLS 失敗時のレポート送信先

すべて DNS に TXT を 1 行足すだけで開始でき、メール全体のセキュリティを底上げできます。導入は SPF / DKIM / DMARC が安定してからで構いません。

受信側が DNS を引く順序

メール認証を学ぶ前に押さえる 3 つの前提

TTL を意識する：DNS の変更は TTL（Time To Live）秒だけ古い値がキャッシュされる。SPF / DMARC の変更前後は TTL を 300 秒程度に下げてから変更すると切り戻しが速い
TXT は 1 ドメインに複数行書ける：ただし SPF は 1 ドメイン 1 レコードのみ。複数行あると Permerror
サブドメインは別世界：mail.example.co.jp の SPF / DKIM / DMARC は、example.co.jp のものとは別に必要。サブドメイン DMARC は親の sp= で代替も可

これらは DNS の挙動に関する話で、メール認証個別の話ではありません。この 3 点を知らずに認証だけを設定すると、必ずどこかで詰まります。

よくある質問

MX を変えたら何分でメールの届き先が切り替わりますか

MX レコードの TTL に従います。一般的に 3600 秒（1 時間）が多いですが、移行前に TTL を 300 秒に下げてから切り替えると、世界中のリゾルバが 5 分以内に新しい値を引くようになります。実務では移行前日に TTL 短縮 → 当日切替 → 1 週間後に TTL 戻し、のパターンが安全です。

SPF / DKIM / DMARC を全部入れれば DNS の仕事は終わりですか

メール認証としてはほぼ終わりですが、PTR（逆引き）と必要に応じて MTA-STS / TLS-RPT / BIMI も検討してください。逆引き未設定のままだと一部の受信側で減点されます。

Cloudflare / Route53 / お名前.com で DNS の挙動は違いますか

問い合わせの結果は同じですが、管理画面の操作性や TXT の文字列長制限、ワイルドカードの扱いに差があります。長い DMARC レコードや DKIM 公開鍵で「保存できない」現象に遭ったら、それは管理画面側の文字数制限が原因です。

まとめ

メール配送は DNS の MX 参照から始まる。MX 設定が間違っていれば物理的に届かない
SPF / DKIM / DMARC は全部 DNS の TXT レコード。DNS が更新できなければ認証は動かない
逆引き（PTR）未設定は意外な落とし穴。MTA 自前運用なら必須
TTL を意識し、サブドメインは別管理という前提を押さえる
個別認証の詳細は DMARC とは / SPF / DKIM / DMARC の違いへ

まずは自社の DNS を可視化

メール認証の前段として、自社の MX / SPF / DKIM / DMARC が DNS にどう書かれているかは、ドメイン番人の無料診断で 30 秒で確認できます。設定の整理や移行作業はお問い合わせからご相談ください。