Brave shipped version 1.94 with a feature called Email Aliases, which generates disposable email addresses on demand when a user signs up for a new service. The alias forwards messages to the person's real inbox, so the site gets a working address it can email, but never learns the address the user actually reads mail at. The activity described here was documented by BleepingComputer.
The gap Brave is closing here is specific. The browser already isolates site data to stop websites from correlating a user across the web through cookies or cache artifacts, but an email address typed into a signup form sits on that company's servers as a permanent, portable identifier. Brave frames the risk in terms of what happens after that company gets breached.
"If a website you signed up for is hacked, your information can be leaked and end up with data brokers or worse. Your email address then circulates far beyond the company you originally trusted with it, and can show up in phishing campaigns for years afterward." - Brave
Using aliases requires a free Brave Account with a registered primary address so forwarding can work, which is separate from a Brave Premium subscription. The free tier covers five aliases, and Brave says a paid Premium version lifting that cap will follow.
None of this is a new idea. Apple Hide My Email, Firefox Relay, and DuckDuckGo Email Protection all do a version of the same thing, and aliasing is steadily becoming a default browser and OS capability instead of a niche privacy tool.
That is why this matters beyond consumer privacy. If your users adopt aliasing, the email address attached to a given account is no longer a reliable way to identify who owns it, which touches account recovery, helpdesk verification, and any process that assumes one person maps to one address. Aliases also change what shows up in breach-notification and credential-monitoring feeds, since the leaked identifier may not match anything in your directory.
How Alias Forwarding Breaks Email-Based Tracking
Each alias Brave generates is unique to the site it was created for, which is what actually breaks the tracking. An email address is one of the few identifiers that stays stable across every service a person uses, so when the same string appears in two different customer databases, those records can be joined. Give each site a different address and the join key disappears.
This matters most against hashed-email matching, the technique that underpins much of modern adtech identity resolution. Data platforms rarely trade raw addresses. They hash them, usually with MD5 or SHA-256, and match on the hash, which lets two companies confirm they hold the same person without ever exchanging the plaintext address. A unique alias produces a completely different hash at every site, so the match fails and the identity graph never links the two records.
The forwarding path itself is a relay. Mail sent to the alias arrives at Brave's infrastructure, gets mapped to the registered primary address, and is delivered onward. Brave stores both the primary address and the generated aliases in an encrypted state, applies only automated spam and malware filtering to the messages passing through, and deletes them from its servers within seconds after delivery. Notes attached to an alias stay local, or are end-to-end encrypted if the user has Brave Sync turned on.
Relay operators still see metadata regardless of how briefly they hold the message. The mapping between alias and real inbox is the service, so the provider necessarily knows which sites a user signed up for, when mail arrives, and who sent it. That is a trust transfer, and it is worth understanding before routing account recovery mail through any relay. If you lose access to the account holding the aliases, you lose the inbound path for every service configured to use them.
Aliases operate at the identity layer only. They do nothing about browser fingerprinting, IP address correlation, or the tracking that happens once someone is logged into a service and browsing while authenticated. A retailer that already knows a customer through a loyalty account does not need the email address to profile them.
Reply paths are the most common leak. A reply has to travel back out through the relay so the outbound message carries the alias in the From header. If a mail client replies directly to the original sender address instead, the real inbox appears in the headers and the site learns the address the alias was meant to hide.
Then there is authentication, which is where relayed mail gets messy in practice:
- SPF breaks on forwarding. The receiving server checks the connecting IP against the original sender's SPF record, and the relay's IP is not in it. Providers work around this with envelope sender rewriting, but the failure is structural.
- DKIM survives only if headers and body are untouched. Any rewriting of the subject line or message body invalidates the cryptographic signature.
- DMARC then decides the outcome. With SPF failed and DKIM broken, a sender publishing a strict reject policy tells the receiving mail server to drop the message outright.
Brave has warned that forwarded messages may land in spam folders while it builds its reputation as an email provider. Some senders also reject known alias and disposable domains at signup, which limits where this works. For business use, that means transactional mail such as invoices, password resets, and shipping confirmations needs testing per sender before anyone relies on an alias for it.
Breach Containment and Data Broker Exposure
When a service you signed up for gets breached, the address in that leaked database is a single-use string that appears nowhere else. That changes what an attacker can do with it. Credential stuffing works because people reuse the same address and password pair across dozens of accounts, so one dumped customer list becomes a key that gets tried against banking, email, and SaaS logins. An address that exists at exactly one vendor gives an attacker one door to try.
That long tail matters more than the initial breach for most people. Leaked address lists get resold and reused for years, which is why you still receive targeted phishing referencing a company you stopped doing business with long ago. Retiring an alias cuts that stream at the source instead of leaving you filtering it forever.
For staff, the reduced phishing surface applies mostly to personal and low-stakes signups. Role-based addresses like billing or accounts payable are a different case, because those are published, shared across a team, and cannot be quietly rotated without breaking vendor workflows. Aliasing helps the individual employee signing up for a webinar or a vendor portal more than it helps the shared mailbox that processes invoices.
If you sit on the receiving side of this, the picture is more mixed. Aliases break customer identity resolution, the process of recognising that the same person appears in your CRM, your support tickets, and your marketing platform. A customer who signs up with one alias, contacts support from another, and later returns through a third looks like three separate people in your records, which distorts lifetime value calculations, churn analysis, and any deduplication you rely on.
Deliverability is the next practical concern. Brave has warned that forwarded messages may land in spam folders while it builds its sending reputation, which means transactional mail you assume arrived may not have. That includes password resets, order confirmations, and appointment reminders. Your bounce and complaint metrics can also shift as customers retire aliases without unsubscribing, since a dead alias behaves like a hard bounce rather than an opt-out.
Regulated onboarding gets harder too. If your KYC or account verification process treats a verified email address as a stable identifier tied to a real person, a disposable forwarding address weakens that assumption. Account recovery is the same problem in reverse. When a customer loses access to the alias, or when they simply cannot remember which alias they used with you, your support team has fewer reliable ways to confirm identity, and recovery calls take longer.
Finally, cheap unique addresses lower the cost of creating multiple accounts. Free trial abuse, referral bonus farming, review manipulation, and promotional code stacking all depend on generating fresh identities, and a per-site address supply makes that easier. The limit of five free aliases constrains casual abuse, though Brave has said a paid tier lifting that cap is planned. If your business model assumes one email equals one customer, that assumption is worth revisiting.
Detection and Policy Considerations for Security Teams
Start with an inventory. Find out whether Brave 1.94 is already installed on managed endpoints and BYOD devices, because alias adoption is a user-driven change that arrives without an IT ticket. Your software inventory or endpoint agent can answer this in an afternoon, and the answer determines whether the rest of this list is theoretical or already live in your environment.
Then make a deliberate decision at the mail gateway about relayed sender domains. Brave has said forwarded messages may land in spam folders while it builds sender reputation as a new email provider, which means aggressive filtering on your side produces silent delivery failures that users blame on the vendor rather than on your gateway. Pick allow or block, document which, and give the mail administrator ownership of the rule.
The third immediate item is account recovery. An alias that is deactivated, or one that never got created because the free tier caps at five, becomes a password reset address that no longer resolves. Check that no break-glass administrator account, domain registrar login, or certificate authority contact uses a relayed address as its only recovery path.
Over the next few weeks, three changes are worth scheduling:
- Acceptable-use and BYOD policy. State plainly whether staff may use browser-generated aliases for work accounts, and who approves exceptions. Security policy owner signs off, HR distributes.
- Fraud and dedupe rules that key on email uniqueness. If your product enforces one account per address, or scores disposable domains as risk signals, aliasing will start rejecting legitimate customers. The fraud or product engineering team owns retuning those rules.
- Signup and password-reset flow testing. Register a test account with an alias, run a full reset cycle, and confirm the message arrives and the link works. QA owns the test case.
Longer term, treat per-service aliasing as a control you adopt on purpose for the accounts that matter, starting with vendor portals, cloud consoles, and shared administrative logins. Pair it with a password manager so the alias and the credential are stored together, and with phishing-resistant MFA using hardware keys or platform authenticators. Brave is explicit that the OPAQUE key exchange behind Brave Accounts, standardized as RFC 9807, keeps passwords and hashes off its servers but does not protect users from phishing or weak passwords. The authentication protocol is not the control that stops a credential from being handed to an attacker on a convincing login page.
Aliasing also gives you a detection signal you did not have before. When a single alias tied to one vendor begins receiving mail from unrelated senders, that vendor has leaked or sold the address, and you can act on it before anyone confirms a breach publicly. Assign someone to review alias spam reports monthly and log which vendor each hit points to, because that record feeds directly into third-party risk reviews.
On the identity side, aliasing changes the address but not the credential. In environments Capstone manages, Adlumin monitors authentication behavior across accounts, flagging logins to administrative and vendor portals from unexpected locations or at unusual times, which is what catches a reused password long after the alias has done its job of limiting who knows the address. Keep alias adoption and identity monitoring as separate controls with separate owners, and review both at the same cadence.
Where Email Aliasing Fits in a Privacy Programme
Email aliasing narrows one identifier. It does not touch the other ways a browser or a device gives you away, and treating it as a privacy fix rather than a single control leads to bad assumptions about what your users are protected from.
Fingerprinting still works. A site that reads your rendering behaviour, fonts, screen geometry, and timing characteristics can build a stable profile without ever asking for an address. Application and OS telemetry keeps flowing regardless of what you typed into a signup form, and an alias does nothing about the location data your phone shares or the identifiers baked into mobile advertising frameworks.
Authentication is the other blind spot. Brave's own documentation is explicit that OPAQUE reduces exposure to password logging and bulk cracking of leaked databases, but does not protect against phishing or weak passwords. A disposable address in front of a reused password leaves the account just as reachable.
The practical friction shows up in your own systems. Fraud engines that score relay and disposable domains as suspicious will start rejecting legitimate customers. Account recovery flows that verify identity by matching an address on file break when the customer no longer remembers which alias they used. Business accounts registered under an employee's personal alias become difficult to reclaim when that person leaves.
The action worth taking is a decision, not a deployment. Agree an organisational position on alias services before staff adopt them individually, write it down, and confirm that your identity verification, fraud scoring, and account recovery processes can accept an aliased address without failing the person on the other end.
