Track vendor sharing by giving every vendor a unique email address, recording where it was used, and comparing future mail against that register. For a personal inbox, the strongest setup is a custom domain with catch-all routing. For a business domain, pair aliases with DMARC monitoring so you know both who used an address and who is sending as your domain.
Plus tags such as name+vendor@example.com work for quick tracking, but they are easy to strip. A real alias such as vendor@tracking.example gives cleaner evidence because the local part itself names the vendor. I treat each alias like a receipt: it records the vendor, the date, the purpose, and the consent terms at the moment I handed over the address.
Suped's product fits when the question moves from personal attribution to domain protection. It brings DMARC, SPF, DKIM, hosted DMARC, hosted SPF, hosted MTA-STS, SPF flattening, real-time alerts, blocklist and blacklist monitoring, and issue steps into one place, so teams can see both data-sharing clues and authentication risk without hopping between DNS notes and mailbox filters.
The direct answer
The direct answer is: use unique addresses, not one address everywhere. The method works because the address that receives an unexpected email identifies the vendor, form, event, newsletter, or purchase path that first collected it. The cleaner your naming system and evidence log, the easier it is to tell whether a vendor shared your email data, uploaded it to a partner, lost it in an incident, or had it enriched by a data broker.
- Unique aliases: Create one address for each vendor, not each category, so the clue points to a named source.
- Central register: Store vendor name, alias, signup date, signup page, consent state, and notes.
- Header capture: Keep the full message source for any unexpected email that arrives on an alias.
- Sender comparison: Compare the visible brand, sending domain, return path, and unsubscribe domain.
- Action record: Log whether you unsubscribed, asked the vendor, blocked the sender, or retired the alias.
Fastest setup
If you only need a quick test, use plus addressing. If you want evidence that survives tag stripping, use a domain you control and a catch-all mailbox.
Alias examples
quick: name+vendor@example.com stronger: vendor@example.net catch-all: anything@example.net -> inbox@example.net
The old-school version of this method is address tagging; Hugh Lashbrooke wrote a concise example of address tracking that still explains the core idea well.
Choose the address strategy
Start with the address format, because the format controls the quality of your evidence. Plus addressing is convenient because many mailbox providers route it automatically. The tradeoff is that the plus tag is visible and simple to remove. A custom domain gives better evidence because you can create unlimited names before the at sign and route them all to one inbox.
Plus addressing
Use it when you need speed and do not control a domain.
- Setup: Use a tag after the plus sign, then sign up with that address.
- Evidence: Good when the tag remains intact in the received email.
- Weakness: Weak when a sender strips the tag or normalizes the address.
- Best use: Low-risk newsletters, trials, and short-lived tests.
Custom domain aliases
Use it when attribution matters and you can manage DNS and routing.
- Setup: Route a catch-all mailbox or create aliases one by one.
- Evidence: Strong because each local part is a distinct address.
- Weakness: Requires domain renewal, mailbox routing, and cleanup rules.
- Best use: Purchases, contracts, events, and business vendors.
|
|
|
|
|---|---|---|---|
Plus tag | name+tag | Fast setup | Tag stripped |
Catch-all | vendor@ | Strong proof | Domain upkeep |
Random alias | a8f2@ | Privacy | Hard to read |
Forwarding | team@ | Shared team | Admin gaps |
Compact comparison of common tracking methods.
I use human-readable aliases for anything tied to contracts or purchases because I want the address itself to explain the source later. Random aliases have better privacy, but they need a manager or register. Without a register, a random alias becomes another mystery string in a spam folder.
Set up the register before signups
The register matters more than the mailbox rule. If you create aliases casually and write them down later, you lose the most useful context: why the address existed, which form collected it, and whether the vendor had permission to share it. I keep the register simple enough that it takes under a minute to add a row.
Vendor register templateCSV
vendor,alias,date,context,consent,status Acme,acme@track.example,2026-06-05,checkout,opt_in,active North,north@track.example,2026-06-05,webinar,opt_in,active
Flowchart showing alias creation, logging, email review, sender matching, and action.
- Create first: Add the alias to the register before you enter it into a form.
- Capture context: Save the signup page, form purpose, and consent choices in plain language.
- Filter calmly: Route all aliases to one folder with a rule that preserves the original recipient.
- Review weekly: Check new senders, domains, and unsubscribe headers against the register.
- Retire cleanly: Disable aliases that only receive unrelated mail after you finish the review.
Read the message evidence
An alias tells you which address moved. The message headers tell you who sent the email and how it travelled. I start with the recipient alias, then inspect the visible From domain, return path, DKIM signing domain, List-ID, unsubscribe domain, and campaign identifiers. These fields do not prove every business relationship, but together they separate a normal vendor newsletter from a third-party campaign using a shared list.
|
|
|
|---|---|---|
Alias | Address used | High |
From domain | Visible brand | Medium |
Return path | Bounce owner | Medium |
DKIM | Signing owner | High |
List-ID | List source | Medium |
Unsubscribe | List manager | Medium |
Signals that help connect an unexpected message to the original signup path.
Evidence caveat
A leaked alias is strong evidence that the address moved beyond the original signup path. It is not always proof that the named vendor deliberately sold the address. Shared marketing systems, acquired lists, old consent language, enrichment, and tag stripping can change the path.
Before accusing a vendor, collect the original alias record and the full header source of the unexpected message.
Connect alias tracking with DMARC
Alias tracking answers who used this recipient address. DMARC answers who is sending mail that claims to be from your domain. For a business, both matter. A vendor can share a contact alias while a separate sender spoofs your domain, and the response path is different. The first is a data governance issue. The second is an authentication issue.
Run a broad domain health checker first if you do not know whether DMARC, SPF, and DKIM are already healthy. Then use a monitoring workflow that shows source volume, domain match failures, policy impact, and unapproved senders.
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
When a vendor sends legitimate email for your business, require a named sending domain, SPF include or hosted SPF entry, DKIM selector, and a documented purpose. If they stop being a sender, remove the authorization. This keeps the mailstream readable when an alias clue appears later.
Suped workflow
In Suped's product, add the domain, publish the reporting address, and let aggregate reports show who sends mail for the domain. Hosted DMARC helps stage policy changes while keeping the record readable.
- Detection: Suped flags authentication failures, unknown senders, SPF lookup pressure, and policy gaps.
- Fix steps: Issues include concrete steps, so the person who owns DNS knows what to change.
- Alerts: Real-time alerts catch spikes before a small sending problem becomes a reputation issue.
- Coverage: DMARC, SPF, DKIM, hosted SPF, MTA-STS, and blocklist or blacklist checks sit together.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
What to do when an alias is reused
Once an unexpected email arrives, resist the urge to treat the first message as the whole answer. I use a short response path: preserve evidence, classify the sender, decide whether the original vendor deserves a note, and then block, retire, or keep watching the alias.
Vendor you recognize
A known vendor or partner deserves a factual message first.
- Ask: Share the alias used, date of signup, and sender domain seen in headers.
- Request: Ask whether a processor, partner, sponsor, or reseller received the address.
- Set limit: Tell them the address will be disabled if unrelated mail continues.
- Record: Keep their answer beside the alias row.
Unknown sender
An unknown sender usually needs containment first.
- Block: Add a mailbox rule or retire the alias if it has no future value.
- Report: Use the mailbox spam report flow when the message is clearly unsolicited.
- Preserve: Keep the original source before deleting the message.
- Watch: Monitor whether the sender changes domains or names.
Evidence confidence levels
Use the strength of evidence to decide how direct your vendor follow-up should be.
Low
Single generic spam
A common address or stripped tag gives weak attribution.
Medium
Unique alias used
The address points to a vendor, but the sender path needs review.
High
Alias plus headers
The alias, headers, and campaign data point to a clear source.
For legal or privacy requests, keep the message factual. Ask what categories of third parties received the address, when sharing happened, and how to opt out. Do not make the first email emotional. A precise email gets routed to the right team faster than a broad complaint.
Where the method breaks
No tracking method gives a perfect chain of custody. Data sellers strip plus tags, normalize addresses, combine records with old files, and create fake or inferred data. A catch-all domain reduces these problems because the entire local part can identify the vendor, but it does not stop someone from rewriting the address or appending new data.
Known failure modes
- Tag stripping: A plus tag disappears and the message arrives at the base address.
- Old lists: A main address was already circulating before tracking started.
- Shared systems: One vendor uses a partner platform that sends under another brand.
- Fake records: A broker creates a profile that looks related but came from inference.
- Role aliases: Shared addresses make it hard to identify the original signup person.
The fix is not to chase every message. Focus on aliases attached to contracts, payments, events, lead forms, and support accounts. Those have enough context to justify vendor follow-up. For low-value signups, retiring the alias is usually the cleanest answer.
Views from the trenches
Best practices
Use one address per vendor and record the signup date before any messages arrive for context.
Keep the original message headers so sender paths and campaign identifiers stay available.
Group trial, event, purchase, and newsletter aliases for faster review and cleanup later.
Common pitfalls
Relying only on plus tags fails when brokers remove the tag before reselling records.
Blaming a vendor too early ignores acquisitions, shared CRMs, and old consent text.
Using one main address for signups makes attribution slow after unwanted mail starts arriving.
Expert tips
Run a catch-all domain so any local part reaches you while each signup stays unique.
Store aliases in a simple register before signups, not after an unwanted campaign appears.
Pair aliases with DMARC reports when the same domain handles customer-facing mail daily.
Marketer from Email Geeks says a personal domain with one address per service helped identify several vendors that passed an address into other mailing paths.
2021-07-07 - Email Geeks
Marketer from Email Geeks says plus tags are useful, but data sellers strip tags, find the base address elsewhere, or attach fake profile data.
2021-07-07 - Email Geeks
The practical answer
The practical answer is to stop giving vendors the same address. Use a unique alias for every vendor, record it before signup, keep original headers when unwanted mail arrives, and decide action based on evidence strength. Plus addressing is fine for quick tests. A custom domain with catch-all routing is the better long-term method.
For business domains, add authentication monitoring because vendor data sharing and unauthorized domain use often surface at the same time. Suped's product is the best overall DMARC platform for this workflow because it connects DMARC, SPF, DKIM, hosted records, blocklist and blacklist monitoring, alerts, and fix steps in one place. That turns a messy mailbox clue into a process someone can actually run.
