The contact form that emailed nobody

Picture a shop whose website has a contact form that has not actually delivered a message in six months. The form still works from the customer's perspective. They fill it out, click submit, see a success message. The message goes into a queue on the web server, gets handed to the local mail agent, and vanishes. Not into spam. Not into a bounce. Into nothing, because the receiving mail server looked at the SPF record, saw that the web server's IP was not authorized to send mail for that domain, and silently discarded it.

The owner finds out when someone mentions they never heard back, or when they realize the last form submission they remember was months ago. There is no error log on the website. There is no bounce message, because the rejection happens after the web server thinks it successfully sent the mail. The form looks like it works, and the loss is invisible until someone asks.

Why web servers fail SPF

Most website contact forms use the server's built-in mail function. In PHP, that is the mail() function. In WordPress, it is wp_mail(), which usually just wraps the same thing. The form collects the input, hands it to the function, and the function tells the operating system to send it. The mail leaves the server with a return path that claims to be from your domain, but the sending IP is the web server, not your actual mail server.

That used to work fine. It has not worked reliably since SPF became standard, which was around 2014. An SPF record is a DNS entry that lists which servers are allowed to send mail for your domain. If your SPF record says mail comes from your mail provider's servers, and then a message shows up from your web host's IP, the receiving server has two choices. It can deliver it to spam, or it can reject it outright. The large providers, Gmail especially, have been rejecting more of it every year.

The problem gets worse if your web host is on shared hosting, because the sending IP is shared with dozens or hundreds of other sites. If any of them send spam, the IP gets a reputation hit, and your legitimate contact form submissions get caught in the same filter.

How to tell it is happening

The fastest way to check is to fill out your own contact form from an outside email address and see if it arrives. Do it from a Gmail account if you have one, because Gmail's filters are the strictest. If it does not show up in spam or inbox within a few minutes, it was probably rejected.

The more thorough way is to check your mail server logs, but most small sites do not have access to those because the mail is hosted somewhere else. If you do have access, look for rejected messages from your web server's IP. The rejection reason will usually mention SPF.

If you are already getting other mail from your domain, but contact form submissions are missing, that is the pattern. Your real mail server is fine. The web server is not authorized, and its mail is getting dropped.

The fix: send through a real mail service

The right way to send mail from a website is to use SMTP through a mail service that has SPF and DKIM configured. That means the website does not send mail directly. It hands the message to a mail server that is authorized to send for your domain, and that server sends it with proper authentication.

For WordPress, that usually means installing an SMTP plugin and configuring it with credentials for your mail host. Most hosting providers support SMTP, and if they do not, there are dedicated transactional mail services that do nothing but send website mail. The configuration takes about ten minutes: install the plugin, enter the SMTP server address, port, username, and password, and send a test.

The test is the part that gets skipped, and that is how you end up with a form that looks like it works but does not. After you configure SMTP, send yourself a message through the form and make sure it arrives. Check the headers to confirm it was sent through the mail service, not directly from the web server.

Where this sits

Mail authentication is part of the hosting and domain work I do, and it comes up every time I move a site or take over an existing one. If the contact form is the only way customers can reach you, it needs to actually work, and on a modern mail infrastructure that means SMTP with SPF and DKIM. I check it during migrations and include it in Care plans, because a form that silently fails is worse than no form at all. At least with no form, you know to put a phone number on the page.