Website Form Emails Not Arriving? Trace the Delivery Path Before Changing Hosts

Quick answer: First establish whether the form accepted the submission, whether the application handed off an email, and whether the recipient’s mail server accepted it. These are separate checkpoints. WordPress explicitly warns that a successful wp_mail() return does not prove receipt; an email provider’s delivery event can mean acceptance by the recipient’s server, not placement in the inbox. Trace one controlled submission through those checkpoints before changing hosts. (developer.wordpress.org)

1. Map the delivery path and identify the missing checkpoint

For troubleshooting, divide the journey into four stages:

Browser → form application → sending service → recipient mail system

The sending service might be the web server’s mail system, a remote SMTP service or an email API. WordPress supports mail through its wrapper function, but a self-managed server needs a functioning mail environment or configuration for a remote SMTP server. (developer.wordpress.org)

Use this evidence map:

Checkpoint	Evidence to look for	What remains unproven
Submission accepted	Application response, submission identifier or saved entry where supported	That a notification was generated
Email handoff completed	Application mail result, SMTP response or API request identifier	That the recipient server accepted it
Recipient server accepted	Provider delivery event and remote server response	That it reached the inbox
Message located	Message found in the intended mailbox, spam folder or quarantine	That other recipients will receive future messages

WordPress documents the limitation of application-level success, while Amazon SES distinguishes successful send requests from recipient-server delivery. Treat the table as a diagnostic framework, not a promise that every tool exposes each checkpoint. (developer.wordpress.org)

Write down the last confirmed checkpoint. That is more useful than “email is broken” when asking a host, developer or mailbox administrator for help.

2. Run a controlled submission before changing settings

Prepare a small test that you can follow without exposing customer information.

Choose a mailbox you control. If possible, prepare a second controlled mailbox at a different provider.
Use synthetic names and a harmless message—no customer records, passwords or sensitive attachments.
Add a unique marker such as FORM-CHECK-A to a field included in the notification.
Record the submission time and timezone, form page, expected recipient and visible response.
Check the application’s entry or activity records, then the sending service’s events.
Search the recipient mailbox for the marker.

Test the actual public form as well as any mail connector’s built-in test function. Treat those as separate tests: one examines the complete workflow; the other may exercise only the mail connection.

Do not assume the form stores entries. Contact Form 7, for example, does not save submitted messages by default. Its documentation describes a separate storage option. Confirm your own form’s behavior before relying on a saved-entry check. (contactform7.com)

Before installing diagnostic plugins or modifying production configuration, preserve the current settings, take an appropriate backup and test in staging where feasible. Keep production tests small and send only to addresses you control.

3. Establish whether the form generated a notification

If you cannot find evidence that the application accepted the submission, start at the form—not DNS.

Inspect:

Required-field validation and the application’s response.
Spam or abuse-filter decisions.
Whether notifications are enabled.
The configured recipient and any conditional routing.
Template fields used in addresses or headers.
A pending notification job, if the application sends asynchronously.

A visible error does not necessarily identify a mail-transport failure. Contact Form 7 documents that the same error wording can appear for failed sending and detected spam. Use its diagnostic distinctions rather than interpreting the wording alone. Other form systems need their own documentation. (contactform7.com)

Check the notification configuration independently of the site’s general administrator settings. In Contact Form 7, the mail template has its own To, From, subject and additional-header fields. Verify the final values the template produces, especially when they contain form-field substitutions. (contactform7.com)

For WordPress, a true result from wp_mail() means the method processed the request without reporting an error. It does not establish that the recipient received the message. A plugin log labeled “sent” may therefore be evidence of handoff rather than final delivery; check what that label means in the plugin’s documentation. (developer.wordpress.org)

If the form never generates a notification, fix that stage first. Changing email authentication cannot repair a notification that was never created.

4. Check the connection between the website and sending service

Once the application attempts to send, inspect the transport result.

For SMTP, compare the configured endpoint, port, encryption mode and credential type with the provider’s instructions. These settings are not interchangeable. Amazon SES, for example, distinguishes STARTTLS from TLS Wrapper connections and requires encrypted connections. Its SMTP credentials are also different from ordinary AWS credentials. (docs.aws.amazon.com)

For an email API, record the response status and request or message identifier where available. Check whether the service reports a permission, sender-verification or sending-limit error.

Use the failure category to narrow the next action:

Observed failure	Practical next check
Connection timeout	Endpoint, outbound network access and host restrictions
Authentication failure	Credential type, validity and configured account
Permission or sender-verification rejection	Sending permissions and approved sending identity
Sending-limit response	Account quota and retry behavior

These categories appear in Amazon SES’s troubleshooting documentation; exact messages and remedies vary by provider. (docs.aws.amazon.com)

Protect SMTP passwords and API tokens during troubleshooting. Do not paste them into public tickets, screenshots, logs or AI chat prompts. Share redacted diagnostic fields instead.

Keep TLS and certificate verification enabled. Do not disable security checks merely to make a test pass. Ask the host to confirm the relevant outbound connection policy before considering a migration.

5. Read delivery events and bounces precisely

After the sending service accepts the message, follow its events using the message identifier.

