Contact form sent, but no email? Trace the missing enquiry

Before replacing a contact form that “doesn't send emails”, find one missing enquiry. Give a controlled test a recognisable reference, record the time and follow it through the system. Was it saved? Was a notification handed to the sending service? Did the recipient's server accept it? Can someone in the business find it and reply? Those are separate questions, and they lead to different repairs.

A reassuring success message answers none of them unless the implementation defines what success means. Your browser can display a green tick while the notification fails later. A small business needs a recoverable enquiry and a clear person responsible for it. Start there. A different plugin can wait until you know which part has failed.

Use a reference you can follow all the way through

Send a test such as “FORM-CHECK-25OCT-A”, using invented details and an inbox you control. Keep the exact page URL and the time, including the time zone. A distinctive reference makes it easier to match a browser request with a stored record, a sending attempt and a message in quarantine. Five submissions with “Hello” in the subject create needless guesswork.

First look in the form's submission store or the system that is meant to receive the enquiry. Some forms save a record before sending a notification; others only attempt email delivery. Establish which arrangement you have. If nothing is stored, a failed notification can also mean the enquiry itself is unavailable for recovery.

WordPress.com's own troubleshooting guide distinguishes saved form responses from notification emails. Other platforms have different screens and storage options. Ask your provider to show both pieces of evidence rather than assuming that a visible form includes a recoverable inbox.

Find the last successful handover

If the submission is absent, work backwards towards the browser. Did validation pass? Was the request actually sent? Did the published page use the correct endpoint? Was an anti-abuse check rejected? A form copied from a preview environment can still point to an old destination. Changing mailbox settings won't fix that.

If the record exists, inspect the notification job. Check the configured recipient, the last attempt and any error. An old staff address, expired credentials or an inactive sending integration are plausible causes. The useful question is specific: “What happened to the notification for this submission?” That can be investigated without sending an entire customer conversation around several support desks.

When the sending service supplies a message identifier, use it to trace the next step. The service may reject the message, defer it or pass it to the receiving server. Acceptance by that server is still short of appearing in the main inbox. Spam filtering, administrative quarantine and mailbox rules can act afterwards. Record the exact status instead of compressing everything into “email broken”.

Keep the visitor out of the sender field

A tempting configuration puts the visitor's email address in the visible From field. The notification then appears to come directly from the customer. However, your website is sending through its own infrastructure while claiming a domain it doesn't control. That discrepancy can cause trouble during authentication and filtering.

Use a sender on a domain you control and have configured with the sending provider. Put the validated visitor address in Reply-To, so the reply button reaches the customer. Contact Form 7 documents this sender/reply-address arrangement. The same distinction is worth discussing with the supplier of a custom form.

For an example business, the display name might be “Website enquiries”, attached to its own authenticated address. Include the enquiry reference in the subject and show the visitor's contact details in the message. Then press Reply in the actual receiving mailbox. You want to discover a wrong reply destination during acceptance testing, rather than after a customer has waited several days.

What to ask about SPF, DKIM and DMARC

Ask the person managing email to verify authentication for a real notification from the published form. The existence of a DNS record is only part of the evidence: the current sending route must use it correctly. A change of hosting, form provider or outbound mail service can leave an older configuration looking reassuring while it no longer matches the messages.

Google's requirements for personal Gmail recipients distinguish ordinary senders from bulk senders: SPF or DKIM applies generally, with additional requirements including DMARC for bulk sending. Authentication supports delivery; it cannot guarantee inbox placement. Corporate recipients and other providers can apply different rules.

Don't paste a random DNS example over the existing configuration. First list the services that send for your domain, including ordinary staff email, invoices, newsletters and form notifications. A repair that helps the website while breaking invoice messages is an expensive shortcut. Keep the previous configuration, change the relevant sender deliberately and check the other important routes afterwards.

A short acceptance test that actually follows the enquiry

Use two controlled receiving inboxes if possible. Keep the normal security checks enabled, and use fictional customer information. The aim is to reproduce the public route accurately, including validation and anti-abuse checks. An email sent from an administrator's test button may use a different route from the contact form.

1. Open the live page in a fresh browser window. Submit the required fields with a unique reference, and save the visible confirmation wording.
2. Find the stored submission. Compare special characters, line breaks and the telephone number with the original input.
3. Locate the notification attempt, actual recipient and message identifier at the sending service.
4. Check the recipient's inbox, junk folder and administrative quarantine where available. Reply and verify the destination.
5. Repeat from a mobile phone using a new reference. Submit an invalid value as well; it must produce a useful error rather than a misleading success state.
6. In a test environment, interrupt notification delivery. Confirm that the enquiry remains recoverable and that restoring delivery doesn't create duplicate work.

If completing the form is already difficult, give that a separate finding. Our guide to accessible enquiry and booking journeys covers keyboard use, zoom and understandable errors. A cropped button and an email rejection deserve their own fixes, even when they happen on the same page.

Make a missing notification survivable

A small team can often work with a modest central submission list. The email points to new work; the stored enquiry provides the record. Decide who checks outstanding items when notifications stop arriving and who takes over during holidays. Reliability doesn't require a large new platform, but it does require somebody to notice an unattended queue.

Retries need limits and a stable enquiry reference. A temporary sending failure should not produce three CRM records, three callback tasks or several people calling the same customer. Re-sending a notification and creating a new business enquiry are different operations. Test their relationship before switching on automatic retries.

Where the form also feeds a CRM, verify the resulting record directly. A successful connection doesn't prove that the name, preferred language or requested service reached the right field. The guide to checking what an automation actually completed explains that wider problem. For this form test, one traceable destination record per reference is a useful starting point.

Acknowledgements can become an abuse route

Automatically emailing the entire submission back to any entered address creates another risk. Someone can enter somebody else's address and use your form to send unwanted material. Prefer a short, fixed acknowledgement with a reference. Avoid blindly echoing arbitrary links or long free-text input into an outbound message.

Limit sending frequency and define how repeated submissions are handled. Consider what information belongs in ordinary email at all, particularly for sensitive enquiries. Diagnostic logs should contain enough detail to investigate delivery without becoming an uncontrolled second archive of customer messages. Set access and retention accordingly.

Give support a case they can investigate

A useful support report contains the public form URL, test reference, timestamp and time zone, browser and exact confirmation message. Add the last proven state and the first missing piece of evidence. Keep passwords and real customer correspondence out of an ordinary support ticket.

After the repair, repeat the same route, including the reply destination and the interrupted-delivery case. Ask how your team will recognise the next failure. Close the investigation when someone in the business can find the test enquiry and take responsibility for it. That is a stronger acceptance condition than another green tick.