Authorized Email Domains
Authorized Email Domains is the Salesforce Setup feature where administrators register the email domains the org is allowed to send From in outbound email.
Definition
Authorized Email Domains is the Salesforce Setup feature where administrators register the email domains the org is allowed to send From in outbound email. Each registered domain pairs with a DKIM key Salesforce generates so receiving mail servers can verify that emails claiming to come from the org's domain actually originated from Salesforce. Without authorized domain registration plus the matching DKIM record on the customer's DNS, outbound emails commonly land in spam folders or get rejected outright by receiving servers.
The feature is the Salesforce side of email authentication. The customer side requires publishing a CNAME or TXT record in DNS that points to the Salesforce-generated DKIM key. Together they tell receiving mail servers: yes, Salesforce is authorized to send for this domain. Authorized Email Domains is one of three related features for outbound email integrity (Email Relay Activation, DKIM Key Management, Email Authentication settings); together they form the deliverability foundation for any org that sends customer-facing email.
Why outbound email deliverability rests on domain authorization plus DKIM
Where Authorized Email Domains lives in setup
Setup, Email, Email Authentication or Setup, Email, Deliverability depending on the org's edition. The page lists every registered domain, the DKIM key for each, the activation status, and the DNS records the customer must publish for the DKIM key to be honored by receiving servers. Salesforce generates the DKIM key automatically when a domain is registered; the customer copies the published CNAME or TXT record values into their DNS provider's console.
Why DKIM matters for outbound deliverability
DKIM (DomainKeys Identified Mail) is one of the three core email authentication protocols, alongside SPF and DMARC. A receiving mail server checks the DKIM signature on an inbound email against the published DKIM key in the sender's DNS; if the signature matches, the email is verified as authentically sent by an authorized server for that domain. Without DKIM, the receiving server has no cryptographic proof that the email is not spoofed. Modern mail providers (Gmail, Outlook, Yahoo) heavily penalize unauthenticated mail; rates of inbox delivery drop sharply for senders without DKIM.
The SPF and DMARC complements
DKIM authenticates the email content. SPF authenticates the sending IP. DMARC tells receiving servers what to do when DKIM or SPF fail. All three should be configured for production email sending. Salesforce ships SPF guidance for the standard Salesforce sending IPs; the customer publishes an SPF TXT record on their domain that includes the Salesforce SPF entry. DMARC is a separate TXT record at the customer's domain that specifies the policy (none, quarantine, reject) for unauthenticated mail. Most orgs start at DMARC policy "none" while validating that all legitimate senders pass DKIM and SPF, then escalate to quarantine and reject.
Activation status and the DNS propagation question
After publishing the DKIM record in DNS, Salesforce verifies the record exists before flagging the domain as Activated. DNS propagation can take minutes to hours; admins who publish the record and immediately re-check the Salesforce page often see Not Verified for the first hour. The verification check runs periodically (every few hours); admins can trigger a manual recheck from the Authorized Email Domains page. Activation is the gate for Salesforce to start signing emails with the DKIM key; until then, outbound mail goes unsigned and may land in spam.
Multi-domain orgs and the per-domain registration pattern
Orgs that send from multiple domains (acme.com, support.acme.com, news.acme.com, acme.co.uk) need to register each as a separate Authorized Email Domain with its own DKIM key. The pattern is straightforward but easy to miss; an admin who registers acme.com and forgets news.acme.com finds that newsletters from news@news.acme.com fail DKIM checks while sales emails from sales@acme.com pass. The audit: pull a sample of From addresses from sent email logs and confirm each domain is registered.
Email Relay and the alternative pattern
Email Relay is a separate feature where Salesforce sends outbound email through the customer's own mail server (Exchange, Postmark, SendGrid) rather than from Salesforce's IPs. With Email Relay, the customer's existing email authentication setup applies; Authorized Email Domains and Salesforce DKIM are not needed. The pattern is appropriate for orgs with strict outbound email governance who do not want Salesforce sending directly. Most orgs do not need it; the additional infrastructure and the latency cost rarely justify the trade-off for sales and service outbound mail.
Monitoring deliverability and feedback loops
Once authorized email domains are configured, monitor deliverability through DMARC aggregate reports (sent by receiving mail providers to the email address specified in the DMARC record) and through Salesforce Email Logs. DMARC reports show how often emails pass or fail authentication at each receiving provider. Email Logs show send status from the Salesforce side. Together they form the deliverability dashboard. Most orgs underuse DMARC reports; pulling the report monthly and reviewing failed-auth volume catches issues (a new sender, a misconfigured CRM integration) before they become spam-folder problems.
How to set up Authorized Email Domains and DKIM for production sending
The setup is short but DNS-dependent. The order: register the domain in Salesforce, copy the DKIM record values, publish to DNS, wait for propagation, verify activation, then start sending. Each step takes minutes; DNS propagation is the slow part and is outside admin control.
- List the domains the org sends From
Pull a sample of outbound email From addresses from your sent log. Every distinct domain (acme.com, news.acme.com, support.acme.com) needs registration.
- Register each domain in Setup, Email Authentication
Setup, Email, Email Authentication. New Domain. Enter the domain name. Salesforce generates a DKIM key and shows the CNAME or TXT records to publish.
- Publish DKIM records to your DNS provider
Copy the Salesforce-generated CNAME or TXT records into your DNS console (Cloudflare, Route 53, Vercel DNS, etc.). The records are subdomain-specific.
- Wait for DNS propagation and verify
DNS propagation typically takes 15 minutes to 4 hours. Re-check the Salesforce page; status moves from Pending to Activated when verification succeeds.
- Confirm SPF includes Salesforce
Salesforce's SPF entry needs to be in your domain's SPF TXT record. Use an SPF lookup tool to verify; missing SPF compounds DKIM problems.
- Add a DMARC policy at "none" first
Publish a DMARC TXT record with policy "none" plus a reporting email. Aggregate reports start arriving within 24 hours and tell you what is passing and failing authentication.
- Escalate DMARC to quarantine then reject after validation
Once all legitimate senders pass DKIM and SPF reliably for 2 to 4 weeks at "none", escalate to "quarantine" (5 percent of failed mail goes to spam). After another 2 to 4 weeks, escalate to "reject" (100 percent rejected).
Every distinct sending domain. Multi-domain orgs need each registered separately.
The selector portion of the DKIM record (typically sf or a date-based string). Salesforce generates this.
CNAME or TXT depending on the DNS provider's support. Both work; Salesforce supports both.
The Salesforce SPF include string the domain's SPF TXT record must contain.
Start at none, escalate to quarantine, then reject. The escalation is what actually enforces the authentication.
- DNS propagation can take hours. Admins who publish records and immediately re-check often see Not Verified for the first hour; this is normal.
- Multi-domain orgs need separate registration per domain. Forgetting subdomain registrations is the most common cause of partial spam-folder issues.
- DMARC at policy "none" does not enforce anything. The escalation to quarantine and reject is what actually makes DMARC matter; orgs that publish DMARC at none indefinitely get no enforcement benefit.
- Email Relay is an alternative pattern, not a complement. Running both adds operational complexity without authentication benefit.
- Receiving mail providers cache DKIM records aggressively. Changing the DKIM key after publishing can produce intermittent failures for hours while caches refresh.
Trust & references
Cross-checked against the following references.
- Authorized Email Domains referenceSalesforce
- DMARC.orgDMARC.org
Straight from the source - Salesforce's reference material on Authorized Email Domains.
- Authorized Email DomainsSalesforce Help
- DKIM Key ManagementSalesforce Help
- Email DeliverabilitySalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. Can a Salesforce admin configure Authorized Email Domains without writing code?
Q2. What is the primary benefit of Authorized Email Domains for Salesforce administrators?
Q3. In which area of Salesforce would you typically find Authorized Email Domains?
Discussion
Loading discussion…