DMARCとは？何を保証し、何を保証しないのか｜設定前に押さえる前提
「セキュリティ対策としてDMARCを設定してください」と外部から言われて、意味がよく分からないまま設定を進めてしまった経験はないでしょうか。設定自体は難しくなくても、何のための仕組みかが分からないまま数値(ポリシー)だけを変更すると、正規のメールが届かなくなる事故につながります。
この記事では、DMARCが実際に何を保証し、何を保証しないのかを、仕様書(RFC)に基づいて整理します。
30秒で要点
- DMARCは「メールの安全性」ではなく「差出人ドメインの説明責任」を扱う仕組み
- DMARCのpassは、送信元がドメイン所有者に認可されていることを示すだけで、メール内容の安全性や望ましさを保証しない
- DMARCが定めるポリシーは、受信側に「従う義務」を課すものではない
- 旧仕様RFC 7489はRFC 9989・9990・9991に置き換え済み。参照する場合は新しい仕様を使う
なぜ「DMARCを設定すれば安全になる」と誤解しやすいのか
DMARCは「セキュリティ対策」という文脈で紹介されることが多いため、導入すればメールにまつわる脅威全般が防げると期待されがちです。しかし実際にDMARCが答えているのは、「このメールは、差出人として表示されているドメインの持ち主が、送信を認めたものか」という1つの問いだけです。
「安全かどうか」という広い問いと、「認可された送信元かどうか」という狭い問いを混同すると、DMARCを設定したあとも別の脅威(認可された送信元からの不適切な内容、認可されていない類似ドメインからの攻撃など)が残っていることに気づけません。
DMARCの最新仕様：RFC 7489からRFC 9989へ
まず、時点情報を整理します。DMARCの仕様は更新されています。IETFのデータトラッカーで確認したところ、DMARCを規定していた2015年3月発行のRFC 7489は、"Obsoleted by RFC 9989, RFC 9990, RFC 9991"(RFC 9989・9990・9991によって置き換え)と明記されています。RFC 7489自体も、Category(区分)は"Informational"(情報提供目的)であり、Internet Standards Track(標準化過程における正式な仕様)ではなかったことが本文中の記載から確認できました。
後継のRFC 9989は、"This is an Internet Standards Track document."と明記されたStandards Track文書(Proposed Standard)で、Abstractには"This document obsoletes RFCs 7489 and 9091."とあります。つまり、DMARCは非公式な情報提供文書の段階から、正式な標準化過程の文書へと格上げされたことになります。
確かなこと：RFC 7489がRFC 9989・9990・9991に置き換え済みであること、RFC 9989がStandards Track文書であることは、IETF公式ページの記載で直接確認できました。
まだ確かではないこと：RFC 9989・9990・9991それぞれの発行年月日は、確認できた範囲(Copyright表記の年)を超えて特定できていません。また、RFC 9990・9991の本文は今回参照しておらず、その表題や内容については扱いません。DMARCの導入を検討する際は、RFC 9989とあわせて、必要に応じて9990・9991も参照することをおすすめします。
DMARCが保証しないこと3つ
RFC 9989の本文を確認すると、DMARCの限界について明示的な記述があります。実務で誤解が起きやすい3点を整理します。
1. メールの安全性そのものは保証しない
RFC 9989には、"a DMARC pass by itself does not guarantee that delivery to the recipient's inbox would be safe or desirable."(DMARCのpassだけでは、受信者の受信箱への配送が安全・望ましいことを保証しない)と明記されています。DMARC passが示すのは、あくまで送信元ドメインの認可状況であり、本文の内容やリンク先の安全性までは検証していません。
2. 受信側の挙動を強制しない
DMARCの設定では、送信側が「認証に失敗したメールをどう扱ってほしいか」というポリシー(none/quarantine/reject)を宣言します。しかしRFC 9989には、"a mail-receiving organization that performs DMARC validation can choose to honor the Domain Owner's requested message handling for validation failures, but it is not required to do so."(受信側組織は、送信側の要求した取り扱いを尊重することを選べるが、従う義務はない)と明記されています。ポリシーを設定しても、すべての受信側が必ずそれに従うとは限りません。
3. 正規メールが必ず届くことは保証しない(誤設定時)
DMARCそのものの記述ではありませんが、上記2点の裏返しとして実務上重要な点です。自社が把握していない送信元(後述)がある状態でポリシーを厳しくすると、その送信元からの正規メールが届かなくなる可能性があります。「保証しないこと」の裏側には「注意して運用すべきこと」が隠れています。
前提知識について：メール認証プロトコル全般(SPF・DKIMなど)の基礎を先に知りたい場合は、メール配信の仕組み入門を参照すると本記事が理解しやすくなります。
DMARC本来の価値：集約レポートによる可視化
では、DMARCの価値はどこにあるのでしょうか。RFC 9989は、集約レポート(送信側に届くDMARCの検証結果の集計)の使い道として、なりすまし送信元の発見と並べて、"to flag and fix gaps in their own authentication practices"(自社の認証運用の穴を見つけて直すこと)を挙げ、こちらのほうが"more importantly"(より重要)である場合があるとしています。
これは実務上、示唆に富む記述です。DMARCを設定して初めて、「営業部門が契約していた外部のメール配信SaaSが、自社ドメインを名乗ってメールを送っていた」といった、社内で把握しきれていなかった送信元が可視化されるケースがあります。DMARCは「攻撃者を止める盾」としてだけでなく、「自社の送信元を棚卸しする鏡」としての価値を持っています。
ポリシーを引き上げる基準、上げてはいけない条件
以上を踏まえると、DMARCのポリシーをp=none(監視のみ)からp=quarantine(隔離)、p=reject(拒否)へと引き上げる際の判断軸が見えてきます。
上げてよい条件:
- 集約レポートを一定期間(数週間程度)受け取り、自社が認識している送信元からのメールがすべて認証を通過していることを確認できている
上げてはいけない条件:
- どの送信元が自社ドメインでメールを送っているか、まだ把握しきれていない
- 転送設定やメーリングリストの利用があり、それらが認証の仕組み上どう扱われるか未確認である
これらの条件を確認せずにp=rejectまで一気に引き上げると、把握していなかった正規の送信元からのメールが届かなくなり、業務影響が出る可能性があります。
自分でも試せる、最小の検証
自社ドメインのDMARCレコードが設定されているかどうかは、無料の確認手段があります。設定がまだであれば、いきなり厳しいポリシーにするのではなく、まずp=noneとレポート送付先(rua=)だけを設定し、1週間ほど集約レポートを観察してみてください。そこに、想定していなかった送信元が含まれていないかを確認するだけで、DMARCが「自社の送信元を可視化する」という価値を実感できます。
判断の土台として押さえておくこと
- DMARCが扱うのは「メールの安全性」ではなく「差出人ドメインの説明責任」。passはドメインの認可を示すだけで、内容の安全性や配送の保証ではない
- 受信側にポリシーへの追従を強制する仕組みではない。従うかどうかは受信側の任意
- 本来の価値は、攻撃者を止めることだけでなく、集約レポートによる自社の送信元の可視化にある
- ポリシーを引き上げる前に、自社が把握している送信元がすべて認証を通過しているかを確認する。仕様を参照する場合はRFC 7489ではなくRFC 9989を使う
自社ドメインのメール送信元をどこまで把握できているか、現状を整理するところから始めたい場合は、状況を整理するところから始めることができます。
状況を整理する（15分）より深く学ぶ
- メール配信の仕組み入門：SPF・DKIMを含むメール認証の基礎
参考資料・引用元
- IETF Datatracker, "RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)". https://datatracker.ietf.org/doc/rfc7489/
- RFC Editor, "RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC)". https://www.rfc-editor.org/rfc/rfc9989.html