July 27, 2026

Salesforce Is Retiring the Email Change Verification Exemption: Set Up Authorized Email Domains Before Winter '27

Salesforce is retiring the Support exemption for email change verification. Set up Authorized Email Domains and DKIM before Winter '27 enforcement hits.

TL;DR

Salesforce is retiring the old exemption process where Support could disable email change verification for your org. The replacement is the Adopt Authorized Email Domains release update, enforced with Winter '27; current reporting points to enforcement from September 2026.
Email change verification means every changed user email sends a confirmation link to the new address, valid for 72 hours, and the change stays pending until the user clicks it. Bulk updates through Data Loader fire one verification email per user.
The self-service replacement has two routes, and you only need one per domain: an active DomainKeys Identified Mail (DKIM) key, or a verified Authorized Email Domain entry with the user-level bypass enabled.
Neither DKIM keys nor Authorized Email Domains survive a sandbox refresh, but Salesforce added a one-click import that copies authorized domains from production into a sandbox.
The knowledge article documenting the old Support process carries no retirement notice, so plenty of admins will find out this path is gone when their next domain migration stalls.

What You'll Learn

What email change verification does today and why the Support-disable path existed at all
How the two replacement routes work, where they live in Setup, and which one to prefer
Why this feature shares a Setup page with the separate email sending-domain verification from Spring '26, and how to avoid conflating them
The sandbox refresh, subdomain, and bulk-update gotchas that bite during migrations
A migration checklist you can run before the enforcement window opens

The Problem

Somewhere in your org's history, someone probably filed a case with Salesforce Support that included a signed letter, a business justification, and a list of trusted email domains. In return, Support disabled email change verification on the backend, and ever since, your provisioning scripts and sandbox refresh runbooks have quietly relied on being able to update user email addresses without every user receiving a confirmation link.

That arrangement is ending. Salesforce is retiring the Support exemption via the Adopt Authorized Email Domains release update, and once it is enforced, the only way to skip per-user verification is a domain you have proven you own through DNS. If your org rebrands, acquires a company, migrates email providers, or just refreshes sandboxes on a schedule, and nobody has set up Authorized Email Domains or DKIM keys, you inherit a world where every bulk email update produces hundreds of pending changes and 72-hour expiry links.

The frustrating part is discoverability. The knowledge article describing the old Support process was republished as recently as April 2026 with no retirement banner on it. If your team's runbook links to that article, nothing in it warns you the path is closing.

Common Questions This Article Answers:

What replaces the Support exemption for email change verification?
How do I set up Authorized Email Domains, and how is that different from a DKIM key?
Why did my bulk email update leave every user in a pending verification state?

Quick Answer

Salesforce is retiring the process where Support could disable email change verification, replacing it with domain-level verification you configure yourself. The release update is called Adopt Authorized Email Domains, it is enforced with Winter '27, and Salesforce Ben reports enforcement from September 2026 (Salesforce has not published a separate sandbox versus production date split, so confirm the org-specific date in Setup under Release Updates once the Winter '27 sandbox preview lands). The replacement works like this: prove you own a domain either with an active DKIM key or with an Authorized Email Domain entry verified through a DNS TXT record, then enable the per-domain setting that skips user-level email verification. Once that is in place, changing a user's email to an address on that domain no longer requires the user to click a confirmation link, which is what makes bulk updates, sandbox refresh fixes, and domain migrations workable again. Each domain and each subdomain needs its own entry, DNS propagation can take up to 72 hours, and the whole thing is scriptable through the Tooling API object AuthorizedEmailDomain.

What email change verification actually does

Before pulling it apart, be precise about the feature being discussed, because 2026 has been a big year for Salesforce email requirements and several of them sound alike.

When anyone changes the email address on a user record, Salesforce sends a verification email to the new address and a notification to the old one. The user must click the link in the verification email within 72 hours, and until they do, the change is pending and the old address stays live. If the link expires, an admin has to re-enter the new email on the user record to trigger a fresh one. Bulk updates behave the same way multiplied: push 500 new addresses through Data Loader and you have sent 500 verification emails, each with its own 72-hour clock.

For a single user who typo-fixed their own email, this is sensible anti-fraud design. An attacker who compromises an admin session cannot silently redirect a user's email (and with it, password resets) to an address they control. The pain arrives at scale: rebrands, acquisitions, email platform migrations, and sandbox refreshes all involve changing addresses for entire user populations at once, where a per-user click requirement is operationally absurd.

The old fix: a letter to Support and an invisible allowlist

The historical escape hatch was a Support case. A system administrator submitted a signed letter on company letterhead with a business justification, the org ID, and a list of trusted domains. Domains the org did not own required consent letters from the third party. Legal review happened on Salesforce's side, and if approved, Support maintained an allowed-domains list on the backend.

