DKIM2 drafts add domain controls for subdomain signing
News
DKIM2 draft revisions published on November 2, 2026 UTC propose a domain control over subdomain signing. Specification revision 09 and DNS revision 03 introduce a DKIM2-only Domain Policy Record. Its optional f=strict flag prevents a subdomain signature from making a parent-domain From address Authentic under the proposed protocol.
As of November 3 in Australia/Sydney, both documents remain adopted DKIM working-group drafts, not final RFCs. These proposals are not current production guidance. They establish no rollout, provider requirement, migration mandate or deadline. I treat the change as a reason to examine delegation boundaries, while keeping deployed DKIM, SPF and DMARC configurations healthy.
One working-group revision event
The official specification publication event records November 2 at 01:39:42 UTC, although the specification text header says November 1. The DNS publication event records November 2 at 15:56:33 UTC. Those times are November 2 at 12:39:42 AEDT and November 3 at 02:56:33 AEDT respectively in Sydney.
These are revisions of existing working-group documents, not new adoptions. Read together, they define the proposed control and its DNS representation. The immediate audience is mail software developers, mailbox providers and ESPs, plus hosting operators and security engineers responsible for delegated domains.
Draft behavior, not a deployment instruction
Do not add a production Domain Policy Record or remove existing key tags solely because these drafts were published. Current deployed DKIM, SPF and DMARC requirements are unchanged by this revision event.
What changed since spec08 and DNS02
Spec08 required a signing domain equal to, or above, the From domain in the DNS hierarchy for its Authentic test. Spec09 adds the reverse comparison, allowing a signing subdomain to authenticate a parent-domain From unless that exact From domain prohibits it.
The main changes are in specification sections 3.8, 7.1, 11.1 and 14.8, with the DNS record defined in DNS03 section 5. DNS03 also extends proposed key-tag deprecation to DKIM1. The comparison is therefore about authorization scope and DNS handling, rather than a new cryptographic launch.
|
|
|
|---|---|---|
From matching | Equal or parent signer | Subdomain option added |
Domain policy | No new control | Optional strict flag |
Key-tag retirement | DKIM2 scope | DKIM1 proposal added |
RSA encoding | Already clarified | Clarification retained |
Comparison of spec08 with spec09 and DNS02 with DNS03.
The policy sits above selector records
The proposed policy for example.com is a TXT record at _domainkey.example.com. A public key instead sits at selector._domainkey.example.com. Those are different DNS names with different purposes: the policy controls subdomain authority, while a selector record supplies a verification key.
The policy begins with v=DKIM1 even though DKIM1 does not use this policy mechanism. An optional f= tag contains colon-separated flags. The defined strict flag disables subdomain authorization for the domain holding the record. Unknown flags are ignored. The proposed syntax looks like this in an isolated test zone:
Proposed policy example, isolated testing onlydns
; Draft DKIM2 policy. Not production setup guidance. _domainkey.example.com. IN TXT "v=DKIM1; f=strict"
Without strict, subdomains remain authorized. That includes a policy without an f= tag, an f= value without strict, and no policy record at all. A temporary DNS failure is a separate outcome, not permission to assume that the record is absent.
The policy has no inheritance. A record for example.com governs From addresses at example.com. It does not govern From addresses at child.example.com, nor does a child record change the parent's policy. Strict also leaves equal-domain signing and signing by a parent domain available under the draft's matching rules.
A delegated subdomain can authenticate a parent From
Consider a controlled test where example.com delegates tenant.example.com to an external sender. That sender controls a key at s1._domainkey.tenant.example.com and signs using d=tenant.example.com. The message has From: billing@example.com and an envelope sender at tenant.example.com. Hold the signature, message hashes and remaining verification checks valid.
Under spec09, the verifier first tries the existing comparison. When that fails, it reverses the domain comparison and finds that the signing domain is a child of the From domain. The policy for example.com then decides whether this relationship is authorized.
Without strict
No restrictive policy exists at _domainkey.example.com. The subdomain relationship satisfies the proposed Authentic check for billing@example.com, assuming the other required checks succeed.
With strict
The policy at _domainkey.example.com includes f=strict. The same subdomain signature cannot make billing@example.com Authentic. Valid cryptography alone does not override that restriction.
This is a specific authorization decision. Authentic does not mean the message contains safe content, and it is not a DMARC pass. A conventional DKIM1 signature and its DMARC evaluation remain separate. A message whose required From check fails cannot be Fully Verified under the DKIM2 draft.
I would test sibling domains separately. A signature for tenant.example.com does not authenticate a From address at accounts.example.com merely because both share example.com. The new comparison follows a parent-child relationship, not a shared organizational-domain shortcut.
DNS failures have distinct outcomes
Spec09 separates missing policy from unusable policy. Records that do not begin with v=DKIM1 are discarded when evaluating policy candidates. If more than one remains, the relevant matching result is PERMERROR. A temporary lookup failure produces TEMPERROR.
Section 14.8 adds diagnostics for these cases and for a domain that forbids subdomain signing. For developers, that distinction matters: an unavailable answer must not silently become the permissive default. I would include both resolver failures and duplicate policy records in isolated verifier tests.
|
|
|---|---|
No policy record | Subdomains authorized |
One record, no strict | Subdomains authorized |
One strict record | Subdomains unauthorized |
Multiple remaining records | PERMERROR |
Temporary DNS failure | TEMPERROR |
Outcomes for the proposed subdomain authorization check, not delivery verdicts.
Key-tag deprecation is also still a proposal
DNS03 proposes deprecating h=, n=, s= and t= in DKIM1 key records. These denote acceptable hash algorithms, human-readable notes, service type and key flags respectively. DNS02 had already described their retirement for DKIM2; DNS03 adds the proposed DKIM1 change in its shared DNS specification.
The affected namespace is the DNS key record. A same-named tag in a signature header has a different purpose. For example, s= identifies a selector in a DKIM1 signature, while t= records a signing timestamp. This draft does not deprecate those signature tags.
The RSA encoding clarification is not new in DNS03. DNS02 already addressed support for RSAPublicKey and SubjectPublicKeyInfo containing an RSA public key. Treating that clarification as part of the November 2 novelty would misstate the revision history. Neither that text nor the proposed tag deprecation is an instruction to rewrite production records today.
Practical work belongs in review and isolated tests
For an implementation team, the useful next step is to compare spec08 against spec09 and DNS02 against DNS03, then build tests around the changed authorization rules. Keep draft-version assumptions explicit so later revisions do not silently change the meaning of recorded results.
For delegation owners, the immediate work is an inventory. Record who controls each signing subdomain, which From domains it uses, and who can publish keys. That makes the trust boundary reviewable without assuming that production receivers implement this draft.
- Compare revisions. Review the matching algorithm alongside DNS03 section 5, including absent policy, strict policy and non-inheritance.
- Test boundaries. In isolated implementations, exercise equal-domain, parent-domain, child-domain and sibling-domain signing, plus policy lookup errors.
- Inventory delegation. Identify tenant-controlled DNS zones and delegated selectors, documenting which parent-domain identities each sender is intended to use.
- Maintain deployed authentication. Check current selectors and review SPF authorization and DMARC results. Make no production DNS change solely because of these drafts.
Suped is our email authentication platform. Its hosted DKIM workflow manages existing TXT and CNAME selectors, while DMARC monitoring helps investigate current sending sources. These are practical ways to maintain the deployed setup while draft implementation work stays isolated.
Use the DKIM checker to inspect a current selector record. A healthy selector result does not demonstrate DKIM2 policy support, and ordinary DMARC aggregate reports do not prove that a receiver evaluated the proposed Domain Policy Record.
Keep production changes tied to deployed behavior
The operational decision today is to review who has signing authority and document the intended boundary for each delegation. I would keep any spec09 and DNS03 experiment in a separate test environment, with its draft version recorded and expected results checked before considering a production change.
Frequency asked questions
No. This is proposed DKIM2 behavior, not current production guidance. Review delegations and test isolated implementations. Do not change production DNS solely because these drafts were published.
The drafts reuse that version marker for DNS consistency. The record location and purpose distinguish the Domain Policy Record, which DKIM1 does not use, from selector key records.
No. The policy applies only to the exact domain holding it. A policy at _domainkey.example.com does not govern From addresses at child.example.com. There is no upward or downward inheritance.
No. Authentic is a DKIM2 draft authorization property for a From header field. Content safety and the separate DMARC evaluation are different questions.
