メッセージは伝わる DMARC それでもメールボックスプロバイダーの送信者の要件を満たしていません。それは必ずしも矛盾しているわけではありません。 DMARC特定のアイデンティティに関する質問に答えます。受信者には、機能するメカニズム、安全なトランスポート、適切なメッセージ構築、および責任ある送信動作も必要な場合があります。
プロトコルの決定から始める
参考文献: RFC 9989 §4.1, RFC 9989 §4.4, RFC 9989 §4.10, RFC 9989 §5.3.5.
RFC 9989は、2026 年 5 月に公開され、従来の RFC 7489 および 9091 を廃止します。そのセクション 4.1 では、作成者ドメインのポリシー レコードが存在し、そのドメインがメッセージからの認証された識別子と一致する場合、 DMARC合格します。 aligned-pass の原則はそのままです。サポートされている少なくとも 1 つの認証メカニズムは、次の条件でパスする必要があります。 アライメント 表示されている From ドメインに送信します。のために SPF DMARC内では、関連する ID はSMTPです。 メール送信元 RFC 9989 §4.4.2 に基づくドメイン。スタンドアロンの HELO ベースのSPF結果は、 DMARC ID の代わりにはなりません。のために DKIM、それは有効な署名の d= ドメインです。必要な調整が行われていない正常なメカニズムは、 DMARCパスに寄与しません。 RFC 9989セクション 3.2.10 および 4.1 ～ 4.3.
アライメントには厳密モードと緩和モードがあります。厳密は、該当するドメインを正確に比較します。 Relax は、組織とドメインの関係を使用します。 RFC 9989セクション 4.10 では次のように定義されています。 DNSツリーウォーク 従来のパブリックサフィックスリストアプローチではなく、ディスカバリーを使用します。検出動作を想定する前に、受信者または評価者の実装バージョンを確認してください。あるドメイン文字列が単に別のドメイン文字列で終わるかどうかを確認することによって、緩和された配置を実装しないでください。欺瞞的なサフィックスや不正な組織ドメインの計算により、誤った結果が生じる可能性があります。
プロバイダー要件を別のレイヤーとして追加する
Microsoft の消費者向け大容量サポート ガイダンスでは、 SPFとDKIM両方に加えてDMARCに合格する必要があります。 Yahooの一括要件では、両方のメカニズムとDMARC通過が必要です。これらは、プロトコルのいずれか調整されたメカニズムのロジックに加えて動作するゲートです。 1 つのプロバイダーから普遍的なルールを推測するのではなく、宛先の現在のソースを確認します。 マイクロソフトのサポート そして Yahoo要件.
DMARC結果用に 1 つの列を作成し、必要な認証、 DNS 、トランスポート、フォーマット、サブスクライブ解除の制御用に別の列を作成します。これらの列のない全体的な緑色のインジケーターでは、ソフトウェアがプロトコルを評価しているのか、プロバイダーのチェックリストを評価しているのか、それとも公開されたDNS構文のみを評価しているのかを判断することが困難になります。
真理値表を使用して違いを明らかにする
参考文献: RFC 9989 §5.3.5.
プライベート レビュー パッケージには、2 つのケースの合成治具が含まれています。まず、 SPFとDKIM両方とも合格しますが、どちらも一致せず、 DMARC失敗します。 2 番目に、 DKIM合格して調整されている間にSPF失敗し、 DMARC合格します。 2 番目のケースでも、 SPF成功を個別に必要とするプロバイダー ゲートに失敗する可能性があります。
これらの入力は意図的に単純なブール値であり、 DNS Tree Walk 検出、従来のパブリック サフィックス ベースの検出、 SPF評価、またはDKIM暗号化の実装ではありません。どちらの場合も、該当するDMARCポリシー レコードが存在することを前提としています。これらは、プロバイダーをテストするふりをせずに、論理的な区別を再現可能にします。実際の調査では、各ブール値を信頼できる観察結果とその評価された ID に置き換えます。
出版と評価を混同しないでください
参考文献: RFC 9989 §5.4.
出版 p=none 成功したメッセージ認証結果ではなく、要求された監視ポリシーを確立します。 DKIM公開キーを公開しても、送信メールには署名されません。を追加する SPFレコード 実際の接続が許可されたアドレスを使用したことを証明するものではありません。各構成アーティファクトには、意図された送信ルートからの対応する監視が必要です。
同様に、 p=noneから p=reject アライメントは修復されません。これにより、ドメイン所有者が要求した障害の処理が変更されます。適用を変更する前に正当なルートをインベントリし、ロールバック計画を保存し、間接フローへの影響を評価します。受信者は依然として独自のローカル処理ポリシーを適用します。要求されたDMARCアクションは配信を保証するものではありません。
有用な成約記録を作成する
参考文献: RFC 8601 §5.
調査したすべてのサンプルについて、From、エンベロープ送信者、接続 IP、 DKIM署名者、および セレクタ、メカニズムの結果、アライメント モード、および最終的な受信応答。それらの結果の信頼できるソースを特定します。 「pass」という単語が含まれているという理由だけで、任意にコピーされたヘッダーを信頼できるものとして受け入れないでください。
プロトコルの検出結果とプロバイダー準拠の検出結果を別々に閉じます。これにより、別の要件が未解決のままDMARC通過したことを正確に判断し、無関係な制御を弱めることなく修正を適切な所有者に割り当てることが可能になります。