Provider terminology matters. In Amazon SES:

Send means the request succeeded; delivery can still be suppressed.
Delivery means the recipient’s mail server accepted the message.
DeliveryDelay indicates a temporary delivery problem.
Bounce records a permanent rejection or a soft bounce after SES stops retrying.
Reject has a specific provider meaning: SES detected virus content and did not attempt recipient delivery. (docs.aws.amazon.com)

Do not assume another service uses these labels identically.

For a bounce or rejection, capture the affected recipient, timestamp, status and diagnostic text. For a delivery event, preserve the recipient and remote server response. SES event records expose these fields, allowing you to connect a submission to its downstream outcome. (docs.aws.amazon.com)

Read the complete response rather than guessing from “550” alone. Identify which server returned it and at which stage. An authentication failure from your sending service is different from a policy rejection by the recipient.

Avoid repeated manual resubmission while the provider is already retrying. For a permanent failure, investigate and correct the stated cause before another test. SES distinguishes permanent bounces from transient failures that may become deliverable after the underlying issue is resolved. (docs.aws.amazon.com)

Absence of an event is not conclusive. First verify that you are viewing the correct account, time range and event destination.

6. Verify sender identity before editing SPF, DKIM or DMARC

A common form configuration mistake is putting the visitor’s email address in From.

Prefer an authorized address on your sending domain for From, with the validated visitor address in Reply-To. Contact Form 7 specifically explains this approach: using another domain’s address as From can make a web-server-generated message appear spoofed, while Reply-To allows replies to reach the submitter. (contactform7.com)

The three authentication mechanisms answer different questions:

Mechanism	What it checks
SPF	Whether the connecting sender is authorized for the SMTP envelope domain, not simply the visible From address
DKIM	Whether a domain’s cryptographic signature validates for the signed message
DMARC	Whether a passing SPF or DKIM identity aligns with the visible From domain, and what policy the domain publishes

These distinctions come from the SPF, DKIM and DMARC specifications. Authentication is not an inbox-placement guarantee. (rfc-editor.org)

Before changing live DNS:

Export or document the existing records, names, values and TTLs.
Inventory legitimate senders, including staff mail, notifications and other services.
Obtain the exact records from the actual sending provider.
Identify which records will change and who can restore them.
Make the smallest necessary change.
Verify the published records and retest the real form.

Do not add a second SPF record at the same name as an existing one. The SPF specification prohibits multiple records that would be selected for the same authorization check. Review the existing policy rather than blindly adding another. (rfc-editor.org)

Do not weaken an established DMARC policy just to suppress an error. First examine alignment and the sending identity. Google’s guidance recommends authentication but explicitly does not guarantee that email providers’ messages will pass Gmail’s spam filters. (support.google.com)

7. Work through an illustrative trace

The following is a hypothetical diagnostic example, not a report of testing or a measured outcome.

Suppose a controlled submission produces this worksheet:

Test marker: FORM-CHECK-A
Form response: accepted
Notification recipient: controlled mailbox
Application handoff: completed
Provider message ID: [redacted]
Provider event: Delivery
Recipient-server response: accepted
Mailbox location: spam folder

For a provider whose Delivery event means recipient-server acceptance, the evidence points to inbox placement, not a failed website-to-mail-service connection. Amazon SES documents that distinction. (docs.aws.amazon.com)

The next checks would be the received message’s authentication results, From identity, mailbox filtering and message content—not an immediate host migration.

Now change one observation:

Application handoff: failed
Transport response: authentication credentials invalid
Provider delivery event: none located

That points earlier in the path. Validate the sending credentials and connection configuration first. SES documents invalid SMTP credentials as a transport authentication error. (docs.aws.amazon.com)

A third pattern—accepted submission but no notification attempt—calls for application investigation. It does not establish a sending-provider fault.

Keep evidence minimal: identifiers, timestamps, event categories and redacted errors. There is usually no need to circulate the full submitted message.

8. Investigate inbox placement, then decide whether hosting is involved

When recipient-server acceptance is confirmed, ask the mailbox owner or administrator to check spam, quarantine, rules and message tracing where available. Compare the intended recipient with the address in the delivery event.

In Gmail, inspect the full message headers through Show original to see authentication results. Google’s sender guidance describes checking authentication and notes that legitimate messages can still be marked as spam. (support.google.com)

Use these practical checks:

Search all relevant folders for the unique test marker.
Check each recipient separately.
Compare actual form messages, not just connector tests.
Retest with a second controlled mailbox, without treating success there as proof of universal delivery.
Change one setting at a time and keep a recovery record.

Consider hosting changes only when evidence connects the failure to the hosting environment—for example, an outbound connection restriction or an unavailable local mail service. WordPress and SES documentation describe these infrastructure dependencies. A remote SMTP service may address a local-mail limitation without moving the website. (developer.wordpress.org)

For escalation, provide the last confirmed checkpoint, timestamp and timezone, redacted message identifier, affected recipient domain and exact error. Leave credentials and personal form content out.

The decision rule is simple: repair the first unconfirmed handoff. Host migration is a possible infrastructure decision, not a substitute for identifying where the message stopped.