MailData

DMARCポリシーの説明: None(何もしない)、Quarantine(隔離)、およびReject(排除)

DMARCポリシーの説明: None(何もしない)、Quarantine(隔離)、およびReject(排除)

DMARCの3つのポリシーを理解する

2024年2月5日
著者: Maitham Al Lawati
翻訳: 竹洞 陽一郎

この記事はPowerDMARCのブログ記事 DMARC Policy Explained: None, Quarantine and Reject の翻訳です。
Spelldataは、PowerDMARCの日本代理店です。
この記事は、PowerDMARCの許可を得て、翻訳しています。

電子メール認証は、サイバーセキュリティにおいて重要な実践となっています。
これは、実在する有名な組織を偽装する事例が増加している結果です。
フォーブスによれば、サイバー犯罪に関連するコストは2025年までに年間10.5兆ドルに達すると予測されています。

これが、DMARCのようなメール認証プロトコルの採用が重要になる理由です。
DMARC（Domain-based Message Authentication, Reporting, and Conformance）は、テキストレコードとしてメール送信者のドメインネームシステム（DNS）に配置することができます。
DMARCを有効にすると、メールの検証とセキュリティが開始されます。
DMARCポリシーは、フィッシング、メールスプーフィング、ランサムウェア攻撃を防ぎ、メールの配信率を向上させる力を持っています。

DMARCポリシーは、認証に失敗したメッセージをどのように処理するかをメール受信者に指示します。
このポリシーは、次の3つの可能なアクションを指定できます。

DMARCポリシー

DMARCポリシーを「reject」に設定することで、ドメインの悪用、ブランドの偽装、フィッシング、およびスプーフィング攻撃のリスクを最小限に抑えることができます。

DMARCによるメールのセキュリティ

メールは簡単に偽造でき、本物と危険な偽物の区別が難しくなっています。
そこでDMARCが役立ちます。
DMARCは、送信者の身元を確認してメッセージを通過させる前に検証するメールセキュリティチェックポイントのようなものです。

実際、Verizonの報告によると、すべてのデータ漏洩の30％以上がフィッシング攻撃の結果であり、DMARCのような強力な保護の必要性を示しています。
DMARCを使用することで、スプーフィングの試みをブロックし、受信トレイを詐欺メールから安全に保つことができます。

IETFのRFC7489によると、DMARCはメール送信者が認証に関する設定を行うことができる独自の機能を持っています。
これを有効にすると、メールの取り扱いや潜在的なドメインの悪用に関するレポートを取得することもできます。
これにより、DMARCはドメインの検証において際立っています。

DMARCの設定プロセスを開始するには、いくつかのDNS変更を行い、プロトコルのDNS TXTレコードを含める必要があります。
ただし、このプロトコルの手動実装は、技術的な知識がないユーザーにとって非常に複雑です。
ビジネスのために外部のCISOを雇う場合、かなりのコストがかかることもあります。

したがって、PowerDMARCのDMARCアナライザーは簡単な代替手段です。
私たちはDMARCポリシーの設定を自動化し、時間とお金を節約します。

GoogleやYahooの新しいメール送信者要件が発行された後、私はPowerDMARCを見つけました。
PowerDMARCはすぐにDMARCポリシーの監視を設定してくれました。
これにより、私たちは徐々に（しかし確実に）より良い保護のために強制ポリシーに移行することができました。

― Rachel R(小規模ビジネスオーナー)

DMARCポリシーとは？

DMARCポリシーは、特別なTXTレコードとして設定できるDNSレベルの指示セットです。
認証に失敗したメールをどのように処理するかを受信メールサーバーに伝えます。
これは、DMARCレコード内の「p」タグで示され、DMARC検証に失敗した場合にメールサーバーが取るべきアクションを指定します。

実際のDMARCポリシーは、ブランドを偽装しようとするメールをどの程度厳密に処理するかを決定するのに役立ちます。
ドメインのセキュリティガードのように考えてください。
IDに応じて、ガードはビル（この場合は受信者の受信トレイ）に入れるかどうかを決定します。 入れさせない（reject）、特別な場所に送ってさらに確認する（quarantine）、またはそのまま入れる（none）かのいずれかです。

