Your contact form sends mail as you. Does your domain agree?

We launched a redesigned website recently and tested the contact form the way everybody does. Fill it in, press send, see the thank you. Then we went to find the email, and it was not there. Not in the inbox, not in junk. The form had done its job and the message had gone nowhere.

The cause took a while to find and it is common enough to be worth writing down.

What a form email really is

When a visitor submits a form, your web server writes an email and sends it. The message says it is from an address at your domain. But the web server is not your mail system. It is a different machine, usually at a different company, borrowing your name.

Receiving mail systems know this trick is also how fraud works, so they check. They look at your domain's SPF record to see whether that server is on the list of machines allowed to send for you. They look for a DKIM signature. Then they read your DMARC policy, which tells them what to do when the checks fail. If the policy says reject, a well behaved receiver does exactly that.

From the outside nothing looks wrong. The visitor sees a confirmation. The web server reports success, because it handed the message over. The rejection happens later, somewhere else, and nobody is told.

Why this is getting stricter

The large mailbox providers have been tightening these rules together. Since 5 May 2025 Microsoft has required domains that send more than 5,000 messages a day to its consumer mailboxes to pass SPF, DKIM and DMARC, with mail that fails going to junk and rejection to follow. Your contact form is nowhere near that volume. The direction is the point. Every year, mail that cannot prove where it came from is treated with less patience, by every provider.

There is a second way it goes wrong, and it caught us too. Some hosting accounts assume they also run email for the domain. A message addressed to your own domain is then delivered locally, to a mailbox on the web server that nobody has ever opened, and never leaves the building.

How to check yours

Send a test enquiry and find the message. If it arrives, open the full headers and read the authentication results. You want SPF or DKIM to pass and to match your domain. A pass on the hosting company's own domain is not enough.

If the message does not arrive, look at three things in order. Is the hosting account trying to deliver the mail to itself? Is the sending server in your SPF record? Is your DMARC policy rejecting it? Fix whichever you find, and then test again from a personal address at another provider, because a message from yourself to yourself can pass where a stranger's would not.

Do this whenever you change web host or mail provider. Those are the two moments the records drift apart, and they are also the two moments nobody is thinking about the contact form.

Where X-Axis fits

Mail authentication is part of every Microsoft 365 move we run, including the website and application senders that are easy to miss. More on our Microsoft 365 work.