Verifying Your Email-Sending Domain

REDA runs on Salesforce, and Salesforce now refuses to deliver email whose sending domain has not been proven to belong to you. If your team's addresses end in @yourcompany.com, somebody has to publish one DNS record proving your company owns yourcompany.com — otherwise users can't set their Salesforce email address to a company address, and email REDA sends on their behalf is dropped. This article explains the requirement from first principles, gives you the exact record to publish, answers the question your IT team will ask before they publish it, and walks the whole sequence from Setup to a working, verified domain. It is written for the person configuring a REDA org during onboarding — you do not need to know anything about DNS beforehand.

What an "email-sending domain" is, and why Salesforce now checks it

An email-sending domain is simply the part of an email address after the @ sign. In ana.silva@yourcompany.com, the sending domain is yourcompany.com. When Salesforce sends an email that appears to come from that address — a mass email a user sent from a REDA record, a notification, an owner statement, an automated alert — Salesforce is sending mail as your company.

Historically Salesforce only checked the individual address: it emailed the user a link, the user clicked it, and the address was marked verified. That proves a person can read that inbox. It does not prove that the organisation running the Salesforce org has any right to send mail as that domain. Because anyone who can create users in a Salesforce org could otherwise create an address on any domain and send mail as it, Salesforce added a second, higher check.

So there are now two independent levels of verification, and both matter:

Salesforce phased this in as the Spring '26 email-sending domain verification requirement. Existing orgs got a temporary allowlist of the domains they were already sending from, and that grace period expired during 2026 — so it is a live requirement, not an upcoming one. It applies to sandboxes as well as production, and it is separate for every domain and every subdomain: verifying yourcompany.com does not cover mail.yourcompany.com.

How the problem shows up

The requirement rarely announces itself. It shows up as one of these, and none of them mentions DNS:

Two ways to prove you own the domain

Salesforce accepts exactly two proofs, and you only need one of them per domain. Both work the same way in principle: you publish a record in your domain's DNS that only the domain's owner could publish, and Salesforce looks it up.

The rest of this article covers the authorized email domain route, because it is one DNS record and it is the one most REDA implementations use to unblock onboarding. If your organisation already has an active DKIM key for the domain, the domain is already verified and you have nothing to do — check Setup → DKIM Keys first before creating anything.

Step 1 — Add the domain and get its verification key

Step 2 — Publish one DNS TXT record

DNS is the public directory that maps domain names to information about them. A TXT record is a free-text entry in that directory, and it is what domain-ownership checks universally use: only somebody who controls the domain can put text in its DNS, so finding the expected text there is proof of control. Whoever runs your company's DNS — your IT team, or a registrar such as Cloudflare, GoDaddy or Route 53 — creates it.

Salesforce accepts the record in three valid locations. The value is identical in all three; only the record's name differs.

Using option 2, this is the complete record — a TXT record whose name is the _sfdv subdomain and whose value is the verification key from Step 1. The default TTL is fine.

Name                     TTL   CLASS   TYPE    VALUE
--------------------------------------------------------------------
_sfdv.yourcompany.com.   600   IN      TXT     "00D000000000P08=1TB00000000000B"

Nothing else changes: no mail routing change, no change to existing SPF, DKIM or DMARC entries, no effect on your company's current email delivery. It is one additive record.

What the record does — and does not — give Salesforce

This is the question every IT or security team asks before publishing, and it deserves a direct answer.

Verification is a read-only DNS lookup. Salesforce queries the public DNS for the TXT record at the name you chose, compares the text it finds against the key it generated, and records the result. That is the entire mechanism.

Step 3 — Verify ownership in Salesforce

DNS changes propagate across the internet on a delay. In practice a new record is usually visible within minutes, but Salesforce's own guidance is to allow up to 72 hours, and the actual time depends on the TTL of the records that were already there. Plan the request accordingly — this is the only part of the sequence you cannot compress.

Step 4 — Decide about "Require Email Verification"

Each authorized email domain carries a second setting, Require Email Verification, which is enabled by default. It controls the user-level check described at the top of this article: whether each individual person on that domain must still click a verification link before Salesforce will send as their address.

Once ownership is verified, you have a genuine choice, and it is a security decision rather than a configuration detail:

To change it: Setup → Authorized Email Domains → Edit next to the domain → clear Require email verification → Save. There is also an org-wide equivalent for DKIM on the Deliverability page (Verify the ownership of email sending domains by DKIM keys), which applies to every domain with an active key at once — the per-domain authorized-email-domain setting is the more precise instrument.

Working around a stuck user while DNS is pending

If someone needs their address changed before the DNS record is live, the verification link often fails simply because it is opened outside an authenticated session — the browser has no Salesforce session, so the link lands on the login page and the change is abandoned. This sequence usually gets a single user through:

Two other org settings produce the same login-page symptom and are worth checking if the above doesn't work: Require identity verification for email address changes (Setup → Identity Verification), which asks the user to confirm from their old address and traps anyone who no longer has access to it; and single sign-on, where a stored SSO start-page cookie can force a logout that discards the link's destination.

Troubleshooting

Official Salesforce references

Domain verification is a Salesforce platform requirement, not a REDA setting, so the authoritative documentation is Salesforce's. Salesforce Help URLs change between releases — if a link moves, search the Help portal for the article title or ID.

Where to go next

1. Creating Users & Granting REDA Access — the onboarding task this requirement interrupts.
2. Mass Email Configurations — where org-wide sending addresses are chosen, all of which need a verified domain.
3. Sending Email from REDA — the end-user side of outbound email.
4. REDA Email Services: Overview — inbound email processing, which this requirement does not affect.
5. Securing Your REDA Org — the wider security configuration this sits within.

Frequently asked questions