Contact Form Not Sending Email? How to Find and Fix the Problem

Find where contact form notifications go missing: test submissions, sending services, inbox filters, SPF and DKIM, then verify delivery.

If your contact form is not sending email, first find the handoff where the enquiry stops. A submission can fail in the visitor’s browser, be rejected by the website, remain saved without a notification, or be accepted by an email provider and then filtered. A success message alone does not prove that the email reached your inbox. This guide gives business owners a practical order of checks for WordPress and custom websites.

Key takeaways

• Send one identifiable test and track it from the form through to the recipient inbox.
• Check stored submissions and provider logs before changing DNS or installing a plugin.
• Use an authorized sender address and place the visitor’s address in Reply-To.
• SPF, DKIM and DMARC help authenticate mail; they do not fix a form that never submits.
• Keep a second way to recover enquiries, with sensible access controls and retention.

Start with one traceable test

Use an address you control and a harmless message such as CONTACT-TEST-06. Record the date and time, page URL, device and browser. Submit the form once and note the exact message shown. If you have a staging site, test there first; if the issue affects real enquiries, a clearly identified production test is useful too. Never enter real customer or sensitive information for a test.

Follow the enquiry through four handoffs

• Browser — Does the form accept the fields and send a request? Record validation or network errors.
• Website — Does the server accept the request and save a submission or lead?
• Sending service — Was a notification created and accepted, queued, rejected or bounced?
• Inbox — Did the receiving mailbox accept it, filter it, forward it or reject it?

Start at the earliest missing handoff; changing later stages cannot repair an earlier failure.

Temporarily display a phone number or another monitored contact method if enquiries are business-critical. If submissions are stored, review the backlog and follow up according to your privacy policy. Do not promise a visitor that a message was received unless the system has actually accepted it.

1. Check that the form really submits

Test required fields, the submit button and any consent or verification step. If the button spins forever, the page reloads unexpectedly, or you see a validation error, the issue may be on the page rather than in email. Try a current browser, a private window and a phone. Do not permanently disable spam controls to make the test pass; investigate false positives and restore protections.

A developer can use the browser’s Network panel to inspect the submission request and response. A 4xx response often points to validation, authentication or a blocked request; a 5xx response points to a server-side failure. Status codes are clues, not a diagnosis. Record the request identifier and time, but avoid exporting passwords, cookies or customer messages into a public support ticket.

2. Look for the saved enquiry

Open the form plugin’s submissions screen, CRM or website admin, if one exists. Search for your test marker. A saved lead with no email suggests that submission and notification are separate steps: investigate notification settings, queues and the sending provider. No saved lead could indicate an earlier failure, but some forms intentionally do not store submissions, so check the design before drawing conclusions.

A useful support question is: “Which system stores submissions, and what happens if email fails after a submission is saved?” If nothing is stored, consider adding a protected fallback queue or CRM record. Limit access, collect only necessary data and define how long records are retained.

3. Check notification settings and delivery logs

Confirm the notification is enabled for the correct form, the recipient address is spelled correctly, and conditions or business-hour rules do not exclude the test. Check the sending provider’s activity log with your test time or message ID. A provider may show accepted, deferred, rejected, bounced or suppressed. “Accepted” means a server accepted a handoff; it is not always proof that a person saw the message.

For WordPress sites, the official wp_mail documentation explicitly says a successful return does not guarantee recipient delivery. A mail log can help, but avoid saving complete messages or personal details indefinitely. For custom sites, ask whether the notification uses SMTP, a transactional email API or a background job, and where failures are logged.

Use the evidence to choose the next check

4. Use an authorized sender and Reply-To

A common setup is to send the notification from an address on a domain you control, such as notifications@example.com, through a provider authorized for that domain. Put the visitor’s address in the Reply-To header so your team can answer them. Do not impersonate the visitor by sending from their Gmail or company address through your own server. Confirm the precise sender and verification requirements with your email provider.

Authenticated SMTP or a transactional email API can provide a reliable sending path and useful logs, but neither is a universal fix. A wrong recipient, broken browser request, missing queue worker or mailbox filter still needs its own correction. Keep API keys and SMTP credentials on the server and rotate exposed credentials.

5. Check domain authentication without breaking existing mail

Your sending provider may require DNS records for SPF and DKIM; DMARC adds a policy and alignment checks. SPF identifies authorized sending infrastructure, DKIM signs messages, and DMARC evaluates whether an authenticated domain aligns with the visible From domain. For the current Gmail requirements, read Google’s sender guidelines.

Check which DNS provider is authoritative before making a change. An organization should not publish multiple separate SPF records for the same hostname; consolidate authorized senders with your provider’s instructions rather than deleting an existing record. Changing a DMARC policy or mail-routing record without understanding the current setup can affect unrelated email. Coordinate with the person who manages your domain and wait for DNS caches to update before retesting.

6. Check the receiving mailbox

Search all mail, spam, quarantine and archive for the test marker and sender. Review rules, forwarding, blocked senders, full mailboxes and shared-inbox permissions. An administrator may need to inspect message-trace or quarantine logs. Test with an independent mailbox you control as well as the business inbox; different results help isolate a receiving-side issue.

7. Confirm the fix and monitor it

A practical verification checklist

• Submit from desktop and mobile using test addresses you control.
• Confirm the server accepted the request and the submission is stored if storage is intended.
• Check the sender’s log and verify arrival in every intended mailbox.
• Reply to the test and verify Reply-To reaches the test address.
• Confirm spam controls still block a harmless test that they are designed to reject.
• Set up failure alerts, a retention policy and a periodic controlled end-to-end test.

Run tests after a hosting move or a redesign, because the form may still point at an old endpoint even while the page looks correct. Our website redesign SEO checklist covers a wider launch process. If a CRM or help desk is involved, see how API integrations work and include the handoff in your test.

Questions to send your developer or provider

• What exact event does the success message confirm?
• Where are submissions stored, and who can access them?
• Which service sends the notification and where can we see its delivery logs?
• What happens when the mail provider is unavailable?
• Who owns the sending credentials and domain DNS?

Sources and further reading

This guide draws on Google Workspace’s contact form troubleshooting guidance, WordPress wp_mail documentation and Gmail’s sender guidelines. Provider settings and requirements can change; verify them with the service you use.