2026 Salesforce Test Emails Won't Send? How to Check Sender Domain Verification

Salesforce documents two routes for meeting its sender-domain verification requirement: a valid DKIM key or a verified authorized email domain (Salesforce’s verification requirements).

Symptom: Salesforce test emails won't send, or they never appear in the test inbox.
Fastest fix: Identify the actual From domain in the affected organization, check its verification status, and configure a supported verification route if needed. Then rerun the test and use the email log to distinguish a send failure from a delivery problem. A test inbox can confirm receipt; it cannot verify the sending domain.

Salesforce admins: map the sender domains used by the organization, users, and automation, then check their status.
Developers: establish whether Apex, Flow, or another process triggered a send and inspect the resulting evidence.
QA engineers: keep the sending result separate from the controlled inbox result, so a missing message is not automatically blamed on the recipient.

Last updated October 24, 2026. Policy and troubleshooting details checked against Salesforce’s official help and release documentation; the affected organization’s current setup and any applicable exceptions still need to be checked in its own Salesforce settings.

Salesforce test emails won't send: start with the sender domain

A verified user email address is not the same thing as a verified sender domain. The first concerns a user’s address. The second concerns the domain used by the organization to send email. Checking only that a user has verified their address can therefore leave the actual sender-domain issue unresolved.

First classify the symptom. This prevents a common troubleshooting mistake: changing DNS when an automation never ran, or blaming the test inbox when Salesforce did not accept the message.

• No send was triggered: The Apex action, Flow, alert, or other automation may not have run, or its conditions may not have been met.
• Salesforce rejected or dropped the message: Check the sender domain, the From address, organization settings, and the error details in the relevant logs.
• Salesforce attempted to hand off the message, but it is absent from the inbox: Investigate delivery and recipient-side filtering after confirming the send attempt. Inbox absence alone does not prove that Salesforce failed to send.

Salesforce’s requirements and exceptions can depend on the organization and its current configuration. Use the official email verification requirements alongside the target organization’s settings. Do not treat a past exception, a temporary exemption, or a setting seen in another organization as a general rule.

Admin milestone: inventory the domains the organization actually sends from

Build the inventory from the affected organization, not from an old setup note or an example domain in a guide. Salesforce provides steps for identifying email domains in an organization. Use that process to check which domains appear in the organization’s email configuration, then compare it with the addresses that real messages use.

Include relevant sources such as user email domains, organization-wide addresses, Email-to-Case, Experience Cloud, and From addresses selected by automation. The aim is not to verify every domain that appears somewhere in a company’s records. It is to identify the domains actually used to send the messages under investigation.

Record the full domain for each From address. A subdomain may need its own review; do not assume that configuring a parent domain automatically covers every subdomain used by the organization. Confirm each case against Salesforce’s current requirements and the organization’s status.

Keep the record actionable: note the sender address, its domain, the Salesforce organization where it is used, who owns the relevant DNS, and the status shown in Salesforce. This gives admins and DNS owners a shared handoff instead of a vague request to “check email authentication.”

DNS milestone: choose a verification route the team can maintain

Salesforce’s documented approaches are a valid DKIM key or a verified authorized email domain. SPF and DMARC are important parts of email authentication and delivery practices, but they are not substitutes for this Salesforce sender-domain verification requirement. Compare the two documented routes with the people who own the configuration before changing DNS.

Choose based on the team’s actual access and support model, not on a generic preference for one method. If the Salesforce admin cannot change DNS, the next step is to give the DNS owner the exact domain and configuration requirements from the official documentation. If DNS can be managed but an existing DKIM configuration is unclear, ask the DNS owner to confirm what is already published before adding or replacing records.

Use Salesforce’s verification considerations to check the current process and boundaries. Do not copy DNS values from an old ticket or another organization: compare the current Salesforce instructions with the settings for the domain being verified.

Sandbox milestone: verify the test organization independently

A production organization’s domain status does not establish that a sandbox is ready to send test emails. Check the sandbox’s own sender configuration and verification status. Salesforce’s requirements apply to the target organization, and the task’s sandbox setup should be evaluated there rather than inferred from production.

Review the From address selected by the sandbox test. If it uses a different address or domain from production, include that domain in the inventory. If both organizations use the same domain, still check the sandbox status rather than assuming it inherited the production configuration.

Some organizations may have alternative sender-address settings, but their availability and scope depend on Salesforce’s current documentation and the organization’s setup. Confirm those boundaries before using an alternate address as a workaround. Do not weaken production protections simply to make a sandbox test pass; keep the test configuration within an authorized, controlled environment.

Developer milestone: prove that automation ran before changing email settings

