WordPress email and SMTP errors: trace delivery failures
- Word press
- September 5, 2025
Table of contents
When WordPress emails do not arrive, first locate the break in the journey: did the site generate the message, did the sending service accept it, or did the recipient’s system filter it? Installing a different SMTP plugin before answering that question can leave the underlying problem unchanged.
This guide diagnoses forms, notifications and transactional messages. Transport configuration is one stage in that process. A successful SMTP test does not establish that every site feature generates the correct notification.
Separate generation, submission and delivery
| Stage | Useful evidence |
|---|---|
| Application event creates a notification | Plugin configuration and event record |
| WordPress passes the message to the mail system | Application result or integration log |
| Sending service accepts the message | SMTP response or provider message identifier |
| Recipient server handles it | Delivery, rejection or deferral status from the provider |
| Message appears in the mailbox | Recipient check, spam folder and mailbox rules |
The wp_mail() documentation explicitly distinguishes a successful return value from confirmed receipt. Follow the evidence across stages instead of asking the SMTP plugin alone to prove the entire journey.
Investigate notifications that are never generated
Perform one action using an address you control and record the time. Check that the notification is enabled, its recipient is correct and any conditional rules are satisfied. An on-screen confirmation does not prove email delivery.
Determine whether every email fails or only one feature. If the transport test works but the form produces no send event, investigate the form’s settings and logs. If the feature queues messages, check that the scheduled work runs before changing SMTP credentials.
For a hypothetical order notification configured to run after a status transition, repeating the SMTP test does not trigger that business rule. Reproduce the required event and inspect its outcome.
This separation is useful when several plugins send messages through the same transport. A failure limited to one notification has a different starting point from a site-wide connection error.
Interpret SMTP errors before changing settings
Keep the complete response code and message, removing credentials, tokens and personal data. The SMTP standard distinguishes temporary 4xx conditions from permanent 5xx rejection of the attempt. The response text and provider documentation explain the particular reason.
| Observation | Next check |
|---|---|
| Connection refused or timed out | Host, port, outbound network access and service status |
| Authentication failure | Account, configured secret and required authentication method |
| TLS negotiation failure | Supported combination of host, port and encryption |
| Sender not authorised | Verified address or domain in the sending account |
| Quota or rate limit reached | Account limits, sending frequency and queue handling |
Use the provider’s specified configuration rather than trying random ports and encryption modes. Some services require a particular authentication method; a webmail password may not be the credential expected by the integration.
Disabling certificate verification is not a routine fix. Resolve the certificate, connection or configuration problem at the corresponding layer.
Trace messages accepted by the sending service
Find the message identifier in the provider’s dashboard. Distinguish initial acceptance, deferral, rejection and delivery to the remote server. Remote acceptance still does not establish inbox placement because recipient filters and rules can intervene.
Check spam, incorrect addresses and any provider suppression list. Preserve bounce reasons before retrying. Repeated resubmissions can create duplicates when a temporary condition clears.
For contact forms, use an authorised website sender and place the visitor’s address in the integration’s appropriate reply field. Do not assume the site can authenticate mail as any domain entered by a visitor.
A useful incident record links one controlled form submission to one provider event and the recipient’s observation. Without that link, it is easy to compare a successful test with an unrelated missing notification.
Check domain authentication and received headers
SPF, DKIM and DMARC concern message authorisation and authentication. Review DNS records and the headers of an actually received message against the sending provider’s instructions. Assess the visible sender domain against DMARC alignment requirements as well.
The official Gmail sender guidelines describe requirements and sending conditions. Authentication is an important check, but it does not guarantee primary-inbox placement for every message.
Before editing DNS, inventory every service sending for the domain: company email, the website and other platforms. Correcting WordPress delivery must not exclude another authorised sender.
Test the actual notification after the fix
Run both the transport test and the application action: form submission, password recovery or an order notification in an appropriate test environment. Check recipient, sender, reply address, links and attachments where applicable. Use controlled mailboxes rather than sending test messages to customers.
Match logs with receipt and look for duplicate sends, including those caused by two active integrations. Retain only the logging data needed for diagnosis; message bodies and password-reset tokens should not become an unnecessarily accessible technical archive.
If site emails remain missing, I can trace the WordPress sending process and establish whether the intervention belongs in the form, transport or domain authentication configuration.