DMARCポリシーをp=rejectに設定すると、スプーフィング、フィッシング、およびドメイン名の悪用を防ぐことができ、ブランドを偽装しようとする悪意のある行為者に対する「立ち入り禁止」サインのように機能します。

3種類のDMARCポリシー：p=reject、p=none、p=quarantine

メールドメインの所有者が確立したい強制レベルに応じて、3つの主要なDMARCポリシータイプがあります。
none、quarantine、およびrejectです。
これらのポリシーオプションの主な違いは、メール送信者がDNSレコードで定義したポリシーに従う際に、受信メール転送エージェントによって取られるアクションによって決まります。

以下に、3つのDMARCポリシータイプの概要と詳細な説明を示します。

DMARC None
「監視のみ」のポリシーで、保護は提供しません。導入初期段階に適しています。
DMARC Quarantine
認証されていないメールをフラグまたは隔離します。
DMARC reject
認証されていないメールの受信トレイアクセスをブロックします。

1. DMARC Noneポリシー

DMARC noneポリシー

DMARCポリシーnone（p=none）は、受信側でアクションをトリガーしない緩いモードです。
このポリシーはメール活動を監視するために使用できます。
サイバー攻撃に対する保護は提供しません。

Noneポリシー実装の使用例


v=DMARC1; p=none; rua= mailto:(メールアドレス);

2. DMARC Quarantineポリシー

DMARC quarantineポリシー

p=quarantineは、ドメイン所有者がDMARCに失敗した場合にメールをスパムフォルダに戻して後で確認するよう受信者に促すことができるため、ある程度の保護を提供します。

Quarantineポリシー実装の使用例 


v=DMARC1; p=quarantine; rua=mailto:(メールアドレス);

DMARC Rejectポリシー

DMARC rejectポリシー

最後に、reject DMARCポリシー（p=reject）は強制ポリシーです。
DMARC認証に失敗したメッセージが拒否されるようにします。
DMARC rejectは、認証されていないメールを廃棄することで最大の強制力を提供します。

Rejectポリシー実装の使用例 


v=DMARC1; p=reject; rua= mailto:(メールアドレス);

DMARCポリシーを強制するメリット

ドメインに厳格なDMARCポリシーを設定する利点を見てみましょう。

1. フィッシングやBECに対する直接的な保護

DMARC reject（DMARC強制）の際は、認証されていないソースからのメールが廃棄されます。
これにより、受信者の受信トレイに詐欺メールが届くのを防ぎます。
したがって、フィッシング攻撃、スプーフィング、BEC、およびCEO詐欺に対する直接的な保護を提供します。

これは特に重要で、

2. 悪意のあるソフトウェアに対する最初の防御線

ランサムウェアやマルウェアは、偽装されたドメイン名から送信される偽のメールを介して広がることがよくあります。
これらは、オペレーティングシステムに侵入し、完全に乗っ取ることができます。

DMARCポリシーをrejectに設定することで、認証されていないメールがクライアントの受信トレイからブロックされます。
これにより、クライアントが危険な添付ファイルをクリックするのを防ぎます。
さらに、ランサムウェアやマルウェアをシステムにダウンロードする可能性を最小限に抑えます。
ここで、DMARCポリシーはこれらの攻撃に対する初歩的な防御線として機能します。

3. メールチャンネルの監視

メッセージの取引や送信ソースを監視するだけであれば、p=noneのDMARCで十分です。
これでは、サイバー攻撃に対する保護は提供されません。

4. 配信前に疑わしいメールをレビューする

認証されていないメールをすぐにブロックしたくない場合、quarantineを使用できます。
quarantine DMARCポリシーを活用して、配信前に疑わしいメッセージをレビューします。
これにより、メールが受信トレイではなくquarantineフォルダに保存されます。

最適なDMARCポリシーの選択とその理由

メールセキュリティの取り組みを最大限に強化し、Gmailのブルーチェック機能を有効にするには、DMARC rejectが最適なDMARCポリシーです。
p=rejectの際、ドメイン所有者はクライアントの受信トレイから認証されていないメッセージを積極的にブロックします。
DMARCポリシーは、サイバー攻撃に対する高い保護を提供します。
これには、直接ドメインのスプーフィング、フィッシング、その他の形式の偽装脅威が含まれます。
したがって、効果的なアンチフィッシングポリシーとしても機能します。

