Sign-In Notifications: Email Users When Their Account Signs In

What Sign-In Notifications Do

Every time a user successfully signs in on any surface (wp-login.php, WooCommerce /my-account/, MemberPress, custom AJAX login, and anywhere else that fires the WordPress wp_login action), GuardPress checks the user’s role against your configured allow-list. If any of their roles match, one email is sent — not to you, the site admin, but to the user’s own email address on file. Subject line: “[Your Site] New sign-in to your account.”

Why the user and not the admin? Because that’s where compromise detection actually works.

• If a user’s password gets phished, the attacker signs in as the user — not as the admin. Emailing the admin every time anyone signs in would drown you in noise on any multi-user site.
• Emailing the user directly means the compromise is visible in their inbox where they can act on it in one click. Every notification includes a “This wasn’t me” password-reset link.
• This is the same pattern Gmail, GitHub, Microsoft, Dropbox, and every serious SaaS uses. Users already recognise the shape of the email and know how to react to a suspicious one.

Alongside the email, GuardPress writes an successful_login_notified entry to the audit log with severity info, capturing the user ID, username, IP, and role. This is the belt to the email’s suspenders — if the user’s mailbox is also compromised, the audit log still records the sign-in for you to spot post-hoc.

Configuring the Feature

Both settings live at GuardPress → Settings → Login Protection → Login Notifications.

The master toggle

Option name: guardpress_login_notify_enabled. Default: on. The single checkbox labelled “Email users when their account signs in.” When off, no notification emails are sent to anyone regardless of role. The audit-log companion entry is also not written when the master toggle is off.

The per-role allow-list

Option name: guardpress_login_notify_roles. Default: [‘administrator’]. The checkbox grid labelled “Notify users with these roles:” shows every role registered on your WordPress install — Administrator, Editor, Author, Contributor, Subscriber, plus any custom roles from WooCommerce (Shop Manager, Customer), MemberPress, or role-editor plugins.

Only users whose roles intersect the allow-list get notified. If a user has multiple roles (WooCommerce Customer + Administrator, for example), being in any one of the allow-listed roles is enough — the intersection check uses array_intersect. Users whose roles don’t intersect at all are silently skipped — no email, no audit-log entry either (the audit entry only fires when the notification is sent).

Common configurations

• Solo admin site: Leave defaults on — you see every sign-in to your own account. If you get an email you didn’t trigger, act immediately.
• Multi-admin team site: Leave defaults on — every admin gets notified about their own sign-ins independently. A compromise of any admin’s mailbox exposes only that one admin’s notifications, not everyone’s.
• Multi-author blog: Add Editor and Author to the allow-list. High-signal roles that can publish content should know when their accounts are used.
• WooCommerce store with high customer sign-in volume: Leave the allow-list at Administrator only. Notifying every customer on every sign-in is generally unwanted — WooCommerce accounts are lower-privilege and users don’t expect a “you signed in” email from every shop.
• Membership site (MemberPress, Restrict Content Pro): Depends on how much you want to alert paying members. Many operators leave notifications admin-only and rely on 2FA + brute-force protection to cover customer accounts.

What the User Receives

The email is HTML-formatted and deliberately styled to look like the Gmail / GitHub sign-in notification users already recognise. Subject line: “[Your Site Name] New sign-in to your account.” The body includes:

• A greeting using the user’s display name if one is set, else their username — “Hi Jane,” or “Hi jane_doe,”
• The lead sentence: “Someone just signed in to [Your Site] using your account. Details:”
• A details table with three rows: Username, IP address, Time
• A “Was this you?” paragraph explaining the two possible responses
• A prominent red “Reset my password” button linking to the WordPress core lost-password URL

A few implementation details that matter:

