WordPress Contact Form Emails Not Sending: A Practical SMTP and DNS Diagnostic Guide

When a WordPress contact form says it was submitted but no notification appears, it is tempting to treat the whole process as one failed action. It is not one action. A form can save an inquiry correctly while its email fails later. An SMTP provider can accept a message while the recipient server rejects it. A recipient server can accept a message and still place it in quarantine or spam.

The fastest reliable investigation follows the message from one boundary to the next. It does not begin by changing several plugins, DNS records, and mailbox settings at once.

Quick diagnostic: where to look first

Start with the symptom you can actually observe, then collect evidence at the nearest boundary. Do not change DNS or SMTP settings until the earlier stages are understood.

Start with the right distinction

There are at least five separate questions:

1. Did the browser submit the form successfully?
2. Did the form plugin handle the submission, and was submission storage enabled?
3. Did WordPress create the intended message and pass it to a mail transport?
4. Did the sending and receiving mail servers accept the message?
5. Did the receiving mailbox place it where the user expected?

The answer can be yes at one stage and no at the next.

WordPress documents that a true result from wp_mail() means only that the selected method processed the request without an error. It does not mean the recipient received the message. Elementor makes a similar distinction in practice: its Form Submissions feature can preserve a form entry in WordPress even when a notification email needs separate investigation.

This distinction prevents a common diagnostic mistake: rebuilding a form that already stores submissions when the actual failure is an unauthenticated sender, blocked SMTP connection, recipient rejection, or mailbox rule.

Map the delivery path

WordPress does not operate a complete mail delivery service. Its mail administration handbook explains that WordPress formats a message and submits it through a mailing interface. By default, wp_mail() uses PHPMailer and commonly relies on the server's local mail environment. A mail plugin can instead configure PHPMailer for authenticated SMTP or send through a provider API.

A typical notification path is:

1. The visitor submits the form.
2. The form plugin validates fields and runs its configured actions.
3. The plugin asks WordPress to create a notification.
4. WordPress and PHPMailer hand the message to local mail, an SMTP server, or a provider integration.
5. The sending service attempts delivery to the recipient's mail server.
6. The recipient's system accepts, delays, or rejects the message.
7. Mailbox filtering decides whether an accepted message appears in the inbox, spam, quarantine, or another folder.

Write this path down for the affected website. Record the form plugin, transport plugin or integration, sending provider, From domain, recipient domain, and who controls each account. A configuration cannot be verified if nobody knows which service is actually sending.

Check the form before SMTP

Start at the form because it is the earliest boundary and usually the easiest one to observe.

Confirm that the submission exists

If the form plugin stores entries, submit a controlled test with a unique reference that contains no personal or confidential information. For Elementor Pro, first confirm that Collect Submissions is present in Actions After Submit and that form submission storage has not been disabled under Elementor settings. Then look under Elementor Submissions. A saved entry shows that the browser request reached Elementor and that the form handler stored the data. It does not show that the email action ran successfully.

Elementor documents that Collect Submissions is active by default, but it can be removed from a form or disabled in Elementor settings. It may also be unavailable in a different plugin, product tier, or form implementation. A missing stored entry is therefore not proof that submission failed. It becomes useful failure evidence only when storage is available, enabled, and expected for that form.

If storage is confirmed as active but a controlled test entry is missing, investigate the form before SMTP:

• Check browser and server errors at the time of submission.
• Confirm required fields, field identifiers, validation rules, and spam protection behavior.
• Confirm that the intended actions after submit are enabled.
• Test for a plugin or theme conflict only in a safe environment or controlled maintenance window.

Elementor's form widget documentation describes separate settings for the recipient, subject, message, From address, From name, Reply To address, and message format. Each can affect the generated notification.

Separate the sender from the visitor

The visible From address should normally be a stable address on a domain authorized for the sending service. The visitor's submitted address belongs in Reply To when the form workflow requires replies to reach that visitor.

Using a visitor supplied Gmail, Outlook, or company address as the From address asks the website to send as a domain it does not control. That can create SPF, DKIM, and DMARC alignment failures and can look like spoofing. Elementor's server error guidance likewise recommends a From address on the website's own domain and the visitor address in Reply To.

Also confirm:

• The To address is typed correctly and still exists.
• The form's email action is enabled, not only a redirect or integration action.
• The message template references valid field identifiers.
• A second email action, such as a visitor confirmation, is tested separately from the internal notification.
• No automation or integration is replacing the expected email action.

If one notification arrives and another does not, compare their recipient, From, Reply To, subject, and conditional settings. They are separate messages and can fail for different reasons.

