フィッシング詐欺が多発する中、DMARCがいかにドメインを保護し、電子メールをより信頼できるものにするかに注目が集まっています。DMARCの導入は、複雑で気の遠くなるようなプロセスであることは周知の事実です。DMARCプロジェクトチームは、DNSベースのプロトコルを展開する際に、しばしば未知の領域に足を踏み入れ、ミスを犯します。当社のサポートおよび展開チームは、DMARCプロジェクトを円滑かつ成功させるために注意すべき一般的な間違いをいくつかまとめました。
DMARCの間違いトップ5
DMARCレコードが見つかりません
ドメインのアクティビティを監視し、電子メールを混乱させないために、p=noneに設定されたポリシーでDMARCレコードを公開することは、導入の第一歩です。DMARCレコードをパブリッシュしないことで、自社の監視対象インフラ以外でドメインがどのように使用されているかを把握できないだけでなく、DMARCが提供するドメイン保護を利用することもできません。DMARCレコードを公開するには、ここから始めることができます。
アクティブドメインで監視なしでポリシー実施暗黙タグの指定
ポリシーを実施するDMARCレコードを持つにもかかわらず、ドメインを監視するためのレポートがない（例：v=DMARC1; p=reject）場合、ドメインの保護を維持するために必要な可視性が得られません。誰が、どのようなメールを送信しているのかを把握するためには、モニタリングが重要です。
暗黙タグの指定
例えば、pct=100は、そのタグと値のペアを入れないのと同じである。rf=afrf、aspf=r、adkim=rも同様です。これらのタグや値を追加すると、レコードが複雑になり、TXTレコードが長くなるため、より多くのスペースを取るようになります。
レポートを別のドメインに送信する
外部ドメイン検証レコードを作成せずに、RUAタグとRUFタグに異なるドメインを含む宛先にレポートを送信すると、セキュリティリスクにつながる可能性があります。特にGoogleはこの要件をチェックしないため、依然としてレポートを受け取ることになる。しかし、他のDMARCリポータは、RUAタグとRUFタグのドメインが異なる宛先には、これらのタグのドメインが明示的にDNSで外部ドメイン検証レコードを公開しない限り、レポートを送信しないという仕様要件に従っています。このレコードは、他のドメインに関するDMARCレポートを送信しても問題ないことを世界に知らせる。これは、DDoS攻撃を防ぐために必要なセキュリティ上の制限であり、今後Googleがこの要件をチェックする可能性が高い。
DMARC構文が無効
DNSレコードを作成する際の留意点は以下の通りです。
- タグと値のペアの間にセミコロンを置くことを忘れないでください。
- p=monitorではなく、p=noneを使用してください。p=monitorは、公開前の初期のDMARCポリシーで、監視ポリシーであるp=noneに取って代わられました。
- 送信報告アドレスの前にmailto:を指定する。
- DNS TXTレコードのホスト名が_dmarcであることを確認する。
- p=タグをv=DMARC1の後に配置する – この位置で必要です。
- DNSのTXTレコードを囲む引用符は削除してください（一部のDNSプロバイダーは引用符を受け付けます）。
私たちがお手伝いします
Brandkeeperでは、メールセキュリティの専門家チームによるDMARCの導入から運用サポート及びコンサルテーション行っています。一旦はDMARCの導入をやってみたが運用を断念したお客様、または、導入時点でいくつものハードルであきらめた企業様のサポートも行っています。
お気軽にご連絡ください
