How Does Amazon Detect Multiple Accounts? The Full 2026 Breakdown

Every week, somewhere on a seller forum, the same post appears. "Second account suspended within 48 hours. Different email, different IP, different laptop. How did they know?"

The replies are usually a mix of folklore and half-truths. Someone blames cookies. Someone blames the router. Someone insists Amazon "tracks your MAC address" (it can't — MAC addresses don't leave your local network). The real answer is both simpler and more uncomfortable: Amazon doesn't rely on any single signal. It runs one of the most mature account-linking systems in e-commerce, built over two decades of fighting fraud, review manipulation, and suspended sellers trying to sneak back in. It correlates dozens of weak signals into one strong conclusion, and most people who get linked handed Amazon three or four of those signals without realizing it.

This article is a practitioner's answer to the question how does Amazon detect multiple accounts — not a scare piece and not a sales pitch. We'll walk through each detection layer in the order Amazon most likely weighs them, separate the myths from the mechanisms, look at when Amazon actually permits multiple accounts, and finish with how professional multi-account operations keep their environments genuinely separate.

One note before we start: if you run multiple seller accounts to evade a suspension, no tool will save you, and this article won't help you. Amazon's Seller Code of Conduct is explicit that operating a second account after an enforcement action is itself a violation. The legitimate use cases — separate legal entities, distinct brands, agencies managing client accounts, regional operations — are the context for everything below.

