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

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:

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:

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.