A customer fills in your contact form. You never see it. Or they book, and the confirmation never arrives, and they ring you two days later to ask whether they actually have an appointment.
This is the most common invisible fault on a small business website, and it is almost never a broken form. The form worked. The email was sent. Something between you and the customer decided it was probably junk.
Here is what is actually happening, and the four-line fix.
The short version
An email says who it is from, and anybody can write anything in that line. There is nothing in the format stopping me sending a message that claims to be from your bank.
So mail providers stopped trusting the From line on its own and started asking the domain it claims to come from to vouch for the sender. Three DNS records do that vouching: SPF, DKIM and DMARC.
If your site sends mail and those records are missing or wrong, Gmail has no way to tell your booking confirmation from someone pretending to be you. It does the safe thing.
This became a hard requirement in 2024
It used to be that authentication helped. Now it is a condition of delivery, and both large providers published the same rules.
Google, on sending to personal Gmail accounts:
Starting February 1, 2024, all email senders who send email to Gmail accounts must meet the requirements in this section. - Set up SPF or DKIM email authentication for your sending domains. - Ensure that sending domains or IPs have valid forward and reverse DNS records […] - Use a TLS connection for transmitting email. - Keep spam rates reported in Postmaster Tools below 0.3%.
Yahoo published a near-identical list — SPF or DKIM at minimum, spam rate below 0.3%, valid forward and reverse DNS.
Send more than 5,000 messages a day to Gmail and the bar goes up: SPF and DKIM, plus a DMARC record, plus one-click unsubscribe on marketing mail. A local business site sending booking confirmations is nowhere near 5,000 a day, so the first list is the one that applies to you — but I set all three up anyway, because the cost is the same and it is one less thing to revisit.
The three records, in plain terms
You will never type these yourself. It is worth knowing what they are so the words mean something when somebody says them to you.
SPF — who is allowed to send as me
A list, published in your domain's DNS, of the services permitted to send mail using your domain. When a message arrives claiming to be from your domain, the receiving server checks whether it came from something on that list.
Not on the list, no vouching. Every service you send from — your website, your mailbox provider, your newsletter tool — has to be on it.
DKIM — and here is the proof
A cryptographic signature on each message. Your sending service signs with a private key; your domain publishes the matching public key in DNS. The receiver checks the signature.
SPF says the sender was allowed. DKIM proves the message is genuinely from them and was not altered in transit.
DMARC — and here is what to do if it fails
A policy that ties the other two to the name a human actually reads. It tells receivers what to do with mail that fails the checks — nothing (p=none), quarantine, or reject — and it can send you reports about who is sending as you.
The important part: DMARC checks alignment. Google's wording:
the domain in the sender's From: header must be aligned with either the SPF domain or the DKIM domain.
Which is the technical version of: the name the customer sees has to be the name that was vouched for.
The mistake almost everybody makes
Sending your website's email from a Gmail address.
It looks sensible. You have [email protected], so the contact form sends from it. But now a server somewhere in your website's hosting is sending mail claiming to be from gmail.com, and Google's SPF record for gmail.com does not list your web host, because of course it does not.
Google has been explicit about this direction of travel:
Gmail will begin using a DMARC quarantine enforcement policy, and impersonating Gmail From: headers might impact your email delivery.
The fix is not a setting. Your site has to send from your own domain — [email protected] — because that is the only domain you can publish records for.
The other half: two kinds of email
These get confused constantly and it changes what tool you need.
Transactional — one message, triggered by one person doing one thing. A booking confirmation, a receipt, a password reset, "somebody filled in your contact form". This is what your website sends.
Marketing — a newsletter to a list. Different rules (that one-click unsubscribe requirement is about marketing mail), different tools, and you mostly do not need it.
Using a marketing tool for transactional email is possible and awkward, and you end up paying for a contact list you do not have. This is why I set clients up on Resend, which does the transactional kind and tells you, per message, whether it was delivered or bounced.
That log is the actual payoff. When a customer says "I never got my confirmation", the answer is a ten-second lookup instead of a day of guessing.
What I do about all of this
On every site I build:
- The site sends from your domain, never from a Gmail or Outlook address.
- I publish the SPF, DKIM and DMARC records for your domain, and verify the domain with the sending provider.
- I test it before launch by filling in your own contact form and confirming the message arrives.
- The form writes the enquiry to your database before it tries to email anyone, so a mail problem on somebody else's server can never lose you a customer. You will still have the message even if the email never gets through.
That last one is the part nobody asks about and the one that has actually saved enquiries.
If you think this is already happening to you
Three things you can check without me.
Send yourself a test. Fill in your own contact form from a phone that is not logged into your business email. Wait five minutes. Check spam.
Ask two recent customers. "Did you get the confirmation email? Was it in spam?" Two answers is enough to know whether you have a problem.
Look at who it says it is from. If any automated email from your website arrives from a @gmail.com or @outlook.com address, that is the problem, and everything above explains why.
If any of that turns up badly, send me a screenshot of the email including the sender address. That is usually all I need.




Comments