How a SaaS founder isolated 23 vendor accounts after a support-agent leak
When your AWS, Stripe, and Postmark all share the same address
Marc's compliance SaaS depends on 23 third-party vendors to run — AWS, Stripe, Postmark, Cloudflare, DataDog, Sentry, PagerDuty, GitHub, Vercel, Slack, Notion, Zoom, the usual stack. Every one of those accounts was set up using his founder Gmail. By the time the team grew past five people, he had no observability into which vendor's support team had access to what.
The incident that prompted the rebuild: a Postmark support agent at a third-party support contractor in the Philippines leaked a chunk of customer-support tickets in mid-2025, and Marc's email — plus the content of his support exchanges with Postmark over six months — ended up in a public Pastebin dump. Some of those exchanges contained partial customer IDs and product configuration details he absolutely did not want public.
The Postmark leak didn't directly compromise his product, but it was a clear demonstration that any vendor's support tier could leak whatever conversation he'd had with them — and his entire founder identity could be searched and correlated across every vendor's data set. He decided he'd had enough. The pattern of an email alias for business operations isn't just consumer privacy — for SaaS founders managing critical vendor stacks, it's incident-response insurance.
The setup: per-vendor aliases on a separate domain
- Registered a second domain solely for operational vendor accounts (
<company>-ops.io). Pointed MX at EmailAlias.io Premium. - Generated one alias per vendor account:
aws@<ops>,stripe@<ops>,postmark@<ops>, etc. - Updated each vendor's billing email + account email to the new alias. Removed the old Gmail from each account's recovery options, replaced with the alias destination ProtonMail.
- Set up a per-vendor exposure-detection alert. Spam on any vendor alias is treated as a signal that vendor's data plane has leaked.
What changed
Marc's founder Gmail is now reserved for customer email and a handful of business-development contacts. Every vendor account routes through a vendor-specific alias on the operational domain, which itself routes to a hardened ProtonMail destination protected by hardware 2FA.
Three weeks after the rebuild, the AWS alias started receiving phishing for the first time — a fake "AWS service interruption" email. Marc traced it: AWS's third-party support contractor had a small data leak that month, and his AWS alias was on the leaked list. He muted the alias for two weeks, generated a new AWS-account alias, updated AWS with the new address, and the issue was over. None of the other 22 vendor relationships were affected. The blast radius was one alias and four hours of cleanup.
The team-level win is operational: when a senior engineer leaves the company, Marc disables the personal alias they used for their work GitHub, transfers ownership using the vendor-account alias, and no email follow-up from that vendor ever reaches the engineer again. Offboarding got cleaner overnight.
What this would have cost without aliases
The economic cost of the Postmark incident, had Marc's founder identity been compromised in a more material way, was non-trivial. SOC 2 audits explicitly inquire about vendor-management practices; a leak that exposed his founder identity across multiple vendor accounts would have flagged in his next audit cycle as a material risk. Aliases reduce the audit footprint by demonstrating that vendor-level compromise is contained at the alias boundary.
There's also a financial-stack risk specific to SaaS founders: if a vendor leak exposes the email registered with Stripe Atlas, AWS Organizations, or his domain registrar, a determined attacker can mount an account-takeover chain that ends with the loss of the corporate AWS root account or the corporate Stripe balance. The expected-loss math for a $1.8M ARR SaaS on those events is brutal. Aliases neutralize the chain by ensuring no two vendor logins share an email address attackers can correlate.
What he tried first
Marc's first attempt to separate vendor identity was a Google Workspace account with role-based aliases (billing@, ops@, security@). That worked for inbound routing but failed at the identity-isolation goal: all those aliases resolved to the same Google account, so a vendor that leaked the billing alias was effectively leaking the founder identity. Aliases need to live on infrastructure that decouples them from a single underlying account — that's the whole point.
He also evaluated addy.io and SimpleLogin. Both work for individual-user setups but neither shipped a clean per-vendor analytics view or an API-first workflow for programmatic alias generation from his admin tooling. EmailAlias.io's documented REST API meant he could wire alias creation into his internal vendor-onboarding workflow — every new vendor signup automatically gets its own alias as part of the procurement step.
The day-2 operational reality
The team-onboarding workflow now includes "vendor aliases" as a discrete onboarding step. New engineers don't learn the underlying vendor passwords; they learn which alias maps to which vendor and access vendor accounts through SSO + the alias. This has an unintended-but-positive consequence: engineer offboarding no longer requires rotating vendor passwords (which most teams skip), because the engineer never had the password to begin with.
Operational maintenance for Marc is about 15 minutes per week — reviewing exposure alerts, occasionally generating a new alias for a freshly-procured vendor, and rotating any alias that's started attracting suspicious activity. The rest of the system runs itself. The setup cost was about 6 hours; the recovered hours per year on incident-response and vendor-correlation paranoia is approximately a full work week.
Lessons for setting this up yourself
- Use a dedicated operational domain, separate from your customer-facing one.
<company>-ops.tldkeeps the email infrastructure isolated. - Generate aliases programmatically via the API as part of vendor onboarding. Manual generation is the failure mode.
- Route alias destinations to a hardened mailbox (ProtonMail, Tuta) with hardware 2FA, not the founder's regular email.
- Make alias rotation part of incident-response runbooks. When a vendor publicly discloses a breach, rotation is a 10-minute task, not a debate.
- Document the alias-to-vendor mapping in your internal vendor registry. Future engineers need the lookup, and "check the EmailAlias dashboard" is faster than "ask Marc."
“Treating my vendor identity as a separable surface, one alias per vendor, made the worst-case impact of any future support leak finite. That was worth the afternoon of setup.
Frequently asked questions
Does using an email alias for SaaS vendors create vendor-management compliance issues?
It actually helps. SOC 2, ISO 27001, and HIPAA all favour explicit separation of vendor identity, audit logs of access changes, and rapid revocation capability. Aliases provide all three in a way that's easier to demonstrate than role-based shared mailboxes. Document the alias system in your security policy and your auditors will accept it.
What if a vendor requires phone-based 2FA on the founder account?
Aliases don't replace phone-based 2FA; they sit alongside it. Most vendors allow a phone number that's separate from the email. Some founders set up a dedicated office line or VOIP number for vendor 2FA the same way they set up aliases — same isolation principle, different surface.
How do I handle vendor accounts that require email verification before allowing changes?
Aliases support this natively — the verification email forwards to the destination inbox, you click the link, and the vendor accepts the new email. Same flow as any other email change. The verification chain works because the alias is a real, deliverable address, not a temporary disposable inbox.
Isolate your vendor stack the same way
Per-vendor aliases on a custom operational domain. Premium covers up to 5 custom domains and unlimited aliases.