Security Alert Email Template for Account Risk Events

A security alert should help a legitimate user recognize an account event and respond safely. It should not turn every normal login into an alarming accusation.

Choose the event

Event	Subject direction	Required context
New device sign-in	New sign-in to your account	Time, approximate location, device
Password changed	Your password was changed	Time and recovery path
MFA changed	Security settings updated	Method and recovery path
Suspicious attempt	We blocked a sign-in attempt	Time, account, secure review action
API key created	New API key created	Key name, creation time, revoke path

Only include location or device information that your product can explain accurately. A guessed city from an IP is not proof of a person’s location.

Template

Subject: Security alert for {{product_name}}

Preheader: Review a recent change to your account.

Hello {{customer_name}},

We detected this account event:

{{event_name}} Time: {{event_time}} Device: {{device_summary}} Approximate location: {{location_summary}}

{{event_explanation}}

[Review account security]

If you recognize this activity, no action may be needed. If you do not recognize it, use the secure recovery page or contact {{security_email}}. Do not send passwords or authentication codes by email.

{{company_name}}

Avoid panic and phishing patterns

Do not use fake deadlines, ask the recipient to reply with credentials, or place a raw login form inside the email. Use a stable, recognizable domain and explain that support will never ask for the secret.

The primary button should lead to a security center, not an arbitrary marketing landing page. If the alert is informational only, say so.

Delivery and deduplication

Security alerts may be high priority, but they still need a reliable event model. Use an immutable event ID and suppress duplicate notifications caused by webhook retries. Group repeated blocked attempts only when the product can explain the grouping without hiding a meaningful event.

Never suppress a password or MFA change alert merely because another login alert was sent. These events have different security consequences.

QA checklist

• Event details match the audit log.
• Unknown location is labeled approximate or omitted.
• Recovery link is authenticated and safe.
• The message never requests secrets.
• Duplicate event delivery does not duplicate alerts.
• Password, MFA, and API-key events use the right copy.
• Plain-text and mobile versions remain actionable.

For one-time codes, see the verification code template.

Event severity and notification policy

Not every event needs the same urgency:

Severity	Example	Message behavior
Informational	New device recognized	Clear details and review link
Action required	Password or MFA changed	Recovery path and security contact
Blocked	Suspicious attempt stopped	Explain that no access was granted
Critical	API key or recovery factor changed	Immediate alert with revoke path

Use the account’s notification preferences only for optional detail, never to suppress a required security alert. If a user has several alerts in a short window, group only events with the same cause and preserve the individual audit records.

Avoid creating a phishing pattern

Use a consistent sender, domain, footer, and destination. Do not ask the user to reply with a code or password. Teach users what the company will never ask for, but keep that advice short enough that the actual event remains the first thing they see.

Give every alert a safe next action

The action depends on the event:

Event	Primary action	Recovery or support path
Recognized new device	Review details	No action needed if expected
Unknown sign-in attempt	Secure account	Revoke sessions or contact support
Password changed	Confirm or recover	Reset through the authenticated account flow
MFA or recovery factor changed	Review security settings	Use the documented account-recovery process
API key created	Revoke or rotate	Show key name, never the secret

Do not send a generic “click here to secure your account” link with no event context. A recipient needs to know whether access occurred, was blocked, or merely changed a setting.

Protect the alert itself

Keep authentication links on a stable HTTPS domain and exclude them from marketing click tracking when rewriting could obscure the destination. Use a consistent security sender and a plain-text part. If a location is approximate, say so; if the product cannot explain a device label, omit it instead of displaying a confident guess.

Test event grouping, multiple alerts in a short period, password and MFA changes close together, an account without a display name, dark mode, and a correction event. Measure time to recovery, unauthorized-account reports, duplicate alerts, and support resolution—not just opens.