Email Verification for Hotels: Cleaning a Guest List Full of OTA Aliases

SimpleVerifier Team·3 November 2026·3 min read

Key takeaways

Booking.com's partner help says it doesn't share guests' private email addresses: you see an anonymous alias ending in @guest.booking.com, and messaging runs from booking until seven days after check-out or cancellation.
Those aliases are reservation relays, not marketing addresses. Take them out of a newsletter or win-back list before you verify anything.
Direct bookings, front-desk sign-ups and Wi-Fi portal addresses are the part worth verifying. They pick up typos at check-in and go stale as guests change jobs.
Verify before the seasonal send, not after: a guest list mailed once or twice a year is exactly the kind that bounces.
Some addresses won't confirm either way. Catch-all company domains and many Microsoft consumer mailboxes (outlook.com, hotmail.com) come back risky or unknown.

Before you verify a hotel guest list, take out the booking-site aliases. A PMS export mixes two kinds of address: ones guests gave you directly, and relay aliases that online travel agencies put on the reservation instead of the real address. Booking.com's partner help is explicit that it doesn't share private email addresses. The aliases are for that stay, not for your newsletter. Remove them, then verify the rest.

Sources, read 2 November 2026: Booking.com for Partners, contacting guests (alias domains, the seven-day messaging window, the 14-day reply window), and Booking.com's messaging security settings.

What's in a guest export

Source	Example domain	Verify it?
Booking.com reservation	`@guest.booking.com`	No. Relay alias, not the guest's mailbox
Other OTA reservations	Each OTA's own relay domain	No. Check the OTA's partner help for its alias rules
Direct booking engine	Guest's own domain	Yes
Front desk / check-in form	Guest's own domain	Yes, and expect typos
Wi-Fi portal sign-ups	Guest's own domain	Yes, and expect fake ones
Group and corporate bookings	Company domain	Yes, often the booker, not the guest

Booking.com says you and your guests only see an anonymous alias ending in @guest.booking.com or @partner.booking.com. You can message the guest from booking until seven days after check-out or cancellation, with a 14-day window to reply when the guest writes to you. Booking.com's security settings also let it block mail from addresses you haven't registered. None of that describes a marketing channel.

Step by step

Export guests from your PMS with the email, the booking channel, the last stay date and the marketing consent field, if your PMS stores one.
Strip the relay domains. Paste the list into remove emails by domain and remove guest.booking.com, partner.booking.com and any other OTA relay domain in the export. Sort by domain first to spot them; they repeat thousands of times.
Keep only guests who agreed to marketing, under the rules that apply to you. Consent rules for past guests differ by country; see is email verification GDPR-compliant? for the European side.
Remove obvious junk: front-desk placeholders such as noemail@, none@ or the hotel's own address typed in when a guest wouldn't give one. The role-based email filter catches info@ and reservations@ addresses of travel agencies.
Verify the remainder on the verify page. Remove invalid results; that's where check-in typos such as gmial.com end up.
Send the risky and unknown group last, in a small batch. Watch bounces before you mail the rest.

What verification can and can't tell you here

Verification confirms the mailbox exists; it can't tell you the guest wants your email or still reads that inbox. And some results won't be firm: corporate bookers often sit on catch-all domains that accept every address, and many Microsoft consumer mailboxes (outlook.com, hotmail.com, live.com) don't answer single-mailbox checks reliably. Those come back risky or unknown, not invalid. The catch-all guide explains why.

The habit that fixes it

The cleanest guest list is the one you collect yourself. Ask for the address at check-in or on your own booking engine, say what you'll send, and check it there and then; a typo caught at the desk is one less bounce in March. For a list mailed only a few times a year, re-verify before each send. How often to re-verify gives a cadence.

Where SimpleVerifier fits

Once the aliases are out, upload the guest list on the verify page; the first 100 checks are free with a Google sign-in. Pro is $39 a month with the first 100,000 checks a month at full speed, then slower, never cut off. See pricing.

Common questions

Can I email Booking.com guests after their stay?

Booking.com's partner help says messaging is available from booking until seven days after check-out or cancellation, and that guests' private addresses aren't shared; you only see an alias ending in @guest.booking.com. Treat the alias as a channel for that reservation, not a marketing address.

Should I verify @guest.booking.com addresses?

No. They're relay aliases run by Booking.com, so a mailbox check tells you nothing about the guest, and the alias isn't meant for marketing. Remove them from marketing lists before verifying.

How do I get a guest's real email address?

Ask for it directly and with consent: at check-in, on your own booking engine, or through a Wi-Fi sign-in that explains what you'll send. An address the guest typed for you is the one you can verify and market to, subject to your local consent rules.

How often should a hotel verify its guest list?

Before each campaign to guests you haven't emailed in the last few months, and at least once a year for the whole list. Most hotels mail past guests seasonally, so each send goes to an older list.

Check your list before you send

Real mailbox checks over SMTP, and nothing is sent to the address. Sign in with Google and your first 100 email checks are free, no card. Plans for bigger lists are on the pricing page.