Your current DKIM checks pass, but a DKIM2 draft update has left you unsure whether to change the test plan.
Fast answer: Keep your current DKIM and delivery checks. Don’t change production sending because of the draft; run a separate, clearly labeled experiment only if your own test chain supports DKIM2 and you can verify it independently.
For developers maintaining their product’s sending and domain authentication: decide whether existing DKIM acceptance tests still apply.
For QA teams: separate evidence that a message arrived from evidence that its signature passed verification.
For technical leads: decide whether an isolated, non-production trial is justified.
Last updated November 7, 2026. The status and version below were checked against the IETF DKIM2 draft record, the IETF DKIM working-group documents, and the current DKIM specification, RFC 6376.
DKIM2 draft email testing: start with maturity, not a production change
The IETF Datatracker lists the DKIM2 signing specification as an active Internet-Draft. The version checked for this article is draft-ietf-dkim-dkim2-spec-09, published November 1, 2026. It is a working draft, not a published RFC. Check the Datatracker entry before making a decision, because the version and status can change.
An Internet-Draft is not evidence that a final standard has been adopted or that mail providers have deployed it. Don’t infer production support from draft publication, discussion, or a tool’s use of the DKIM2 name. For implementation status, look for an explicit statement from the implementation owner and verify the behavior in an environment you control.
That distinction settles the first decision: the draft’s existence does not invalidate a test that checks the DKIM mechanism your product actually uses. Keep that regression coverage. Treat DKIM2 as a separate proposal until your sending and verification chain can demonstrate otherwise.
Current DKIM tests and DKIM2 experiments cover different ground
Current DKIM acceptance tests should exercise the message your system sends and the signature that message carries. DKIM uses a domain signature that a receiver can verify against the message and the corresponding public key; see the current requirements in RFC 6376. In practical terms, confirm that the expected message is generated, that the signing setup is applied, and that the receiving side reports the expected DKIM result.
The DKIM2 draft describes a proposed way to record changes made as a message passes through processing and to form a verifiable chain. That is a proposal to evaluate against the actual draft text—not a reason to assume that an existing mail server, test tool, or recipient already implements it. Use the current draft and its revision history to check terminology and requirements for the version you are evaluating. Don’t combine details from earlier draft revisions with the current one.
This matters when a QA report says “the signature passed.” Ask which signature mechanism was tested, which message and configuration were involved, and which verifier produced the result. A DKIM pass does not establish that a DKIM2 chain was generated or verified. Conversely, an experimental DKIM2 result does not replace the evidence you need for the current production path.
The DKIM2 update does not affect existing DKIM email tests
No—not by itself. If your product sends with current DKIM and your tests verify that path, keep them. The update changes your work only if you have a specific DKIM2 implementation or a controlled experiment to evaluate.
Do not add a test that merely searches an email for a DKIM2-looking header or label and marks the build as passing. That would test for text, not establish that the proposed mechanism was correctly implemented or verified. Until you have a verifier that supports the precise draft version under test, such a check can create a false sense of coverage.
Keep the scope tied to your own product or an environment you are authorized to test. A developer test email address can help isolate a message from company or personal mail, but the address is only a destination. It does not make an unsupported protocol work, and it does not independently verify a DKIM2 signature.
Each evidence type has clear limits
Separate the evidence into three records: authentication results, sender-side logs, and the message observed in a controlled inbox.
An Authentication-Results field can record authentication results reported by a receiver or processing system. RFC 8601 defines the field and its use. Read the result in context: it is evidence of what that system reported, not proof that every receiving system will make the same decision.
Your sender’s logs can show whether your application handed a message to its sending service or whether a transport step reported a response. SMTP’s role in transferring mail is specified in RFC 5321. A successful handoff is not the same as a message appearing in a recipient’s inbox.
A controlled receiving address gives you evidence that a particular message reached that test destination and lets you inspect what is available there. It does not, by itself, prove that DKIM passed, that a DKIM2 chain was validated, or that the message reached other users. Nor does an authentication result alone prove delivery or completion of your product’s business flow—for example, that a user could complete an account confirmation.
This is an important operational boundary: when a message is missing, you need to inspect the sending path and recipient evidence; when authentication fails, you need the relevant headers or verifier output. Don’t treat one as a substitute for the other. If you’re mapping where a controlled inbox fits into your test, review how address lifecycles affect test setup and decide whether the test needs a temporary receiving address or a longer-lived option.
Check both DKIM and DKIM2 only when both are testable
Only when both mechanisms are actually in scope and independently testable. If your production chain uses current DKIM alone, verify current DKIM and actual receipt for that chain. There is no benefit in requiring a DKIM2 result from infrastructure that does not implement it.
If your team has a DKIM2-capable sender and verifier, run DKIM2 checks as a separate experimental suite. Record the draft revision and test configuration. Keep the result labeled as a draft experiment; don’t merge it into a production acceptance gate as though it were a final-standard requirement.
The comparison below is a decision aid, not a claim that any particular provider or receiving service supports DKIM2.
| Test option | What it can establish | Use it when | Decision |
|---|---|---|---|
| Current DKIM regression | Whether your existing sending path produces the expected current DKIM outcome | Your product currently uses DKIM | Keep it in the normal regression suite |
| Controlled inbox receipt | Whether a test message reached the chosen receiving address, and what message evidence is available there | You need to confirm receipt in a test environment | Use alongside authentication checks, not instead of them |
| Isolated DKIM2 experiment | Behavior of a specific DKIM2 implementation and verifier against a recorded draft version | You control both implementation and verification conditions | Keep separate and label as draft testing |
| No DKIM2-capable test chain | No reliable DKIM2 verification result | You have no implementation, verifier, or controlled test setup | Wait; don’t invent a pass condition |
An isolated trial is worth the cost only under specific conditions
A separate experiment is reasonable only when you can answer yes to all of these questions:
- Do you have a specific DKIM2 implementation to test, rather than only a draft document or a header-name check?
- Can you use a test domain and a non-production sending path that you control?
- Do you have a verifier that supports the draft revision you intend to evaluate?
- Can you save the original message data, relevant headers, configuration, and verification output so another engineer can reproduce the result?
- Can you keep the experiment out of production acceptance criteria until your team has reviewed what the result means?
If any answer is no, retain your current DKIM regression tests and monitor the draft instead. Don’t change production DNS, signing behavior, or delivery expectations merely to keep pace with a working draft. Don’t describe an unverified capability or a test that only checks for a marker as DKIM2 validation.
Draft changes require versioned test expectations
Treat each experiment as a versioned test artifact. Keep the draft version, test configuration, raw message or relevant original headers, and verifier output in separate, identifiable records. This makes it possible to distinguish a changed input from a changed verification rule.
When the draft changes, review the new version before changing assertions. Compare the fields, algorithms, and verification requirements that matter to your experiment. Then decide whether the implementation or verifier needs an update. An old test result remains evidence about the version and setup that produced it; it is not automatic evidence of compatibility with a newer draft.
A lightweight test record can include:
- Draft reference: the exact Datatracker document revision and the date your team checked it.
- Implementation: the sender and verifier versions or commits used in the experiment.
- Configuration: the test domain and any relevant signing or verification settings. Keep secrets out of logs.
- Input evidence: the original message and the headers needed to reproduce the test, handled under your team’s data-retention rules.
- Outcome: the verifier’s result and any delivery evidence, recorded separately.
- Status label: “current DKIM regression” or “DKIM2 draft experiment,” not a blended pass/fail label.
For receipt testing, make the receiving window and the message evidence part of the test’s own expectations. A message that arrives at a controlled address answers a delivery question for that test. It does not certify protocol support or prove universal inbox placement. The delivery-window guide can help you think through receipt timing without treating a delay or missing message as an authentication verdict.
Without DKIM2 signing support, accept mail against current capabilities
Continue testing the behavior your product actually depends on. Verify that your application generates the expected message, that the current DKIM signing and verification results meet your existing requirements, and that the message reaches a controlled recipient when receipt is part of the test. Keep those assertions independent so a passing authentication result cannot hide a delivery failure, or vice versa.
If the product flow depends on a confirmation link or another user action, test that application behavior separately. A message arriving at an inbox is not proof that the link works, that the account state changed correctly, or that a user completed the flow. This is especially useful in regression work: isolate the failure to message generation, signing, transfer, receipt, or application behavior rather than reporting all of them as “email passed.”
Use this decision table to route the work:
| Your current capability | What to do now | What not to claim |
|---|---|---|
| Current DKIM only, with a working regression suite | Keep current DKIM checks and receipt checks; track the draft for relevant changes | Don’t claim DKIM2 compatibility |
| Independent DKIM2 implementation and verifier, plus a controlled test domain | Run a parallel, non-production experiment against a named draft revision | Don’t present a draft result as production-standard compliance |
| No implementation or no verifier for the draft version | Defer implementation; set a review trigger for a new draft version, workflow change, or official status update | Don’t create a placeholder “pass” test |
| Receipt testing without protocol-verification evidence | Use the controlled address to check whether the test message arrived | Don’t treat arrival as DKIM or DKIM2 verification |
The decision for your next release
For the next release, keep the existing DKIM acceptance path unless your product’s actual sending chain has changed. If you have a controlled DKIM2 implementation and a verifier, run that work in parallel and record the draft version. Otherwise, defer the experiment and revisit it when the IETF document changes, your implementation gains explicit support, or you have a reproducible verification setup.
If your immediate question is whether your own test message reached a controlled inbox, a receiving address can supplement the current sending checks. Before choosing one, confirm the available inbox and address behavior on MyTempBox. Treat any message you receive as receipt evidence for that test—not as a DKIM2 validation result or a guarantee of inbox placement.
Confirmed this is a restartable short task?
Open a temporary inbox and stick with one address until it’s done. If the task later becomes long term, migrate the email first, then close this receiving window.
Create a disposable inbox