DMARC強制の際、BIMIも実装できます。
BIMIを使用すると、GmailやYahooの受信トレイでメールにブルーチェックマークを表示できるので、とてもクールです！

よくあるDMARCポリシーの誤解を解消

DMARCポリシーに関する一般的な誤解があります。
これらのいくつかは、メール配信に深刻な影響を与える可能性があります。
それらが何であり、その背後にある真実を学びましょう。

1. DMARC noneはスプーフィングを防ぐことができる
DMARC noneは「アクションなし」のポリシーであり、サイバー攻撃からドメインを保護することはできません。
攻撃者はp=noneポリシーを悪用してドメインを偽装することがよくあります。
これまでの数年間、多くのドメイン所有者がPowerDMARCに連絡し、DMARCを実装していてもスプーフィングされていると説明しました。
当社の専門家がさらに確認したところ、ほとんどがDMARCポリシーを「none」に設定していることが判明しました。
2. p=noneの際にDMARCレポートを受け取らない
p=noneの際でも、送信者の有効なメールアドレスを指定するだけで、日々のDMARCレポートを受け取り続けることができます。
3. DMARC「quarantine」は重要ではない
よく見過ごされがちですが、DMARCのquarantineポリシーは移行段階で非常に有用です。
ドメイン所有者はこれを利用して、アクションなしから最大の強制力にスムーズに移行できます。
4. DMARC rejectは配信可能性に影響する
DMARC rejectの際でも、正当なメールがスムーズに配信されるようにすることができます。
送信者の活動を監視し、認証結果を分析して失敗を早期に検出することが重要です。

DMARCポリシーのエラーのトラブルシューティング

次のような一般的なDMARCポリシーのエラーに遭遇する可能性があります。

構文エラー
プロトコルが正しく機能するようにするために、レコードの設定時に構文エラーに注意する必要があります。
構成エラー
DMARCポリシーの設定時にエラーが発生することはよくあり、DMARCチェッカーツールを使用することで回避できます。
DMARC spポリシー
DMARC rejectポリシーを設定しても、サブドメインポリシーをnoneに設定している場合、コンプライアンスを達成することはできません。
これは、送信メールに対するポリシーの上書きが原因です。
「DMARCポリシーが有効になっていません」エラー
レポートにこのエラーメッセージが表示された場合、DNSにDMARCドメインポリシーが欠落しているか、「none」に設定されていることを示します。
レコードを編集してp=reject/quarantineを組み込み、この問題を解決します。

DMARCポリシーの更新、強制、および最適化の安全な方法

PowerDMARCのDMARCアナライザープラットフォームは、DMARCプロトコルの設定を簡単に行うのに役立ちます。
クラウドネイティブインターフェースを使用して、数回クリックするだけでレコードを監視および最適化します。
その主な利点を見てみましょう。

DMARCポリシーを実装し、結果を簡単に監視するために、今日私たちにお問い合わせください！

DMARCポリシーのFAQ

私のメールがDMARC準拠かどうかはどうすればわかりますか？
PowerDMARCの顧客は、ダッシュボードの概要を確認することで準拠を簡単に評価できます。
PowerAnalyzerを使用して、現在のセキュリティ体制を分析することもできます。
DMARCポリシーを修正するにはどうすればよいですか？
DNS管理にアクセスしてポリシーを手動で修正できます。
DNS管理に入ったら、DMARC TXTレコードを編集する必要があります。
より簡単な解決策は、ホストされたソリューションを使用して、ワンクリックでポリシーを変更することです。
デフォルトのDMARCポリシーは何ですか？
ポリシーを追加するためにDMARCジェネレーターツールを使用する場合、「none」がデフォルトモードとして割り当てられます。
手動で実装する際には、「p=」フィールドにポリシーを定義する必要があります。
そうしないと、レコードが無効と見なされます。
コンテンツと事実確認のレビュープロセス
このコンテンツはサイバーセキュリティの専門家によって執筆されました。
技術的な正確性と関連性を確保するために、社内のセキュリティチームによって綿密にレビューされています。
すべての事実は、公式IETFドキュメントと照らし合わせて確認されています。
情報を裏付けるレポートや統計への参照も記載されています。