SPF, DKIM and DMARC for hotels: confirmation emails that arrive, fakes that do not

SPF, DKIM and DMARC are three DNS records that decide whether mail sent as your hotel's domain is trusted. SPF lists the servers allowed to send, DKIM signs each message so tampering shows, and DMARC tells the receiving mailbox what to do when either check fails, and reports back to you.

A guest books on your website late at night, the confirmation lands in spam, and the front desk spends the morning proving the reservation exists. The same domain that failed to deliver that confirmation is the one a stranger can use to ask the guest for a card payment. After reading this guide you will be able to list every system that sends mail as your hotel, ask each vendor the right questions in writing, and tighten the three records in an order that does not cost you bookings.

Why do confirmation emails land in spam while fakes reach the guest?#

Because receiving mailboxes judge the domain, not the message. A hotel that has never published authentication records looks exactly like a stranger writing in its name.

The receiving mailbox runs its checks before the guest sees anything. A message that fails can be filtered, quarantined or rejected with no notice to the sender, so the hotel never learns it happened. The first symptom is usually a phone call, not an error message.

One hotel domain usually has several senders: the PMS sending confirmations, the booking engine, the newsletter tool, front desk and sales mailboxes, the accounting system. Each is judged separately, and each must be listed. A domain where the PMS passes but the newsletter tool fails will deliver confirmations and lose campaigns, or the reverse.

Forwarding breaks SPF. A confirmation forwarded by an agency or by a guest's own mail rule arrives from a different server than the one SPF names, so SPF fails. DKIM survives forwarding better, because the signature travels inside the message, which is why both records matter.

A fake message with the hotel's exact address in the From: line passes every check when no DMARC record exists. Nothing tells the receiver what to do with an unauthenticated message, so the mailbox falls back to its own guess. That guess is often wrong in the fraudster's favor, because the fake is written to be convincing.

Authentication is not a spam filter. It decides whether the sender is trusted, not whether the content is wanted. Google's guidelines also ask senders to keep the spam rate reported in Postmaster Tools below 0.3% (Gmail Help, answer 81126, 2026), which is about content and list quality, not records. And fake booking messages sent through OTA extranets are a separate problem with a separate fix; authentication does nothing about them.

Who sends email as your hotel? Start with the sender inventory#

Before touching a single record, list every system that puts your domain in the From: line, because a record you publish without knowing the sender will lock that sender out.

For each sender, record six things: the system, the vendor, the exact From: domain (main domain or a subdomain), whether it writes to guests or to staff, who holds its credentials, and who can change its settings. Most of the work of email authentication is this list, not the records themselves. A hotel that cannot produce it cannot safely enforce anything.

Typical entries include the hotel operating system sending confirmations, the booking engine, the newsletter and campaign tool, front desk and sales mailboxes, the accounting or e-invoice sender, the website contact form, a survey tool, and any agency sending on the hotel's behalf. Note who sends on your behalf too: a group head office, a representation agency or a campaign partner may put your domain in the From: line, and each one belongs on the list.

Ask each vendor two questions in writing: which SPF entry do we add for you, and what is your DKIM selector and key length. A vendor that cannot answer both is a vendor whose mail will fail. Get the answers in writing so you can hold them to it later.

Prefer a subdomain for marketing. A newsletter sent from a separate subdomain carries its own records and its own policy, so a mistake there never touches booking confirmations. Keep the inventory as a living document with a date and a named owner; it is the first thing anyone needs when a confirmation stops arriving.

This inventory also belongs inside your broader hotel cybersecurity checklist for owners and general managers, because the systems that send your mail are the same systems that hold guest data.

What are SPF, DKIM and DMARC in plain words?#

They are three entries in the domain name system (DNS), the internet's address book, and each answers a different question about a message.

SPF is a list, published in DNS, of the servers allowed to send mail for the domain. The receiving server compares the server that delivered the message with that list. There is one SPF record per domain, never two, and it has a fixed limit on how many extra lookups it may make, so stacking many vendors' entries can break it. When a hotel adds a fourth sender without checking, the whole record can silently stop working.

DKIM is a signature. The sending system signs each message with a private key, and the matching public key sits in DNS under a selector name. The receiver checks the signature, so a message altered in transit fails. Google requires keys of at least 1024 bits and recommends 2048 (Gmail Help, answer 81126, 2026).

DMARC is a policy. It sits at a fixed name under the domain and tells the receiver what to do when a message fails both SPF and DKIM alignment with the visible From: domain: nothing (none), treat as suspicious (quarantine), or reject. It also names where reports are sent, which is how you learn what is happening in your name.

Alignment is the idea that ties the three together. SPF or DKIM must pass for the same domain the guest sees in the From: line, not for some other domain in the message. DMARC needs at least one of the two to pass and align; with neither, the policy has nothing to act on and the message is judged as unauthenticated.

