☰

rua なしの DMARC... 適切な形式ですか?

tag-icon • tag-icon dmarc
rua なしの DMARC... 適切な形式ですか?

Shopify によると、Yahoo と Google では現在 DMARC が必須となっています。私はクライアント用に設定していますが、集計レポートは必要ありません。必要な場合はこれらの企業が正当な送信者を確認できるようにするためだけに必要です。rua を削除できることを読みましたが、クライアントのメールが引き続き受け入れられることを確認したいのです。現在、次のように記述しています: v=DMARC1; p=none; rua=mailto:dmarc-reports@mydomain, mailto:artist@mydomain 代わりに v=DMARC1; p=none; mailto:artist@mydomain を使用すればよいのでしょうか?
dmarc での検証がどのように機能するかわかりません。私のホストは _dmarc.mydomain を追加するので、それを追加する必要はありません。

答え1

TL;DR:v=DMARC1; p=none;構文的には有効ですが、実際には意味をなしません。

あなたは楽な道を選んでおり、それは裏目に出るでしょう。Googleの2024年2月1日の要件DMARCに関する要件は緩い。一方で、次の要件はGoogleが要求することになるようだ。配置 ポリシーがあってもp=none。

  • 送信ドメインのDMARCメール認証を設定します。DMARC施行方針に設定できますnone。もっと詳しく知る
  • ダイレクトメールの場合、送信者のFrom:ヘッダーのドメインはSPFドメインまたはDKIMドメインのいずれかと一致している必要があります。これは、DMARCアライメント。

しかし、これは DMARC ポリシーの使用のほんの始まりに過ぎません。これは、p=none正当なメールの配信が実際の DMARC の適用に合格するかどうかがまだわからない移行段階です。あなたは集計レポートは必要ないと言っていますが、私はそれには同意しません。集計レポートを取得して読むことが、次の段階でのスムーズなメール配信に必要な知識を得る唯一の方法です。さらに、Google と Yahoo も次にそれを適用し始めるかもしれません。

また、企業は「必要に応じて正当な送信者を確認」できる必要があるとも述べています。 はp=noneそれを規定していません。DMARC の施行に向けて一歩前進しているとは述べていますが、現時点では、受信者が当社のドメインから偽装された電子メールをどのように扱うかは問題ではありません。

その後、少なくともp=quarantineメールインフラが静的かつ安定していれば、かもしれないを削除するrua=と、正当なメールが隔離され始めたかどうかがわからなくなります。 を使用すると、p=reject拒否されたメッセージからそれを知ることができます。ただし、たとえば、マイクロソフトの扱い p=rejectまさにその通りですp=quarantine。

答え2

rua タグを設定した場合にのみ DMARC レポートを受信します。準拠する最小限の DMARC レコードは次のようになります。

v=DMARC1; p=none;

のタグ記録に使用できるものは次のとおりです。

  • v (必須) - バージョンタグ。許可される値は「DMARC1」のみです。正しくない場合、またはタグがない場合、DMARC レコードは無視されます。リスト項目
  • p (必須) - DMARC ポリシー。許可される値は、「none」、「quarantine」、または「reject」です。デフォルトは「none」で、認証されていないメールに対しては何もアクションを実行しません。これは、DMARC レポートを収集し、現在のメール フローとその認証ステータスを把握するのに役立つだけです。「quarantine」は失敗したメールを疑わしいものとしてマークし、「reject」はブロックします。
  • rua - 集約レポートの送信先。これは、ESP が失敗レポートの送信に使用する「mailto:」URI です。このタグはオプションですが、省略するとレポートを受信できません。
  • ruf - フォレンジック (障害) レポートの送信先。これは、ESP が障害レポートの送信に使用する「mailto:」URI です。このタグはオプションですが、省略するとレポートを受信できません。
  • sp - サブドメイン ポリシー。ここで特に定義されていない限り、サブドメインは上で説明したドメイン ポリシー タグ (p=) を継承します。ドメイン ポリシーと同様に、許可される値は「なし」、「隔離」、または「拒否」です。このオプションは現在あまり使用されていません。
  • adkim - DKIM 署名の配置。このタグは、DKIM ドメインと親の Header From ドメイン間の配置に従います。許可される値は「r」(緩和) または「s」(厳密) です。「r」はデフォルトで部分一致を許可しますが、「s」タグではドメインが同じである必要があります。
  • aspf - SPF アライメント。このタグは、SPF ドメイン (送信者) と Header From ドメイン間のアライメントに従います。許可される値は、「r」(緩和) または「s」(厳密) です。「r」はデフォルトで、部分一致を許可しますが、「s」タグではドメインが完全に同じである必要があります。
  • fo - フォレンジック レポート オプション。許可される値は、「0」、「1」、「d」、「s」です。「0」はデフォルト値で、SPF と DKIM の両方が整合パスを生成できなかった場合にフォレンジック レポートを生成します。プロトコルの結果のいずれかがパス以外の場合は、「1」を使用します。「d」は DKIM が無効な場合にレポートを生成し、「s」は SPF に対して同じことを行います。フォレンジック レポートを受信するには、ruf タグを定義します。
  • rf - 失敗レポートのレポート形式。許可される値は「afrf」と「iodef」です。 pct パーセンテージ タグ。このタグは、「quarantine」または「reject」ポリシーを持つドメインでのみ機能します。これは、特定のポリシーを適用する失敗したメールの割合を示します。残りは、より低いポリシーに該当します。たとえば、「quarantine」ポリシーを持つドメインで「pct=70」の場合、70% の時間だけ適用されます。残りの 30% は「p=none」に該当します。同様に、「p=reject」および「pct=70」の場合、「reject」は失敗したメールの 70% に適用され、30% は「quarantine」に該当します。
  • ri - レポート間隔。受信した XML レポートの頻度を秒単位で指定します。デフォルトは 86400 (1 日 1 回) です。設定された間隔に関係なく、ほとんどの場合、ISP はさまざまな間隔 (通常は 1 日 1 回) でレポートを送信します。v バージョン タグ。許可される値は「DMARC1」のみです。この値が正しくないか、タグが欠落している場合、DMARC レコードは無視されます。

SPF と DKIM を使用することを忘れないでください。そうしないと、DMARC は機能しません。

ドメインの不正使用を検出し、将来の配信を保証するために、DMARC 処理サービスの使用を検討する必要があります。

DMARCについてもう少し詳しく知りたい方は、https://dmarc.org/

関連情報