Design & Architecture

Email & Notifications

Intermediate

Email and other notifications are how we reach customers. They are also where a small mistake becomes a privacy breach (the wrong recipient), a security risk (a message that is easy to phish), or a delivery failure (everything lands in spam). Send with care: the right content, to the right person, clearly from us.

Notifications carry two risks people underestimate. First, content and addressing: an email can leak personal data to the wrong recipient, or include sensitive details it should not. Second, trust and delivery: if our domain is not configured properly (SPF, DKIM, DMARC), attackers can spoof our mail or it gets filtered as spam. And our customers are exactly the people phishers target.

Treat outbound messaging as a small product: a verified sending identity, minimal sensitive content, clear and hard to spoof, and resilient when the messaging provider fails.

Send safely

DoCheck that the recipient comes from the correct, current record. Wrong-recipient emails are a common, avoidable data breach.
DoKeep sensitive data out of the message body. Link to the secure app to view details instead of emailing PII, statements, or documents.
DoMake our messages hard to mistake for phishing and hard to spoof: a consistent sender, no 'click here and log in' patterns, and SPF, DKIM, and DMARC configured on our domain.
ConsiderLetting users control non-essential notifications, and honouring unsubscribe and communication preferences and consent (see Cookie Consent & Tracking and Privacy).
NeverEmail secrets, passwords, full card or account numbers, MFA codes, or special-category data. Share access through the secure app, not the inbox (see Secrets at Rest & in Transit).

Send reliably

DoSend through the approved provider via an interface you own, and treat it as a third party that can be slow or down (timeouts, retries, queue) (see Third-Party Integrations).
DoMake sends idempotent or deduplicated, so a retry does not send the same notification five times (see Asynchronous Messaging & Eventing).
DoSend transactional messages off the request path (queue or background job), so a slow mail provider does not slow the user's action (see Background Jobs & Scheduled Work).
ConsiderMonitoring delivery and bounces, and keeping templates current and reviewed, so a broken or misleading template is not sent at scale.
AvoidKeeping the user waiting while an email sends, or failing their action just because the notification failed. Decouple the two.

Self-review checklist

AskIs the recipient definitely the right, current person — could this go to the wrong inbox?
AskIs there any sensitive data in the body that should be behind a login instead?
AskCould a retry send this notification more than once?
AskIs our domain configured so this can't be spoofed and won't be filtered as spam?

Why it matters: A misaddressed or over-detailed email is a real, common privacy breach. A well-configured sending domain that is hard to spoof protects our customers from phishers pretending to be us. And decoupled, idempotent sending keeps the app fast and avoids spamming people. Notifications are customer-facing and security-sensitive, so send them with care.