Business email for hotels: reservation mailboxes, shared access and leavers

A hotel email setup done properly means one domain the hotel owns, role addresses such as reservations@ and info@, and a shared mailbox that each person opens with their own login. Nobody shares a password, every reply carries a name, and a leaver's access ends the day they leave.

The reservations address is a free consumer mailbox registered years ago in someone's name, three people on the shift know the password, and the receptionist who left in October still has it saved on a phone at home. This pattern is common in independent hotels and it holds up right up to the day it does not: a disputed booking, a locked account, a departure. After reading this guide you will be able to audit your current setup, move reservations onto a domain the hotel controls, and handle leavers and season end without losing mail or sleep.

What goes wrong when reservations runs on a free mailbox and a shared password?#

Everything works until a person leaves, a booking is disputed or the account is locked, and then nobody can prove who said what. The problem is not the free service; it is that the account belongs to a person and the password is the only key.

The mailbox is registered to an individual or a personal phone number, so account recovery runs through whoever signed up, not through the hotel. If that person is on holiday, unreachable or no longer friendly with the hotel, the recovery path runs through them anyway. The hotel's reservations history lives inside an account it does not control.

One password across shifts removes attribution. The sent folder shows the mailbox, never the person who wrote the reply. When a guest says a late cancellation was accepted by email, no one can show who wrote what and when. There is no audit trail, and in a dispute the hotel has nothing to point at.

Changing the password means telling the whole team at once, so in practice it stays unchanged for years, and former staff keep full access from personal phones. Free tiers also cap storage and attachment size, so a rate sheet or a scanned contract bounces or disappears without anyone noticing. And a guest paying a serious sum for a stay sees a consumer address on the confirmation, which reads as informal and is trivial for anyone to imitate.

Who should own the hotel's domain and the mailbox accounts?#

The hotel company owns both, in accounts the company controls and can recover without any single employee. Ownership is a paperwork question before it is a technical one.

The domain registrant should be the company, not the general manager, the web agency or the consultant who set up the website. Whoever can edit the domain's DNS settings, the records that tell the internet where the hotel's mail and website live, can redirect the hotel's mail to another server. DNS access is mail access, so it must be listed and limited like any other key.

Keep the registrar and mail admin logins in company-controlled accounts, with a recovery method the hotel holds, such as a company phone kept in the office safe rather than a personal mobile. Put the domain and mail subscription on a company card with a long expiry, so a departed employee's cancelled card does not take the mail down at renewal.

Write down who holds admin rights today, and review that list once a year and at every change of management. When a hotel changes hands or management companies, domain and mailbox administration is part of the handover, alongside keys and contracts. The same ownership discipline applies to the website itself, as covered in hotel website security and ownership: domain, certificate, updates and logins.

Which email addresses should a hotel have?#

A small independent hotel needs three to six role addresses, each with a named owner, and one shared mailbox behind the busiest of them. Fewer, well-read addresses beat many that nobody opens.

Role addresses describe a job, not a person, so they keep working when staff change. Personal addresses are for internal identity only. A shared mailbox is one address several people can open, each signing in with their own account; an alias only forwards and keeps no shared state. Use send-as, a setting that lets a person reply from reservations@ while the mailbox log still records which person sent the message.

Give every address an owner and a backup owner, and delete addresses nobody is prepared to read. Keep the guest-facing set stable: changing the reservations address breaks old confirmations, printed material and saved contacts. Decide where channel notifications land before you create addresses, so booking alerts do not compete with guest questions in one inbox.

How does a team answer from one mailbox without stepping on each other?#

Agree two visible habits: a message is claimed before it is answered, and a reply is signed by the person who wrote it. The mailbox then shows both the hotel's voice and the individual behind it.

Claim the message first: move it to a folder named for the person, or apply a category, so the second person on shift can see it is taken. Leave a one-line internal note with the time and what was sent, so the next shift knows the state without reading the whole thread. Reply from the shared address and sign with your own name; the guest sees one hotel, the team sees one person.

