Free 10-minute diagnostic
Contact form says sent. No email arrives.
Do not start by swapping plugins or editing DNS. First locate the last layer with repeatable evidence: browser, handler, mailer, provider, or mailbox.
No login - no scan - no customer data - no delivery promise
The evidence chain
A green message is only one checkpoint.
- 01Browser accepted
The page received a response it chose to display as success.
- 02Handler processed
The server validated and handled exactly one request.
- 03Mailer processed
The application handed a controlled message to its mail layer.
- 04Provider accepted
The configured provider accepted, rejected, or deferred that test message.
- 05Mailbox received
The controlled destination can actually show the message.
10-minute checklist
Find the last proven layer.
Use controlled test data. Record outcomes, not passwords, production secrets, or customer messages.
- 01
Reproduce once
Use one controlled sender and destination. Record the exact time, page, visible result, and whether retrying creates a duplicate.
- 02
Check the browser result
Confirm that the network request finishes and the on-page message matches the response. A spinner, generic success, or swallowed error is a frontend clue - not delivery proof.
- 03
Check server evidence
Look for one receipt, record, or bounded processing event for the same timestamp. No record points upstream; multiple records point to retry or idempotency problems.
- 04
Separate mailer acceptance from receipt
Record whether the application mail layer accepted or rejected the controlled message. Do not call acceptance a delivered email.
- 05
Check provider and mailbox states
Use the authorized provider event state when available, then check spam, quarantine, routing rules, and a second controlled destination. Do not change DNS or mailbox settings without owner approval.
Evidence map
What each checkpoint proves - and does not prove.
| Layer | Useful evidence | Still unproven |
|---|---|---|
| Browser | One timestamped request and its visible result | The page can claim success before downstream work finishes |
| Handler | One stored record, receipt, or explicit processing result | The request can fail, retry, or duplicate after the button click |
| Mailer | A bounded success or failure event without message content | Mailer acceptance is not inbox receipt |
| Provider | A delivery-event or rejection state for controlled test mail | The provider can reject or defer after application acceptance |
| Mailbox | The controlled message is visible in the expected folder | Filtering, quarantine, or rules can hide an accepted message |
WordPress-specific trap
wp_mail() returning true is not inbox proof.
WordPress documents that a true result means the configured method processed the request without errors; it does not establish that the recipient received the message. The same limit applies to the wp_mail_succeeded action.
Official wp_mail() reference ->Official success-hook reference ->
Stop before changing production
Escalate instead of guessing when:
- there is no verified backup or rollback path;
- the test would expose customer data, passwords, tokens, or mailbox access;
- the form handles regulated or sensitive information;
- site, DNS, provider, or mailbox authority is unclear.
Still missing the break?
Buy the diagnosis before buying the repair.
The $49 diagnosis maps one reproducible path, names the last proven layer, and returns a written repair recommendation. A $149 repair starts only after scope, funding, authorized access, and rollback are agreed.
Describe the missing email