Two properties of that arrangement are worth noticing, because they explain both why it worked and why it is going away. First, the list was invisible: Salesforce's own knowledge article states the allowed domains list can only be viewed and modified by Salesforce Support, with no way to see it from inside your org. You could not audit your own exemption. Second, it was manual on both ends, which Salesforce cites as the reason for retirement: the process relied on a human change by Support, which created operational inefficiency and risk.

If your org has one of these exemptions, dig out the original case while you still can. The domain list it granted is not visible in Setup, and whether existing exemptions get force-revoked at enforcement or linger until touched is not documented anywhere I could find. Plan as if the exemption evaporates on your enforcement date.

The replacement: two routes, one needed per domain

The self-service replacement verifies ownership at the domain level, and either of two mechanisms qualifies a domain. Salesforce's documentation is explicit that when a domain is verified through either route, email verification is not required for users with addresses on that domain.

Route one: a DKIM key. From Setup, search for DKIM Keys, create a key (2048-bit RSA is the recommendation), publish the generated CNAME records in your DNS, wait for propagation, then activate the key. If you already run DKIM for deliverability, you may be most of the way there. One catch that surprises people: a DKIM key for example.com does not cover mail.example.com. Every domain and every subdomain needs its own key.

Route two: an Authorized Email Domain entry. From Setup, search for Authorized Email Domains, click Add, and enter the domain. Salesforce generates a verification key in the form 00D000000000P08=1TB00000000000B, which you publish as a DNS TXT record. Propagation can take up to 72 hours, after which you verify ownership. Salesforce's docs recommend the DKIM route where possible, but the TXT-record route is simpler if you have no reason to sign outbound mail from that domain.

Either way, verification alone is not the whole job. The user-level bypass is a per-domain setting: edit the domain entry in Authorized Email Domains and enable the option that skips user email verification for addresses on it. Through the Tooling API this is the AuthorizedEmailDomain object (API v64.0 and later, requiring the Email Administration permission), where the working combination is IsDomainOwnershipVerified true and IsEmailRequired false. That the object has full create, read, update, and delete support matters for anyone managing many orgs: your domain list is now scriptable and auditable, which the old Support-side list never was.

One security note, and it is Salesforce's own warning: enabling the bypass for example.com disables user-level verification for every address ending in @example.com. Domain-level trust simplifies management and widens the impersonation surface in the same move. Authorize domains you tightly control, and nothing else.

Same Setup page, different requirement: do not conflate this with sending-domain verification

Here is where 2026 gets confusing. In Spring '26, Salesforce began enforcing email sending-domain verification: outbound org email from an unverified domain fails delivery, with enforcement waves that started on 9 March 2026 and ran through mid-year. That requirement uses the same two Setup pages (DKIM Keys and Authorized Email Domains) as the user email verification bypass this post is about.

So an admin who diligently verified sending domains in March can reasonably believe they are done, and they are not. Sending-domain verification and the user-level verification bypass are separate outcomes that happen to share plumbing. The bypass is the per-domain setting you enable on the Authorized Email Domain entry after verification. If you verified domains earlier this year, the remaining work is small (check the setting on each domain), but it is not zero. Audit the toggle, not just the verification state.

The broader 2026 enforcement calendar is covered in Salesforce Security Enforcement in 2026: Every Change, Date, and What Admins Must Do, and September 2026 is a crowded month: the OAuth 2.0 username-password flow retirement starts deploying to production around the same time, covered in Salesforce Is Retiring the Username-Password OAuth Flow in Winter '27.

The sandbox refresh trap

Sandbox refreshes are where the retirement will bite hardest, because refreshes already have an email problem and the old exemption was a common fix for it.

On refresh, Salesforce appends .invalid to every user email so a sandbox cannot spam real users. Removing .invalid counts as an email change, which means every user you fix triggers a verification email with a 72-hour link, and unverified users cannot receive workflow or flow email alerts. Orgs with the Support exemption never felt this. Orgs without it are about to.

Two more sandbox facts to plan around. DKIM keys and Authorized Email Domain entries do not survive a refresh, so each sandbox needs its own setup. And Salesforce shipped a partial answer: in production you mark which authorized email domains should be available to sandboxes, and after a refresh you import them in the sandbox with one click. Build that import step into your refresh runbook, right after the refresh completes and before any user email fixes run. There is an open IdeaExchange request to persist domain verification across refreshes automatically; until that happens, the import step is manual.

Your migration checklist

Run this before your enforcement date, and treat the DNS steps as lead-time items, not day-before items.