• The Time value honours the site’s timezone and locale. If your WordPress Settings → General has timezone set to America/Los_Angeles, the email shows the sign-in time in Pacific time — not UTC. This uses wp_date() internally.
• The IP is whatever GuardPress detected via GuardPress_Logger::get_client_ip(). Behind Cloudflare or another CDN, this reflects CF-Connecting-IP or the equivalent proxy header (1.6.30+) — not the CDN’s edge IP.
• The reset-password button links to WordPress core’s standard wp_lostpassword_url() — if you have a custom login URL set, it uses that URL. Users clicking through get the normal WordPress password-reset flow, not something GuardPress-specific.
• The From header is Your Site Name <admin_email>. If you have Royal SMTP or another SMTP plugin active, delivery goes through it — the notification uses wp_mail() so it inherits whatever mail infrastructure your site has.
• Sign-in notifications are NOT rate-limited. A user who signs in ten times a day gets ten emails. This is intentional — a user signing in normally isn’t surprising, but a user signing in from three unfamiliar countries in an hour is a signal worth seeing every time. Contrast this with brute-force alerts, which are throttled per attacker per hour.

Reading the Audit-Log Companion

Every notification that fires also writes an entry to GuardPress → Audit Log with action = successful_login_notified and severity info. The description reads:

Notify-eligible sign-in by [username] (role: administrator) from [IP]

Why bother? Because email is a single point of failure. If an attacker compromises both the WordPress admin account and the user’s email account (which happens — both often share the same password), they can delete the sign-in notification before you see it. The audit log lives in your database, is only accessible from wp-admin, and is one layer of protection deeper. If you’re investigating a suspected compromise post-hoc:

1. Open GuardPress → Audit Log and filter for successful_login_notified entries.
2. Cross-reference IPs against the Sign-In Notifications emails in the user’s inbox. Any audit-log sign-in that didn’t produce an email in the user’s inbox suggests the email was deleted after the fact — a strong signal the email account is also compromised.
3. Check the IP geolocation against where the user actually was at that timestamp. GuardPress’s audit log stores raw IPs; you can look them up with any reverse-IP or geo-IP service.

The audit log entry only records the fact that a notification-eligible sign-in happened. If you want to see all successful sign-ins including those to roles outside the allow-list, WordPress core’s wp_login action fires for every sign-in regardless. GuardPress’s brute-force module also logs failed sign-ins to gp_failed_logins.

Turning Notifications Off

Two ways, depending on how selective you want to be:

Turn off entirely

Turn off for specific roles only

Common Mistakes

Adding Customer to the allow-list on a busy WooCommerce store

Customers sign in dozens or hundreds of times a day depending on your traffic. Emailing them all every time is a support-ticket generator, not a security feature. Keep customer accounts on the standard set of protections (brute-force + 2FA opt-in) and leave sign-in notifications for higher-privilege roles.

Assuming the admin gets copies of the emails

The admin does not automatically get a copy. Each user gets their own notification for their own sign-ins. If you want centralised visibility as the admin, use the audit-log filter (above) — that’s the intended channel.

Panicking about your own routine sign-in emails

If you’re the site’s sole admin and the default settings are on, you’re going to get an email every time you sign in. That’s working correctly. Check the IP in the email matches where you were and the timestamp matches when you signed in. If both match, ignore. If either doesn’t, act on the “This wasn’t me” link immediately.

Trusting only the email channel

A sophisticated attacker who owns your WordPress admin account will often also target your email — either because you reuse passwords, or via account recovery flows on the mail provider. The audit log is your defence in depth. Get in the habit of checking GuardPress → Audit Log → successful_login_notified periodically, not just when a suspicious email lands.

Forgetting sign-in notifications don’t block anything

This feature tells you a sign-in happened. It doesn’t block bad ones. For blocking, layer it with 2FA (see Per-Role 2FA Enforcement) and brute-force protection.

Still Stuck? Email Priority Support

If sign-in notifications aren’t behaving as expected — not sending when they should, sending to the wrong recipient, sending too many, showing the wrong IP:

Email support@royalplugins.com with the diagnostic info below. Priority email support is included with your GuardPress Pro license — typical response time is within 24 hours.