login.com

Security alert triage · verified 2026-08-17

New-device sign-in email: what to check

Treat an unexpected alert as a reason to inspect the account, not as proof that the email itself is genuine. Open the service independently, check its own activity record, and act from a trusted session.

Answer first. Do not click an unexpected new-device sign-in email. Open the service from a trusted bookmark, app, or known domain and check recent activity there. If the sign-in was not yours, change the password from a trusted device, revoke unknown sessions, secure the recovery email and phone, and enable the strongest available authentication.

Why a new-device alert can be real or misleading

Many services send an alert when a browser, app, or device appears unfamiliar. The displayed place and device name are clues, not conclusive proof. Mobile networks, corporate gateways, privacy relays, browser updates, cleared cookies, and a replaced phone can make your own session look new. A real service can also send a correct alert after someone else signs in with a stolen password.

Attackers copy the same format because urgency creates clicks. A message may claim that you must confirm a device, stop a suspension, or call support immediately. The safest response is the same in both cases: avoid the message's route and inspect the account through a destination you already trust.

Six steps to verify and respond safely

  1. 01

    Do not use the email's sign-in, reset, phone, or support link.

  2. 02

    Open the service independently from a trusted bookmark, app, or known main domain.

  3. 03

    Review recent sign-ins, active sessions, devices, and recovery details inside the account.

  4. 04

    If the event was not yours, change the password, end unknown sessions, and replace exposed recovery methods.

  5. 05

    Turn on the strongest available authentication and save a separate recovery route.

  6. 06

    Keep the alert and record the time, displayed device, and approximate location without sharing account secrets.

If the service offers a passkey or FIDO security key, consider registering it after the incident is under control. These methods are bound to the real site and resist common fake-page credential relay. An authenticator app is a useful alternative when passkeys or security keys are unavailable. Never approve an unexpected push prompt or give a live code to a caller or chat contact.

What to review inside the account

Check active sessions and devices first. Remove entries you do not recognise, but preserve enough evidence to record the time and device before ending the session. Review password changes, passkeys, two-factor methods, recovery codes, recovery email and phone, connected applications, forwarding rules, and any account-specific activity such as messages, purchases, files, projects, or profile changes.

Secure the email account that can reset the affected service. If the same password was reused elsewhere, replace it on every account, beginning with email, password managers, and services that can reset other accounts. Generate new recovery codes when old ones may have been viewed or downloaded.

How to inspect the message without trusting it

The visible sender name is not ownership evidence. On a computer, hover over links without opening them and read the registered domain. On any device, you can copy the address without visiting it and use the local link-safety checker. If you have the raw message headers, the email-header analyser can parse SPF, DKIM, DMARC, reply-to changes, and delivery hops in the browser without uploading the header text.

Authentication results help assess delivery; they do not make every link or request safe. A compromised legitimate sender can pass mail checks, and an attacker can register a convincing lookalike domain. Confirm the event inside the account through an independently opened route.

When the alert was yours

If the account's own activity record matches a sign-in you initiated, no emergency reset is normally required. Confirm that the device, browser, and time are plausible, then review why it was treated as new. A cleared browser profile, device replacement, new app, network change, or disabled cookies may explain it. Keep strong authentication enabled and make sure a separate recovery method still works.

Primary guidance used for this checklist

Steps last verified: 2026-08-17. Recheck the affected service's own activity and recovery documentation because labels and menu paths vary.