Where the Address Travels Inside a Company

Stage: the systems behind the form. In control: the company and its vendors.

1. The address is almost never stored in one place

A single signup normally writes your address into four or five separate systems, not one. They belong to different departments, they were bought at different times, they run on different servers, and they do not keep each other informed in real time.

This is ordinary architecture rather than anything sinister, and it explains most of what people find inexplicable about companies and their mail. The mental model of a company database with your row in it, which you can go and edit, does not correspond to any company that has been operating for more than a year.

2. Each system takes its copy for a different reason

The application's own database holds the address because it needs to identify you at sign-in and reach you when something breaks. The sending platform holds it because that is the machine that actually delivers messages, and it cannot deliver to an address it does not have. The customer relationship system holds it because sales and support work from a picture of a person, not a row in an application schema.

Analytics holds it, or a hash of it, so that behaviour recorded in different places can be attributed to one person. The support desk holds it so that an incoming message is recognised as coming from a known customer. Five systems, five purposes, five retention rules, and none of them redundant from the point of view of the team that bought it.

3. The address becomes the joining key because nothing else is shared

These systems were never designed together, and they have no common identifier between them. The application has its internal ids, the sending platform has its subscriber ids, the support desk has ticket numbers, and none of those mean anything to the others.

The address is the one field every system has, so the address becomes the key by default. Nobody decided this at a meeting; it emerged because it was the only option available at each integration step. The consequences of that default are serious enough that people who design schemas argue about it, which is the subject of why the address makes a poor user id.

4. Changing the address in your profile updates one copy

When you edit the address in your account settings, you have changed the application's copy. Everything else finds out later, or does not find out.

Some systems are wired to sync on a schedule, so the change propagates in hours or days. Some sync only on specific events, so the change moves when you next do something that triggers an update. Some integrations were built one way, pushing records out and never pulling changes back, and those copies stay wrong permanently. This is the honest explanation for mail arriving at an address you replaced half a year ago: nothing failed, the message came from a system that was never told.

5. Vendors hold copies too, and the consent you gave did not name them

The company sends nothing itself. A sending platform sends. Support is often a third product, analytics a fourth, and any of those may run on infrastructure belonging to a fifth.

You agreed to a relationship with one company, and your address ended up in several organisations' systems as a direct consequence. Privacy notices describe this in the language of processors and subprocessors, which is accurate and almost unreadable. The practical version is simpler: the number of companies holding your address after a signup is larger than one, and the number is not usually stated on the form. Some of them received it before you clicked anything, because the copies start moving while the confirmation message is still in flight.

6. A suppression list exists so that some addresses cannot be erased

Every serious sending platform keeps a list of addresses it must not send to. Addresses land there when someone opts out, when a message bounces repeatedly, or when a complaint is registered.

That list creates a permanent tension with deletion. If the platform forgets your address completely, it also forgets that it was told not to write to you, and the next import from the customer system puts you straight back into the sending queue. Keeping a record of who must not be contacted is the only way to honour a request not to be contacted, and that record is your address. It is a system that has to remember something about you in order to leave you alone.

7. Deletion removes the live copies and leaves the residue

When a company acts on a deletion request, what disappears is the working records: the account row, the customer profile, the subscriber entry. That is most of what matters and it is genuinely done.

What survives is the residue that systems produce as a side effect. Backups made before the request, which expire on their own rotation. Operational logs with retention periods of their own. Financial records, which are frequently required by law to be kept regardless of what anybody prefers. And the suppression entry. None of that is a company quietly ignoring you; it is the shape of systems built from separate parts with separate rules, which is the same reason your address was in five places to begin with.

The handover

Control here belongs to the company and to the vendors it pays, and it stays there whatever you do with your own profile. The next step outward is where it stops being about this company at all: any of those systems can take the address and buy the rest of your details against it, which is a market with its own suppliers and its own logic. The exception is a signup where no address was handed over in the first place, since signing in with an account you already have distributes something slightly different. And the address you paste next time can be one that expires on its own.