「通知メールが、Gmail宛てだけ届かなくなりました」
「証明書の自動更新が、急に失敗するようになりました」
最近増えているこうした相談も、原因をたどるとDNSのレコードに行き着くことが少なくありません。メールや証明書は、今やDNSの設定と切り離せない関係にあります。
第5回（前編）では、ゾーンの骨格になるSOA・NS・A/AAAA・CNAMEを見ました。後編の今回は、メールの配送と認証（MX・SPF・DKIM・DMARC）、Active Directoryで使うSRV、逆引きのPTR、証明書のCAA、そして比較的新しいHTTPS/SVCBレコードを扱います。
MXとNull MX
MX（Mail eXchange）は、そのドメイン宛てのメールの配送先です。送信側のメールサーバーは、宛先ドメインのMXを引いて接続します。
example.jp. 3600 IN MX 10 mail1.example.jp.
example.jp. 3600 IN MX 20 mail2.example.jp.
; メールを受け取らないドメインであることを明示する（Null MX）
noreply.example.jp. 3600 IN MX 0 .- 優先度（プリファレンス）は小さいほど優先。同じ値を複数置いた場合の振り分けは送信側の実装しだい
- 値はA/AAAAで引けるホスト名。IPアドレスやCNAMEの名前は書かない（第5回）
- MXはサブドメイン（
sub.example.jp）にも個別に置ける
見落としがちなのが、MXが無い場合の動きです。MXが無いと、送信側は名前のA/AAAAを配送先とみなして送ろうとします（RFC 5321）。Webサーバーしかないドメインでも、メールを受け取ろうとする通信が来てしまうのです。
受け取らないドメインは、Null MX（MX 0 .、RFC 7505）で明示しましょう。無駄な配送と誤配送を防げます。
TXTとSPF
TXTは任意の文字列を入れるレコードです。1つの文字列は255バイトまでですが、複数の文字列に分けて入れれば、それ以上を格納できます（DKIMの長い公開鍵など）。
主な用途は2つです。
- メール送信ドメインの認証（SPF・DKIM・DMARC）
- ドメインの所有確認（Microsoft 365、Google、各種SaaS、証明書の発行などで「指定の文字列をTXTに登録してください」と求められるもの）
example.jp. 3600 IN TXT "v=spf1 ip4:192.0.2.25 include:_spf.example.net -all"
example.jp. 3600 IN TXT "MS=ms12345678"SPF（RFC 7208）は、そのドメインのメールを送ってよいサーバーを宣言します。
-all：列挙以外は失敗~all：列挙以外は疑わしい
SPFには、ハマりやすい制約があります。
- SPFのレコードは1つの名前に1つだけ。2つ書くとどちらも無効扱いになり得る
includeなどで引くDNSの問い合わせは10回までの制限がある。SaaSを足し続けると超えやすい- SPF専用のタイプ（タイプ99）は廃止。TXTで書く
「メール配信サービスを追加するたびにincludeを足していたら、いつの間にか10回を超えていた」というのは、本当によくある話です。
DKIMとDMARC
SPFとあわせて、メールの送信ドメイン認証にはDKIMとDMARCを使います。3つの関係を整理しましょう。
| 仕組み | レコードの場所 | 内容 | 規格 |
|---|---|---|---|
| SPF | ドメイン名（example.jp）のTXT | 送信を許可するサーバー | RFC 7208 |
| DKIM | セレクター._domainkey.example.jp のTXT（CNAMEで事業者に向ける場合も） | 署名を検証する公開鍵 | RFC 6376 |
| DMARC | _dmarc.example.jp のTXT | SPF・DKIMの結果とFromの一致を見て、失敗時の扱いとレポート先を示す | RFC 7489 → RFC 9989（2026年5月） |
s1._domainkey.example.jp. 3600 IN TXT ( "v=DKIM1; k=rsa; "
"p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..." )
_dmarc.example.jp. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-rua@example.jp"（DKIMの公開鍵は省略しています）
DMARCは、いきなり厳しくしないのがコツです。p=none（監視のみ）でレポートを集め、正規のメールが通ることを確かめてから、quarantine、rejectへ段階的に強めます。いきなりrejectにすると、把握していなかった送信元（古いシステムの通知メールなど）が全部止まります。
なお、DMARCは2026年5月にRFC 9989へ改訂されました。Microsoft 365ではDKIMをselector1._domainkeyなどのCNAMEで向けます。
送信者ガイドラインとDNS
冒頭の「Gmail宛てだけ届かない」の背景にあるのが、大手メール事業者の送信者ガイドラインです。
| 受信側 | 開始 | すべての送信者 | 大量送信者（1日5,000通以上） |
|---|---|---|---|
| Gmail | 2024年2月 | SPFまたはDKIM、正引き・逆引きの設定、TLS、迷惑メール率0.3%未満 | SPFとDKIMの両方、DMARC（p=none 可）、Fromとの一致、ワンクリック登録解除 |
| Yahoo | 2024年2月 | SPFまたはDKIM、正引き・逆引きの設定、迷惑メール率0.3%未満 | SPFとDKIMの両方、DMARC（p=none 以上）、Fromとの一致、ワンクリック登録解除 |
| Microsoft（Outlook.com・Hotmail 等の個人向け） | 2025年5月5日 | （推奨事項のみ） | SPFとDKIMの成功、DMARC（p=none 以上）でFromと一致。不適合は 550 5.7.515 で拒否 |
DNSの担当者に関係するのは、SPF・DKIM・DMARCのTXTと、送信サーバーのIPアドレスの逆引き（PTR）と正引きの一致です。Gmailは2025年11月から、要件を満たさないメールの一時的・恒久的な拒否を強めています。
社内のシステムからの通知メールも対象になり得ます。複合機のスキャン送信、監視システムのアラート、業務システムの通知など、送信元をすべて洗い出してSPF・DKIMに含めましょう。
SRV：サービスの場所を示す
SRV（RFC 2782）は、「このサービスは、どのサーバーの何番ポートにあるか」を示すレコードです。名前は_サービス._プロトコル.ドメインの形になります。
; _サービス._プロトコル.名前 TTL SRV 優先度 重み ポート ターゲット
_ldap._tcp.corp.example.jp. 600 IN SRV 0 100 389 dc01.corp.example.jp.
_kerberos._tcp.corp.example.jp. 600 IN SRV 0 100 88 dc01.corp.example.jp.
_ldap._tcp.dc._msdcs.corp.example.jp. 600 IN SRV 0 100 389 dc01.corp.example.jp.- 優先度は小さいほど優先、同じ優先度の中では重みの比率で振り分ける
- ターゲットにCNAMEの名前は書かない
SRVの最大の利用例は、Active Directoryです。
クライアントはSRVを引いてドメインコントローラーを見つけます。そのため、「ドメインに参加できない」「ログオンが遅い」は、まずSRVの欠落を疑います（第10回）。
$ dig _ldap._tcp.dc._msdcs.corp.example.jp SRV +short
0 100 389 dc01.corp.example.jp.
PS> Resolve-DnsName _ldap._tcp.dc._msdcs.corp.example.jp -Type SRVPTRと逆引きゾーン
PTRは、IPアドレスから名前を引く逆引きのレコードです。IPv4はin-addr.arpa、IPv6はip6.arpa（RFC 3596）の下に、アドレスを逆順にした名前で置きます。
; IPv4：192.0.2.10 → 10.2.0.192.in-addr.arpa.
$ORIGIN 2.0.192.in-addr.arpa.
10 IN PTR www.example.jp.
; IPv6：2001:db8::10 → 32桁の16進数を1桁（nibble）ずつ逆順に並べる
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR www.example.jp.なぜ逆順なのかというと、DNSの名前は右ほど大きい単位だからです（第2回）。IPアドレスは左ほど大きい単位なので、逆にすればDNSの木構造にそのまま乗せられます。
$ dig -x 192.0.2.10 +short
www.example.jp.
PS> Resolve-DnsName 192.0.2.10 # IPアドレスを渡すと PTR を引く逆引きで押さえておきたいのは次の3点です。
- 逆引きゾーンの委任は、ドメインのレジストラではなく、IPアドレスの割り当て元（ISP、JPNIC・APNIC等）から受ける。/24より小さい割り当ては、CNAMEを使うクラスレス委任（RFC 2317）で委任されることがある
- 逆引きが無いと、接続元を逆引きするサーバー（SSH等）でタイムアウト待ちの遅延が起きる
- メール送信サーバーやvSphereでは、正引きと逆引きの一致が求められる（第10回）
CAA：証明書を発行してよい認証局
CAA（RFC 8659）は、そのドメインの証明書を発行してよい認証局（CA）を宣言するレコードです。
example.jp. 3600 IN CAA 0 issue "letsencrypt.org"
example.jp. 3600 IN CAA 0 issue "amazon.com"
example.jp. 3600 IN CAA 0 issuewild ";"
example.jp. 3600 IN CAA 0 iodef "mailto:security@example.jp"上の例は、Let’s EncryptとAmazon（ACM）だけを許可し、ワイルドカード証明書は発行させない設定です。
- 2017年9月8日から、CAは発行前にCAAを確認する義務がある（CA/Browserフォーラム Ballot 187）。CAAがあれば、列挙されていないCAは発行を拒否する
- CAAが無い名前は、親の名前へさかのぼって確認される（www.example.jp → example.jp）。どこにも無ければ、どのCAでも発行できる
iodefは違反の通知先。accounturi（RFC 8657）でCAのアカウントまで限定でき、issuemail（RFC 9495）はS/MIME証明書用
冒頭の「証明書の自動更新が急に失敗する」の原因がこれ、というケースがあります。CAを変えるときや、ACMなど新しいCAを使い始めるときにCAAの追加を忘れると、発行や自動更新が失敗します。
HTTPS／SVCBレコード
最後に、比較的新しいレコードです。SVCBとHTTPSレコード（RFC 9460、2023年11月）は、接続する前に「どう接続すればよいか」をDNSで伝えるレコードです。
HTTPSレコードはWeb用の形で、次のような情報を載せられます。
- 対応するプロトコル（
alpn="h3,h2"ならHTTP/3にも対応） - IPアドレスの候補（ipv4hint・ipv6hint）
- TLSのECH（接続先の名前を暗号化する仕組み、RFC 9849、2026年3月）の鍵
ブラウザーは最初からHTTP/3を選んだり、ECHで名前を隠したりできます。HTTPSレコードが無い場合は、まずHTTP/2で接続してAlt-Svcヘッダーを受け取り、次回からHTTP/3になるので、つなぐ前につなぎ方まで分かるのが利点です。
また、優先度0のAliasModeを使うと、頂点から別の名前へ、標準の仕組みで向けられます（第5回）。
書き方と対応状況
; ServiceMode：HTTP/3 と HTTP/2 に対応していることを伝える
example.jp. 3600 IN HTTPS 1 . alpn="h3,h2" ipv4hint=192.0.2.10 ipv6hint=2001:db8::10
; AliasMode：頂点から CDN の名前へ向ける（優先度 0）
example.com. 3600 IN HTTPS 0 cdn.example.net.$ dig example.jp HTTPS +short
1 . alpn="h3,h2" ipv4hint=192.0.2.10 ipv6hint=2001:db8::10値の.は「この名前自身」を表します。
| クライアント | HTTPSレコードの利用（2026年9月時点） |
|---|---|
| Safari（iOS 14／macOS 11以降） | OSのAPIが接続時に問い合わせる |
| Chrome（117以降） | 内蔵のリゾルバーまたはDoHで取得し、ECHに使う（既定で有効） |
| Firefox | DoH使用時に取得。129以降はOSのリゾルバー経由でも取得（macOSを除く） |
対応していないクライアントは無視するため、追加しても既存の接続は壊れません。一部のCDNは自動で公開しています。
注意点として、Windows標準のResolve-DnsNameはHTTPS型を指定できないため、確認にはLinuxなどのdigを使います。また、ipv4hintなどはあくまで候補で、A/AAAAレコードの代わりにはなりません。A/AAAAを変えたらヒントも合わせて直しましょう。
その他のレコード
ここまでで扱わなかったレコードも、名前だけ押さえておきましょう。
| タイプ | 用途 | 補足 | 規格 |
|---|---|---|---|
| TLSA | サーバー証明書（公開鍵）のハッシュをDNSで示す（DANE） | _25._tcp.mail.example.jp のように置く。メールサーバー間のTLSで利用。DNSSECが前提 | RFC 6698 |
| SSHFP | SSHのホスト鍵の指紋 | OpenSSHの VerifyHostKeyDNS で照合。DNSSECが前提 | RFC 4255 |
| NAPTR | 文字列の書き換え規則 | ENUM（電話番号→URI）やSIPで利用 | RFC 3403 |
| DS／DNSKEY／RRSIG／NSEC・NSEC3 | DNSSECの鍵・署名・不在証明 | 第9回で扱う | RFC 4034 等 |
| HINFO | ホストの情報 | ANY問い合わせへの最小限の応答に使われる | RFC 8482 |
| SPF（タイプ99） | SPF専用 | 廃止。TXTで書く | RFC 7208 |
DNSのタイプはIANAの一覧で約90種類が定義されていますが、日常の運用で使うのは第5回・第6回で扱ったもので大半です。見慣れないタイプに出会ったら、IANAの「Resource Record (RR) TYPEs」で番号と規格を確認しましょう。
考えてみよう
- 自社ドメインのSPF・DKIM・DMARC・CAAを、digで確認してみてください。システムからの通知メールの送信元は、すべてSPFに含まれていますか。
- メールを送らない・受け取らないドメイン（Web専用のドメインなど）に、Null MXやSPFの
-allは設定されていますか。 - 社内のサーバーやメール送信サーバーのIPアドレスに、正しい逆引き（PTR）は設定されていますか。
ヒント：dig example.jp TXT、dig _dmarc.example.jp TXT、dig example.jp CAAの3つで、メールと証明書に関わる設定のほとんどが見えます。PowerShellではResolve-DnsName _dmarc.example.jp -Type TXT（CAAは指定できないためdigで確認）。
まとめ
- MXが無いとAに配送しようとする。受け取らないドメインはNull MXで明示
- SPFは1つの名前に1つ、DNSの問い合わせは10回まで
- DMARCはp=noneで監視してから段階的に強める
- Gmail・Yahoo・Microsoftの送信者ガイドラインで、SPF・DKIM・DMARC・逆引きは実質必須に
- ADはSRVでDCを探す。逆引きは割り当て元から委任を受ける
- CAを変えるときはCAAも忘れずに。HTTPSレコードは追加しても壊れない
次回は、これらのレコードを置く権威DNSサーバーを、どう運用するかを見ていきます。
連載「DNS入門」全12回
- DNSとは？名前解決の全体像と3つの登場人物
- ドメイン名の階層と委任
- 名前解決の流れ
- DNSメッセージとトランスポート
- リソースレコード 前編
- リソースレコード 後編（この記事）
- 権威DNSサーバーの運用
- コマンドで調べる
- DNSのセキュリティ
- クラウド・社内環境のDNS
- DNSトラブルシュート
- DNS設計演習
コメント