Contact form not sending email: find the cause

The visitor fills in a name, a question and an email address, then presses Send. The page changes to a thank you line, which tells the visitor nothing about the mail step. The owner sees no message, and the visitor waits, then calls someone else or leaves. Three different faults produce this exact picture: the form never submitted, the form submitted but the mail step failed, or the mail went out and was filtered before it reached the inbox. Each fault needs a different fix, and the inbox alone cannot separate them.

• After Send, does the message appear in your form tool's submissions list or in the site's database?
• Does the browser's Network tab show a request to the form address that returns a success code?
• Does the form have a hidden field that autofill could fill, and does the server drop any message where it has text?
• Does the mail service's send log show the message as accepted, bounced, rejected or held?
• Does the sender address belong to a domain the mail service has marked as verified?

Start at the form tool or the site's own database, not at your inbox. Many form tools keep a list of submissions, and a custom form often writes to a table. Send one test message with a name you will recognize, then look for it there. If it is stored, the form worked, and the fault sits in the step that sends mail. If it is not stored, the message never got past the form, and the mail settings are not the place to look yet.

The mail service keeps its own log. Find the send record for the test message and read its status. Accepted means the service took the message and passed it on. Bounced or rejected means the receiving server refused it, often because of the sender domain. Held or suppressed means the service stopped sending to that address on purpose, for example after an earlier bounce. Each status points to a different fix, so write it down before you change anything.

Many forms add a field the visitor never sees, sometimes called a honeypot, to catch bots. The form expects that field to stay empty, and it throws away any submission where it has text. Browser autofill can write into fields whose names look like contact details, even when the form hides them. The visitor sees a thank you, the server sees a filled trap, and the message is dropped on purpose.

To check this, open the form in a fresh browser profile that has saved contact details, fill the visible fields by hand, and send. If the message shows up when you type every field yourself, and not when autofill fills the form, the trap is the cause. Fix it by giving the field a name a browser will not guess, and by logging dropped messages so they leave a trace.

A message can leave the mail service and still land in spam, or be rejected at the receiving end. Receiving servers check that the sending domain has authorized the service to send for it, usually through records in the domain's DNS settings. If you moved the domain, changed hosts or added a second mail service, one of those records can be missing. A message that reaches one mailbox and not another points at the receiving side, so write down which provider each mailbox uses.

Check the sending domain in the mail service's settings. Look for a verified status on the sending address and read any warning beside it. The form tool cannot make that check for you, because the record lives with whoever manages your domain. A form that sends from an address at your domain can stop after a DNS change, and the form itself shows no error when it does.

A rotated mail password, a changed DNS record or a plugin update can stop the form again without touching the form page. Send a fresh test message after each change to the mail account, the domain or the form tool. With paid credits, visitors can also open a protected preview, so a form change on a staging site gets the same run before it goes live.