Booking.com Setup to ensure email & link delivery

Overview

Booking.com protects guests by hiding their real email address. Instead of the guest's personal address, your reservation carries an alias on the guest.booking.com domain, and Booking.com forwards anything sent to that alias on to the guest. Because Booking.com sits in the middle, it applies its own security rules to that traffic: Messages coming from a sender it does not recognize, and messages containing links to domains it does not recognize, can be filtered, stripped of their links, or blocked entirely. When that happens, you may also receive a warning notification inside your Booking.com Extranet.

Duve sends your confirmation emails, pre-check-in invitations, arrival messages, and guest app links to that alias like any other email address. To make sure those emails arrive intact and the links inside them stay clickable, you need to tell Booking.com two things: which address Duve sends from, and which link domains Duve uses.

This article covers the Duve side of that setup (verifying your sending domain and knowing your exact sender address and link domains) and the Booking.com Extranet side (allowlisting them).

Use cases

Guests booking through Booking.com are not receiving your Duve confirmation email or pre-check-in invitation.
Guests receive the email, but the guest app link is missing, greyed out, or not clickable.
You received a notification in your Booking.com Extranet about an unapproved sending address.
You are rolling out a custom sending domain in Duve and want Booking.com deliverability to keep working after the change.
You are onboarding a new property that takes a high share of Booking.com reservations and want delivery working from day one.

Before you start

Confirm you have manager permissions in Duve, since Settings is required.
Confirm you have administrator access to the Booking.com Extranet for each property you need to configure. Booking.com settings are managed per property.
If you plan to send from your own domain rather than Duve's default, get access to your DNS provider (for example, GoDaddy, Cloudflare, Route 53, or your IT team). You will need to add TXT and CNAME records.
Decide which sending address you want to use before you start, because that is the exact address you will allowlist in Booking.com. Changing it later means updating Booking.com again.

How to set it up

Step 1: Find or set your Duve sending address

Everything you allowlist in Booking.com depends on the address Duve actually sends from, so start here.

In Duve, go to Settings > Advanced > Domain verification.

You will see one of two states:

You are using Duve's default domain. The page shows mail.duve.co as the sending domain. Your guest emails go out from an address on mail.duve.co, and that is what Booking.com sees. This works, but the emails are not branded with your own domain.
You have a verified custom domain. The page shows your domain with a green check mark, plus a field where you set the local part of the sender address. Your emails go out from [prefix]@[your verified domain], for example reservations@yourhotel.com.

Write down the full sending address exactly as it appears. You will paste it into Booking.com in Step 3.

Step 2: Verify your own domain in Duve (recommended)

Verifying your own domain is not strictly required for Booking.com delivery, but it is strongly recommended. Emails sent from your own verified domain are far more likely to pass Booking.com's checks and the guest's own spam filters, and they carry your brand.

Go to Settings > Advanced > Domain verification.
Under Setup Custom Mail Domain, enter the domain you want to send from, then start the verification.
Duve generates the DNS records you need to add at your DNS provider. There are three groups:
- A TXT (SPF) record on your root domain, with the value v=spf1 include:amazonses.com ~all.
- Two TXT records: one named _amazonses.[your domain] holding the verification token, and one named [key id].[your domain] holding a matching key value.
- Three CNAME records for DKIM, each named [token]._domainkey.[your domain] and pointing to [token].dkim.amazonses.com.
Use Export (CSV) to hand the full list to whoever manages your DNS.
Once the records are live, click Test DNS setup. Duve re-checks every record and shows a green check mark next to each one that resolves correctly.
When all records pass, the domain is marked as verified, and you can set the sender prefix, so emails go out as [prefix]@[your domain].

Troubleshooting notes:

Note that the domain is only marked as verified when every single record passes. A partially verified domain keeps sending from mail.duve.co.
If your account uses multiple brands, domain verification is configured per brand as well as at the company level. Verify the domain for each brand that sends guest emails, and allowlist each resulting sender address in Booking.com.

Step 3: Allowlist your sending address in the Booking.com Extranet

Do this for every property that receives Booking.com reservations.

Sign in to your Booking.com Extranet.
Open Property > Messaging preferences > Security settings.
Add the exact Duve sending address you noted in Step 1. If you are on Duve's default domain, that is your address on mail.duve.co. If you verified your own domain, it is [prefix]@[your verified domain].
If you run multiple brands or multiple sender prefixes in Duve, add each one.

Step 4: Allowlist the Duve link domains

Even when your sender address is approved, Booking.com can strip or block links pointing to domains it does not recognize. Duve's guest-facing links live on the following domains, so add them to the approved or trusted links list in the same Booking.com security settings area:

m.duve.co is the default guest app domain. Every guest app, pre-check-in, and guidebook link Duve sends uses this domain unless your account has a custom guest subdomain.
[your prefix].duve.co is your dedicated guest app subdomain, if one has been provisioned for your account. Check a real guest link from a recent reservation to see which domain your account actually uses.
duve.co is the parent domain for both of the above. Adding it covers you if your guest link domain changes.
[your verified domain] Should be added if you verified your own domain in Step 2, because your sender address and any links you add to your own templates will use it.
Add duve.com if your email templates actually contain links to it. duve.com is Duve's corporate website, not the guest app domain, so it is not needed for guest links to work.