None of the three encrypts anything or reads the content. They answer two questions only: was this sent by someone the domain owner allows, and was it changed on the way.

In what order should a hotel set this up?#

Authenticate every sender first, then publish DMARC in monitor mode, then tighten. Reversing that order is how hotels lose their own confirmations.

Step one is the sender inventory. Step two is one SPF record that covers every sender on it. Step three is DKIM switched on for each sender, with the signature confirmed as passing before you move on. Step four is DMARC at policy none with a reporting address, left in place while reports accumulate. Step five is fixing or removing every legitimate source the reports show as failing. Step six is quarantine, then reject, once the reports are clean.

Google's Email sender guidelines (Gmail Help, answer 81126, 2026) require all senders to Gmail accounts to set up SPF or DKIM, and senders of 5,000 or more messages a day to set up both plus DMARC, with the policy allowed to be none. The same source says enforcement has been ramping up since November 2025, with temporary and permanent rejections for messages that do not meet the requirements. Waiting is not a strategy; the requirements are already being enforced.

Keep a rollback note: the exact previous value of every record, who changed it and when. A mistake then takes minutes to undo instead of a day. Do not delete a former vendor's entry the day you stop using them; confirm nothing still sends from that system first. And keep transactional mail and marketing mail apart where you can, because they have different failure modes and different reputations.

How do you read DMARC reports with your IT provider?#

The reports are machine files listing every server that sent mail as your domain and whether it passed. Their only use is to tell you which sources to keep and which to stop.

Two kinds arrive: aggregate reports, sent daily by most large mailbox providers, and failure reports, sent by some and not others. Plan on aggregate reports and treat the rest as a bonus. Each entry shows the sending server's address, the domain it claimed, how many messages it sent, and whether SPF and DKIM passed and aligned.

Read the reports as three lists: sources you recognize and can name, sources you recognize but had forgotten (an old newsletter tool, a booking engine test environment), and sources you cannot explain. The third list is either a forgotten system or someone sending as you. Watch for sources that appear only at month end, such as an accounting, reporting or backup system that sends on a schedule.

Ask the provider for a one-page monthly summary: every source, its owner, pass or fail, and the action taken. A raw file nobody reads protects nothing. Reports arrive even at policy none, which is precisely why the monitor stage exists, and why it should last weeks rather than hours.

If the report vocabulary is unfamiliar, the same plain-language discipline applies as with phishing, ransomware and two-step sign-in: the terms are few, and each one names something concrete.

How do you check a confirmation email from the guest's side?#

Send a real confirmation to a mailbox you control, open the message's original headers, and read three lines: spf, dkim and dmarc.

In a Gmail mailbox, the show original view gives the authentication results; in an Outlook mailbox the message headers show the same lines. Ask the IT provider to walk through it once, then keep the habit. Look for spf=pass, dkim=pass and dmarc=pass, and check that the domain in those results is the one the guest sees, not a vendor's domain.

Check the visible From: name and address, the reply-to address, and that links point to your domain rather than a shortened or third-party one. Then check the journey, not just the record: book on the website from a phone, late in the evening, and see whether the confirmation arrives within a minute and renders properly on a small screen. For marketing mail, confirm a visible unsubscribe link and one-click unsubscribe, which Google's guidelines require of bulk senders (Gmail Help, answer 81126, 2026).

Repeat the check after any change of vendor, domain or DNS host, and once a quarter otherwise. Record the result with a date, so that when something breaks you know what changed and when.

The same test tells you whether your pre-arrival emails are actually reaching guests, not just being sent.

Who should hold the domain and the DNS settings?#

The hotel should own the domain registration and reach its DNS settings directly. The agency should work through delegated access, never through ownership.

Register the domain in the hotel company's name, under a registrar account the hotel controls, with a contact address the hotel itself owns. Keep at least two people at the hotel who can sign in to the registrar and the DNS host, and keep renewal dates and the transfer lock in a written record. Give the agency its own account with access to the records it needs, so that access can be removed in one step when the relationship changes.

Keep a change log: date, record, old value, new value, who did it, why. Authentication breaks are almost always an unrecorded change made by someone with good intentions. Name one person who may change the DMARC policy, and require the change log entry before the change, not after. If the relationship ends, the domain, the DNS zone and the records stay with the hotel; test that you can still reach them before you need to.

What to do next#

This week, write the sender inventory and send every vendor on it the same two questions: which SPF entry do we add for you, and what is your DKIM selector. Then publish DMARC at policy none and read the reports for a month before tightening. The records themselves are small. The list of senders behind them is the work, and it is the part that decides whether the confirmation arrives and the fake does not.