How can I track which vendors share my email data with others?
Updated on 25 Oct 2026: We clarified how to verify vendor email reuse and added a privacy inquiry for sharing that never produces an email.
Track vendor sharing by giving every vendor a unique email address, recording the signup context, and comparing future mail with that register. For a personal inbox, use a separate alias for each vendor, with or without a custom domain. For a business domain, pair aliases with DMARC monitoring so you can separate recipient data reuse from mail that impersonates your domain.
Plus tags such as name+vendor@example.com work for quick tracking, but they are easy to strip. A distinct alias such as vendor-r7k9@tracking.example gives clearer attribution because it does not expose your base mailbox address and is harder to guess than a vendor name alone. Treat each alias like a receipt: record the vendor, date, purpose, and consent terms at the moment the address is provided.
Start with one address per vendor
Use unique addresses, not one address everywhere. An unexpected email to a recorded alias identifies a signup path to investigate; it does not establish who shared the address. A consistent naming system and evidence log make it easier to investigate whether a vendor shared the address, uploaded it to a partner, lost it in an incident, or had it matched with data from another source.
- 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
For a quick test, use plus addressing if your mailbox supports it. For tracking that survives tag stripping, create separate aliases or use a domain you control with catch-all routing. Test delivery before signup.
Alias examples
quick: name+vendor@example.com separate alias: vendor-r7k9@example.net catch-all: unconfigured@example.net -> inbox@example.net
Hugh Lashbrooke's address tracking example explains the catch-all method. Treat unexpected mail as an investigative lead rather than proof of a sale.
Choose the address strategy
Start with the address format, because the format controls the quality of your evidence. Plus addressing, also called subaddressing, is convenient when your mailbox provider supports it. Some signup forms reject the plus sign, so test the form and delivery first. The tradeoff is that the plus tag is visible and simple to remove. Separate aliases give better attribution because each address has its own local part before the at sign. A custom domain lets you route those addresses 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: The base address remains visible, and stripping the tag removes your tracking label.
- Best use: Low-risk newsletters, trials, and short-lived tests.
Custom domain aliases
Use them when attribution matters and you can manage DNS and routing.
- Setup: Route a catch-all mailbox or create aliases one by one.
- Evidence: Stronger because each local part is a distinct address.
- Weakness: Requires domain renewal and routing rules; a catch-all also accepts spam sent to guessed addresses.
- Best use: Purchases, contracts, events, and business vendors.
|
|
|
|
|---|---|---|---|
Plus tag | name+tag@example.com | Fast setup | Tag stripped; base address exposed |
Catch-all routing | unconfigured@example.net | Receive unconfigured aliases | Spam to guessed addresses |
Random alias | a8f2k9@example.net | Less predictable recipient address | Needs a register |
Alias forwarding | vendor@example.net -> inbox@example.com | One destination inbox | Original recipient can be rewritten |
Address formats and routing options can be combined; catch-all routing is not a separate type of alias.
Use human-readable aliases for contracts or purchases when the address itself should explain the source later. Random aliases provide more privacy, but they need a manager or register. Add a random suffix to readable names, such as acme-r7k9@track.example, to make guessing harder. Aliases on the same custom domain still expose a common domain. Before contacting a vendor, check whether you can send or reply as the alias without exposing your main address.
Set up the register before signups
The register matters more than the mailbox rule. If aliases are created casually and documented later, the useful context disappears: why the address existed, which form collected it, what the privacy notice said, and whether the vendor had permission to share it. Keep the register simple enough that adding a row takes under a minute.
Vendor register templateCSV
vendor,alias,date,context,consent,policy_date,sharing_terms,status Acme,acme@track.example,2026-06-05,checkout,opt_in,2026-05-01,processors_only,active North,north@track.example,2026-06-05,webinar,opt_in,2026-04-18,partners_listed,active
Vendor email tracking workflow: create an alias, log the signup, review incoming mail, match the sender, and decide what to do.
- Create first: Add the alias to the register before you enter it into a form.
- Capture context: Save the signup page, form purpose, privacy notice date, and consent choices in plain language.
- Filter calmly: Test that routing preserves the original recipient alias, then filter incoming messages using that field.
- Review weekly: Check new senders, domains, and unsubscribe headers against the register.
- Retire cleanly: Update login, account recovery, and billing contacts before retiring an alias. With catch-all routing, add and test an explicit rejection or discard rule for that address.
Check what the privacy policy says about sharing
Your alias register records where you supplied an address. A privacy policy shows what the vendor said it might collect, disclose, sell, or share. Before signup, or as soon as an unexpected message arrives, save the policy's effective date and the wording that applied when the address was collected.
- Data covered: Check whether personal information or contact data explicitly includes email addresses.
- Recipients: Look for service providers, processors, affiliates, advertising partners, data brokers, resellers, and event sponsors.
- Purpose: Separate operational processing from a recipient's own marketing or advertising use.
- Your choices: Record any consent withdrawal, opt-out, access, correction, or deletion process available to you.
- Version history: Keep the effective date or saved copy because policy wording can change after signup.
A service provider sending on the vendor's instructions is different from a partner using the address for its own campaign. Policy wording alone does not establish consent or prove that a specific transfer happened, and a restrictive policy does not identify whether the cause was misuse, a security incident, or data matched from another source.
Add policy evidence to the register
Record the policy title, effective date, relevant disclosure wording, signup-page consent choice, and any privacy request response. This creates a dated comparison point without treating policy language as proof of the message path.
Ask about sharing that never produces an email
Alias tracking detects reuse only when mail reaches an address. A vendor can disclose an email address to a data broker or upload a hashed version for advertising audience matching without another company emailing you. A quiet inbox does not prove that the address stayed private.
The FTC's guidance on hashed identifiers explains that hashing an email address does not make it anonymous. Ask about derived identifiers as well as the original address.
Vendor privacy inquiry templatetext
Subject: Question about use of my email address I provided [alias] on [signup date] for [purpose]. Have you disclosed this address, or a hashed or matched identifier derived from it, to third parties? Please identify the recipients or recipient categories, dates, purposes, and any onward sharing you can confirm. Please explain which opt-out or deletion choices are available to me. Please keep essential account messages enabled.
Send the inquiry through the vendor's published privacy contact and save the response beside the alias record. An unsubscribe request concerns a mailing subscription; it does not establish that other recipients deleted your data.
Read the message evidence
An alias identifies a signup path to investigate. Message headers show technical sending and delivery details, rather than a complete record of who shared the address. 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 help separate a normal vendor newsletter from a third-party campaign using a shared list.
Open the full message source or "Show original" view. A Bcc recipient does not have to appear in To or Cc. Look for Delivered-To, X-Original-To, or a provider-specific original-recipient field where available. Confirm which field your receiving service inserts, since forwarding can replace the destination. Google documents an original-recipient header for rerouted mail. If the alias is missing, check routing logs or test the setup before relying on it.
Use authentication results added by your receiving service. A DKIM d= value is only a claimed signing domain until the signature passes verification. The DKIM specification distinguishes the signer from the purported author; a valid signature does not identify who supplied a mailing list.
|
|
|
|---|---|---|
Recipient alias | Connection to a recorded signup | Public or predictable addresses can be guessed |
From domain | Claimed sender identity | Can be forged |
Return path | Envelope sender for delivery failures | Often belongs to a shared sending service |
Verified DKIM | Domain responsible for the signature | Does not identify who supplied the address |
List-ID | Mailing list identifier | Does not prove where the list came from |
Unsubscribe destination | Mailing list management system | Does not identify every data recipient |
These signals support an investigation; none independently proves that an address was sold.
Evidence caveat
Unexpected mail to an alias used only for one vendor is a lead worth investigating. A predictable catch-all address can also be guessed without any disclosure. It is not proof that the named vendor deliberately sold the address. Shared marketing systems, acquired lists, old consent language, enrichment, and address rewriting can change the path.
Before accusing a vendor, collect the original alias record, the applicable privacy notice, and the full header source of the unexpected message.
Connect alias tracking with DMARC
Alias tracking identifies which recipient address received a message. DMARC aggregate reports summarize sending sources and authentication results for mail claiming your domain in the visible From field, as seen by reporting receivers. They are not incoming mailbox logs and do not identify who shared a recipient address. The aggregate reporting specification defines this reporting scope.
For a business domain you control, use Suped's domain health checker to review DNS configuration, then monitor actual sending sources and authentication results. A DNS check alone does not establish whether every message passes authentication.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
When a vendor sends email for your business, record its From domain, DKIM signing domain and selectors, return-path domain, and approved purpose. Under RFC 9989, DMARC passes when either SPF or DKIM passes with a domain that matches the visible From domain under the applicable relaxed or strict rules. Configure both where supported and remove obsolete DNS authorization when the sending relationship ends.
Suped workflow
In Suped's DMARC reporting product, add the domain, publish a DMARC record with an aggregate reporting address, and review the sources sending mail for that domain. Hosted DMARC helps stage policy changes while keeping the record readable.
Compare reported sources with vendors approved to send for your business. Investigate unknown sources or authentication failures, fix legitimate mail, and review report results before strengthening the DMARC policy. Keep recipient-sharing investigations in the alias register.
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 treating the first message as the whole answer. Use a short response path: preserve the evidence, classify the sender, decide whether the original vendor deserves a factual 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: Explain that you will retire the alias if unrelated mail continues, after updating any account contacts that depend on it.
- Record: Keep their answer beside the alias row.
Unknown sender
An unknown sender usually needs containment first.
- Block: Block the sender or retire an unused alias. With catch-all routing, deleting an explicit alias does not stop catch-all delivery; reject or discard that recipient explicitly.
- 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 evidence to frame a factual inquiry, without treating it as proof of a sale.
Low
Single generic spam
A common address or stripped tag gives weak attribution.
Medium
Unique alias used
An alias recorded for one vendor points to a signup path, subject to guessing and other explanations.
High
Corroborated records
The alias, delivery details, and signup records support a specific inquiry; they still do not prove a deliberate sale.
Contact the vendor through its published privacy channel. Ask an unexpected sender where it obtained your address, using a verified contact rather than a suspicious message link. Save each response with the original evidence.
Limits of alias tracking
No tracking method gives a perfect chain of custody. Some senders strip plus tags, normalize addresses, combine records with old files, or create inferred data. Separate aliases preserve a vendor label when a plus tag would be stripped, but they do not prevent address rewriting or matching against another source.
Known failure modes
- Tag stripping: A plus tag disappears and the message arrives at the base address.
- Address guessing: A catch-all accepts mail to unconfigured addresses, so a vendor name alone is weak evidence of a leak.
- Old lists: A main address was already circulating before tracking started.
- Shared systems: One vendor uses a partner platform that sends under another brand.
- Inferred records: A broker creates a profile that looks related but came from matching or inference.
- Role aliases: Shared addresses make it hard to identify the original signup person.
Do not 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, retire the alias after confirming that no account or recovery messages depend on it.
Frequently asked questions
Yes, when your provider supports plus addressing and the signup form accepts it. A tag such as name+vendor@example.com helps only while it stays intact and still exposes the base address. Use a separate alias when attribution matters.
They are complementary. An alias is the address given to a vendor, while catch-all routing delivers mail for unconfigured addresses at your domain to a chosen mailbox. Catch-all routing also accepts guessed-address spam. Create explicit aliases and disable catch-all routing when you want only approved recipients to receive mail.
Save the alias register row, signup context, applicable privacy notice, original message source, sender domain, return path, DKIM signing domain, unsubscribe details, and any vendor response. A screenshot alone is weak because it drops header data.
No. DMARC aggregate reports summarize sources and authentication results for mail claiming your domain in the visible From field, as observed by reporting receivers. They do not trace recipient addresses or show who shared them. Use your alias register and original delivery evidence for that investigation.
Ask which processors, affiliates, partners, or sponsors handled the address and request the privacy information available in your location. Ask the unexpected sender where it obtained the address, and keep monitoring the alias. If you retire it, first update account and recovery contacts, then block or discard that recipient explicitly if catch-all routing remains active.
Use unsubscribe for a legitimate sender you recognize. Use the mailbox spam-report flow, block the sender, or retire an unused alias when the sender is unknown or deceptive. Blocking or retiring an alias controls incoming mail; it does not delete data already held by vendors.
