The site generates a message, the server sends it, the receiving provider filters it, and somebody reads it. Most failures happen in the middle two steps, and the fix is usually sending through a proper mail service rather than from the web server.

The four steps

Worth understanding because it tells you where to look when something breaks.

The site builds the message from what was typed, using whatever the form plugin does.

The server sends it, usually from the same machine that hosts the website.

The receiving provider decides what to do with it, which is where filtering happens.

Somebody reads it, or does not, depending on which folder it landed in.

Businesses assume failures happen at step one. They almost always happen at two or three.

Why web servers send poor mail

The structural reason for most of this.

A web server sending email is not what it was built for. It often sends from an address that does not exist, on a machine shared with many other sites, with no authentication proving it is allowed to send on your behalf.

Receiving providers are suspicious of exactly that combination, because it is what unsolicited mail looks like.

So the message either goes to junk or is refused outright. Nothing about the form is broken and the mail never arrives.

The address the message comes from

A specific and very common cause.

Many forms are configured to send from the address the customer typed, so replying is convenient.

That means your server is sending mail claiming to be from a stranger's address at a domain it has no authority over. Receiving systems treat that as forgery, because structurally it is.

The correct arrangement is to send from an address at your own domain, and set the customer's address as the reply-to. You still reply with one click and the message is no longer pretending to be from somebody else.

This one change fixes a large share of delivery problems.

Sending through a mail service instead

The structural fix, and it is not difficult.

Rather than the web server sending directly, the site hands the message to a proper mail provider, which sends it with the right authentication from a reputation it maintains.

That can be your existing business email provider, or a service built for the purpose.

The result is mail that arrives, consistently, and a log showing what was sent and what happened to it.

Most form plugins support this and most sites have never had it configured, because the default works well enough to look fine at launch.

A worked example

A dental practice whose enquiries had always been intermittent, which they assumed was normal.

Roughly half of submissions arrived. The other half were being rejected by their own mail provider because the web server was sending from the patient's address with no authentication.

Nobody had noticed a pattern because half is not nothing, and the failures were silent.

The fix was configuring the site to send through the practice's existing mail provider and using a proper from address.

Delivery went to essentially all of them. Their enquiry volume appeared to jump by eighty percent, and no additional visitor had arrived.

The instructive part is how plausible the old numbers had looked. There was nothing to investigate because nothing seemed wrong.

The authentication records

Briefly, because they matter and are not complicated to describe.

Records attached to your domain state which servers are permitted to send mail claiming to be from you. Receiving systems check them.

If your web server sends mail as your domain and is not listed, the message fails that check. If it is listed, it passes.

Getting this right is a job for whoever manages your domain records, takes minutes, and prevents a whole category of quiet failure. It is the single highest-value ten minutes in this whole subject.

It also protects you against somebody else sending mail pretending to be your business, which is a separate benefit.

The counter-case

Where none of this is worth doing.

A site whose form stores submissions and does not rely on email at all. Then delivery is not in the path and none of the above applies.

A very low-volume site where the occasional lost enquiry genuinely does not matter, though that describes fewer businesses than claim it.

And a business whose enquiries arrive by phone almost exclusively, where the form is a formality rather than a channel.

For everybody else, mail delivery is load-bearing and worth the hour it takes to set up properly.

Where messages actually end up

  1. The intended inbox, which is the assumption.
  2. The junk folder, which is the most common alternative.
  3. A filter rule created years ago and forgotten.
  4. A shared inbox nobody has claimed responsibility for.
  5. A forwarding address that no longer forwards anywhere.
  6. Rejected entirely, with the bounce going to an address that does not exist.

The third and fourth are organisational rather than technical, and they are just as effective at losing enquiries. A shared inbox with no owner is a technically perfect delivery to nobody.

The second copy that solves most of it

A pragmatic answer for anybody who does not want to think about mail authentication.

Have the form send to two addresses: your normal one, and a second at a different provider entirely.

Delivery problems are rarely universal. A message rejected by one provider frequently arrives at another, so a second copy converts a total loss into a copy sitting somewhere you can find it.

It costs nothing, takes two minutes, and requires no understanding of the underlying mechanics whatsoever.

It is not a substitute for configuring things properly, and it is a reasonable safety net while you get round to it, which for most small businesses is the realistic timeline.

Checking the whole path

Once, properly, rather than testing the form and assuming.

Submit from an outside address. Check the intended inbox and its junk folder. Look at the message headers to see whether authentication passed. Confirm the from address is at your domain and the reply-to is the customer.

If your form plugin has a log, read it. If it does not, that is itself worth changing, because a log is what turns an invisible failure into a visible one, and most of this subject is about making silent things audible.

The visible half of the same problem is covered in the enquiry that never arrived.


Frequently asked questions

What are the four steps?

The site builds the message, the server sends it, the receiving provider filters it, and somebody reads it. Failures are usually in the middle two.

Why do web servers send poor mail?

They send from addresses that may not exist, on shared machines, without authentication proving they may send on your behalf. That is what unsolicited mail looks like.

What is the most common misconfiguration?

Sending from the customer's typed address. Your server is then claiming to be a stranger's domain, which receiving systems treat as forgery.

What is the correct arrangement?

Send from an address at your own domain, with the customer's address as reply-to. You still reply with one click and the message is not pretending.

What is the structural fix?

Hand the message to a proper mail provider rather than sending from the web server. Most form plugins support it and most sites never had it configured.

Where do lost messages actually go?

The junk folder, an old filter rule, a shared inbox nobody owns, a forwarding address that stopped forwarding, or rejection with the bounce going nowhere.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Enquiries arriving intermittently?

That pattern usually means half your mail is being rejected, which is fixable in an hour.

Start a Conversation