Inventory the domains in play. A quick way is exporting SELECT Email FROM User WHERE IsActive = true and splitting on the @ to get distinct domains, subdomains included.
Check whether your org holds a legacy Support exemption. The backend list is invisible, so your evidence is old case history. If you find one, list the domains it covered.
For each domain you own, pick a route. DKIM if you want signing anyway (Setup, DKIM Keys, create, publish CNAMEs, activate after propagation). Authorized Email Domain otherwise (Setup, Authorized Email Domains, add, publish the TXT record, verify). Budget up to 72 hours for DNS propagation on either route.
Enable the user-level bypass on each verified domain by editing the domain entry. Verification without the bypass setting does not skip anything.
In production, mark the domains for sandbox availability, and add the one-click import to your sandbox refresh runbook.
Test the whole thing in a sandbox: bulk-update a batch of test users to addresses on the authorized domain via Data Loader and confirm no verification emails fire and no changes sit pending.
Check the Adopt Authorized Email Domains entry in Setup under Release Updates once the Winter '27 sandbox preview reaches you (previews are reported from late August 2026) for your org-specific enforcement date.

If your provisioning automation creates or updates users through the API, this is also a good moment to reread how those scripts handle email fields; the mixed DML constraints covered in Salesforce Mixed DML Operations in User Provisioning tend to live in the same scripts.

What Salesforce has not documented

An honest accounting of the gaps, so you know what to verify rather than assume.

The precise enforcement date comes from Salesforce Ben's Winter '27 coverage (September 2026) and the release update's Winter '27 enforcement labeling, not from a dated Salesforce knowledge article I could point you to. No sandbox versus production split has been published for this specific update, unlike the MFA and sending-domain rollouts. The maximum number of Authorized Email Domain entries per org is undocumented. And there is no documented equivalent for the old third-party consent-letter scenario: if your users carry addresses on a domain you cannot touch DNS for (agency-managed domains, partner domains), I could not find a published path, which is worth a proactive Support case if it describes you.

None of these gaps change the core move. Verified domains with the bypass enabled is the supported future; get there before the release update forces the question.

Frequently Asked Questions

Q: We already set up DKIM for the Spring '26 sending-domain enforcement. Are we covered?

A: Mostly, but verify the last step. An active DKIM key for a domain does qualify it for the user email verification bypass, and that is the route Salesforce recommends. But if your domains were verified through Authorized Email Domain entries rather than DKIM, the user-level bypass is a separate per-domain setting you enable by editing the domain entry. Check each domain's settings rather than assuming the March work finished the job.

Q: What happens to bulk email updates if we do nothing before enforcement?

A: Every changed address triggers a verification email to the new address with a 72-hour link, and the change stays pending until clicked. A Data Loader run over 500 users produces 500 pending changes, and every expired link needs an admin to re-touch the user record to resend. For a domain migration this effectively turns a one-hour job into a multi-week chase, which is exactly what the old Support exemption existed to prevent and what Authorized Email Domains now prevents instead.

Q: Does verifying a domain weaken security?

A: It trades a per-user control for a domain-level one. Salesforce's own documentation warns that enabling the bypass for a domain disables user-level verification for every address on it, which is an impersonation risk if the domain is not tightly controlled. The right posture is to authorize only domains where you control both DNS and mailbox provisioning, leave the bypass off for everything else, and treat the Tooling API's AuthorizedEmailDomain object as part of your audit surface so additions to the list get reviewed like any other privileged change.

Q: Our sandbox refresh scripts strip .invalid from user emails. What changes?

A: Without an exemption, each stripped .invalid counts as an email change and fires a verification email. The fix is to import your production-marked authorized email domains into the sandbox immediately after refresh (it is a one-click import), then run your email fixes. Domains and DKIM keys do not survive refreshes on their own, so the import belongs in the runbook permanently.

Key Takeaways

The Support exemption for email change verification is being retired via the Adopt Authorized Email Domains release update, enforced with Winter '27, with reporting pointing to September 2026. Confirm your org's date in Setup under Release Updates.
The replacement is self-service domain verification: an active DKIM key or a verified Authorized Email Domain entry, plus a per-domain bypass setting that people forget. Each domain and subdomain needs its own entry.
Two different 2026 requirements share the same Setup pages. Verifying sending domains in Spring '26 did not automatically enable the user email verification bypass.
Sandbox refreshes are the hidden casualty: .invalid cleanup triggers verification per user, and domain entries do not survive refreshes, so add the production-to-sandbox domain import to your runbook.
DNS lead time is real: up to 72 hours propagation per route, so this is a plan-ahead migration, not an enforcement-day fix.

What's Next?

Recommended Reading:

Action Items:

Inventory every email domain across active users in production and sandboxes, subdomains included.
Verify each owned domain via DKIM or an Authorized Email Domain entry, enable the per-domain bypass, and test a bulk update in a sandbox.
Check Setup under Release Updates for the Adopt Authorized Email Domains entry once Winter '27 previews land, and dig out any legacy Support exemption case so you know what you are replacing.

The 2026 enforcement calendar keeps adding entries, and the pattern is consistent: manual Support-side arrangements are being replaced by self-service controls you own and can audit. That is a good trade, but only if you make the move before the deadline makes it for you. If you would rather have the whole Winter '27 wave assessed against your actual org configuration than track each update yourself, that is what CloudCounsel does day to day.

Resources & References

Written by the team at CloudCounsel — builders of Paywren and Mehfil.