IETF email setup draft adds DNS delegation and impersonation safeguards
News
On October 5, 2026 at 08:06:25 UTC, the IETF Datatracker accepted and published revision 04 of the Mail Maintenance working group's PACC Internet-Draft. The revision adds explicit rules for delegating an account-configuration document and its DNS digest to a mail provider. It also adds safeguards against treating names or logos in that document as verified identity.
This is material because the proposed discovery flow can direct an email client toward endpoints that receive credentials. Revision 04 clarifies who controls the HTTPS content and matching DNS proof, how clients follow aliases, and what users should see before confirming server domains. It remains an active draft, not a final standard, production requirement, rollout announcement, or migration deadline.
Treat every capitalized normative term below as proposed behavior inside revision 04. No provider has been announced as universally supporting or enforcing this mechanism, and the draft can change before publication as an RFC.
What changed in revision 04
I read the change set as three connected corrections to the trust model. First, new section 5.2.2.4 defines paired delegation of the configuration document and DNS digest. Second, digest discovery now explicitly follows CNAME records while keeping the lookup anchored to the domain in the user's email address. Third, sections 7.2 and 7.3 sharpen the limits of branding claims and delegated trust. The official revision 04 text contains the proposed normative language.
|
|
|
|---|---|---|
Delegation | Provider publishes records | Paired ownership rules |
DNS aliases | Direct TXT query | CNAME following stated |
Brand display | General provider display | Unverified identity warning |
Trust boundary | DNS zone operator | Delegated provider included |
Material differences between the two draft revisions
The comparison matters because revision 03 already had digest checks, transition overlap for cached content, TLS 1.3 as the proposed minimum, certificate validation on every redirect hop, redirect limits, and confirmation of final server names. Those controls are not new October 5 requirements. The news is the explicit delegation model, CNAME-aware digest lookup, and stronger warnings about identity claims.
How delegated ownership now works
The client starts with the domain in the user's email address. It fetches the JSON document at the well-known HTTPS path under that domain, then looks up the digest at the corresponding underscored DNS name. HTTP redirection does not move the DNS trust anchor. The client still queries the original email domain, follows any CNAME chain, and compares the published digest with a hash of the final decoded HTTP response.
Revision 04 flow from email domain to configuration digest validation
- Document owner. The party controlling the served JSON must also control the matching digest when delegation is used.
- Original domain. The digest lookup begins at the domain from the email address, even when HTTPS redirects elsewhere.
- Final bytes. The proposed check hashes the fully decoded final response, not an encoded transfer form or an intermediate response.
- Failed match. When a client performs validation and no digest matches, the draft says it must ignore the configuration.
The two proposed delegation models
Section 5.2.2.4 permits two patterns. Both move control of the digest to the provider and require the provider to control the matching configuration. A domain owner must not delegate only the digest while keeping an independent local copy of the JSON. It also must not send document retrieval to the provider while retaining a separate digest. Split control fails as soon as either side changes without the other.
Option 1: two DNS aliases
The domain owner aliases both the HTTPS hostname and digest owner name to the provider. The provider's certificate must cover the original customer hostname, not only the alias destination.
Illustrative option 1 recordsDNS
ua-auto-config.example.org. CNAME ua-auto-config.example.net. _ua-auto-config.example.org. CNAME _ua-auto-config.example.net.
Option 2: owner redirect
The domain owner keeps the initial HTTPS server and certificate, then redirects the well-known request to the provider. Existing proposed redirect protections still apply. The digest remains delegated through DNS.
Illustrative option 2 recordDNS
_ua-auto-config.example.org. CNAME example-org.example.net. # HTTPS stays local, then redirects to the provider.
DNS operators also need to account for record-type and cache behavior. A CNAME cannot coexist with a TXT record at the same owner name, so local digest publication ends at that delegated name. The CNAME TTL adds another cache window. During changes, operators need overlap between old and new digests long enough to cover DNS caching plus HTTP cache behavior.
White-label configuration needs separate digest targets
A provider can use one shared digest target when every delegated domain receives identical configuration bytes. The risk changes when an MSP or hosting operator creates domain-specific documents with different names, logos, endpoints, or policy data. Pointing every customer at one shared digest target would let one customer's document validate for another customer that delegates to the same target.
A white-label document needs a domain-specific digest target. Shared targets are suitable only when the provider serves identical configuration bytes to every participating domain.
This is one of the most operationally important additions. It turns customer isolation into a DNS design issue, not only a JSON-generation issue. I would inventory whether configuration varies by customer before choosing shared aliases. Tests should include a document from customer A against customer B's delegated digest path, because a successful cross-customer match reveals an unsafe shared target.
Branding is not verified identity
New wording in section 7.2 states that a name or logo asserted inside the configuration is not verified identity. An attacker-controlled document can claim any brand, so a client must not label that content as verified. The draft also says those branding elements should not receive greater visual prominence than the registrable server domains the user is asked to confirm.
Unsafe interface signal
A large brand logo appears as proof of identity while the actual server domains are hidden, truncated, or visually secondary.
Proposed safer signal
The interface treats branding as asserted metadata and keeps the registrable domains clear before credentials are entered.
A mismatch between a legitimate domain owner's brand and the provider or server domains is not proof of an attack. White-label services and outsourced hosting routinely create that difference. The correct response is to show the relevant domains and ask for confirmation, while avoiding any claim that the configuration's brand has been independently authenticated.
The trust boundary is narrower than it looks
Section 7.3 now explains the delegated case directly. When DNS remains trustworthy, digest validation can stop compromised HTTP hosting from substituting a configuration. If the domain owner delegates both the document and digest to its provider, the provider controls both sides. The digest can still detect tampering in the provider's web-hosting path, but it cannot protect against the trusted provider itself publishing a different document and matching digest.
CNAME-aware DNSSEC validation requires every zone in the alias chain to be signed. The draft also describes a trusted resolver reached through DNS over TLS or DNS over HTTPS as an integrity option.
Digest validation remains a proposed SHOULD. A client without trustworthy DNS answers, or without DNS query capability, is permitted to omit it. Such a client relies on the draft's TLS and certificate rules plus user confirmation of the final server domains. When the client does perform the digest check and validation fails, the proposed behavior is to ignore the configuration rather than continue with partially trusted data.
What operators and client developers should do
No production migration is required by this publication. The useful response is a controlled review and lab plan for domain owners, mail-hosting operators, MSPs with custom domains, and client developers. The focus should stay on ownership, certificate coverage, cache transitions, and user-interface trust signals.
- Read the additions. Review proposed sections 5.2.2.4, 7.2, and 7.3 against the previous revision.
- Map ownership. Record who controls the JSON, digest target, initial HTTPS certificate, redirects, and final endpoint.
- Test failure paths. Exercise CNAME chains, mismatched digests, stale cached answers, redirect certificates, and decoded-body hashing.
- Isolate customers. Verify that every domain-specific or white-label document has its own digest target.
- Track the working group. Keep lab behavior separate from production policy until the draft advances and implementations publish support.
Client teams should also test that asserted branding never gets a verified indicator and never eclipses confirmed registrable domains. Operators using OAuth-based setup can review the related OAuth client protections, but should treat that work as a separate draft with its own status and scope.
What this does not change
PACC concerns account setup trust. It does not change DMARC. It also leaves SPF and DKIM records unchanged, does not authenticate the visible From header, requires no MTA-STS change, and does not improve inbox placement by itself. Those controls apply to mail-message authentication and transport policy, while this draft concerns how a client discovers account service settings such as IMAP, POP, SMTP submission, JMAP, and calendar or contact protocols.
Suped is our DMARC and email authentication platform. For most teams that need operational message-authentication monitoring, it is the best overall practical fit because it combines DMARC visibility and SPF/DKIM checks with automated issue detection, real-time alerts, blocklist monitoring, and hosted controls. It does not implement this PACC draft or make a domain compliant with it.
Use Suped's domain health checker to review current authentication records, and use DMARC monitoring for aggregate reporting and source-level investigation. A separate email tester can inspect a real message's authentication and delivery signals. None of these checks validates a PACC configuration document or its delegated digest.
What to take forward
Revision 04 makes the proposed deployment model more precise. A delegated provider must control both the configuration and matching digest, clients follow DNS aliases without abandoning the original email-domain lookup, and user interfaces cannot treat self-asserted branding as verified identity. Those changes reduce ambiguity around a path that can lead users to credential-receiving endpoints.
My practical takeaway is to model the ownership boundary now, test the failure cases in a lab, and watch the Mail Maintenance working group. Do not convert draft language into a production mandate, claim provider adoption, or schedule a universal migration.
