Masked Email and the Message That Still Lands

A masked address looks like a dead end. It is a working route, as long as you send from the right place.

Last updated: October 31, 2026

A masked address isn't a broken address. It's an alias the platform issues for one booking, it relays to the guest while the stay is live, and it stops when the booking closes. Most messages that vanish were sent from the wrong door: a fresh compose window instead of a reply, a changed subject line, an attachment that had nowhere to go. Fix the route and the guest is reachable.

Key Takeaways

• It's an alias, not a mailbox. It belongs to the platform and it exists for the length of one booking.
• Reply, don't rewrite. Answer the message you received, and let the address that brought it stay exactly where it is.
• Plain text travels better. A short body, one question, dates and the property named inside it.
• A silent thread is a signal. Two unanswered messages means the route is wrong, not that the guest is ignoring you.
• Move to the thread when it matters. Money, changes and same-day arrivals belong in the channel, where the record is.

What a masked address actually is

Start with what you're looking at. The guest booked through a platform. The platform issues an address for that booking, and anything sent to it gets passed on to the guest's real inbox. The guest's real address stays hidden, and yours may stay hidden from them too. From the host side, the alias is simply the address you were given.

Three consequences follow, and each one explains a failure hosts blame on the guest.

The alias has a lifetime. It works while the booking is active and stops when it closes. A message sent two months after checkout, to the same address, goes nowhere — and nothing bounces back to tell you so.

The alias carries no context. It doesn't know your property name, your street or which of your three units the guest booked. Everything the guest needs to understand the message has to be inside the message.

The alias isn't a contact record. You can't add it to a mailing list, use it for the next stay, or treat it as consent to market anything. It's a route for one conversation, and treating it as a customer record is how hosts end up with an unsubscribable list of addresses that no longer resolve.

None of that makes the route fragile. It makes it specific. Specific routes work well when you use them the way they were built.

Two routes that still reach the guest

There are two ways a message gets to a guest who booked through a channel, and they fail in different ways.

The reply route. The guest writes to you through the channel, the platform passes the message on, and you answer it. As long as you reply to that message — keeping the alias in the recipient field and leaving the subject as it arrived — the reply follows the same path back. This is the route that works most reliably, and it's the one that requires you to change nothing.

The thread route. The channel's own messaging keeps the conversation inside the platform, where the booking record already sits. Nothing is relayed, nothing can be filtered, and the guest sees the message the next time they open the app. It's slower to write in and far harder to lose.

What tends not to work is a hybrid. Typing the alias into a fresh email, changing the subject so it reads better, copying a second address in, or adding a colleague halfway through. Each of those breaks the thing that made the route work, and none of them produces an error you can see.

localsbnb.com puts Airbnb, Booking.com, Agoda and Trip.com on one calendar, so a booking's channel is visible next to the stay rather than something you have to remember. That matters here, because the route you should use depends on which channel the booking came from — and knowing that at a glance saves the guesswork on a Friday night.

Writing a message that survives a relay

Write for a relay rather than for a mailbox, and the message gets through more often.

Keep the body plain. A short paragraph, no coloured template, no signature block with four images in it. Rich formatting is the first thing a filter has reason to touch, and a message that arrives as an empty box is worse than one that never left.

Put the booking inside the text. "Your stay at the two-bedroom on Soi 8, arriving Friday 6 November" does the work that the alias can't. A guest reading it on a phone, three days after booking, needs the reminder more than they need the pleasantries.

Ask one question. A message with four asks gets one answer, usually to the easiest. If you need an arrival time and a bed configuration, send the arrival time first and the second question once the reply arrives.

Say where to look, rather than pasting a link. Links are the part of a message most likely to be stripped or held, and a guest who can't see the link can't follow the instruction attached to it. "Open the booking in the app and check the check-in section" survives a filter in a way a URL doesn't.

End with the next step in the same thread. Ask the guest to reply there rather than to call, because a reply keeps the route open and a call leaves no record you can point at later.

Then wait longer than feels natural. A relayed message can sit between two systems for a while, and a host who sends three follow-ups in an hour is training the guest to ignore all of them.

When to move to the in-app thread

The relay is fine for routine messages. It's the wrong tool for four situations, and recognising them is most of the skill.

Move to the thread when the question involves money — a refund, an extra night, a damage claim — because you'll want the exchange in one place if it's ever disputed. Move it when the guest asks for a change to the booking, since the channel is where the change has to happen anyway.

Move it when the arrival is within a day. At that point the message needs to be seen now, and the thread is the only place with a notification the guest is already looking at.

And move it after two unanswered messages. Two is the number. One can be a guest on a plane. Two means the route isn't working, and a third message down the same path is a waste of a day.

Once you move, say so. A single line — "I've moved this into your booking messages so it's all in one place" — stops the guest wondering why the emails stopped.

There's one more thing worth knowing about where the thread lives. Inside LOCALSBNB, the guest inbox covers Airbnb conversations. A booking from another channel keeps its thread in that channel, which is fine as long as you know which window to open. The calendar tells you which channel it is; the message itself lives where the booking lives.

FAQ

Why did my message to a guest disappear?

Three common causes, and none of them involve the guest. The alias had expired because the booking closed. The message was composed fresh rather than sent as a reply. Or the formatting was heavy enough that it arrived as an empty body. Check which of the three applies before you send a fourth message.

Can I keep the masked address for the guest's next stay?

No. The alias belongs to the booking, not the person, and the next stay will come with a different one. Anything you want to carry forward — a preference for a late check-in, a note about the parking — belongs in your own record against the guest, not in an address you saved.

Is the channel thread always better than email?

For anything that matters, yes. It's slower to write in and it keeps the exchange where the booking is. Email is better for a single routine question, where speed matters more than the trail. Most hosts end up using both, and the discipline is knowing which one a given message deserves.

Two routes, one plain message, and a rule for when to move. localsbnb.com keeps the four channels and their bookings in one calendar, so the question "which route does this guest need" has an answer you can see before you start typing.

---

This article is general guidance for hosts and isn't legal, tax or insurance advice. What a platform relays, and for how long, is set by that platform and can change. Check the current partner terms and the message rules for each channel you use before you rely on a route.