Once the sender domain is known, confirm the application path. Check whether the relevant Apex, Flow, alert, or other automation ran, and whether its conditions allowed the email action. Then identify the From address that the action used. A correct domain configuration cannot fix a process that never reached its send step.

Use Salesforce email logs to connect the send attempt with its outcome. Salesforce’s email log format reference explains the fields available for review. Look at the status and error details, and compare them with the sender address and domain status. A permanent failure or an explicit error related to an unverified domain is useful evidence, but it is not a universal explanation for every missing email.

Email logs have request and availability constraints. Check Salesforce’s email log considerations before relying on a log request as the only evidence. Salesforce’s release documentation also describes particular email error messages; use those messages as evidence about the recorded failure, not as proof that every failed send has the same cause (Salesforce release note).

After correcting a configuration issue, rerun the same workflow in the authorized test environment. Record whether the automation ran, which From address it selected, the relevant log result, and whether the controlled recipient received a readable message. This makes the next investigation reproducible and prevents a successful inbox check from being mistaken for proof of domain authentication.

QA milestone: separate send evidence from inbox evidence

A controlled test recipient address is useful only after the sending path has been checked. It can show whether a message reached a test inbox and whether the message content is readable. It cannot demonstrate that the sender domain is verified, and it cannot repair a Salesforce configuration.

Keep three kinds of evidence separate:

• Domain evidence: the actual sender domain and its verification status in the affected organization.
• Automation evidence: whether the expected Apex, Flow, or other process ran and reached its email action.
• Recipient evidence: whether the controlled inbox received the message and whether its content matched the expected result.

If the send log does not show a successful attempt, return to the automation and sender configuration. If Salesforce accepted and attempted the send but the inbox remains empty, investigate delivery and filtering without concluding that the test recipient caused the original failure. For more on choosing an isolated address for a test, see our guide to test address choices.

Salesforce sandbox email testing checklist

Use this checklist for the organization where the failure occurs. Stop at the first unchecked item that blocks the send; changing unrelated DNS or production settings adds risk without improving the diagnosis.

• [ ] Confirm the affected environment is the intended Salesforce sandbox or production organization.
• [ ] Identify the exact From address used by the failing Apex, Flow, alert, or other process.
• [ ] Record the sender domain, including any subdomain, and check the organization’s current domain inventory.
• [ ] Confirm whether the user’s email address is verified, but do not treat that as proof of sender-domain verification.
• [ ] Check whether the sender domain has a valid DKIM key or is a verified authorized email domain, using Salesforce’s current instructions.
• [ ] Ask the DNS owner to confirm the relevant records when DNS changes are part of the selected route.
• [ ] Verify the domain status in the affected sandbox or production organization rather than inferring it from another environment.
• [ ] Confirm that the automation ran and that its conditions allowed the email action.
• [ ] Inspect the email log and preserve the status and error details for the test attempt.
• [ ] Rerun the same authorized test and record the send result separately from the controlled inbox result.

FAQs

What should we check first when a Salesforce sandbox test email does not arrive?

Start with the sandbox’s own sender configuration. Confirm which From address the test uses, identify its domain, and check that domain’s verification status in the sandbox. Production configuration does not prove that the sandbox is configured. Then confirm the Apex, Flow, or other automation actually ran and inspect the relevant email log before treating the controlled inbox as the cause.

Why can Salesforce still fail to send after a user verifies an email address?

A verified user address and a verified sender domain are different checks. The address check confirms the user’s email address; it does not by itself establish that the domain used in the From address meets Salesforce’s sending requirements. Identify the actual sender domain and verify it through a valid DKIM key or an authorized email domain, subject to the target organization’s current settings.

Should a Salesforce sender domain use DKIM or an authorized email domain?

Salesforce documents both as ways to meet the sender-domain verification requirement. Choose based on the organization’s existing DNS ownership and DKIM setup, plus who can maintain the configuration. If DNS access is available and a signing setup is appropriate, coordinate DKIM with the DNS owner. Otherwise, evaluate the authorized email domain route against Salesforce’s current setup instructions and organization status.

How can Salesforce email logs show that domain verification caused a failure?

Find the log entry for the relevant send attempt and examine its status, error details, and sender information. A permanent failure or an explicit message about an unverified domain is useful evidence, but one error does not explain every email failure. Correlate the log with the automation run and current domain status; if Salesforce accepted the send, continue investigating recipient-side delivery separately.

Once sender-domain verification and the Salesforce send attempt are confirmed, a separate inbox can help QA check receipt and readability without mixing test messages with a work mailbox. Tempsender is one possible controlled recipient for that final check; it should be treated as a receiving option, not as a fix or proof of Salesforce domain authentication. For a broader look at using a dedicated inbox in a development workflow, see our email relay guide.

Frequently asked questions