Contact form says sent, but no email arrives: what to check

A website form can look reassuring while an important message never reaches the person who handles enquiries. Before replacing the form or changing your email provider, separate the visitor's experience from the delivery process.

1. Follow the message through three stages

A confirmation on the page cannot, by itself, prove that the final mailbox received the email. Contact Form 7 documents this exact situation: the sending function may finish successfully while delivery still fails later. Its missing-email FAQ recommends looking for evidence in the mail logs and spam filtering.

Notice what actually fails. A button that does nothing, an error after submission, and a successful submission with no email are different symptoms. If the button only fails on a phone, start with the mobile website checklist too.

2. Check where the enquiry should arrive

The email shown on your Contact page and the notification recipient configured behind the form can be different. Ask the person managing the website to confirm the recipient for the affected form. A second form on another page may have its own settings.

• Search the mailbox: look in spam, junk, quarantine and folders used by inbox rules. Search for the test subject or a distinctive phrase from your message.
• Check access: confirm that the team is checking the intended mailbox, including a shared inbox if you use one.
• Separate the two email routes: an ordinary message to the business address tests receiving email. It does not test the website's ability to send a notification.
• Check stored entries, if available: an enquiry saved in the website may help establish that submission worked. Some forms do not store entries at all.

For WPForms specifically, notification settings and conditional rules are among the items its own troubleshooting documentation covers. Use instructions for your actual form system rather than installing a plugin intended for a different platform.

3. Run one useful test

Tell the person receiving enquiries that you are testing. Use an address you control and an obvious message such as “Website delivery test — no action needed.” Note the exact page, time and time zone. Submit once, record the confirmation, and check the destination.

If notifications are queued, the website operator should tell you how long processing normally takes. Avoid repeatedly pressing Submit: several requests can arrive later and make the test harder to interpret.

4. What a developer should check next

Ask for an explanation that connects the fault to the evidence. The investigation should establish whether the application accepted the request, whether the outgoing service accepted the message, and whether any rejection or delivery event is available. A provider accepting a message is still different from a person finding it in the inbox.

On this site, the contact endpoint uses PHPMailer with SMTP, and the visitor's address is used for Reply-To. The local tests exercise message creation and both acceptance and rejection by a test mail server. Those checks help verify application behavior; a separate test against the configured live mailbox is needed to confirm real delivery.

A useful repair handover states what changed and records the final check from the public form to the intended mailbox. Keep the affected form, recipient and test outcome together so that a future hosting or mailbox change is easier to verify.

5. Send a clear repair enquiry

You do not need to name the technical cause before asking for help. Copy these prompts and fill in what you know:

Affected page:
What I expected:
What appeared after submitting:
Where the notification should arrive:
Test time and time zone:
When I first noticed the issue:
Recent website or email changes, if known:
Platform or form tool, if known:

Leave passwords, private customer messages and sensitive logs out of the public enquiry. Any access needed for an agreed investigation can be arranged separately. See how scoped website fixes work for the next step.