Verify SMTP and sender configuration

Authenticated SMTP can replace an unreliable local mail path, but an SMTP plugin alone does not make the configuration correct. The settings must match the actual provider and verified sender identity.

Port 587 is commonly used for message submission with STARTTLS, while port 465 is registered for implicit TLS submission. The relevant standard, RFC 8314, recommends TLS for email submission and access. Do not choose a port or encryption mode by habit. Use the exact combination documented by the provider because selecting implicit TLS on a STARTTLS endpoint, or the reverse, can prevent a connection.

Credentials also vary. A provider may require a full mailbox address, an application password, an SMTP specific credential, OAuth, or an API key used through its own integration. Never paste credentials into public diagnostics, screenshots, support forums, source control, or form content. If a secret may have been exposed, rotate it through the provider.

Avoid running multiple mail plugins that both alter wp_mail() or PHPMailer. Conflicting transports, From overrides, and logging layers can make the active path unclear. Keep one intentional transport and record its configuration owner.

Hosting restrictions can interrupt the path

When WordPress produces no provider event, the website may be unable to reach the configured transport. Ask the host for evidence about:

• Whether local PHP mail or a sendmail compatible service is available.
• Whether outbound connections to the provider's SMTP host and port are permitted.
• Whether a firewall, security policy, or hosting rule blocks the connection.
• Whether the server can resolve the SMTP hostname through DNS.
• Whether current TLS libraries and certificate validation support the provider.
• Whether a platform level mail limit or suspension applies.

Do not disable TLS verification or security controls as a permanent workaround. A certificate or hostname error is evidence to correct the endpoint, server clock, trust store, or hosting environment.

Read SPF, DKIM, and DMARC correctly

SPF, DKIM, and DMARC answer related but different questions. None of them guarantees inbox placement.

SPF authorizes sending sources

SPF lets a domain publish which hosts are authorized to use that domain in the SMTP MAIL FROM or HELO identity. The visible From address in an email client is a different identity.

Important limits:

• SPF authenticates a domain used during SMTP, not the person shown in the message From field.
• Forwarding can break SPF because the forwarding server may not be authorized by the original domain.
• A domain must not publish multiple competing SPF records. Combine legitimate senders into one correctly constructed policy.
• Adding an include without understanding every existing sender can interrupt mail from other services.

DKIM signs a message with a domain

DKIM adds a cryptographic signature. A receiving system retrieves the public key from a selector under the signing domain and checks whether the signed parts of the message still validate.

A DKIM pass shows that a valid signature associated with the d= signing domain survived verification. It does not by itself prove that the visible From domain is the same domain or that the message belongs in the inbox.

DMARC evaluates authentication and alignment

DMARC connects SPF and DKIM results to the domain in the visible From header. A message passes DMARC when at least one relevant SPF or DKIM result passes and its authenticated domain aligns with the From domain under the domain's configured alignment mode.

This is why spf=pass can appear beside dmarc=fail: SPF may pass for a provider controlled Return Path domain that is not aligned with the visible From domain. DKIM can have the same problem when the provider signs only with its own domain.

RFC 9989 also makes an important limitation explicit: a DMARC pass validates authorized use of the author domain. It does not guarantee that the message is safe, wanted, or destined for the inbox. Recipient reputation systems, content evaluation, user rules, and local policy still apply.

Read the published DNS records without changing them

The following commands perform public DNS lookups. Replace example.com with the sending domain. Replace selector1 with the selector supplied by the sending provider.

dig TXT example.com
dig TXT selector1._domainkey.example.com
dig TXT _dmarc.example.com

On systems where dig is unavailable, nslookup can query the same TXT records:

nslookup -type=TXT example.com
nslookup -type=TXT selector1._domainkey.example.com
nslookup -type=TXT _dmarc.example.com

These lookups show what DNS currently publishes. They do not prove that a specific message used that sender, carried the expected DKIM selector, or passed alignment. Use the actual message headers and provider event for that.

Do not copy a generic SPF, DKIM, or DMARC record into production DNS. Obtain required values from the provider, inventory all legitimate senders for the domain, and plan a safe rollout. An incorrect record can affect business mail, marketing systems, support platforms, invoicing tools, and website notifications beyond the form being investigated.

Use provider logs as evidence

A sending provider's activity log is often the most useful dividing line in the investigation. Search by the controlled test recipient, timestamp, message identifier, or unique subject reference.

Status names vary, but the evidence usually means:

• No provider record: WordPress may not have invoked the intended transport, the transport may be misconfigured, or the website may be blocked before it reaches the provider.
• Rejected before queueing: Check authentication, account state, sender verification, request format, permissions, or provider policy.
• Accepted or queued: The provider accepted the request, but has not yet proved recipient server acceptance.
• Delayed: The provider is retrying after a temporary response or connection problem. Preserve the response code and reason.
• Bounced or failed: Read the SMTP response. An unknown recipient, policy rejection, authentication failure, and temporary mailbox problem require different action.
• Delivered: The recipient server returned an acceptance response. This is strong evidence of server handoff, not proof of final inbox placement.

Postmark's delivery documentation explicitly distinguishes recipient server acceptance from inbox placement. Other providers may use different names, so read that provider's definition rather than assuming every “sent” or “delivered” label means the same thing.

Preserve the provider message identifier and exact SMTP response. A response such as 550 5.1.1 can indicate a nonexistent recipient, while other 550 responses can reflect policy, authentication, or content decisions. The full enhanced status and provider explanation matter more than the first three digits alone.

Check the receiving mailbox

If the provider records recipient server acceptance, move the investigation to the receiving environment.

Check:

• Spam, junk, quarantine, focused inbox, and other filtered folders.
• Inbox and transport rules that move, redirect, or delete messages.
• Shared mailbox permissions, aliases, forwarding, and distribution group restrictions.
• Mailbox capacity, disabled accounts, and recently changed addresses.
• Organization wide security tools or gateways that quarantine mail before the mailbox sees it.
• Message trace or email log search in the recipient's Google Workspace or Microsoft 365 administration system, when authorized access is available.

If an actual message copy is available in the inbox, spam, quarantine, or another controlled mailbox, inspect its full headers. Look for Authentication-Results, the visible From, Return-Path, DKIM d= domain and selector, and the chain of Received headers. If no copy is available, there are no final recipient headers to inspect. Use the sending provider's event and the recipient administrator's message trace instead. Google publishes current sender guidelines covering authentication, alignment, TLS, and related sending requirements. Microsoft explains how SPF, DKIM, and DMARC work together in Microsoft 365.

Do not create a broad allow rule as the first fix. An allow rule can hide an authentication or identity problem, reduce protection, and apply more widely than intended. Correct the sending identity and transport where possible, then use narrowly scoped recipient controls only when there is a documented business reason.

Test safely and change one variable

A good test is small, repeatable, and observable.

1. Record the current configuration without copying secrets into notes.
2. Confirm that production submissions are stored or otherwise protected.
3. Choose a recipient mailbox you are authorized to inspect.
4. Use a unique subject reference such as FORM TEST YYYYMMDD HHMM UTC.
5. Submit neutral content with no customer or confidential information.
6. Record whether the form stored the entry.
7. Record the WordPress mail event or error.
8. Record the provider event and message identifier.
9. If accepted, inspect recipient trace, quarantine, and message headers.
10. Change only one relevant setting, then repeat with a new reference.

Do not send repeated tests to random addresses. Do not use a list of real customers. Do not switch DNS, transport plugins, From identities, and encryption settings in one attempt. Multiple simultaneous changes destroy the evidence that identifies the cause and can introduce a second failure.

A test is complete only when its result answers a defined question. “The plugin said sent” is not enough. “The form stored the entry, the provider accepted message ID X, the recipient server accepted it, and the controlled mailbox received it with aligned DKIM” is much stronger evidence, while still not guaranteeing future inbox placement.

WordPress email troubleshooting sequence

Work downward until the first stage without supporting evidence. Investigate that boundary before changing anything later in the path.

Know when to stop

Stop making changes and request qualified assistance when:

• A live form may be losing enquiries and no reliable submission store exists.
• Nobody can identify the active transport or account owner.
• SMTP credentials, API keys, or private message data may have been exposed.
• The website appears compromised or sends mail that nobody authorized.
• DNS changes could affect several business systems and the full sender inventory is unknown.
• Delivery fails only for one organization and its mail administrator needs to inspect a trace or policy.
• Server logs show recurring connection, TLS, or firewall errors that require hosting access.
• A migration changed the From domain, Return Path, DKIM selector, DNS provider, or receiving mailbox.
• The apparent fix depends on disabling authentication, certificate validation, spam protection, or security controls.

Cubehawk provides WordPress troubleshooting, maintenance, and security support for businesses that need help tracing the active mail path, interpreting provider evidence, correcting configuration, and planning changes without treating every missing notification as the same problem.

No configuration can guarantee inbox placement. The practical goal is to establish an authenticated, observable delivery path, preserve submissions independently of email where appropriate, and retain enough evidence to locate future failures quickly.