Salesforce Flow Send Email Not Received in Sandbox: Fixes

Executive Summary

A Salesforce Flow whose Send Email action "finished" in a refreshed sandbox has proven one thing: the automation path ran. It has not proven that Salesforce was authorized to send, and it has not proven that a message reached a mailbox. This report separates three evidence stages: automation execution, permission to send, and delivery observed at an approved test inbox. It is scoped to Salesforce Winter '27, whose release notes were scheduled for August 19, 2026 and whose production upgrades ran on three weekends (September 4, October 2 and October 9) according to the Salesforce Admin blog ^[1].

The first authorization gate is the sandbox Deliverability level. Salesforce documents that new and refreshed sandboxes default to System email only ^[2], a level that allows only automatically generated emails such as new user and password reset messages ^[2]. A working password reset therefore does not show that a Flow's business email can leave the sandbox. The second gate is verification. Salesforce requires both domain-level and user-level email verification ^[3], and the individual address must be verified in all cases. The July 6, 2026 Salesforce notice sets a phased enforcement for allowlisted domains from June 29 to July 27, 2026, a phase specific to allowlisted domains rather than the first enforcement of domain verification ^[4], applies to email relay, and warns that Flow and other automation sends may show no error in the interface ^[4].

Sandbox addresses add a third gate. Salesforce appends .invalid to user email addresses on refresh ^[5] but does not change other addresses, such as those on contact records, so recipient fixtures need deliberate replacement with approved inboxes. Winter '27 adds the option to copy verified authorized email domains from production into a sandbox ^[3], and a release update that retires domain allowlists for user email verification is scheduled for enforcement on December 1, 2026 ^[3].

Even when Salesforce logs show the message left, inbox placement is a recipient-side fact. Salesforce says the R and D log statuses confirm only that email was triggered from Salesforce ^[6], and the SMTP standard describes acceptance as a handoff of responsibility rather than proof of arrival ^[7]. This report therefore supplies a bounded test plan, a three-stage evidence ledger and a handoff package for the mail administrator. It labels any unobservable stage unknown, never zero. One documented gap remains: the current official text read for this report does not state whether Flow Builder debug or rollback runs send email, so the test mode must be recorded and tested rather than assumed.

Introduction and Background

Admins and consulting partners testing a Flow in a freshly refreshed sandbox often meet the same symptom: the debug run is green, the Flow interview completes, and no email appears. The instinct is to edit the Flow. In most cases the Flow logic is not the cause, and editing it destroys the evidence. The diagnostic question is which of three stages failed: Stage 1 (did the intended path and action run?), Stage 2 (was Salesforce authorized to send this message from this sender?), or Stage 3 (did a receiving system accept, filter or deliver it to an approved inbox?).

Several terms recur. A sandbox is a copy of a production org used for development and testing. Deliverability is the Setup page that controls the "Access to Send Email" level. DKIM (DomainKeys Identified Mail) lets the owner of a signing domain claim responsibility for a message ^[8], while SPF (Sender Policy Framework) exists because email on the Internet can be forged in a number of ways ^[9]. An org-wide email address is a verified shared From address configured in Salesforce. A mail transfer agent (MTA) is a mail server that relays or delivers messages.

The verification rules predate Winter '27. Salesforce's Summer '26 admin summary already describes the move to sending only from verified domains ^[10]. Winter '27 refines the tooling around it. This report keeps the two apart so that a Winter '27 sandbox is not blamed for a requirement that predates it. Release dates differ by source and instance: the Salesforce Admin blog lists a sandbox preview beginning August 28 and tells readers to check Trust for their sandbox upgrade window ^[1], while a Salesforce Ben preview article lists different weekends and notes they depend on the instance ^[11]. Record the actual release of the sandbox under test rather than relying on a calendar.

Stage 1: What "Finished" Means for a Flow Email

Capture the run before changing anything

A completed interview is a statement about automation, nothing more. Before any setting is touched, record the following, with timestamps and a stated timezone:

