A website security alert asks you to log in: verify it before following the link

Use a route that the message did not supply

Open the service using a trusted bookmark, its official app or a known address entered deliberately. Check the hostname and intended account. Avoid sponsored search results or contact details copied from the suspicious message when you already have a reliable official route.

The FTC recommends contacting a company through a website or number you know is real rather than information in a suspicious message. This is particularly useful for alerts: independent navigation removes the need to decide whether a long tracking or sign-in URL is safe before you can review the account.

If you do not have an account with the named service, do not create one to investigate the message. Consider whether it might concern an organization you legitimately administer, but establish that relationship independently. A familiar company name is not enough to authorize an account action.

A fictional alert review

A fictional website owner receives a message saying a new device accessed the hosting account. The message offers a large Secure account button. The owner instead opens a previously saved hosting address and signs in through the normal route.

In the official activity view, the owner finds an unfamiliar accepted session and a recovery change that was not requested. This supports treating the account as potentially compromised, even if the original email’s link has never been opened. The owner follows the provider’s incident process, removes affected access and checks account control.

In a second fictional variation, the activity corresponds to the owner’s own browser update and no unexpected changes are found. The owner records that narrower result. Neither example is a tested incident, and neither establishes that a city label alone determines legitimacy.

Sender authentication is useful, but does not approve the action

RFC7489 explains that DMARC does not tell a receiver whether a message stream is good and does not solve every form of fraudulent email, including visually similar domains. A passing authentication result therefore does not certify that the requested login or attachment is appropriate.

If you know how to inspect message headers, use them as supporting evidence in a private review. Do not ask an ordinary reader to derive safety from a technical header they cannot interpret. Independent account navigation remains a practical route even when mail authentication details are unavailable.

A logo, familiar display name, correct personal detail or HTTPS padlock is also insufficient on its own. Evaluate the actual account route and requested operation. Never provide a current password, recovery code or authenticator approval to a person claiming to verify the alert for you.

If you already interacted, describe exactly what happened

Opening a message, following a link, entering credentials, approving an authenticator prompt and installing software are different events. Record the sequence privately and use the provider’s official compromised-account guidance from a trusted device. Do not minimize an approval simply because no password was typed.

If credentials were entered on an untrusted destination, address those credentials and existing sessions through the official service. Review recovery methods and connected apps. The account protection and recovery guide helps identify those dependencies; it does not replace a provider’s incident process.

Do not distribute the complete alert or live sign-in link across public support sites. Redact identifiers, tokens and personal data, retaining the original privately where your organization’s procedure requires it. Report through the mail client’s or organization’s supported phishing route.

Keep link clicks and successful account actions distinct

A mail system may record link access by a security scanner. The mail-scanner click guide explains that a recorded click need not be a human action. It also does not establish that a login succeeded. Correlate security events with the authoritative account record.

For a legitimate recovery message whose link fails, use the reset and magic-link diagnosis. That is a separate issue from determining whether the message is trustworthy. Your next step is to save one reliable official account route and check the alert’s specific claim there, recording any unresolved evidence boundary.

Make the support handoff answerable

If official activity history cannot resolve the warning, contact support from the independently opened service. Supply the alert’s time, claimed event type and a redacted account reference. Ask whether that event occurred and which supported containment steps apply. Do not ask support to validate a live credential-bearing URL by forwarding it indiscriminately.

Keep a compact outcome record: recognized event, unfamiliar accepted access, blocked attempt or unresolved claim. Preserve the distinction between message authenticity and account impact. Even a forged message can coincide with a real security problem, while a genuine notification can describe an attempt the service already blocked.