How do I report a suspicious login on my Valid Email Checker account?

If a row in your Valid Email Checker Active Sessions list looks wrong — an unknown device, an unfamiliar country, a session that started while you were asleep — the priority order is: cut the attacker off first, then report. Telling support before you have changed the password gives a real attacker minutes to do more damage. The whole containment sequence takes under three minutes if you move fast.

Step 1: cut the attacker off

1. Sign in from your own trusted device if you are not already. The new login automatically terminates the previous session (single-active-session model) — but a rogue session that was already terminated by your normal login still shows up in the list with status Terminated, which is the row you are about to report.
2. Change your password immediately from Account Settings → Security → Change Password. The current password is presumed compromised. Use a password manager to generate a long unique value.
3. Enable [authenticator-app 2FA](how-to-enable-2fa) if it is not on already. A leaked password without a second factor is a complete account takeover; a leaked password with TOTP is much less useful to an attacker.
4. Save the backup codes that appear at the end of the 2FA setup. You will need them if you later lose your authenticator.

Step 2: capture the evidence

Before you email support, grab the details from the Active Sessions row that worried you:

• IP address (the monospace string in the IP column).
• Location (city, country).
• Device, browser, OS.
• Created At and Last Active timestamps.
• Status (Terminated, Expired, Active) and the termination reason if present.

A screenshot of the row is fine — it captures all of the above at once. Note that location is approximate (see how accurate is session city and country) so an unfamiliar city is a softer signal than an unfamiliar country.

Step 3: email support

Send a message to support@validemailchecker.com from the email address on the account. Include:

• The session details you captured above.
• What you've already done (password changed, 2FA enabled).
• A brief description of why the session looks wrong (where you actually were at that time, what devices you actually use).
• Any other anomalies — verifications you did not run, credit movements you did not initiate, integration syncs that look unexpected.

On our side, we pull the full login_history server-side (including failed attempts that don't appear in the user-facing session list), check for credit movements and API key generation in that window, and review any other signals (admin flags, related sessions). If we find genuine compromise we can also force-terminate every session, lock the account, and walk you through a clean re-onboarding.