DMARC レコード dmarc-record
DMARC とは what-is-dmarc
DMARC（Domain-based Message Authentication, Reporting, and Conformance）は、ドメイン所有者が自身のドメインを不正使用から保護できるようにするメール認証方式です。メールプロバイダーやインターネットサービスプロバイダー（ISP）明確なポリシーを提供することで、自分のドメインから悪意のある関係者がメールを送信するのを防ぐことができます。DMARC を実装すると、正当なメールがスパムとしてマークされたり拒否されたりするリスクが軽減され、メールの配信品質が向上します。
また、DMARC では、認証に失敗したメッセージに関するレポートを提供し、DMARC 検証に合格しないメールの処理を制御できます。実装されている DMARC ポリシーに応じて、これらのメールは監視、強制隔離または拒否できます。これらの機能を使用すると、潜在的なエラーを軽減し、対処するための行動をとることが可能になります。
認証に失敗したメールを制御しながら配信品質の問題を防止できるように、Journey Optimizer は現在、直接管理インターフェイスで DMARC 技術をサポートしています。詳細情報
DMARC の仕組み how-dmarc-works
SPF と DKIM はいずれも、メールをドメインに関連付け、連携してメールを認証するために使用されます。DMARC はこれをさらに一歩進め、DKIM と SPF によってチェックされたドメインと照合することで、詐称を防止します。
DMARC 認証に合格するには、メッセージが SPF または DKIM に合格する必要があります。
- SPF（Sender Policy Framework）は、送信サーバーの IP アドレスをドメインの認証済み IP アドレスのリストと照らし合わせて確認することで、メールメッセージが許可された送信元から送信されたものであることを確認するのに役立ちます。
- DKIM（DomainKeys Identified Mail）はデジタル署名をメールメッセージに追加し、受信者がメッセージの完全性と真正性を検証できるようにします。
これらの両方またはいずれかが認証に失敗した場合、DMARC は失敗し、選択した DMARC ポリシーに従ってメールが配信されます。
DMARC ポリシー dmarc-policies
メールが DMARC 認証に失敗した場合、そのメッセージに適用するアクションを決定できます。DMARC には次の 3 つのポリシーオプションがあります。
- モニター（p=none）：メッセージに対する通常の処理をすべて実行するよう、メールボックスプロバイダー／ISP に指示します。
- 強制隔離（p=quarantine）：DMARC 認証に失敗するメールを受信者のスパムフォルダーまたは迷惑メールフォルダーに配信するよう、メールボックスプロバイダー／ISP に指示します。
- 拒否（p=reject）：DMARC 認証に失敗してバウンスが発生するメールをブロックするよう、メールボックスプロバイダー／ISP に指示します。
DMARC 要件の更新 dmarc-update
Google と Yahoo! は、業界のベストプラクティス実施の一環として、メール送信に使用するすべてのドメインに対して DMARC レコード を要求しています。この新しい要件は、2024年2月1日（PT） から適用されます。
そのため、アドビでは、次のアクションを実行することを強くお勧めします。
-
Journey Optimizer でアドビに 委任済みのすべてのサブドメイン に対して、DMARC レコード が設定されていることを確認してください。方法についてはこちらを参照
-
アドビに 新しいサブドメインをデリゲート すると、直接 Journey Optimizer 管理インターフェイス で DMARC を設定 できるようになります。方法についてはこちらを参照
Journey Optimizer での DMARC の実装 implement-dmarc
Journey Optimizer 管理インターフェイスを使用すると、アドビに委任した、または委任しているすべてのサブドメインに対して DMARC レコードを設定できます。詳しい手順は以下の通りです。
DMARC の既存のサブドメインを確認します。 check-subdomains-for-dmarc
Journey Optimizer で委任したすべてのサブドメインに対して DMARC レコードが設定されていることを確認するには、次の手順に従います。
-
管理／チャネル／サブドメイン メニューにアクセスし、「サブドメインの設定」をクリックします。
-
委任されたサブドメインごとに、DMARC レコード 列を確認します。指定のサブドメインのレコードが見つからなかった場合は、アラートが表示されます。
note caution CAUTION Gmail および Yahoo! の新しい要件に準拠し、上位の ISP の配信品質の問題を回避するには、すべての委任されたサブドメインに対して DMARC レコードを設定することをお勧めします。詳細情報 -
DMARC レコードが関連付けられていないサブドメインを選択し、組織の要件に応じて DMARC レコード セクションに入力します。DMARC レコードフィールドに値を入力する手順について詳しくは、この節を参照してください。
-
次の 2 つのオプションを検討します。
-
変更を保存します。
新しいサブドメイン用の DMARC の設定 set-up-dmarc
Journey Optimizer で新しいサブドメインをアドビに委任すると、お使いのドメインの DNS に DMARC レコードが作成されます。DMARC を実装するには、以下の手順に従います。
-
新しいサブドメインの設定方法についてはこちらを参照
-
「DMARC レコード」セクションに移動します。
サブドメインに DMARC レコードがすでに存在する場合、および Journey Optimizer で取得される場合、インターフェイスで強調表示されているのと同じ値を使用したり、必要に応じて値を変更したりできます。
note note NOTE 値を追加しない場合は、事前に入力されたデフォルト値が使用されます。 -
DMARC が失敗した場合に受信者サーバーが実行するアクションを定義します。適用したい DMARC ポリシーに応じて、次の 3 つのオプションのいずれかを選択します。
- なし（デフォルト値）：DMARC 認証に失敗したメッセージに対して何のアクションも実行しない一方で、送信者にはメールレポートを送信するよう受信者に指示します。
- 強制隔離：DMARC 認証に失敗したメールを強制隔離するよう受信メールサーバーに指示します。これは、通常、受信者のスパムフォルダーまたは迷惑メールフォルダーにこれらのメッセージを配置することを意味します。
- 拒否：認証に失敗したドメインのメールを、完全に拒否（バウンス）するよう受信者に指示します。このポリシーを有効にすると、ドメインで 100％認証されたメールのみが受信トレイに配置される可能性があります。
note note NOTE ベストプラクティスとして、DMARC の潜在的な影響を把握できるように、DMARC ポリシーを なし から 強制隔離 に、さらに 拒否 にエスカレーションすることで、DMARC の実装を徐々に展開することをお勧めします。 -
必要に応じて、1 つまたは複数のメールアドレスを選択して追加し、認証に失敗したメールに関する DMARC レポート が送信される組織内の場所を指定します。レポートごとにアドレスを 5 つまで追加できます。
note note NOTE これらのレポートを受け取ることができる正規の受信ボックス（アドビ以外）を管理下に置いてください。 ISP が生成するレポートには、送信者が DMARC ポリシーの RUA/RUF タグを通じて受信できるものが 2 種類あります。
- 集計レポート（RUA）：GDPR に触れる可能性のある PII（個人を特定できる情報）は含まれていません。
- フォレンジック失敗レポート（RUF）：GDPR に触れるメールアドレスが含まれています。利用する前に、GDPR に準拠する必要がある情報の処理方法を社内で確認してください。
note note NOTE これらの高度に技術的なレポートでは、スプーフィング（なりすまし）を試みたメールの概要を提供します。これらはサードパーティーのツールを使用するとよく解釈できます。 -
DMARC の対象となるメールの 適用割合 を選択します。
この割合は、ご利用のメールインフラストラクチャに対する信頼度と、誤検知（正当なメールが不正と判定されること）の許容度によって異なります。組織では、DMARC ポリシーの設定を なし から始め、徐々に DMARC ポリシーの割合を増やし、正当なメール配信への影響を注意深く監視するのが一般的です。
note note NOTE メール管理者や IT チームと協力し、メール認証の実践に自信を持てるようになるのにつれ、割合を徐々に増やしていきます。 ベストプラクティスとして、DMARC のコンプライアンス率を高め（理想的には 100 %に近い水準に目標を定め）、誤検出のリスクを最小限に抑えながら、セキュリティ上のメリットを最大限に活用します。
-
レポート間隔 を 24 時間から 168 時間の間で選択します。これにより、ドメイン所有者はメール認証結果に関する最新情報を定期的に受け取り、メールのセキュリティを向上させるために必要な措置を講じることができます。