DMARC導入におけるよくある5つの失敗
フィッシング攻撃が過去最高水準に達する中、DMARCがドメインの保護やメールの信頼性向上にどのように役立つかについて、認識が高まっています。DMARCの導入が複雑で困難なプロセスになり得ることは周知の事実です。DMARCプロジェクトチームは、このDNSベースのプロトコルを導入する際、未踏の領域に踏み込み、ミスを犯してしまうことがよくあります。そこで、当社のサポートおよび 導入チームは、お客様のDMARCプロジェクトをより円滑かつ成功に導くために、注意すべきよくあるミスをまとめました。
DMARCに関するよくある間違いトップ5
1. DMARCレコードが見つかりません
ポリシーが p=none に設定し、ドメインの活動を監視しつつメール配信を妨げないよう設定したDMARCレコードを公開することが、導入の第一歩です。DMARCレコードを公開していないと、自社の監視対象インフラ以外でドメインがどのように使用されているか把握できないだけでなく、DMARCが提供するドメイン保護のメリットも享受できません。DMARCレコードを公開するには、こちらから始められます。
2. 監視機能のないアクティブなドメインでの ポリシー 適用
ポリシー適用（例：v=DMARC1;p=reject）が設定されているものの、ドメインを監視するためのレポート機能がないDMARCレコードでは、ドメインの保護を維持するために必要な可視性が得られません。誰が、どのようなメールを自分の名義で送信しているかを把握するには、監視が不可欠です。
3.暗黙の タグの指定
例えば、pct=100 と指定することは、そのタグと値のペアを指定しないのと同じ意味になります。rf=afrf、aspf=r、adkim=r についても同様です。これらのタグと値を追加すると、レコードが複雑に見え、TXTレコードが長くなるため、より多くのスペースを占有することになります。
4. 異なるドメインへのレポート送信
RUAおよびRUFタグに異なるドメインが含まれる宛先に、外部ドメイン検証レコードを作成せずにレポートを送信すると、セキュリティ上のリスクにつながる可能性があります。特にGoogleはこの要件を確認しないため、レポートは正常に受信されます。 しかし、他のDMARCレポーターは、RUAおよびRUFタグ内のドメインが異なる宛先へのレポート送信を禁止するという仕様要件に従っています。ただし、それらのタグ内のドメインがDNSに外部ドメイン検証レコードを明示的に公開している場合は例外です。このレコードは、他のドメインに関するDMARCレポートをそのドメインに送信しても問題ないことを公に示すものです。これはDDoS攻撃を防ぐために必要なセキュリティ上の制限であり、Googleも将来的にこの要件を確認するようになる可能性が高いです。
5. DMARC構文が無効です
DNSレコードを作成する際に留意すべき点は以下の通りです：
- タグと値のペアの間には、必ずセミコロンを入れるようにしてください。
- 使用 p=none を使用し、p=monitorは使用しないでください。p=monitorは、公開前の初期のDMARCポリシーであり、 p=none（監視ポリシー）に取って代わられました。
- 送信報告用アドレスの先頭に「mailto:」を指定してください。
- DNSのTXTレコードにホスト名「_dmarc」が設定されていることを確認してください
- p=タグはv=DMARC1の 後に配置してください。 この位置に配置することが必須です。
- DNSのTXTレコードから引用符を削除してください。ただし、引用符を許可しているDNSプロバイダーもあります。
dmarcianは、DMARCに関する知識と理解を広めることで、メールの安全性向上に努めています。まだDMARCの導入を開始されていない場合は、こちらから一切の制約のない無料トライアルにお申し込みいただけます。
この会話を続けたいですか？dmarcianフォーラムへどうぞ。