The short answer (and why it's incomplete)

If you want the one-paragraph version: Amazon links accounts using four overlapping layers — network identity (IP addresses and their history), device and browser fingerprints (the technical signature of the machine you log in from), account data (payment methods, bank accounts, addresses, phone numbers, tax IDs), and behavioral patterns (what you sell, how you write, when you're active). No single layer is decisive. A shared IP alone rarely triggers anything — millions of households share IPs through carrier-grade NAT, and plenty of couples run separate seller accounts from one kitchen table. But a shared IP plus a matching browser fingerprint plus an overlapping product catalog is a different story. That combination doesn't look like coincidence to a risk model, because statistically, it almost never is.

The incomplete part of that answer is when the linking happens. Amazon isn't running a real-time dragnet that instantly connects every account you've ever touched. Linking intensifies at specific moments: registration and verification, a policy violation on any connected account, a spike in risk signals (sudden category change, velocity anomalies, a flood of A-to-z claims), and periodic backend sweeps. An account can carry latent links for months and never feel them — until one linked account gets suspended and the whole cluster goes down together. That delayed-fuse behavior is why sellers so often believe a new mistake got them caught, when actually the link was established on day one and only mattered later.

Understanding the layers individually is what lets you reason about your own exposure. Let's take them in turn.

Layer 1: Network signals — the first filter, not the last word

What your IP address actually reveals

Every request your browser makes to Amazon carries your public IP address. From that single value, Amazon derives far more than "a number": the ISP or hosting provider that owns it (the ASN), a rough geolocation, whether the address belongs to a residential broadband pool, a mobile carrier, a corporate network, or a datacenter, and — critically — the history of every Amazon session ever seen from that address and its neighbors.

History is the part people underestimate. If a suspended account logged in from 84.12.x.x last March, and your fresh account registers from the same address today, that's a recorded association even if you never do anything else wrong. IPs from datacenter ranges (AWS, Hetzner, OVH, DigitalOcean) are effectively pre-flagged; ordinary shoppers don't browse from a Frankfurt server rack, so a seller registration from one starts life with a risk score it never asked for.

Why cheap proxies make things worse, not better

The reflexive fix — "just use a proxy" — routinely backfires, because the proxy itself becomes the linking signal. Shared datacenter proxies are sold to thousands of customers; the exit IPs are known, catalogued, and frequently associated with previous abuse. Worse, a rotating proxy means your account appears to teleport between cities mid-session, which is its own anomaly. Real people have boring network lives: one ISP, one city, occasional travel. The accounts that survive are the ones whose network story is boring too — a dedicated residential or ISP-type address, in a location consistent with the account's registered address, used by that account and nothing else. We covered the sourcing and hygiene details in the residential proxies playbook, but the one-line rule is: one account, one static residential exit, forever.

One more network detail that trips people up: WebRTC. Even behind a proxy, the browser's WebRTC stack can disclose network-level information through ICE candidate gathering unless the browser masks it. A proxy that hides your HTTP traffic while WebRTC whispers your real network details isn't hiding anything. Any serious multi-account setup masks WebRTC at the browser level so the advertised address matches the proxy exit — Dual Login does this natively per profile.

Layer 2: Device and browser fingerprinting

This is the layer that answers the forum poster's actual question — the "different email, different IP, still caught" cases. Because even with a clean network identity, the browser you log in with has a signature, and if two accounts share it, they share a device in Amazon's eyes.

What Amazon's scripts can collect

Browser fingerprinting works by combining dozens of attributes that are individually mundane but collectively near-unique. When you load a page on a fingerprinting-instrumented site, JavaScript can read, without any permission prompt:

• User agent and client hints — browser, version, OS, architecture
• Screen geometry — resolution, color depth, device pixel ratio, available screen space (which encodes your taskbar and dock)
• Hardware signals — CPU core count, device memory, touch support
• Canvas rendering — the same drawing instructions produce subtly different pixels on different GPU/driver/OS combinations, hashable into a stable ID (see MDN's Canvas API docs for what the API exposes)
• WebGL — the GPU vendor and renderer strings plus dozens of capability parameters; we dissected this one in WebGL fingerprint spoofing explained
• Audio context — a rendered audio signal hashed the same way canvas is
• Fonts — the installed-font set, measured through element sizing, which encodes what software you've installed over the years
• Timezone, languages, and locale formatting

The EFF's Cover Your Tracks project demonstrates the punchline: most browsers are unique among hundreds of thousands tested. If you'd like the ground-up version of how these signals combine, start with our beginner's guide to browser fingerprinting.

Now apply that to multi-accounting. You log into Account A in Chrome. You log into Account B in an incognito window — or in Firefox, or after "clearing everything." Incognito doesn't change your canvas hash. A different browser still reports the same screen, the same fonts, the same GPU, the same timezone, the same core count. The overlap is overwhelming, and it's deterministic: it will match every single session, forever, until the hardware changes. This is precisely the failure mode we broke down in how websites detect multiple accounts on the same device — the device betrays what the login form conceals.

Cookies and storage: the ghosts of old sessions

Below the fingerprint sit the old-fashioned identifiers: cookies, localStorage, IndexedDB, cache. Amazon sets long-lived identifiers (the session-id and ubid-* family among them) that persist across logouts. Log out of Account A and register Account B in the same browser profile, and the new account inherits the old one's stored identifiers — the two accounts are linked before you've typed your name. Clearing cookies helps with this specific vector but does nothing about the fingerprint layer above it, which is why "I cleared everything" appears in so many suspension post-mortems. Storage isolation and fingerprint isolation are different problems; you need both.

Why spoofing is harder than it sounds

The naive countermeasure — install an extension that randomizes your fingerprint — usually makes detection easier. Randomized values drift between sessions (real devices don't), and JavaScript-injected spoofs are themselves detectable: overridden functions have telltale properties, and inconsistencies bloom everywhere the lie isn't maintained. A spoof that claims macOS in the user agent while the fonts, canvas artifacts, and client hints all say Windows is worse than no spoof at all — it's a fraud signal, not a disguise. A fingerprint has to be internally consistent and stable per identity, which is an engineering problem, not a browser-extension problem. We wrote up the practical standard in how to change a browser fingerprint — the short version is that the spoof has to live in the browser engine itself, not in injected JavaScript that a detector can trip over.

Layer 3: Account data — the strongest links of all

Here's the layer that catches people who did everything right technically. Fingerprints and IPs are probabilistic evidence; account data is declarative evidence. You told Amazon these accounts are connected. Verification and periodic review compare, across the entire seller base:

• Bank accounts and deposit methods. The single strongest link. Two accounts settling into the same bank account are the same operation, full stop.
• Credit cards used for the charge method.
• Tax identifiers — EIN, VAT number, or national ID from the verification process.
• Names — legal name, business name, and the names of beneficial owners submitted during verification.
• Addresses — business address, deposit address, return address, and even the ship-from address on FBM orders. Normalization catches trivial variations; "Suite 4B" versus "#4B" fools nobody.
• Phone numbers — including a number reused for two-step verification.
• Email patterns — not just the address itself, but recovery emails and, plausibly, structural similarity.

There's a second, subtler tier of data linkage that operates on your catalog: identical product photos across two "unrelated" storefronts, matching ASIN sets, boilerplate descriptions with the same typos, the same custom packaging in returns. Amazon has strong incentives to detect this cluster because it's how review manipulation and shadow-inventory schemes operate. If you run two brands, they need to actually be two brands — separate imagery, separate copy, separate suppliers where feasible.

The operational implication is blunt: legitimate multiple accounts require separate legal and financial identities, not just separate browsers. A second entity with its own bank account, tax ID, and address isn't a workaround; it's the actual requirement, and it's the part no software can provide.

Layer 4: Behavioral correlation

The fourth layer is the fuzziest and the least publicly documented, but its existence is not in doubt — behavioral analysis is standard in modern risk systems (device fingerprinting research has long extended into behavioral biometrics). Signals plausibly in play:

• Session rhythms. Two accounts that always come online within minutes of each other and go quiet at the same hour, week after week.
• Interleaved activity. Account A acts, then Account B acts from a different IP thirty seconds later, in an alternating pattern no two independent humans would produce.
• Writing style. Support messages and listing copy carry idiosyncrasies — phrasing, punctuation habits, recurring misspellings.
• Operational fingerprints. Identical pricing-rule behavior, identical handling-time settings, repricer API calls with matching timing signatures.

Behavioral signals rarely trigger enforcement alone. Their role is corroboration: when a fingerprint match or an address overlap puts two accounts under review, the behavioral record either supports the link or doesn't. You defend against this layer with genuine operational separation — different team members, different schedules, honestly distinct businesses — not with tricks.

The signals ranked: what actually links accounts

A rough field guide, ordered by how much weight each signal carries and how hard it is to change once recorded:

Two readings of this table matter. First, everything above the fingerprint rows is data you submit — no browser can fix it, which is why entity separation comes before tooling. Second, everything from the fingerprint down is environmental — and it's exactly the set of problems an isolation tool exists to solve.

What probably doesn't link you (myths worth retiring)

• MAC addresses. Layer-2 identifiers that never traverse the internet. A website cannot read yours.
• Buying from one account, selling from another. Amazon's policy concerns multiple seller accounts. A buyer account alongside your seller account is normal life.
• A VPN by itself flagging you. Millions shop over VPNs. VPN exits are shared and historied, which makes them bad for seller logins — but the mechanism is IP reputation, not "VPN detection" as a scarlet letter.
• Household members getting each other banned. Two genuinely separate businesses run by spouses from one home IP is a known, generally tolerated pattern — if every other layer is clean (separate banks, entities, devices/profiles). The IP overlap alone isn't the killer; the killer is IP overlap plus shared payment or fingerprint data.
• Phone-account linking via apps. Real but often overstated; the mechanisms mirror the browser story (device IDs, network, account data). The same one-identity-per-environment rule applies.

When Amazon actually allows multiple accounts

Since 2020, Amazon's policy has been more permissive than folklore suggests. The Seller Code of Conduct allows operating multiple seller accounts when you have a legitimate business need — commonly: separate brands with separate operations, distinct product lines, manufacturing for different companies, or program requirements that demand separation. You no longer need pre-approval in most regions, but three conditions are effectively non-negotiable: each account needs its own legitimate business justification, its own bank account, and a clean record — if any account in the cluster earns a suspension for cause, expect the enforcement to propagate.

This reframes the whole exercise. The goal of account separation isn't to hide from Amazon in some adversarial sense — Amazon likely knows more than you think regardless. The goal is to prevent accidental cross-contamination: the fat-finger login of Brand A into Brand B's browser, the cookie bleed, the fingerprint overlap that turns two legitimate businesses into one suspicious cluster in a risk model, so that a problem on one account (a rogue complaint, a verification hiccup, a false-positive velocity flag) doesn't cascade across everything you've built. Agencies live this daily: one careless employee session can entangle two clients' accounts. Our Amazon seller ban-avoidance playbook covers the policy-compliance half of the survival equation; the rest of this article covers the environmental half.

How professional operators keep accounts separated

After watching hundreds of setups succeed and fail, the pattern among the survivors is consistent enough to write down as rules.

Rule 1: One account, one environment, no exceptions

Every account gets a dedicated, persistent environment: its own browser profile with isolated cookies and storage, its own consistent fingerprint, its own static residential IP, its own email and phone. That environment is where the account lives — every login, every session, from registration onward. The word doing the work is persistent. A fingerprint that changes every session is an anomaly; a fingerprint that is stable but identical to another account's is a link. What you need is stable-and-distinct, per account, indefinitely.

Rule 2: Make the isolation structural, not procedural

Procedural isolation — "remember to switch Chrome profiles," "remember to toggle the VPN" — fails the first time a human is tired. Structural isolation means the environment enforces itself. This is the actual job of an antidetect browser: each profile runs as a separate browser instance with its own data directory (cookies, localStorage, IndexedDB, cache — nothing shared), its own internally consistent fingerprint applied at the engine level rather than through detectable JavaScript injection, its own proxy bound to the profile so traffic cannot accidentally egress from your real IP, and WebRTC masked to match. Opening the wrong account in the wrong environment becomes structurally difficult instead of one lapse away. Dual Login was built around exactly this model — real per-profile browser processes, native fingerprint application, per-profile proxies — and the same architecture is why the approach generalizes beyond Amazon to eBay and every other platform that fingerprints its sellers.

Rule 3: Match the fingerprint to the story

A fingerprint doesn't just need to be unique; it needs to be plausible and coherent. A US-registered account should present a US timezone, US locale, common US-market hardware, and an IP that geolocates accordingly. Every attribute should agree with every other attribute. This coherence is where hand-rolled setups fall apart and where engine-level fingerprinting earns its keep: canvas, WebGL, fonts, screen, navigator, and client hints all telling the same story, consistently, across every session and every web worker.

Rule 4: Separate the paperwork before the pixels

Worth repeating because it decides outcomes: browser isolation protects legitimate separation; it cannot manufacture it. Separate entities, separate banks, separate tax IDs, separate addresses, honestly distinct catalogs. If two accounts share a bank account, their fingerprints are irrelevant.

Rule 5: Audit your own exposure before Amazon does

Periodically ask, per account: has this account ever been touched outside its environment? Does anything in its verification data overlap with another account? Do the catalogs overlap? Has its proxy exit stayed static and residential? Teams that run this review quarterly catch the drift — a VA who logged in from a personal laptop "just once," a proxy provider that silently rotated an exit — before it compounds into a linked cluster.

What this means if you're starting today

If you're setting up a second (legitimate) account this week, the order of operations that follows from everything above:

1. Entity first. Register the business, open its bank account, get its tax ID, secure its address and phone. Weeks of lead time, zero software involved.
2. Environment second. Create a dedicated browser profile with a stable, coherent fingerprint. Assign a static residential proxy in the right geography. Verify the fingerprint story end to end before first contact with Amazon.
3. Register inside the environment. The account's first impression — registration — should come from the environment it will live in forever. Registering on your personal laptop and "moving" later means the link to your real device is already on file.
4. Operate with discipline. Distinct catalog, distinct copy, sessions kept separate in time, environment never breached. Document the business rationale so you can answer a verification inquiry without scrambling.

Sellers who follow that sequence mostly never think about linking again. Sellers who invert it — account first, hygiene later — are the ones writing the forum posts we started with.

FAQ

Can Amazon detect multiple accounts on the same computer?

Yes, reliably. Even with separate Chrome profiles or incognito windows, the underlying device presents the same canvas hash, WebGL renderer, fonts, screen geometry, and hardware signals — a fingerprint that matches across accounts on every session. Meaningful separation on one machine requires an isolation layer that gives each account its own storage and its own engine-level fingerprint, which is what an antidetect browser provides.

Does using a VPN stop Amazon from linking my accounts?

No. A VPN changes exactly one signal — your IP — and replaces it with a shared, datacenter-hosted exit that thousands of others use, which often raises your risk score. Your browser fingerprint, cookies, and account data pass through unchanged. If you need distinct network identities, use one static residential proxy per account instead.

Is it against Amazon's policy to have two seller accounts?

Not inherently. Amazon's Seller Code of Conduct permits multiple accounts when each has a legitimate business justification — separate brands, separate companies, distinct product lines. Each needs its own bank account and clean standing. What's prohibited is using a second account to evade enforcement on the first; that converts a policy question into a near-certain ban for the entire cluster.

Why was my new account linked when I used a different computer and network?

Almost always account data: a reused bank account, credit card, address, phone number, or tax detail submitted during registration or verification. Data links are declarative — you told Amazon the accounts are connected — so no amount of device separation offsets them. Catalog overlap (same photos, same copy) is the next most common cause.

Does Amazon link buyer accounts to seller accounts?

Amazon can associate them — same login infrastructure, often shared data — but having a personal buyer account alongside your seller account is normal and not a violation. The risk appears when a buyer account is used to manipulate your own listings (buying your products, reviewing them), which review-abuse detection treats severely.

If one of my linked accounts gets suspended, will the others go down too?

Frequently, yes — this is the main practical consequence of linking. When an account is suspended for cause, related-account enforcement commonly propagates to accounts Amazon considers connected. Clean separation is what contains a problem to the account that had it; entanglement is what turns one bad week into losing everything at once.

The bottom line

So, how does Amazon detect multiple accounts? By never needing to be certain from any single clue. Network history, device fingerprints, submitted account data, and behavioral rhythm each contribute probability, and the sum is usually conclusive — because genuinely independent accounts don't overlap on three layers at once. The defense, for sellers with a legitimate reason to run more than one account, mirrors the detection: real separation at every layer. Paperwork and banking you have to solve as a business. The environmental layer — isolated storage, stable and coherent per-profile fingerprints, dedicated residential IPs, WebRTC that doesn't leak — is a solved engineering problem.

That second layer is what Dual Login does: real per-profile browser processes with engine-level fingerprinting, isolated data directories, and per-profile proxies, at a price that doesn't assume enterprise budgets (see how it stacks up against the pricier incumbents). If you're running more than one storefront and want the isolation to be structural instead of a daily memory test, give Dual Login a try — set up your first two profiles side by side and see the difference for yourself.