結論（SPF・DMARC・DNSSEC）
SPF・DMARC・DNSSECの診断では、SPFレコードが1件で正しく評価できるか、DMARCでFrom偽装への方針を宣言しp=quarantineかrejectまで強化しているか、メール配送の暗号化をMTA-STSで求めているか、CAAやDNSSECでドメインの悪用を防いでいるかを確かめます。最優先は重要（high）のDMARCレコードとSPFの一意性・構文です。
DNS・メールのなりすまし対策の診断項目一覧（10項目）
SPF・DMARC・MTA-STS・CAA・DNSSECなど、ドメインとメールのなりすまし対策を確認します。各項目名から、意味・診断基準・リスク・具体的な対策を解説したページへ移動できます。
| No. | 診断項目 | 重大度 | 概要 |
|---|---|---|---|
| 61 | SPFレコード | medium | SPFレコードは、ドメインを名乗ってメールを送ってよいサーバーをDNSのTXTで公開する仕組みです。 |
| 62 | SPFの終端ポリシー | medium | SPFの終端ポリシーは、SPFレコード末尾のallで「一覧外の送信元をどう扱うか」を示す部分です。 |
| 63 | DMARCレコード | high | DMARCレコードは、_dmarcのTXTで差出人ドメインの偽装メールの扱いを宣言する仕組みです。 |
| 64 | DMARC強制ポリシー | medium | DMARC強制ポリシーは、DMARCのpタグをquarantineかrejectにして偽メールの配送を抑止する設定です。 |
| 65 | DMARC集計レポート送信先 | low | DMARC集計レポート送信先は、DMARCレコードのruaタグにmailto:で指定します。 |
| 66 | CAAレコード | low | CAAレコードは、サーバー証明書を発行してよい認証局（CA）をDNSで宣言する仕組みです。 |
| 67 | DNSSEC | medium | DNSSECは、DNS応答にデジタル署名を付けて改ざんを検証できるようにする仕組みです。 |
| 92 | SPFの一意性・構文・DNS参照数 | high | SPFの一意性・構文・DNS参照数は、SPFを1レコードに統合し、+allや修飾子なしallを使わず、DNS参照を10回以内に収めることです。 |
| 93 | MTA-STS | medium | MTA-STSは、自ドメイン宛てメールを検証済み証明書のMXへTLSで届けるよう送信側に求める仕組みです。 |
| 94 | SMTP TLSレポート（TLS-RPT） | low | SMTP TLSレポート（TLS-RPT）は、送信側がTLS接続の成否を毎日報告する仕組みで、_smtp._tlsにTXTを1件置くだけで有効です。 |
SPF・DMARC・DNSSECの診断とは
SPF・DMARC・DNSSECの診断は、自組織のドメイン名を悪用したなりすましメールや、DNS・サーバー証明書の不正な利用を防ぐ設定が、DNSに正しく公開されているかを確かめるものです。セキュリティ診断127項目のうち、ドメインとメールのなりすまし対策に関する10項目がこの分類に入ります。
メールの差出人は、仕組み上、誰でも自由に書けてしまいます。そこで、受信側が「本当にそのドメインの持ち主が送ったメールか」を判断できるよう、ドメインの持ち主がDNSに宣言を公開します。SPFは「このドメインを名乗って送ってよいサーバーの一覧」をTXTレコードで公開する仕組みです。DMARCは、SPFとDKIMの結果を使って差出人（Fromヘッダー）のドメインが本物かを判定し、偽物だった場合の扱い（none／quarantine／reject）を宣言する仕組みです。現行仕様は2026年5月に公開されたRFC 9989です。
メールの配送経路の暗号化も対象です。SMTPのSTARTTLSは任意の暗号化のため、経路上で平文に戻されたり偽のメールサーバーへ誘導されたりするおそれがあります。MTA-STSは、検証済みの証明書を持つ指定のメールサーバーへTLSで届けることを送信側に求める、WebのHSTSのメール版にあたる仕組みで、TLS-RPTはその結果の報告を受け取る仕組みです。
さらに、ドメインそのものを守る設定として、証明書を発行してよい認証局をDNSで宣言するCAAと、DNSの応答にデジタル署名を付けて改ざんを検証できるようにするDNSSECを確認します。
10項目の全体像（4つのグループ）
この分類の10項目は、大きく4つのグループに分けて考えると整理しやすくなります。
| グループ | 診断項目 | 確認する内容 |
|---|---|---|
| SPF | 「SPFレコード」、「SPFの終端ポリシー」、「SPFの一意性・構文・DNS参照数」 | v=spf1 のレコードがあるか、末尾が -all か ~all か、レコードが1件だけで全許可になっておらずDNS参照が10回以内か |
| DMARC | 「DMARCレコード」、「DMARC強制ポリシー」、「DMARC集計レポート送信先」 | _dmarc にレコードがあるか、p が quarantine か reject か、rua に mailto: の集計レポート送信先があるか |
| メール配送の暗号化 | 「MTA-STS」、「SMTP TLSレポート（TLS-RPT）」 | MTA-STSのTXTとポリシーファイルがそろい mode: enforce か、_smtp._tls に有効なTLS-RPTレコードが1件あるか |
| ドメインと証明書の保護 | 「CAAレコード」、「DNSSEC」 | 証明書を発行してよい認証局を宣言しているか、DNSの応答が署名で検証されADが立つか |
SPFとDMARCは「なりすましメールを見分けて止める」ための組み合わせで、SPF単独ではFromの偽装を防げません。MTA-STSとTLS-RPTは「自組織宛てのメールを安全に受け取る」ための組み合わせ、CAAとDNSSECは「ドメインと証明書が悪用されない」ための設定と考えると、それぞれの役割が分かりやすくなります。なお、MXがないドメインではSPFやTLS-RPTの項目は対象外になり、DMARCレコード自体がない場合はruaの項目を二重に減点しないよう対象外とします。
優先して確認すべき項目
この分類には「最重要（critical）」の項目はなく、「重要（high）」の2項目から確認します。
- DMARCレコード：MXがあるドメインに適用されるDMARCレコードがなければ×です。v=DMARC1 は必ず先頭に書き、_dmarc に複数のDMARCレコードがあると、すべて破棄されDMARCがないのと同じになります。
- SPFの一意性・構文・DNS参照数：v=spf1 で始まるレコードが2件以上ある、+all や修飾子なしの all で全許可にしている、トップレベルのDNS参照が10回を超えている場合は×です。いずれもSPFが機能しないか、SPFを置いていないより悪い状態です。
次に「中（medium）」の5項目を確認します。「SPFレコード」はMXがあるのにSPFがなければ△、「SPFの終端ポリシー」は ?all や +all、all がない状態を問題とします。「DMARC強制ポリシー」は、p=reject、またはテストモードでない p=quarantine を合格とし、p=none は△です。「MTA-STS」は、TXTがあるのにポリシーファイルが無効なら×です。「DNSSEC」は、Google Public DNSの応答でADが立たなければ△です。
「低（low）」の「DMARC集計レポート送信先」「CAAレコード」「SMTP TLSレポート（TLS-RPT）」は、監視や予防のための設定です。ただしDMARCのruaは、p=quarantine／rejectへの強化を安全に進めるための「目」にあたるため、DMARCを公開したらすぐに設定しておくのが効率的です。
直すときの進め方と注意点
DNSとメールの設定は、誤ると正規のメールが届かなくなったり、Webサイトが表示できなくなったりします。次の点に注意して進めます。
- SPFは1件にまとめて書き換える：配信サービスを追加するときは、新しいTXTレコードを作らず既存のレコードへ追記します。DNS参照が10回を超えそうなら、不要なincludeの削除、ip4:・ip6:での直接記述、送信システムのサブドメインへの分離で減らします。
- 終端は ~all から始める：まず ~all で始め、DMARCレポートで正規の送信元に漏れがないと確認してから -all を検討します。メールを送らないドメインには v=spf1 -all を公開します。
- DMARCは監視から強制へ段階的に進める：まず p=none と rua で集計レポートを受け取り、委託システムや複合機など設定されていない送信元がないかを確認してから、quarantine、reject へ移行します。p=none は監視のみで、なりすまし抑止の効果はありません。
- MTA-STSは testing で準備し、TLS-RPTで確かめてから enforce にする：testing には保護効果がありません。mta-sts サブドメインは他へリダイレクトしてはいけません。MXを変えるときは、先にポリシーへ新しいMXを追加してTXTの id を更新し、max_age が経過するのを待ってから切り替えます。
- CAAは使っている認証局を漏れなく列挙する：CNAME先のCDNやSaaSが自動発行に使う認証局を許可し忘れると、証明書の自動更新が失敗してサイトが表示できなくなります。
- DNSSECは鍵とDSの運用を計画に入れる：鍵の更新失敗、署名の期限切れ、DS登録の不整合で検証に失敗すると、ドメイン全体が名前解決できなくなります。DNS事業者を変更するときは、DSの扱いを移行計画に明記します。
自治体・公共機関のサイトで特に注意すること
自治体や公共機関のドメインは、住民や事業者からの信頼が厚いぶん、なりすましメールに悪用されると被害が大きくなります。政府機関等の対策基準策定のためのガイドライン（令和7年度版）は、基本対策事項6.2.2(1)-3でDMARCによる対策と、p=quarantine または p=reject の設定を求めています。地方公共団体に直接適用される基準ではありませんが、自治体のセキュリティポリシーを検討する際の有力な参照先です。よくある注意点として、次のようなものがあります。
- 本庁のメール以外にも、委託システムや複合機など、ドメインを名乗ってメールを送る送信元が残っており、DMARCを強化すると届かなくなる。集計レポートで洗い出してから移行する。
- DMARCのレポートや TLS-RPT のレポートを個人の受信箱で受けると、担当者の異動で確認が途切れる。担当課と委託事業者が確認できる共有の専用アドレスにする。
- 職員が日常的に使うドメインは、メーリングリストへの影響などを踏まえ、quarantine を当面の到達点とし、reject は影響を確かめてから判断するのが安全である。
- CAAは代表ドメインに設定すれば配下のサブドメインにも適用されるが、サブドメインで別の認証局を使う場合は個別の設定が必要になる。
メールを送るシステムとドメインの一覧、DNSを管理する事業者と担当者を台帳にまとめ、DMARCのレポートを定期的に確認すると、こうした設定の漏れや運用の途切れを防ぎやすくなります。
よくある質問（FAQ）
SPF・DMARC・DNSSECの診断項目は、どの順番で直せばよいですか？
まず重要（high）の、DMARCレコードがあることと、SPFレコードが1件で構文やDNS参照数に問題がないことを確認します。次にSPFの公開と終端ポリシー、DMARCのruaでレポートを受け取り、レポートを見ながらDMARC強制ポリシーへ移行します。MTA-STS、TLS-RPT、CAA、DNSSECは、メールの基本設定が整った後に段階的に進めます。
SPFを設定していれば、SPF・DMARC・DNSSECのうちDMARCは不要ですか？
不要ではありません。SPFが確認するのはエンベロープ送信者で、利用者が見る差出人（Fromヘッダー）ではないため、攻撃者は自分のドメインでSPFを通しつつFromだけ自治体名にできます。From偽装はDMARCでしか判定・宣言できません。
DMARCをp=noneで公開していれば、SPF・DMARC・DNSSECの対策として十分ですか？
十分ではありません。p=noneは導入初期の監視段階としては正しいものの、受信側に特別な処理を求めないため、偽メールが受信箱に届くことは止められません。集計レポートで正規の送信元の認証を確かめてから、p=quarantineやp=rejectへ段階的に移行します。
SPF・DMARC・DNSSECの設定を変えると、メールやWebサイトが止まることはありますか？
あります。SPFレコードを2件にするとpermerrorでSPFが無効になり、MTA-STSをenforceのままポリシー外のMXへ切り替えるとメールが届かなくなります。CAAでCDNが使う認証局を許可し忘れると証明書の自動更新が失敗し、DNSSECの鍵更新やDS登録に失敗するとドメイン全体が名前解決できなくなります。
SPF・DMARC・DNSSECの10項目はまとめて確認できますか？
セキュリティAIチェッカーにURLを入力すると、この10項目を含む127項目を公開情報から自動で診断し、項目ごとの判定と改善の優先順位を表示します。