A seller opens a second Amazon account for a new brand, gets written permission, and does everything by the book on the paperwork side. Three weeks later both accounts are suspended for being "related." No policy violation, no counterfeit claim, no negative feedback spike. Just a linkage signal that Amazon's systems considered sufficient.
This happens constantly, and the cause is almost never the business documentation. It is the technical layer: two Seller Central sessions sharing an IP, a browser profile fingerprint that appears in both accounts' histories, a residential IP that was previously used by a suspended seller, or a login pattern that shows two "different" companies operating from the same network at the same hours.
Amazon's related-account detection is one of the more aggressive linkage systems in e-commerce. Understanding what it actually measures, and building proxy and session infrastructure that respects those boundaries, is the difference between running multiple legitimate storefronts and losing all of them in a single enforcement action.
What Amazon Actually Means by "Related Accounts"
Amazon permits multiple selling accounts in defined circumstances: separate legal entities, distinct product lines, or legitimate business need with prior approval. Policy permission and technical invisibility are two separate problems. Even approved multi-account sellers get caught by linkage systems that do not read your approval email before flagging you.
The signals Amazon correlates fall into a few groups.
Network identity. The IP address you log in from, its ASN, its geolocation, and its history across other Seller Central accounts. This is the signal most sellers get wrong first.
Device and browser identity. Canvas and WebGL fingerprints, installed fonts, screen resolution, timezone, language headers, and hardware concurrency. Two accounts producing identical fingerprints from different IPs are still obviously the same operator.
Business and financial identity. Bank accounts, tax IDs, credit cards, phone numbers, addresses, and even the names of authorised users. Proxies do nothing for this layer, and no amount of network hygiene compensates for a shared deposit account.
Behavioural identity. Listing text reuse, identical SKU naming conventions, the same supplier invoices, matching product photography, and shipping from the same warehouse address.
Proxies address the first group and support the second. They cannot fix the third or fourth. Any strategy that treats IP separation as a complete solution is going to fail, and it will fail in a way that takes every account with it.
Why Residential IPs Alone Do Not Solve This
There is a widespread assumption in seller communities that buying residential proxies solves account linkage. It does not, for three reasons worth being precise about.
First, rotation is actively harmful here. A rotating pool that hands you a new IP every request looks nothing like a legitimate business owner logging into Seller Central. Amazon expects a seller to appear from a reasonably stable location. An account that logs in from Ohio, then Lisbon, then Manila within a day generates its own set of flags: not linkage flags, but account takeover flags, which trigger identity verification loops that are arguably harder to escape.
Second, IP history matters more than IP type. A shared residential IP in a large pool may have been used last week by someone running review manipulation on the same platform. Amazon retains association data on IPs it has seen tied to enforcement actions. Inheriting a burned IP is a real risk that no amount of "it's residential" marketing language addresses.
Third, subnet and ASN proximity leaks the relationship. Two accounts on IPs in the same /24 block, from the same ISP, in the same city, appearing during overlapping hours, are correlated even without an exact IP match. Buying five IPs from one small pool in one metro area is not five identities. It is one identity with five addresses.
Building the Right Proxy Architecture
The workable model for Amazon multi-account management is stability plus separation, not rotation plus volume.
One dedicated static IP per account, permanently
Each Seller Central account should map to a single IP that no other account ever touches. That means static residential or ISP proxies, held for the life of the account. The goal is that Amazon builds a consistent history for that account: same IP, same city, same ASN, month after month. Consistency is trust. A seller who has logged in from the same connection for eighteen months is a low-risk profile.
ISP proxies are often the strongest fit here. They carry residential ASN attribution while sitting in datacenter infrastructure, which gives you uptime and speed that peer-based residential nodes cannot always match. For a session that involves uploading inventory files or working in Seller Central for hours, dropped connections are not a cosmetic problem: mid-session IP changes are exactly the event that triggers re-verification.
Diversify across ASNs and geographies, deliberately
If you run four accounts, source those four IPs from four different ISPs where possible, in different metro areas, with different subnet ranges. This is not about hiding from a determined human investigator. It is about not handing an automated correlation engine a trivially obvious cluster.
Geography should match the account's story. A UK-registered entity selling on Amazon UK should log in from a UK IP. A US LLC should appear from the state its documentation references. Mismatches between registered business location and login geography are a soft flag on their own, and they become a hard problem during any verification review.
Pair each proxy with an isolated browser profile
IP separation without fingerprint separation is half a strategy. Each account needs its own persistent browser profile: distinct canvas fingerprint, timezone matched to the proxy's location, locale and Accept-Language headers matched to the region, and its own cookie and local-storage store that never mixes with another account.
Antidetect browsers handle this properly. Separate Chrome profiles do not: they share too much at the hardware fingerprint level. Whatever tool you use, the timezone must follow the IP. A proxy in Manchester paired with a browser reporting America/New_York is a contradiction that fingerprinting scripts detect on the first page load.
Keep session behaviour plausible
Stagger login times across accounts. Do not open four Seller Central dashboards simultaneously from four proxies on the same machine, because network-level timing correlation is real and cheap to compute. Vary working hours per account. Let each account have its own rhythm, ideally aligned to the timezone you have assigned it.
Common Mistakes That Get Accounts Linked
Reusing an IP after a suspension. If an account gets suspended, retire the IP with it. Reintroducing that IP to a healthy account transfers the association.
Testing a new proxy by logging into an existing account. Sellers do this constantly to "check it works." That single login permanently associates the IP with that account, contaminating it for future use.
Letting a VPN or system-level proxy override the per-profile setting. WebRTC leaks, DNS resolution outside the tunnel, and OS-level VPNs that capture traffic your antidetect browser thought it was routing elsewhere. Validate the actual egress IP before every important session rather than trusting the configuration screen.
Shared support tooling. Repricers, inventory managers, and PPC platforms that connect to multiple accounts from a single provider IP create a linkage path through the API layer. Where these tools support per-account proxy configuration, use it.
Mobile app logins. Logging into the Amazon Seller app on a phone that has been used for another account links them through device identifiers. Phones need the same discipline as desktops.
Where Proxies Fit In
Multi-account infrastructure lives or dies on whether the proxy layer offers the right pool type, genuine geographic granularity, and IPs whose history you can reason about. Rotating consumer-grade access from a cheap pool is the wrong tool for Seller Central entirely: what this workflow needs is dedicated, stable IPs with clean reputation and predictable geolocation, backed by enough pool diversity that you can spread accounts across distinct ASNs instead of stacking them in one subnet.
That is where a provider with several pool types matters. EnigmaProxy offers residential, ISP, datacenter, and mobile pools, which lets you assign static ISP IPs to high-value seller accounts while keeping rotating residential capacity for competitive research and price monitoring, two workloads that should never share infrastructure with your login sessions.
Ethical sourcing is not a compliance footnote in this context. IP pools assembled without consent tend to carry contaminated history and get taken down, and either outcome puts your accounts at risk. Choosing ethically sourced residential proxies with transparent provenance reduces the chance of inheriting an IP that Amazon has already associated with enforcement.
Before any account touches a new IP, verify it independently. Running the address through a proxy testing tool to confirm geolocation, ASN attribution, and the absence of DNS or WebRTC leaks takes a minute and prevents the kind of mistake that costs a storefront.
Strategic Insights and Where This Is Heading
Linkage detection is moving beyond the IP. Platform-side correlation increasingly weights device graphs, behavioural biometrics such as typing cadence, and supply-chain overlap. Network separation is becoming necessary but decreasingly sufficient. Sellers should assume the operational layer (listing copy, imagery, suppliers, staff) will be scrutinised as heavily as the technical layer.
Static, high-trust IPs will keep gaining value over raw pool size. The market has spent years selling pool volume. For account management specifically, the useful metric is how long you can hold a clean IP with consistent geolocation. Expect pricing and packaging to reflect that shift.
Verification friction will increase. Video verification, live address checks, and utility bill requests are already routine for new Amazon accounts. Technical hygiene that avoids triggering verification loops in the first place is worth more than any recovery playbook.
Compliance and infrastructure are converging. Proving where your IPs come from is becoming part of vendor due diligence, particularly for agencies managing accounts on behalf of clients. Providers that cannot document sourcing will struggle in that conversation.
Conclusion
Running multiple Amazon seller accounts safely is a discipline problem, not a purchasing problem. The technical foundation is straightforward to state and harder to maintain: one dedicated static IP per account, held indefinitely, spread across distinct ASNs and regions, paired with an isolated browser profile whose timezone and locale match the IP, and never cross-contaminated by casual testing or shared tooling.
Get the proxy architecture right and the platform sees what it should see: several independent businesses with stable, unremarkable login histories. Get it wrong and no amount of documentation will unwind the association.
For teams building that foundation, working with a provider that offers business-grade reliability across multiple pool types and transparent sourcing, such as EnigmaProxy, gives you the flexibility to assign the right IP to the right job rather than forcing one pool to cover every workflow.