Your booking emails are going to spam. Here's why.

A cleaning company I built a site for had online booking working perfectly. Customers picked a time, filled in their details, hit submit, got a confirmation on screen.

The owner never saw a single notification. They were all in spam.

This is one of the most common problems I run into on small business sites, and it almost never gets diagnosed correctly. People assume the form is broken, or the plugin is bad, or the host is at fault. Usually it’s none of those. The email is being sent successfully — Gmail is just deciding not to trust it.

Why Gmail doesn’t trust your site’s email

When your website sends an email, it’s claiming to be you. A message goes out saying it’s from bookings@yourbusiness.com, and the receiving mail server has to decide whether to believe that.

Anyone can put anything in a “From” field. That’s how phishing works. So Gmail, Outlook, and everyone else check the sending domain for proof: has the owner of this domain published a record saying “this server is allowed to send mail on my behalf”?

If there’s no record, the message is unverified. Unverified mail from an unfamiliar server that looks automated goes to spam. Gmail has been tightening this steadily, and since 2024 the rules for bulk senders are strict enough that “it used to work” is a real thing people experience.

The fix is three DNS records. None of them are hard, but they have to actually exist, and on most small business sites nobody ever set them up.

The three records

SPF lists which servers are allowed to send email for your domain. It’s a single line published in your DNS. When Gmail receives a message claiming to be from your domain, it looks up your SPF record and checks whether the sending server is on the list.

The most common failure isn’t a missing SPF record — it’s having two. A domain can only have one, and if your host added one and your email provider added another, they conflict and the check fails. If mail suddenly stopped being delivered after you changed hosts or added a service, this is the first thing to look at.

DKIM adds a cryptographic signature to every outgoing message. Your server signs the mail with a private key; the matching public key lives in your DNS. The receiving server verifies the signature and knows the message genuinely came from you and wasn’t altered on the way.

Most hosting control panels can generate and publish DKIM keys with one click. Many just don’t have it turned on.

DMARC ties the other two together and tells receiving servers what to do when a check fails — nothing, quarantine, or reject. It also gives you reports on who is sending mail claiming to be your domain, which is genuinely useful if you’ve ever wondered whether someone is spoofing you.

Start DMARC in monitoring mode. Setting it to reject before you’ve confirmed your legitimate mail passes is how people accidentally block their own invoices.

Where to actually set them up

All three are DNS records, which means they live wherever your domain’s DNS is managed. That’s not always your website host — if you’ve ever pointed nameservers somewhere else, they go there instead. Getting this wrong is why people publish records and see no change.

If you’re on cPanel, look for Email Deliverability. It’ll show you which records are missing and offer to fix them. If your DNS is managed elsewhere, it’ll show you exactly what to add, and you copy those values over.

Google Workspace, Microsoft 365, and most email providers publish their required values in their own documentation. Use theirs — don’t copy a random SPF record off a forum, because it’ll list the wrong servers and make things worse.

Verify it actually worked

This is the part people skip, and it’s the part that matters.

Publishing the records isn’t proof. DNS takes time to propagate, values get typo’d, and a record in the wrong place does nothing at all. So test it:

Send a real message through the actual system — submit your own booking form, not a test email from your desktop client. Those take a completely different path and prove nothing about what your website sends.

Then open the message in Gmail, click the three dots, and choose “Show original.” You’ll see SPF, DKIM, and DMARC each listed as PASS or FAIL. That’s the answer, in plain terms, with no guessing.

For the cleaning company, that’s exactly how we confirmed it. Records published, live test booking submitted, message opened, three PASS lines. Then a second one a day later to be sure it wasn’t a fluke.

The part worth remembering

If your site sends email — booking confirmations, contact forms, receipts, password resets — and you’ve never set up SPF, DKIM, and DMARC, some portion of it is not arriving. You won’t get a bounce message. You won’t get an error. It just quietly goes to spam, and the customer who filled in your form assumes you ignored them.

That’s the real cost. Not a technical failure you can see, but leads you never knew you had.

Check yours. Send a booking through your own form and read the headers. It takes five minutes, and it’s the highest-value five minutes most small business sites have available.