Summary

  • The 1 November DKIM2 working-group revision adds a Domain Policy Record absent from the 27 October version. A parent can publish strict to stop a subdomain signer making the parent’s visible From address “Authentic.”
  • The proposed default runs the other way. With no policy record, or no strict flag, the subdomain remains authorized under the draft’s upward domain match.
  • The record belongs at _domainkey for the parent whose From name is at issue. It does not inherit across the DNS tree; a temporary lookup failure produces TEMPERROR, not a clean authorization decision.

The annex has keys to the front door

A company gives a mail vendor control of mail.example.com so it can sign traffic from its own corner of DNS. Under the new DKIM2 revision, that subdomain’s signature can also help make example.com in the visible From field “Authentic.” The draft says this follows existing DKIM1 convention and avoids disrupting established delegation. The 27 October version did not have the new Domain Policy Record or the corresponding upward-match check.

The new record is a parent’s veto. Section 3.8 places a TXT policy at _domainkey.example.com, starting v=DKIM1. Its optional f= flags may include strict. That flag tells DKIM2 verifiers not to let signing subdomains authenticate a From field using example.com. Without strict, the draft authorizes them. No record means the same permissive result. This is a policy on the proposed DKIM2 “Authentic” From test, not a change to the authority of an already deployed DKIM1 signature.

The match has two directions. Section 7 first compares the From domain with the relevant signature’s d= domain. If that fails, it reverses the comparison. That reverse pass is where a child signing domain can match its parent From name; the parent’s strict record then blocks the result. An exact parent-domain signer does not need that reverse pass. The draft also limits the record to the domain that publishes it. A rule at example.com is not inherited by another.example.com, and a policy at a child does not govern the parent.

DNS failure matters to the decision. Multiple valid policy records create PERMERROR; a temporary DNS failure while retrieving the record creates TEMPERROR. A verifier cannot quietly treat either as a definite yes. The IETF record lists revision 09 as a working-group Internet-Draft, still I-D Exists. The checked record has no interoperable deployment trace for this new parent-domain switch.