Winad · Article

Why your booking inquiries are landing in spam (and the DNS fix)

You're not losing bookings because people aren't interested. You're losing them because your emails never reach the inbox — and the fix is free.

By Daniel Aguiar · 2026-08-13

The silent killer of bookings

Someone fills out your booking form, excited about a trip. Your site fires a confirmation email. It lands in their spam folder. They never see it, figure you're slow, and book with the operator who did reply. You never knew there was a problem, because from your side everything “sent” fine. This is one of the most expensive problems I see with tour operators precisely because it's invisible — no error, no bounce, just quiet lost revenue. The cause is almost always the same three DNS records that tell the world your email is legit: SPF, DKIM, and DMARC. Deliverability is the boring plumbing I've been fixing for fifteen years, and it's free to set up.

SPF, DKIM, DMARC in plain English

SPF is a guest list — a record that says “these servers are allowed to send email for my domain.” If you send through Google Workspace, your booking software, and a newsletter tool, all three need to be on the list, and most operators forget one. DKIM is a wax seal — an invisible cryptographic signature on every email so the receiver can confirm it really came from you and wasn't tampered with. DMARC is the instructions — it ties SPF and DKIM together, tells receiving servers what to do on failure, and emails you reports on who's sending as you. All three work as a set; one alone isn't enough.

How to check what you've got

You don't need to be technical. Send a test email to a Gmail address, open it, click the three dots, and hit “Show original.” You'll see three lines — SPF, DKIM, DMARC — each marked PASS or FAIL. Any FAIL is a leak. The most common mess I find: an SPF record set up years ago for one provider, never updated when the operator switched booking systems or added a newsletter, so the new sender isn't on the guest list. Or a DMARC record set to “reject” before SPF and DKIM were working — which means the operator is bouncing their own legitimate email. Check before you touch anything.

Fixing it without breaking anything

The fix lives in your DNS settings wherever your domain is registered — you're adding or editing a few TXT records. It's not hard, but the order matters. Get SPF listing every real sender first. Add DKIM for each service using their keys. Then, and only then, add DMARC — start it in monitoring mode (p=none) so you get reports without risking real mail. Watch for a couple weeks, confirm everything passes, then tighten. Do it in the wrong order and you can knock out your own booking confirmations. This is exactly the unglamorous, high-leverage fix I handle in a Sprint — usually done in about three days.

Get a free demo

Want to know if your booking emails are even reaching people? I'll check your deliverability as part of a free homepage demo — no charge, no commitment — and tell you exactly what's leaking.

Reply ‘demo’

← All articles