Why am I not receiving emails from my contact form?

The thank you page is reporting on a different system

Start with what the thank you page actually proves, because it is less than it looks.

MDN describes the whole of what a form is: "An HTML form on a web page is nothing more than a convenient user-friendly way to configure an HTTP request to send data to a server."

A request to a server. That is the entire job. The surrounding architecture is the ordinary one, where "a client (usually a web browser) sends a request to a server" and "The server answers the request using the same protocol."

So the sequence is short. The browser sends the form data. The web server answers. The browser shows whatever that answer told it to show.

Notice what is missing. No email has happened yet. The thank you page can be rendered by a server that has not yet tried to send anything, that tried and failed, or that never intended to send mail at all. The page is an answer to the request, not a receipt for a delivery.

This is why the fault is so confusing to report. Your visitor is telling you the truth when they say it worked, and you are telling the truth when you say nothing came. They are describing different systems, and only one of them is in front of them.

Everything that goes wrong from here goes wrong after the part anybody can see.

Your form is probably sending mail under somebody else's name

Here is the setting that causes most of this, and it is usually chosen on purpose for a good reason.

A contact form has to decide what address to put in the From field of the email it sends you. There is an obvious candidate: the visitor. Put their address there and you can hit reply straight from your inbox, which is exactly what you want to do.

That choice is also a claim, and the receiving mail server treats it as one. Your website has just sent a message asserting it came from a domain that belongs to a stranger.

The standard that checks this is SPF. Domains publish records "specifying which hosts are permitted to use their names", and receiving servers use those records "to test the authorization of sending Mail Transfer Agents (MTAs)".

Read that against what your form just did. The visitor's employer publishes a list of machines allowed to send mail using their name. Your website is not on it, and should not be. The check works correctly and the answer is no.

DMARC then takes that result and asks a further question about the name the reader will actually see. It defines the domain under scrutiny as "the domain name of the apparent author", meaning the address displayed in the From field rather than anything in the technical envelope underneath.

That distinction is the whole mechanism. It is not enough for a message to pass a check somewhere. The thing that passed has to match the name on the front.

And the consequence is stated without hedging: "Messages with Author Domains for which such policies exist that are not validated using the DMARC mechanism will not reach the inbox at Mail Receivers that participate in DMARC and honor the Domain Owner's expressed handling preference."

Will not reach the inbox. Not will be marked, not will be delayed. So your form is not broken in any way you could find by testing the form. It is working precisely as built, and being refused by a system built to refuse exactly this.

Accepted and delivered are different events, and only one of them is visible

Now the part that makes a failure so quiet, which is a rule about who becomes responsible and when.

SMTP hands the message over at a specific moment. Once a server has issued a success response at the end of the mail data, "a formal handoff of responsibility for the message occurs: the protocol requires that a server MUST accept responsibility for either delivering the message or properly reporting the failure to do so".

Put plainly, "the receiver takes full responsibility for the message" at that instant. Your side is finished and considers the job done.

But acceptance is not delivery. A server can take a message, then discover a problem with it afterwards, and the standard covers that case directly: "Errors that are diagnosed subsequently MUST be reported in a mail message".

Sit with that sentence, because it is the trap. The report of the failure is itself an email. It has to be composed, sent, and accepted somewhere, which means it depends on the same machinery that just failed.

So there are two ways to lose the message. The delivery can fail, and the notice about the failure can fail too. Neither event touches your website, and neither leaves a mark anywhere your visitor or your form can see.

That is what a silent form looks like from the inside. Nothing crashed. Every component did its own job correctly and handed the problem to the next one.

Where the message actually goes, and why nobody tells you

The failure notice has to be addressed to somebody, and that address is a third setting most people have never seen.

Bounce messages go to the return path, which is set separately from the From field. If your form put the visitor's address in both, the report of the failure has been sent to the visitor, who did not send the message, will not understand it, and will almost certainly ignore it.

There is a worse version. If the return path points at an address on your own domain that nobody monitors, the notices are arriving and being read by nobody. That failure is not silent at all. It is loud in a room with no one in it.

DMARC also explains why a receiving server is reluctant to bounce anything back. Because "a message that fails this validation is not necessarily associated with the Author Domain", replying to a failed message risks sending mail to a person who had nothing to do with it. Discarding quietly is the safer behaviour, so quiet discarding is the common behaviour.

This is the honest shape of the problem. The system is not hiding the failure from you out of carelessness. It is declining to send more mail about a message it could not trust in the first place.

Which means the fix is never to hunt for the missing notification. The fix is to stop sending mail that gets refused.

What to check, in order

Five checks, and every one of them is free.

• Submit your own form from an address outside your company, then look in the junk folder as well as the inbox. Testing from your own domain is the one test that can pass while everything is broken, because mail inside a single provider often never leaves it.
• Find out what address your form puts in the From field. This single setting decides most of the outcome, and in most form tools it is a plain text box somebody filled in once.
• Set From to an address on your own domain, and put the visitor's address in Reply To instead. You keep the one click reply and you stop making a claim about a domain you do not control.
• Ask whether your website and your email are run by the same provider. If mail leaves from your website host while your domain authorises a different mail provider, the check fails by design rather than by accident, and it will keep failing until the record and the sender agree.
• Store every submission on the website itself, not only in email. A form that saves the enquiry before it tries to send it turns a delivery failure into an inconvenience instead of a lost customer.

Do those in that order and most contact forms start working, because the common cause is a name in a field rather than anything broken.

One thing worth separating out. If your problem is the opposite one, too much mail rather than none, that is a different question with a different answer, and treating it as a delivery fault will send you looking in the wrong place.

Getting form notifications to arrive reliably, and keeping a copy of the enquiry where a mail failure cannot reach it, is part of what we do when we build and look after a site.

Sources

• Sending form data (MDN Web Docs)
• RFC 5321, Simple Mail Transfer Protocol (RFC Editor, Standards Track)
• RFC 7208, Sender Policy Framework for Authorizing Use of Domains in Email (RFC Editor, Standards Track)
• RFC 9989, Domain-Based Message Authentication, Reporting, and Conformance (RFC Editor, Standards Track)

Last reviewed 2026-09-12.