Domain-based Message Authentication, Reporting and Conformance （DMARC）の実装
このドキュメントの目的は、電子メール認証方法 DMARC に関する追加情報を読者に提供することです。 DMARC の仕組みと様々なポリシーオプションを説明することで、読者は DMARC がメール配信品質に与える影響をより深く理解できます。
DMARC とは about
ドメインベースのメッセージ認証、レポートおよび準拠は、ドメイン所有者がドメインを不正使用から保護できるようにする電子メール認証方法です。 また、DMARC はメール認証ステータスに関するフィードバックを提供し、認証に失敗したメールの処理を送信者が制御できるようにします。これには、実装されている DMARC ポリシーに応じて、メールを監視、隔離、強制隔離、拒否するオプションが含まれます。
DMARC には次の 3 つのポリシーオプションがあります。
- 監視（p=なし）: メールボックス プロバイダー/ISP に対して、通常メッセージに対して行う操作を指示します。
- 強制隔離（p=quarantine）: DMARC を受信者のスパムフォルダーまたは迷惑メールフォルダーに渡さないメールを配信するように、メールボックスプロバイダーや ISP に指示します。
- 拒否（p=拒否）: バウンスの原因となる DMARC を通過しないメールをブロックするようにメールボックスプロバイダーや ISP に指示します。
DMARC の仕組み how
SPF と DKIM はいずれも、メールをドメインに関連付け、連携してメールを認証するために使用されます。DMARC はこれを一歩進めて、DKIM と SPF でチェックされたドメインと照合することで、スプーフィングを防ぐのに役立ちます。 DMARC 認証に合格するには、メッセージが SPF または DKIM に合格する必要があります。これらの両方が認証に失敗した場合、DMARC は失敗し、選択した DMARC ポリシーに従ってメールが配信されます。
DMARC を実装すべき理由 why
DMARC はオプションであり、必須ではありませんが、無料で、メール受信者がメールの認証を簡単に識別できるため、配信が改善される可能性があります。 DMARC の主な利点の 1 つは、SPF や DKIM に失敗したメッセージに関するレポートを提供することです。 また、これらの認証方法のいずれも渡さないメールがどうなるかを、送信者が制御できるようにします。 DMARC レポートを通じて、送信者はどのメッセージが DMARC に失敗しているかを可視化し、さらなるエラーを軽減するための手順を取ることができます。
DMARC 実装のベストプラクティス best-practice
DMARC はオプションなので、ESP のプラットフォームでは、デフォルトでは設定されません。 ドメインを機能させるには、ドメインの DNS に DMARC レコードを作成する必要があります。 さらに、組織内で DMARC レポートを送信する場所を示すには、任意のメールアドレスが必要です。 ベストプラクティスは次のとおりです。
dmarc の潜在的な影響を DMARC が理解できるように、DMARC ポリシーを p=none、p=quarantine、p=reject にエスカレーションして、DMARC 実装をゆっくりと展開することをお勧めします。
-
受け取って使用するフィードバック（p=none）を分析します。このフィードバックは、認証に失敗してもメールレポートを送信者に送信するメッセージに対しては、何のアクションも実行しないように受信者に指示します。 また、正当なメッセージが認証に失敗する場合は、SPF／DKIM の問題を確認および修正します。
-
SPF と DKIM が連携し、すべての正当なメールに認証を渡しているかどうかを判断し、ポリシーを（p=quarantine）に移動します。これにより、受信メールサーバーに、認証に失敗したメールを強制隔離するように指示します（通常、これらのメッセージをスパムフォルダーに配置することを意味します）。
-
ポリシーをに調整（p=reject）。 p= reject ポリシーは、認証に失敗したドメインのメールを完全に拒否（バウンス）するよう受信者に指示します。このポリシーを有効にすると、ドメインで 100％認証された電子メールのみがインボックスにも配置される可能性があります。
note note NOTE このポリシーは慎重に使用し、組織に適しているかどうかを判断してください。
DMARC レポート reporting
DMARC は、SPF/DKIM に失敗したメールに関するレポートを受信する機能を備えています。 認証プロセスの一環として、ISP サービサーによって生成される異なる 2 つのレポートがあります。これらのレポートは、送信者が DMARC ポリシーの RUA/RUF タグを介して受信できます。
- 集計レポート（RUA）: には、GDPR に影響を受ける可能性のある PII （個人を特定できる情報）は含まれていません。
- フォレンジックレポート（RUF）: GDPR に機密のメールアドレスが含まれます。 を利用する前に、GDPR に準拠する必要のある情報に対処する方法を内部で確認することをお勧めします。
これらのレポートの主な用途は、スプーフィングが試行されたメールの概要を受け取ることです。 これらは、サードパーティのツールを介してダイジェストするのが最適な、高度に技術的なレポートです。 DMARC 監視を専門とする企業の一部を次に示します。
DMARC レコードの例 example
v=DMARC1; p=reject; fo=1; rua=mailto:dmarc_rua@emaildefense.proofpoint.com;ruf=mailto:dmarc_ruf@emaildefense.proofpoint.co
DMARC タグとその機能 tags
DMARC レコードには、DMARC タグと呼ばれる複数のコンポーネントがあります。 各タグには、DMARC の特定の側面を指定する値があります。
1：何かが失敗した場合にレポートを生成
d: DKIM が失敗した場合にレポートを生成
s: SPF が失敗した場合にレポートを生成
rua=mailto:aggrep@example.comruf=mailto:authfail@example.comDMARC とAdobe Campaign campaign
DMARC エラーの一般的な理由は、「From」と「Errors-To」または「Return-Path」アドレスの位置ずれです。 これを回避するには、DMARC を設定する際に、配信テンプレートの「送信者」および「エラー先」アドレス設定を再確認することをお勧めします。
-
配信テンプレート内で、現在「送信者」アドレスとして設定されているアドレスを確認します。
-
ここから「プロパティ」を選択すると、配信テンプレートをさらに編集できます。 このウィンドウで、「SMTP」を選択し、「プラットフォームに定義されているデフォルトのエラーアドレスを使用する」を選択している場合はオフにします。 Adobe Campaignの配信テンプレートでは、デフォルトでこのチェックボックスをオンにします。 デフォルトのエラーアドレスは、この配信テンプレートの送信元アドレスに関連付けられたアドレスではない可能性があります。
-
このチェックボックスをオフにすると、テキストフィールドが表示され、送信元アドレスに設定されたものと同じドメインを使用する一意のエラーアドレスを入力できます。
これらの変更を保存すると、正しいドメインの整合性を持つ DMARC 実装を進めることができます。