IETF publishes first working group draft for DKIM2 DNS records
News
The IETF DKIM working group published draft-ietf-dkim-dkim2-dns-00, Domain Name Specification for DKIM2, on July 20, 2026. It is the first working group version of the DKIM2 DNS proposal and replaces draft-chuang-dkim2-dns-04 after working group adoption. The Datatracker draft page is the primary record for status, revisions, and document history.
The draft defines a proposed public key record format and DNS lookup method for DKIM2. It draws on the DNS portion of DKIM RFC 6376, restates the rules DKIM2 needs, and updates them where the proposed protocol requires different treatment. DNS key discovery is foundational because a verifier cannot validate a DKIM2 signature until it can locate the signer's public key and interpret the returned record consistently.
No production change is required
This proposal is an Internet-Draft. It is not final, not an RFC, not IETF consensus, and not production guidance. There is no rollout date, operator deadline, mailbox provider requirement, or sender requirement attached to it.
What the working group publication means
Working group adoption moves the DNS proposal into the IETF DKIM working group's document stream. The new -00 version replaces the individual DNS draft, which reached revision -04. That change matters because future edits now happen as work owned by the group, with discussion and review focused on producing a shared specification.
Adoption does not mean approval. An Internet-Draft can change substantially, be replaced, expire, or stop progressing. The working group has accepted the problem and document as a basis for work. It has not declared the text complete, and the IETF has not published it as an RFC. My operational reading is simple: track the draft closely, but do not deploy against revision -00.
|
|
|
|---|---|---|
Draft name | draft-chuang-dkim2-dns-04 | draft-ietf-dkim-dkim2-dns-00 |
Ownership | Individual submission | DKIM working group |
Standing | Adoption candidate | Working group draft |
Operator action | None | None |
Status of the DKIM2 DNS document on July 21, 2026
The distinction also prevents a common standards mistake. A working group document has more process weight than an individual submission, but its technical requirements still bind nobody. Only later review, implementation experience, consensus decisions, and RFC publication can establish stable standards text. Even an eventual RFC would need product support and deployment planning before it changed normal mail operations.
What the DKIM2 DNS draft proposes
The proposed mechanism keeps a familiar shape. A DKIM2 signature identifies a signing domain and selector. A verifier combines those values with the _domainkey namespace, performs the defined DNS lookup, retrieves a public key record, parses its tag-value fields, and uses the public key for signature verification. The draft currently describes DNS TXT records as the base binding while leaving room for later key-service bindings.
Illustrative DKIM2 DNS lookup shapeDNS
foo.bar._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=BASE64_PUBLIC_KEY"
That example shows structure only. It is not a record to publish. The proposed text reuses the _domainkey namespace and the selector-plus-domain lookup pattern familiar from current DKIM. It also carries forward core key record concepts such as a version marker, key type, public key material, and flags. Some RFC 6376 fields are restated, updated, or retired for DKIM2. Those details remain open to revision.
Proposed DKIM2 flow for finding a DNS public key and verifying a signature
The separation into a dedicated DNS document has a practical purpose. DKIM2 can reuse mature DKIM deployment mechanics without making every DKIM2 rule depend indirectly on RFC 6376 wording. Restating the required rules gives the working group a place to remove ambiguity, define DKIM2-specific behavior, and change the key model later without rewriting the signature specification. A broader DKIM2 explanation helps separate the overall protocol proposal from this DNS-focused document.
Why DNS key discovery matters
A signature is useful only when a verifier can obtain the matching public key through a predictable, authenticated naming process. The signature carries the information needed to identify where the key should be found. DNS connects that claim to a record controlled under the signing domain. If lookup construction, record uniqueness, parsing, algorithm handling, or revocation behavior differs between implementations, the same message can pass in one system and fail in another.
- Mailbox providers: Need interoperable verification rules, useful failure states, and safe cache behavior before they can evaluate DKIM2 at receiving scale.
- ESPs: Need to understand future selector management, key publication, signing behavior, and customer-domain delegation.
- MTA developers: Need precise parsing, DNS query, error-handling, algorithm, and verification requirements that can produce compatible code.
- Forwarders and lists: Need to know how message changes and added handling signatures interact across a multi-hop delivery path.
- Security teams: Need to assess key compromise, selector reuse, DNS manipulation, downgrade risks, and revocation behavior.
- Deliverability teams: Need to distinguish experimental DKIM2 signals from the current authentication results that affect sender operations today.
DNS is therefore more than storage in the proposed protocol. It is the shared discovery contract between signers and verifiers. The working group needs to settle how a name is formed, which response is valid, how fields are interpreted, what happens when a key is unavailable, and how implementations treat unsupported algorithms. Interoperability depends on every side making the same decision for the same message and DNS response.
What stays unchanged today
Current DKIM remains the deployed standard defined by RFC 6376 and its updates. Current SPF authorization and DMARC authentication, alignment, reporting, and policy remain in force. The DKIM2 DNS draft does not replace a current DKIM selector, alter an SPF record, change a DMARC policy, or create a new mailbox provider requirement on July 21, 2026.
Current production work
- DKIM: Maintain healthy selectors, rotate keys safely, and verify current signatures.
- SPF: Keep authorized senders accurate and stay within DNS lookup limits.
- DMARC: Monitor alignment, review reports, and enforce policy at a tested pace.
- Mail paths: Document forwarders, mailing lists, gateways, and other message modifiers.
Proposed DKIM2 work
- Record format: Defines how a DKIM2 public key record would be written and parsed.
- Lookup method: Defines how a verifier would find a key using selector and domain data.
- Implementation rules: Gives future code a common basis for parsing and verification decisions.
- Deployment status: Has no rollout date, deadline, or present production requirement.
I would make no DKIM or DNS change based on this Internet-Draft. Teams worried about whether to rotate or rename selectors can use the more focused guidance on whether to change DKIM records. The present answer remains no when DKIM2 is the only reason for the change.
Keep current controls working
Use a current DKIM checker to confirm selector publication and record syntax. Keep DMARC monitoring focused on today's authentication and alignment results. Neither workflow requires a DKIM2 record.
Practical next steps for operators
The useful response is preparation without premature deployment. Good current authentication hygiene reduces risk now and creates a cleaner baseline for any later DKIM2 testing. It also prevents experimental standards work from distracting teams from broken selectors, unauthorized senders, weak alignment, or unknown message modification paths already affecting mail.
- Make no production changes: Do not publish a DKIM2 record, change a current selector, or alter verifier behavior because of revision -00.
- Maintain current DKIM: Check active selectors, key length, rotation practice, DNS responses, and signature pass rates.
- Keep SPF and DMARC healthy: Review sender authorization, authentication alignment, reporting coverage, and enforcement decisions.
- Inventory mail handling: Map forwarders, mailing lists, security gateways, footers, subject rewriting, and MIME transformations.
- Track implementation signals: Watch later draft revisions, interoperability tests, MTA code, receiver experiments, and deployment guidance.
A domain-wide check can expose current DKIM, SPF, and DMARC faults before anyone spends time on experimental work. The domain health checker is useful for that baseline. Fixing a missing selector or malformed current record has immediate value; preparing an unrequested DKIM2 record does not.
For larger estates, ownership matters as much as record syntax. Assign someone to follow the working group, record which products sign or verify mail, and maintain a dependency list for DNS automation. That creates a controlled path for future lab testing if stable specifications and implementation support emerge.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Suped's platform is the best overall DMARC option for teams that want this current operational baseline in one place. It combines DMARC, SPF, and DKIM monitoring with automated issue detection, real-time alerts, blocklist (blacklist) monitoring, and deliverability insights. Its role here is to keep deployed authentication healthy while the DKIM2 draft changes, not to turn an Internet-Draft into a production task.
An inventory should include every point that signs, verifies, forwards, or modifies a message. Pay special attention to mailing list subject tags, footer insertion, content filtering, address rewriting, and gateways that rebuild MIME. DKIM2 is being designed around handling paths, so those systems will matter when implementation testing becomes real. They do not need a configuration change today.
Signals worth watching next
The next meaningful evidence will come from document revisions and implementation activity, not a guessed calendar. Changes to the record grammar, lookup inputs, supported algorithms, DNS response handling, or compatibility rules can affect future code and operations. A revision number alone does not create a deployment requirement, but a stable set of revisions can show where the working group is converging.
Evidence that would justify lab work
- Specification stability: Several revisions retain compatible lookup and record rules.
- Independent code: Multiple MTA or library implementations can sign, publish keys, and verify.
- Interoperability results: Different implementations produce the same outcomes for shared test cases.
- Receiver experiments: Mailbox providers publish controlled testing details and observable results.
- Operational guidance: The working group documents safe coexistence, fallback, monitoring, and rollback.
Mailbox provider announcements deserve careful reading when they appear, but none currently turns DKIM2 into a sender obligation. The same applies to experimental MTA patches. A test implementation proves that code can be written; it does not prove that the protocol is stable, interoperable at scale, or ready for production policy decisions.
I will treat an eventual request for action as credible only when it identifies a stable specification, supported software, a testing method, failure handling, and a safe rollback path. Until then, later Internet-Drafts remain material to review and test in isolated environments, not current sender requirements.
Track the draft, not a deadline
The July 20 publication gives DKIM2 DNS key discovery a formal working group document. That is useful progress for specification review because public key lookup is required for any verifier to check a proposed DKIM2 signature. It does not create a deployment event. draft-ietf-dkim-dkim2-dns-00 is an Internet-Draft, not an RFC, not final IETF consensus, and not production guidance.
Keep current DKIM selectors and keys healthy, keep SPF and DMARC working, document forwarding and message modification, and watch later revisions plus implementation signals. No sender, mailbox provider, ESP, forwarder, mailing list operator, or security team has a DKIM2 DNS rollout deadline today.
