Check the sender before relying on booking confirmation emails

Decide which sending path you are accepting

Before switching routine confirmations to a new booking app, ask the supplier to demonstrate the actual customer-facing sending path. A preview of a template, or an email sent manually by a sales representative, does not demonstrate what happens after a customer books. Use a staff-controlled test booking with invented customer details. This is an onboarding check; it does not assume your business already has a delivery problem.

Agree whether customers should see the app supplier’s domain or your own business domain in the From address. A supplier-managed identity may be an acceptable starting point if the business accepts how it appears to customers. A business-domain identity needs the supplier’s supported setup and someone authorised to change domain records. Ask about plan restrictions, setup charges and access to sending evidence before choosing. Also decide who will receive customer replies; the displayed sender and reply destination belong in the acceptance record.

Give each part of the route an owner

Create one inventory row for each app and sending identity, separating confirmations, reminders and cancellation notices if they use different settings. The booking supplier and the mail provider may be the same company, but confirm that instead of inferring it from the logo. Record roles and support contacts, not passwords. Keep the inventory narrow enough for a shop manager to use when a test needs repeating or a supplier asks who can make a change.

Keep the result from a real test message

Send the test directly to a personal Gmail mailbox you control. In browser Gmail, open that message and use the More menu beside Reply, then Show original, following Google’s header guide. Save the sample’s date, booking reference and Message-ID alongside the original headers in a restricted project folder. Ask the supplier to explain the receiving service’s Authentication-Results, including each recorded SPF, DKIM and DMARC result and the domains involved. Use test data so the evidence can be shared with support without exposing customer appointments.

SPF checks whether a sending host is authorised for a domain; DKIM provides a verifiable signature. Google’s authentication help identifies spf=pass or dkim=pass in the headers as evidence of those checks passing. Write down which domain passed, rather than copying only the word pass. A result for a supplier domain needs to be understood in relation to the From identity you agreed. For a business-domain setup, ask the supplier to explain DMARC alignment with that visible identity.

Keep three observations separate: the app generated a message, the received sample passed the relevant authentication checks, and the sample appeared in a particular mailbox folder. None establishes every future delivery. If a message never arrives, request the app’s sending record and any rejection or delay response; there is no received header to inspect. If authentication passes but the message lands in spam, investigate delivery separately. Do not describe either case as proof that the booking itself failed.

Apply Gmail requirements within their scope

Google’s sender guidelines apply to personal Gmail accounts. Their authentication baseline is SPF or DKIM; bulk senders additionally need SPF, DKIM and DMARC, with alignment for direct mail. TLS and valid forward and reverse DNS are also required. These are selected requirements, not a complete compliance checklist. Ask the mail provider to confirm the applicable sending-volume category and the full requirements. Authentication does not guarantee inbox placement, and these Gmail rules are not a universal policy for every receiving service.

For a Hong Kong business serving both Chinese- and English-reading customers, repeat the agreed booking journey in both template languages. Check the appointment time, location, reply destination and whether each sample used the intended sender. Also send to another staff-controlled mailbox on a service relevant to your customers. Treat this as broader delivery observation, not certification against Gmail rules. Record exactly which templates and receiving services were tested so an untested reminder is not silently included in the sign-off.

Accept, fix or consider a different provider

Consider an illustrative salon onboarding: the first test uses the app’s own From domain, although the manager expected the salon’s domain. Even if the sample is authenticated, the agreed identity has not been demonstrated. Ask whether the existing subscription supports the required identity and obtain its setup instructions. After an authorised administrator applies the agreed change, repeat the booking test. In a repair shop that accepts a supplier-managed sender, the same route could be acceptable once its identity, results and reply handling are documented. These are decision examples, not reported customer outcomes.

Start the budget discussion with a configuration check from the current supplier. Request a named owner, the missing evidence or change, any charge and a retest date. Consider migration only when a documented limitation prevents the required sender identity, evidence or support arrangement. Compare the replacement’s subscription, integration work, domain changes and repeat testing before committing. While a required check remains unresolved, nominate a staff member to confirm test-period bookings through an agreed existing contact method and record that contact to avoid conflicting confirmations.

Your next action is a short acceptance session with the shop manager, app support and domain administrator: complete the inventory, inspect an actual sample and assign every unresolved item. If the findings reopen the software choice, use the existing SaaS comparison guide to assess the wider trade-offs. If the issue is a separately operated connection, the system integration service scope can help frame a bounded investigation using your evidence pack.