Troubleshooting note: Make sure that the "Block" toggle is off for both "all email communication" and "all links"

Step 5: Test end to end

In Duve, open a real or test reservation that came from Booking.com and confirm the guest email is the guest.booking.com alias.
Trigger or resend the confirmation email or pre-check-in invitation.
Check the message thread in your Booking.com Extranet inbox to confirm it went through and that the guest app link is intact and clickable.
Open the link yourself to confirm it resolves to the guest app.

Troubleshooting

The SPF record shows an error such as "SenderID record found, but markup incorrect." Your domain has an SPF record, but it does not meet all three requirements. It must be the only SPF record on the domain, it must include include:amazonses.com, and it must end with an all mechanism such as ~all or -all. Merge any additional SPF records into a single record rather than publishing two.
The DNS records still show as failing after you added them. DNS changes take time to propagate, and some providers cache for several hours. Wait, then click Test DNS setup again. Also check that your provider did not silently append your domain to a record name that already contained it, which produces names like _amazonses.yourhotel.com.yourhotel.com.
You cannot enter your domain in Duve at all. Duve does not accept domains starting with www., public email provider domains such as gmail.com or outlook.com, or Duve's own domains. Use the root domain you control, for example yourhotel.com.
Emails arrive, but the link is removed or not clickable. The sender is approved, but the link domain is not. Go back to Step 4 and confirm the exact domain in your guest links matches what you allowlisted.
Everything is configured, and delivery still fails for some reservations. Confirm those reservations really are Booking.com reservations with a valid ten-digit Booking.com reservation number. Reservations that reach Duve without a proper Booking.com identifier are treated as ordinary reservations.
You changed your sender prefix or verified a new domain. The old address is allowlisted, and the new one is not. Repeat Step 3 with the new address.

Restrictions & limitations

Booking.com's security settings are managed per property in the Extranet. Configuring one property does not configure the others.
Booking.com controls whether a message reaches the guest. Allowlisting improves delivery; it does not guarantee it, and Booking.com can change its filtering rules at any time.
Emails sent to an guest.booking.com alias are forwarded by Booking.com, so you have no visibility into whether the guest actually opened them beyond what Booking.com reports.
A Booking.com alias stops forwarding once the stay is over, so post-stay messages sent to it may not reach the guest.
Duve treats OTA masked addresses as invalid contact details during pre-check-in, so a guest whose only address is the Booking.com alias is asked to provide a real one.

Tips & tricks

The most durable fix is to collect the guest's real email address. When a guest completes pre-check-in, Duve asks for a real address because it recognizes the guest.booking.com alias as masked. From that point on, your emails go directly to the guest and Booking.com's filters are out of the picture entirely.
If you connect Booking.com to Duve as a messaging source, you can reach Booking.com guests through Booking.com's own message thread rather than through email. That channel is not affected by email sender filtering and is worth enabling alongside this setup.
Run "Test DNS setup" again after any DNS migration, since a provider change can drop the SPF and DKIM records without warning.

FAQs

Q: Do I have to verify my own domain, or can I stay on Duve's default?

A: You can stay on Duve's default mail.duve.co domain and still allowlist that sender in Booking.com. Verifying your own domain is recommended because it improves deliverability overall and brands your emails, but it is not a hard requirement for this setup.

Q: Which exact email address should I add to Booking.com?

A: The full address Duve sends from, which you can read on the Domain verification page. It is an address on mail.duve.co if you use Duve's default, or [prefix]@[your verified domain] if you verified your own. Add the address, not just the domain.

Q: Why do I need to allowlist links as well as the sender?

A: Booking.com filters sender addresses and link destinations separately. An approved sender can still have its links stripped if the link domain is not recognized, which is why guests sometimes report receiving the email with no working guest app link.

Q: Which link domain does my account use?

A: Most accounts use m.duve.co. Accounts with a provisioned guest subdomain use [your prefix].duve.co. Open a guest link from a recent reservation to see which one applies, and allowlist duve.co as well to cover both.

Q: Do I need to add duve.com?

A: Only if your email templates link to it. duve.com is Duve's corporate website and is not used for guest app links, so it is not required for delivery.

Q: How long does domain verification take?

A: The records are generated immediately, but DNS propagation usually takes from a few minutes to a few hours depending on your provider. Click Test DNS setup to re-check. The domain is only marked verified once all seven records pass.

Q: I have several brands in Duve. Do I configure this once?

A: No. Domain verification is available per brand as well as at the company level, and each brand can send from a different address. Allowlist every sending address your account uses.

Q: Why does Duve ask my Booking.com guest for an email address during pre-check-in when one already exists?

A: Because the address on the reservation is a Booking.com alias, not the guest's real address. Duve recognizes OTA-masked addresses and asks for a real one so that future messages reach the guest directly.

Q: Does this setup also affect SMS and WhatsApp?

A: No. This article covers email and the links inside emails. SMS and WhatsApp are separate channels with their own configuration and are not filtered by Booking.com.