• Org ID and sandbox name, plus the release the sandbox was running (Winter '27 or a preview).
• Flow API name and version. Only one version of a flow can be active at a time ^[12], and a practitioner guide warns that a debugger can end up on an old version ^[13]. Winter '27 also lets builders restore a past version as a new version ^[3], so version numbers can change during a test.
• Actual test mode: record-triggered run, scheduled run, screen run, Debug, or Debug with rollback.
• Branch reached, and the exact Send Email action inputs (sender type, sender address, recipients, template, log setting).
• Exact error or output text, including any fault path output.

Verify the debug mode's side-effect contract

Debug runs act on real data. Salesforce's Trailhead guidance states that Debug interacts with your org data ^[14] and recommends debugging in a sandbox ^[14]. In a Trailhead exercise, a successful debug run updated the actual task record ^[15]. Rollback is an opt-in checkbox that Trailhead describes as preventing debug runs from affecting data ^[15].

None of that text addresses email. The official pages read for this report did not say whether a Send Email action is sent, queued or suppressed in a normal debug run or a rollback run. Do not assert that every debug mode sends email, and do not assert that none can. Treat "rollback prevents data changes" as a data statement, not a statement about external messages. Read the current Flow Builder debug documentation for the sandbox's release on the day of the test, copy the relevant sentence into the evidence ledger, and, if it is silent, mark the mode's email behavior unknown.

Why absence of an error is weak evidence

The July 6 notice states that emails sent through Apex, Flows, alerts and automations may not be able to show an error message in the interface. Practitioners summarize the same behavior as dropped mail with no bounce and no error for most automations ^[16]. A Flow that shows no fault is therefore consistent with success, with policy discard, and with an unobserved mailbox filter. If the Flow does show a fault, read it first.

Daily limits and what they count

Daily limits rarely explain a single missing test message, but the sources should be known. The Apex Developer Guide sets single emails at a maximum of 5,000 external addresses per day on a Greenwich Mean Time basis ^[17] and says the limit is also enforced for Send Email actions in flows for orgs created in Spring '19 and later ^[17]. When a counted email cannot be sent because of the limit, Salesforce notifies by email and adds a debug-log entry. The Flow action reference adds a nuance: the limit is the single email limit when logEmailOnSend or a template is used, and the daily workflow email limit otherwise ^[18].

Salesforce Help articles describe the counting of Flow emails in slightly different terms, so treat the exact rule as unresolved and read the sandbox's own limits page. No sandbox-specific daily number was found in the pages read; the documented reduced figure applies to Developer Edition and trial orgs, at 50 recipients per day ^[17].

Stage 2, Gate A: Inventory the Exact Sender and Recipients

Three sender types that must stay distinct

The Send Email action reference defines the sender through a senderType input. The default is the email address of the user running the flow ^[18] (CurrentUser). A second option is the email address of the default workflow user ^[18] (DefaultWorkflowUser). The third is an OrgWideEmailAddress, for which the action takes the address to be used as the sender ^[18]. In scheduled flows the only valid value is OrgWideEmailAddress ^[18].

These are different identities with different verification states, so the first question for any missing message is which identity the action actually used. A Salesforce Ben guide on overriding system sender addresses tells admins to find Send Email actions that send as the Default Workflow User or the Current User ^[19], a useful discovery step but a different task. Do not change the org-wide Default Workflow User just to fix a single test: that setting is shared by other automation, and changing it alters the sender for flows that are not under test.

Recipient fields

Recipients on the action are capped at 150 combined ^[18], but for a bounded test one recipient is enough. The inventory records which address is the sender, which is the recipient, who owns the inbox and who approved it.

Table 1 below shows the inventory worksheet. Every row is a teaching fixture (Hypothetical Example) with invented addresses on the reserved example.com domain, not a benchmark and not data from any real org.

The interpretive point of Table 1 is that two of the seven rows (sender address and sender domain) are verification facts that look identical in the Flow editor but live in different parts of Setup. A row left blank means the stage cannot be assessed; it does not mean the value is correct.

Stage 2, Gate B: Sandbox Send Policy and Recipient Addresses

Deliverability access level

Salesforce documents three levels. No access prevents all emails ^[20]. System email only allows only automatically generated emails, such as new user and password reset emails ^[2]. All email allows all types of outbound email ^[2]. New and refreshed sandboxes use System email only by default, and Trailhead repeats that it is the default on any new sandbox and advises checking the setting at first login ^[20]. The setting is found by entering Deliverability in Setup Quick Find.

Three consequences matter for diagnosis:

• A successful system email is not a pass. A password reset or welcome message is exactly what System email only is meant to allow, so it cannot show that business email is allowed.
• No page read states the Flow-specific outcome in so many words. The Help definition covers "automatically generated emails", and a practitioner article states that the setting restricts flows from sending, noting the limitation extends beyond flows ^[21]. Treat it as a strongly indicated cause that still needs a controlled test.
• The setting may not be editable. Salesforce's page says to set the level "if editable", so some orgs will need Salesforce's involvement.

A refreshed sandbox resets earlier work. Trailhead warns that anything changed since the sandbox was created or last refreshed will be destroyed ^[20], so a setting changed before a refresh must be reapplied afterward and read back.

Why the restriction exists, and why to keep it

Salesforce describes System email only as useful for controlling email sent from sandboxes. A practitioner article asks what happens in a refreshed partial or full sandbox with some real data when a mass update runs ^[21]. Switching a sandbox to All email for a Flow test, with customer-derived contact addresses still present, is exactly the situation the default is meant to prevent. The approved test window should be as short as the test, with the original setting recorded first and restored afterward.

The same article notes a safer pattern for the Flow itself: the Organization object has a boolean IsSandbox field even though it is not on the layout ^[21]. A Decision element on that field can keep production-only branches from sending in a sandbox. That is a design option for the Flow owner, not a substitute for the Deliverability setting.

What .invalid does and does not cover

On sandbox creation or refresh, Salesforce appends .invalid to user email addresses ^[5]. It does not modify other addresses, such as email addresses in contact records ^[5], and tells admins to manually invalidate or delete all email addresses in their sandboxes to avoid sending unsolicited email ^[5]. Each sandbox user's account email must also be verified before that user can send email.

Three distinctions follow. A username suffix is a login identifier, and an email address is a mailbox; changing one does not change the other. A user email with .invalid cannot receive or be verified as a real mailbox, so a tester whose address still carries the suffix will not pass the individual verification gate. And a contact or custom-object email copied from production is still live. The practitioner reports line up: on a Stack Exchange thread about a Flow-invoked send that reported success but delivered nothing in a partial sandbox, the owner had Deliverability at All Emails ^[22], the first suggested check was whether the user's sandbox email was valid ^[22], and the explanation was that the user must verify the change through a message Salesforce sends ^[22]. This research did not confirm from a Salesforce primary page whether email address changes now require a valid session, so check in the sandbox whether correcting a tester's address needs an interactive, approved login by that tester.

Correct only approved tester identities and replace fixture recipients with controlled inboxes. Do not bulk-restore real customer addresses to make a test convenient.

Stage 2, Gate C: Sender and Domain Verification

Two layers, not one

Salesforce's requirements page states that it requires domain-level and user-level email verification ^[23], and the Winter '27 admin summary repeats that both are required for email to send correctly ^[3]. The Apex reference adds that delivery fails if any verification is incomplete ^[24]. The Help article for the Flow Send Email action reference could not be read as raw text in this research session, so the Flow-specific wording is not quoted here; the requirement is established from the pages above.

• User-level: each user must verify their Salesforce email address. Domain verification does not replace this: the individual address must still be verified in all cases ^[4].
• Domain-level: verification is required for each email-sending domain; confirm in Salesforce Help whether subdomains need their own verification.
• Methods: Salesforce recommends DKIM keys over authorized email domains whenever possible.

Timing: use the official timeline, not an older vendor date

Earlier trade-press coverage differed on dates: a guide dated April 15 gave May 4, 2026 as the date Salesforce was due to enforce the changes in Production orgs ^[19]. The official notice, last updated July 6, 2026, instead describes phased, monitored enforcement: verification of allowlisted domains required starting June 29, 2026 ^[4] and ending July 27, 2026. Earlier phases are in a separate Salesforce timeline article. For a Winter '27 test, enforcement has already begun, and the question is not "is the deadline here?" but "what does this org's Setup say about this domain and this user today?" Use the org's actual state, not any article date, as the test input.

Winter '27 adds new controls on top of the existing verification rule. A per-domain setting chooses whether address verification applies Always, For Updated Addresses Only, or Never ^[3], a User Email Domains page shows verified and unverified address counts for each domain ^[3], and a release update that retires the domain allowlists is scheduled for enforcement on December 1, 2026 ^[3]. Treat any sandbox result before December 1 as time-bound.

Sandboxes need their own verification

A refresh does not carry DKIM verification over: practitioners summarize that DKIM keys and Authorized Email Domains are not automatically copied when a sandbox is created ^[16]. Winter '27 changes that for authorized email domains: instead of working through DNS verification for each authorized domain in a new sandbox ^[3], an admin can copy verified domains, provided each is set in production as sandbox-portable as a one-time setup ^[3]. The copy feature affects domain verification only. It does not verify the tester's individual address.

Email relay is in scope

The notice states that the requirement applies to email relay ^[4]. Relay means Salesforce hands the message to the organization's own mail server, which does final delivery. The practical rule is to verify the route the test actually uses. Do not assume a relay exempts the message, and do not assume relay is in use unless Setup shows it.

The substitute-domain option

Salesforce added an option to send email from unverified domains in late April 2026 ^[4]. Its mechanics, from the dedicated Help page, are narrow:

• The user's display name and reply-to address remain unchanged.
• If no organization-wide address is selected, Salesforce sends from a Salesforce-controlled substitute domain keyed to the org or site ^[25].
• Only org-wide addresses meeting all listed conditions (verified address, verified domain, and use allowed for all profiles) appear in the selection list ^[25].
• If the feature is disabled, Salesforce no longer sends email from unverified domains.
• In some cases, users get no message and can believe the email was sent when it was dropped ^[25].

Use the option only if it fits policy and the user's individual address is verified. Capture the resulting From identity in the evidence ledger. Substitution is not verification of the original domain, so a message that arrives from the substitute identity proves only that the substitute path works.

Stage 3: Delivery Evidence and the Mail Administrator Handoff

What Salesforce's own log can establish

Salesforce's delivery article says successful delivery appears as a D in the Mail Event column ^[26], and a permanent failure appears as a P. It also states that delivery is attempted for up to 24 hours before a bounce, so an absent bounce within minutes is not proof of success. The July 6 notice tells admins to search the Setup email logs for the string 550 5.7.1 Delivery not authorized, message discarded ^[4]. Under the enhanced status code standard, X.7.1 means the sender is not authorized to send to the destination ^[27], and a class 5 failure is not likely to be resolved by resending the message in the current form ^[27].

The key limit: Salesforce says the R and D statuses confirm that emails are being successfully triggered from Salesforce. They confirm the Salesforce side. They do not show inbox placement. Separately, bounce flags on Contact or Lead records come from Salesforce's Bounce Management feature, which this research did not confirm covers Flow sends, so do not treat those flags as evidence about a Flow send.

The log's retention window, request limits and field list should be read from the Request an Email Log screen of the org under test. The pages that describe them rendered only as empty shells during this research, so no numbers are stated here, and a missing log row must be recorded as unknown, never as zero messages.

Activity logging is optional and is not delivery proof

The Send Email action can log to the activity timeline, which needs a recipient or related record ID ^[18]. Turning on logging or using a template changes which daily limit applies ^[18], and a community write-up warns that templates change the API the action calls ^[28]. A logged activity records that Salesforce handled the send. It still does not show what the recipient's server did. Whether the plain action creates an EmailMessage record was not established by a readable official page, so that stays unknown.

What an accepted send does and does not prove

The SMTP standard (RFC 5321) says that at the end of the data transfer a formal handoff of responsibility for the message occurs ^[7], and describes a server accepting responsibility for delivering or relaying the message ^[7]. It also acknowledges that dropping mail without notifying the sender is permitted in practice ^[7], against the expectation that mail is either delivered or returned ^[7], and that silent forwarding without notice to the sender is common ^[7]. A permanent mailbox rejection uses reply 550 ("mailbox unavailable") ^[7], and a temporary 4yz condition means the action may be requested again ^[7].

Filtering is a further route. DMARC (Domain-based Message Authentication, Reporting and Conformance) lets a domain owner ask receivers to treat failing mail as suspicious ^[29], and receivers may reject or quarantine mail even when it passes the DMARC check ^[29]. A sandbox message with a changed From identity, an unfamiliar sending path or a modified domain is a plausible target for such policies. That is a hypothesis for the recipient's administrator, not a finding.

Handoff package for the mail administrator

When the Salesforce stage is confirmed but nothing arrives, Salesforce's own guidance is to give the Message ID of the D event to the recipient's IT team ^[6]. Prepare a package with: send timestamp and timezone, sender address, recipient address, the Salesforce log identifiers, the Flow API name and version, and the test identifier. The recipient-side tools are well documented by the mail platforms themselves:

• Microsoft 365: message trace lets an administrator determine whether the service received, rejected, deferred or delivered a message ^[30], supports ranges up to 90 days ^[30], and can filter by the internet message ID taken from the message header ^[30]. Statuses include quarantined as spam, bulk or phishing ^[30] and spam-filtered rejection ^[30]. Reported status can lag the real status by five to ten minutes ^[30].
• Google Workspace: Email Log Search cannot show message contents ^[31], uses the unique message ID ^[31], and for a message marked delivered tells the administrator to check the external network ^[32]. The recipient might also have deleted, archived or labeled a delivered message ^[32].

If the administrator finds the message delivered and later moved by a user rule, record "delivered, relocated"; that closes the Flow question.

A Bounded Test Plan with Controlled Recipients

A single, pre-approved test beats a series of exploratory sends. The plan below assumes the Deliverability change, if any, has been approved by the RevOps owner in writing, and that the recipient inbox has a named owner.

1. Freeze and record. Capture Table 1 and the Stage 1 items: org ID, release, Flow version, test mode, timestamps.
2. Confirm the debug mode's email contract. Read the current documentation and copy the relevant sentence, or mark it unknown.
3. Replace the recipient with the single approved inbox. Never send to a contact copied from production.
4. Check the sender identity the action will use, and confirm the individual and domain verification states in Setup.
5. Open the send window. If the level is System email only, request approval to change it to All email, record the original, and set a stop time.
6. Run once. Record the branch reached, the output and the time.
7. Collect evidence at each stage (see Table 2 below), including the Salesforce email log entry if available and the inbox result observed by its owner.
8. Restore and read back. Return the Deliverability level and any temporary addresses to the approved state, read each value back, and record unresolved stages with an owner.

Table 2 below is a teaching fixture (Hypothetical Example): five invented runs showing how the three stages combine with the Deliverability level, verification state and test mode. It is not a measurement of any org or a benchmark, and the counts at the end must not be turned into rates.

Of the five fixture runs, five reached the action (attempted Flow paths: 5), two show send evidence (D events: 2), and one message was received (received test messages: 1). Those three counts answer different questions and none supports a delivery rate: five synthetic runs cannot estimate one. Table 2 should be read row by row. The point of the ledger is that the same visible symptom ("Flow finished, no email") maps to four different owners: the Flow author, the Salesforce admin, the DNS owner and the mail administrator.

Data Analysis and Evidence

The quantitative core of this topic is dates and limits rather than rates. No public benchmark of sandbox email-delivery failure rates was found, and none is implied. The figures that matter are the documented ones.

Documented dates (as of November 2, 2026):

• June 29 to July 27, 2026: phased, monitored enforcement for allowlisted domains.
• August 19, 2026: Winter '27 release notes date in the Salesforce Admin blog.
• September 4, October 2 and October 9, 2026: Winter '27 production weekends, depending on the instance.
• December 1, 2026: enforcement date for the release update that retires domain allowlists for user email verification.
• Late April 2026: the substitute-domain option for unverified domains was added.

Documented limits:

• 5,000 external single-email addresses per day per licensed org, on a GMT day.
• 150 combined recipients on a Send Email action.
• 50 recipients per day for Developer Edition and trial orgs.
• 24 hours of delivery attempts before a bounce.
• 90 days maximum trace range in the Microsoft 365 message trace tool.

Source discrepancies to disclose. Earlier trade-press dates for the verification deadline (for example May 4) differ from the official phased timeline. Winter '27 production weekends differ between the Salesforce Admin blog and a Salesforce Ben preview article ^[11]. The counting rule for Flow emails is described differently across Salesforce Help articles. This report uses the originator (Salesforce) for each date and limit and flags the rest as unresolved.

Evidence-ledger fields to record for every run, so that two testers' results can be compared: org ID, release, Flow API name and version, test mode, timestamps with timezone, actual From and To, test identifier, source of each observation, approver, original and restored setting, and remaining owner. The distinction between three counts (attempted paths, observed send evidence, received messages) prevents the common error of reporting a completed Flow as a delivered message.

Implications and Future Directions

Where AI assistance fits, and where it does not

An AI client can reduce inventory and triage effort in this workflow: reading visible Flow metadata, comparing the sender settings against a written worksheet, and flagging mismatches with source names. It cannot approve recipients, see an inbox, or read DNS unless a tool exposes those. No time-saving figure is claimed here because none was measured.

Salesforce's hosted MCP servers show the permission model to ask about. They can read, create, update and delete records with tools that respect field-level security and sharing rules ^[33], can expose Flows and Apex actions as tools ^[33], and use per-user OAuth 2.0 with PKCE ^[33]. Salesforce's developer blog states that MCP tools run with the same permissions as the user who authenticated ^[34], that all MCP servers are inactive by default ^[34], and that a human remains in the loop to connect and grant access ^[34]. Activity is logged through Event Monitoring ^[34]. The local Salesforce DX MCP repository carries an end-of-life notice dated November 2, 2026 ^[35], so confirm which server a team's assistant actually uses.

Table 3 below frames what to confirm before using any AI-connected admin tool for this diagnosis. It lists the documented Salesforce option.

Table 3 supports one conclusion: tool support for Deliverability, logs and DNS must be checked per tool, because the permission model alone does not say what is visible. Any write, such as editing Flow metadata or a setting, still needs the same approval and read-back as a manual change.

Direction of travel

The trend in the sources is toward more explicit sender verification, not less. Winter '27 adds per-domain verification modes ^[3], sandbox domain copy ^[3] and a scheduled enforcement date for allowlist retirement ^[3]. Partners writing acceptance plans should expect that a sandbox test that passes today may need re-running after December 1, 2026, and should record the date of each test.

Frequently Asked Questions (FAQs)

Why did a Flow Send Email not arrive in a sandbox even though the Flow succeeded?

Success means the automation ran. Automation sends may show no error in the interface, and new or refreshed sandboxes default to System email only. Check the Deliverability level first, then verification, then the log.

What is the sandbox email deliverability access level?

It is the Access to Send Email setting, with the levels No access, System email only and All email. The default for a refreshed sandbox is System email only.

Why is a sandbox "system email only" while some emails still work?

System email only allows automatically generated emails, such as new user and password reset emails. That is why a password reset can work while a Flow's business email does not.

Does the Flow Send Email action need verification?

Yes. Salesforce requires domain-level and user-level verification, and the individual address must be verified in all cases.

How is a sending domain verified for Flow email?

Verification is required for each email-sending domain, using DKIM keys (recommended) or authorized email domains. Winter '27 can copy verified authorized domains into a sandbox.

Which org-wide email addresses qualify for the substitute-domain list?

For the substitute-domain list, only org-wide addresses with a verified address, a verified domain and use allowed for all profiles qualify. The Help pages on creating and verifying org-wide addresses did not render during this research, so the setup steps are not quoted here.

Do sandboxes change contact email addresses?

No. User addresses receive .invalid, while contact addresses are not modified.

Does a successful Debug run prove the email was sent?

No. Debug interacts with org data, but the current official text read does not say whether email is sent in debug or rollback modes. Record the mode and mark the behavior unknown unless the release documentation states it.

What goes to the mail administrator?

The send time and timezone, sender, recipient, Flow identifiers, test identifier and the Message ID of the D event, as Salesforce advises.

Conclusion

A missing Flow email in a Winter '27 sandbox is a three-stage question. Stage 1 asks whether the intended path and Send Email action actually ran, with the Flow version and test mode recorded and the debug mode's side-effect contract checked rather than assumed. Stage 2 asks whether Salesforce was authorized to send: the Deliverability level, the individual sender's verification, the sending domain's verification (or an approved substitute) and the state of sandbox addresses. Stage 3 asks whether an approved inbox received the message, which Salesforce's own log cannot answer and which belongs to the recipient's mail administrator when Salesforce shows the message left.

The most reliable method is one bounded, approved test with a controlled recipient, a three-stage evidence ledger and a read-back of every temporary change. Absent evidence is recorded as unknown. A completed Flow, a green debug run, an accepted send and a delivered message are four different facts, and the existing verification requirements, still being refined in Winter '27, make it more likely that the second and third are the ones that are missing. For the decision the audience faces, the ledger answers it directly: change the Flow only if Stage 1 fails, change sender or domain settings if Stage 2 fails, and call the mail administrator if Stage 2 passes and Stage 3 does not.