WordPress email failures need a trace through the whole delivery path: the form or order event, wp_mail(), the configured transport, the sending provider and the receiving mailbox. A successful form submission proves that the application accepted the request. It does not prove that the notification arrived. Start with one controlled message and follow its identifiers before changing plugins or DNS.
How to find which WordPress emails are not being sent
Record the affected workflow, recipient, timestamp with timezone and the last known successful delivery. Separate contact notifications, password resets, order confirmations and marketing campaigns. They can use different templates, hooks and transports on the same installation. If only order confirmations fail, changing global SMTP settings can disrupt mail that already works while leaving the actual WooCommerce event problem untouched.
First check whether the application attempted to send. A form can validate and save successfully without invoking the notification action. A payment callback can arrive after the browser closes. An order can remain in a status for which the relevant email is disabled. Inspect the workflow configuration and its event log, then compare a direct transport test with an actual user action. A plugin’s test button bypasses part of that business logic.
The WordPress reference for wp_mail() explains that a successful return value does not establish recipient delivery. Treat it as a handoff result. In your incident notes, keep application acceptance, provider acceptance and mailbox receipt as separate observations. Without that distinction, a reassuring green status can hide a rejection that happened several seconds later.
Use a controlled address belonging to the team. Do not send test messages to customers or place real personal information in sample forms. Include a recognisable reference in the subject so the recipient can find the exact message. If the site has a staging copy, verify that it sends to an approved test destination rather than forwarding copied customer addresses.
How to choose an SMTP plugin and sending service for WordPress
An SMTP plugin configures how WordPress hands mail to a service. It is not itself a mailbox provider or an allowance of monthly messages. FluentSMTP and WP Mail SMTP are examples of integration plugins; the sending account determines quotas, authorised domains, retention and support. Compare the integration available in your installed version with your provider’s current documentation before selecting it.
Keep one active component in charge of the transport. Two plugins modifying PHPMailer or intercepting wp_mail() can overwrite sender settings or route different messages unpredictably. Check must-use plugins and custom theme code as well as the visible plugin list. Disable a competing integration only after recording its configuration and confirming whether another workflow depends on it.
For authenticated SMTP, obtain the hostname, port, encryption mode and authentication method from the provider. Port 465 usually means TLS from the start; port 587 commonly uses STARTTLS. Match the service’s actual instructions rather than pairing a port with whatever option makes a test appear to work. A TLS certificate problem should be repaired, not hidden by disabling certificate verification.
An API integration can give you structured responses and provider event identifiers. SMTP can also be suitable for transactional mail. Neither transport guarantees inbox placement, and an HTTP API is not automatically instantaneous or immune to rate limits. Decide using supported authentication, event visibility, credential rotation and the provider’s handling of delivery failures. Avoid ranking providers by unmeasured claims about speed or deliverability.
How to keep SMTP credentials safe on production and staging
Create credentials for the website’s sending task where the provider supports that scope. Do not reuse a staff member’s everyday mailbox password across production, staging and local development. If an integration supports secrets outside the database, follow its documented mechanism and restrict access to the deployment environment. A constant with a guessed name is not a configuration contract.
Treat database backups and configuration exports as potentially sensitive. Some plugins store mail credentials or message bodies in settings and logs. Limit administrative access, exclude secrets from screenshots and check whether support bundles redact them. Rotate a credential that has appeared in a repository, shared ticket or copied production database; deleting the visible copy does not revoke access.
Staging needs a deliberate delivery policy. Use a separate account or a mail capture service, and prevent production recipients from receiving test orders. After a deployment, verify which environment supplies credentials and sender settings. Copying a staging database over production can silently replace the sending account even when the DNS configuration remains correct.
What is the difference between From, Return-Path and the DKIM domain
The visible From address, the envelope sender used for bounces and the DKIM signing domain are separate identities. SPF evaluates the sending infrastructure against the envelope domain. DKIM validates a message signature for its signing domain. DMARC considers whether a passing SPF or DKIM result aligns with the visible From domain. One aligned passing mechanism can satisfy DMARC; it is inaccurate to describe DMARC as failing whenever either mechanism fails.
Use an address from a domain that the organisation controls and that the sending service has verified. Put the visitor’s validated email in Reply-To for a contact form. Using the visitor as From asks your infrastructure to impersonate a domain whose authentication policy you do not control. It also makes diagnosis harder because each submission can introduce a different sender domain.
For Contact Form 7, review the mail configuration documentation and check the actual mail tags configured in that form. Keep the organisational sender stable, map the reply address to the intended field and verify that required fields cannot be omitted. Test both the administrator notification and any visitor confirmation because they are separate messages with separate recipients.
How to set up SPF, DKIM and DMARC for WordPress
Inventory every legitimate sender before editing SPF: the website, staff mail, invoicing platform and marketing service. Publish one SPF record for each relevant domain name, combining authorised mechanisms according to provider instructions. Do not create a second v=spf1 record alongside the existing one. The SPF specification also limits DNS-dependent evaluation, so adding includes indefinitely is not a sustainable fix.
Copy DKIM names and values from the sending service. Some services request a TXT record, others provide CNAME records pointing to managed keys. The selector belongs in the record name and need not be default. Check the fully qualified name after saving; DNS panels differ in whether they append the zone automatically. A duplicated domain suffix creates a record that looks correct in the panel but cannot be found by recipients.
For DMARC, begin with monitoring when you have not yet established which services send legitimate mail. Read aggregate reports and confirm alignment across those services before enforcing quarantine or rejection. A policy change can affect invoices and employee mail, not just WordPress. The DMARC specification describes alignment and policy handling; provider dashboards can help interpret reports without replacing the underlying DNS check.
When SPF and DKIM both show pass and DMARC still fails, the checks passed for domains other than the visible sender. Open the source of a received message (in Gmail, Show original) and compare the domains in the Authentication-Results header: smtp.mailfrom for SPF, header.i or header.d for DKIM and header.from for the address the recipient sees. If neither of the first two shares the organisational domain of header.from, DMARC has no aligned result to accept. Mailfully’s guide SPF, DKIM and DMARC setup, step by step, published in October 2026, adds two checks to run at the same time. On Cloudflare, keep DKIM CNAME records set to DNS only (grey cloud): Cloudflare’s proxy documentation lists email records among those its HTTP proxy does not support. A sending subdomain without its own _dmarc record falls back to the record at the organisational domain, which can set a subdomain policy with sp= (RFC 7489, section 6.6.3). Check what the subdomain already inherits before you publish a weaker p=none for it.
Do not paste an example containing a different organisation’s include or reporting mailbox. Keep a change record with the previous value, the requested new value, the responsible administrator and the verification result. DNS caching means an updated control panel is not proof that all resolvers already see the new record. Query the authoritative records and repeat the mailbox test after the change has propagated.
What WordPress SMTP errors mean and where to look
| Observation | Investigation |
|---|---|
| No application mail event | Form actions, order status, hooks and disabled templates |
| Connection timeout | Outbound firewall, hostname, port and provider availability |
| Authentication rejected | Credential, permitted method, account state and rotation |
| Provider accepted, recipient absent | Delivery event, suppression, bounce and mailbox filtering |
| Inbox receipt but broken message | Template, encoding, links and attachment handling |
A timeout happens before recipient filtering. Inspect outbound connectivity from the same runtime that serves WordPress; a laptop reaching the service proves little about the hosting firewall. Record the error code and elapsed time without logging the authentication exchange. Ask the hosting operator about permitted submission ports when the network is the first failing layer.
An authentication failure needs the provider’s account view. Check whether the credential expired, a security policy changed or the account requires OAuth rather than a password. Repeated retries with the same invalid credential can add noise and trigger restrictions. Repair authentication first, then make one controlled test through the application.
If the provider accepted the message, look for its delivery or bounce event using the timestamp and recipient. An accepted message can later be rejected, deferred or suppressed. A delivered event generally means the recipient’s server accepted it; it still does not prove that a person saw it in the inbox. Inspect the received message headers when it is available rather than relying solely on a dashboard summary.
How to resend failed WordPress emails without duplicate orders
Distinguish temporary failures from permanent ones using the provider’s documented status codes. A temporary service problem can justify a bounded retry. An invalid recipient or a suppression caused by a hard bounce needs investigation, not endless resending. Define a maximum retry policy and an alert for messages that remain unsuccessful after it ends.
Timeouts create an awkward state: the sending service may have accepted a request before WordPress lost the response. Blindly sending the same confirmation again can produce duplicates. Associate the delivery attempt with a business event, preserve the provider identifier when available and check whether the service supports idempotency. Do not assume that changing SMTP plugins will deduplicate previously queued messages.
For WooCommerce, agree which notifications are business critical and how staff recover them. The order itself should remain the source of truth for fulfilment. A missing email must not erase an order, and replaying a notification must not charge the customer again. During recovery, resend only the affected notification after verifying its state and recipient.
If background jobs perform delivery, monitor that queue as a separate component. A functioning SMTP connection cannot help a job that never runs. Check the scheduler, stuck jobs and the environment responsible for executing them. Avoid turning synchronous form submissions into a home-made queue without a clear retry, retention and observability design.
What to keep in WordPress email logs and who should get alerts
Record workflow type, event identifier, send time, provider identifier and status. Full message bodies are rarely necessary for proving whether delivery occurred. Password-reset links, customer addresses and order contents require stricter access and retention than an operational status record. Choose logging settings intentionally, then verify that deletion and backup policies cover those logs too.
Alert on a meaningful failure pattern such as repeated authentication errors or a stopped critical workflow. A daily synthetic test can detect transport trouble, but it will not exercise every order state or form configuration. Supplement it with periodic workflow tests and make sure someone owns the alert. Notifications sent through the same broken mail route are a poor incident channel.
Check Gmail’s sender guidelines when Gmail is a relevant destination. Authentication requirements differ between ordinary and bulk senders, and marketing subscription messages have additional requirements. Do not infer that a transactional order confirmation needs exactly the same handling as a newsletter, or that adding authentication obliges a recipient to accept unwanted mail.
Why contact form enquiries get lost even when the email is sent
An SMTP setup can be flawless and enquiries can still be lost. In July 2026 a web developer described on r/Wordpress how form notifications cost him a client. After a call from someone whose message never arrived, he checked the stored submissions, the form log, the SMTP plugin log and the sending service’s dashboard: everything had been sent and delivered. The cause was somewhere else:
That’s when I discover that the staff member receiving the emails left three months ago.
Later in the same thread he added that no deliverability measure on the DNS side would have helped here: “The leads were arriving, just at an inbox that didn’t exist.” (r/Wordpress).
Which address should contact form messages go to
The most common advice in the thread is an address the business owns rather than one person’s mailbox, such as a client-owned role address or group with at least two members (r/Wordpress). Another agency adds a second notification to a shared inbox that several people can access, as a backup for staff changes (r/Wordpress). In WordPress this means two addresses in the form’s notification settings instead of one.
How to check that a WordPress contact form is working
The SMTP plugin log only confirms that the message left the server. A test submission sent through the form on a fixed schedule, for example once a week, checks the whole path, although, as the author of that advice points out, it “still cannot tell you whether a human read the lead” (r/Wordpress). The second method from the thread is a monthly report of all form submissions, compared with the previous month and sent to the client (r/Wordpress). The report shows enquiries that came in but that nobody answered.
Do SPF, DKIM and DMARC make sure form emails arrive
No. The DNS records described above decide whether the recipient’s mailbox accepts the message, but they cannot tell whether anyone reads that mailbox. Participants in the thread list both causes side by side: increasingly strict anti-spam measures and clients changing who is supposed to receive the emails (r/Wordpress).
What to do when the employee who received enquiries leaves
Add the notification recipient address to the offboarding checklist, next to accounts, passwords and access rights. In the site handover, record who receives the submissions, who is the backup and who must tell the site’s developer when either of them leaves (r/Wordpress). If the form stores submissions in the database, check after such a change whether unanswered enquiries from recent weeks are waiting in the dashboard.
How to test WordPress email after fixing it
For a UK shop serving customers in other languages, test the actual localised templates as well as the generic transport message. Currency symbols, product names and accented customer names can expose encoding faults. Verify that links retain the intended locale and the production hostname. A successfully delivered password-reset message pointing to staging is still a broken workflow. Also check whether attachments are required for that notification: a large attachment can hit a provider limit even when a plain test succeeds. Record the applicable limit from the account configuration rather than assuming every route accepts the same payload.
Run a transport test, submit the contact form, request a password reset for a test account and create an approved test order if the site sells products. Include the recipient domain that originally failed and another independent destination. Record whether each message was generated, accepted and received, and inspect authentication results on the received copy.
Check mobile rendering, reply behaviour, links and attachments before closing the incident. A deliverable message with the wrong reply address still breaks the contact process. Remove diagnostic hooks, revoke temporary credentials and retain a short runbook showing the provider owner, DNS owner and recovery steps. Repeat these checks after a host migration, sender-domain change or credential rotation.
For WordPress development and maintenance, send the affected workflow, approximate failure time and redacted error details in the project email. Those details let the investigation start at the failing layer while keeping customer data and credentials out of the conversation.