Close the loop in the hotel system: once the booking is confirmed, record the confirmation number and mark the thread done, so the mailbox and the reservation do not disagree. Set a response expectation per shift and write a short handover note at every shift change listing open threads and promised callbacks. Turning these threads into actual reservations is its own discipline, covered in phone, email and WhatsApp booking requests: turning inquiries into reservations.

One hard rule: never forward guest mail to a personal address to finish it at home. That copy is outside every control the hotel has, and it survives every offboarding step you will ever run.

What should never be stored in the reservations mailbox?#

Identity documents, card details and signed forms should not sit in a mailbox, because a mailbox has no retention rule and no reliable deletion. Personal data in an inbox is still personal data, and the inbox is the least controlled place to keep it.

Passport and identity card scans, driving licences, credit card authorization forms and contracts carrying card numbers do not belong in email. Every forward, reply and backup creates another copy, so a document sent once can exist in five places nobody can list. In Türkiye, every stay involves a payment, a fiscal document, a guest identity notification (KBS, misafir kimlik bildirimi) and personal data under KVKK (kişisel verilerin korunması kanunu), so the volume of documents flowing toward a reservations desk is real, which makes the rule matter.

Prefer channels you control: ask the guest to complete details at the front desk on arrival, or through the hotel's own guest application, rather than as an attachment. If a document must arrive by email, move it into the controlled system and delete the message, then let the retention table decide how long the record lives. Decide retention per record type with your adviser, write it down, and actually delete on schedule; an unwritten rule is not a retention policy. Building that table is covered in how long should a hotel keep guest records? Building a retention and destruction table.

Train the team on the rule in one page, because the failure is almost always a helpful receptionist forwarding a passport to a colleague.

What do you do with a leaver's mailbox, and at season end?#

Decide before the last working day whether the mailbox is redirected, delegated or closed, and who approves it. Do not leave it running because nobody wanted to choose.

There are three options, chosen in advance: redirect to the manager or team address for a fixed period, delegate read access to a named colleague, or close with an auto-reply giving the new contact. Reading the contents of a former employee's mailbox is a personal-data and labour-law question, not an IT preference; take written advice, and put the rule in contracts and the staff handbook before you need it. Business mail and personal mail can share one mailbox, so do not assume everything inside belongs to the hotel; your adviser decides how that is handled.

Seasonal staff accounts are disabled on the last day of the contract, with a calendar reminder set when the contract is signed, not when someone remembers. Keep one offboarding checklist covering mail, the hotel system, the guest application admin, shared drives, Wi-Fi, door codes and any hotel phone. Hand over open threads in writing: unanswered inquiries, promised rates and pending group quotes, so nothing dies in a closed inbox.

How do you make sure hotel email arrives and cannot be faked?#

Three records in the domain's DNS settings tell the world who may send mail as the hotel and what to do with anything else: SPF, DKIM and DMARC. Without them, a genuine confirmation can land in spam and a fake one can carry the hotel's name.

SPF is a list of the servers allowed to send for the domain; anything not on the list is suspect. DKIM adds a cryptographic signature to each outgoing message, so a receiving system can check it was not altered on the way. DMARC tells receiving systems what to do when a message fails those checks, and sends the hotel reports about who is sending as it.

Start DMARC in a monitoring setting, read the reports for a few weeks, then move to a rejecting setting once legitimate senders are covered. Add every legitimate sender first, including the booking engine, the hotel system and any newsletter tool, or you will block your own confirmations. Test after every change by sending to several external addresses, and re-check whenever a new system starts sending mail for the hotel. The mechanics are covered step by step in SPF, DKIM and DMARC for hotels: confirmation emails that arrive, fakes that do not.

What to do next#

Name one person who owns the hotel's mail, list every address and every person who can open it, then move the guest-facing addresses onto the hotel's own domain as shared mailboxes with individual logins. That single step fixes attribution, revocation and handover at once. The domain ownership work and the SPF, DKIM and DMARC records are the two follow-ups that keep it standing.