Skip to main content
The verification email proves booking linkage through the booking email already on file. It must be warm and safe, but never leak booking-private details.

​
Delivery Rule

Verification emails go only to the booking email already on file. Guest-entered email is never trusted as the destination. The guest may supply information that helps find a candidate booking, but the delivery destination is owned by the booking record.

​
Privacy Boundary

The verification email must not expose: 
booking ID
booking email
payment details
stay dates
private booking details
The guest-facing chat must not expose: 
email address
token
magic URL
private booking detail

​
Current Implementation

Current email implementation: 
Resend-backed delivery implemented
email design matches the HelloLucia.ai waitlist email design
Engine branded verification result page matches the verification email design
magic-link URL hardening avoids duplicated paths
opaque token link is consumed by Engine
verified session can be checked after token consumption
This is current live-development implementation. Deliverability, rate limiting, replay defense, and production consent copy remain hardening work.

​
Tone Contract

The email should feel: 
warm
clear
legitimate
privacy-safe
hospitality-native
It should not feel: 
alarming
robotic
procedural
like a security trap
The guest should understand that Lucia is helping verify the connection without seeing private booking information.

​
See Also