A separate email for banking is a dedicated, permanent address used only for financial accounts and handed to no one else. The bank receives the real address, never a masked or relay alias. Everything else gets aliases, which keeps the banking address out of unrelated databases.
Banking and identity verification
Banks hold money, verify identity under regulation, and use email as a recovery and notification channel. Password resets, statements, fraud alerts and, after an incident, breach notifications all run through the address on file. The address therefore carries the recovery path to the account, which makes its permanence matter more than its secrecy. Losing access to the banking address can mean losing the way back into the account itself.
SBI's security pages state that the bank never asks customers for user IDs, passwords, one-time passwords, card numbers or CVV values by email, text or phone, and asks customers to report any such request to report.phishing@sbi.co.in (SBI security awareness tips). SBI UK's fraud guidance gives the same rule in shorter form: the bank never requests passwords or one-time passwords, and customers are told to check that the sender domain of any mail claiming to come from it is trustworthy (SBI UK fraud alert). The banking inbox still receives real bank mail, which is why the address has to be one the holder actually opens.
Den Delimarsky, writing about email aliases in November 2024, holds that aliases are a privacy measure rather than a security measure, and advises treating all email addresses as if they were public information; his post began as a debate about using aliases for bank accounts (Den Delimarsky on email aliases). The security boundary sits at the inbox itself. It needs a unique password and two-factor authentication, because every password reset flows through it, which is also why the breach-response checklist puts email first (breach-response checklist). Bank and card numbers do not travel by email at all, dedicated address or not (what not to send by email).
The SBI data exposure of October 2026
On 16 October 2026, the State Bank of India received alerts from its threat intelligence provider, the Defence Cyber Agency and CERT-In that customer data had appeared on the dark web. On 21 October the bank filed a stock-exchange notice titled "Incident involving Data Loss". The preliminary analysis covered about 375,000 records and identified 3,897 customer records containing personal data. The listed fields included registered mobile numbers, dates of birth, names, gender, email addresses, home addresses, branch and customer information file identifiers, lead IDs and loan metadata (Indian Express explainer). Passwords, PINs and one-time passwords were not among the listed fields. The full incident is covered separately (the SBI breach analysis).
On 23 October SBI said it had individually informed every customer whose data was identified as involved, through email and/or WhatsApp, and reiterated that account balances were safe (mid-day report). The address given to the bank is therefore the address the bank uses to warn its customers after a breach, and a banking address that sits unused weakens that channel at the moment it is needed.
The exposure included the email addresses the bank itself held. Isolation limits where else an address appears; it does not stop the bank's own breach, and no customer-side habit changes that. The Internet Freedom Foundation, in its analysis of the filing, notes that a caller who quotes a name, date of birth, branch, customer identifier and loan details sounds like the bank, and that leaked data erodes a customer's ability to tell a fraudster apart from the bank (Internet Freedom Foundation analysis). In a related pattern, the Foundation reports that in July 2026 Bank of Baroda began a forensic investigation after a compromised employee email account allowed unauthorised access to its data; that account rests on the Foundation's reporting and has not been independently re-verified here.
Bank guidance on email contact
Banks publish the same rule in different words: they do not ask for credentials over email. That rule defines what the banking inbox should contain. Real bank mail is statements, alerts and notices. Anything asking for a password, a one-time code or payment details is not the bank, whatever the display name says.
After a breach, forged notices copy the company's real templates and land in the same window as the genuine ones, quoting the same apology. When the attacker holds the real customer file, content checks stop working and the channel has to do the work instead. A dedicated banking address makes the channel test mechanical: mail that claims to be the bank and arrives on an address the bank never held identifies itself as forged. The mechanism is worked through in detail in the piece on post-breach phishing (how post-breach phishing works), and the companion piece on checking a suspicious email covers the same test (checking a suspicious email).
Masked addresses and financial accounts
A masked or relay address is the wrong tool for banking, even though it is the right tool elsewhere. The distinction is permanence. A temporary or masked address is built to be abandoned, which suits signups that will never matter again and breaks anything that relies on email for password resets or account recovery. A temporary-email guide published by robots.net in October 2026 states that disposable email should not be used for banking or for anything that relies on email for password resets; the same guide notes that plenty of services check signups against lists of known disposable domains and reject them, and gives the positive form of the rule as keeping the main address for people, banks, employers and the handful of services depended on, and giving everything else an alias or a temporary address (robots.net temporary email guide). No verified case of a bank rejecting a relay-mask domain specifically was found; the verified fact is the general disposable-domain blocklist, and the bank-specific case is not claimed here.
The privacy community draws the same line. In a Privacy Guides community thread opened in January 2024, the original poster treated banking and shopping as the "real-you identity" email use case, kept separate from the anonymous aliases used for forums, reddit and newsletters (Privacy Guides discussion). The thread debates how far the separation should go. The banking classification is uncontested in it.
The dedicated banking address
The setup that follows from all of this is one permanent address, owned by the account holder, used only for banks, brokers and other financial accounts, and handed to nobody else. It can be an address on the holder's own domain or a plain mailbox; what matters is that it is real, permanent and exclusive to banking. It is the deliberate exception to the general rule that separation should come from aliases rather than extra inboxes, and the general piece on second addresses states the banking exception in the same terms (do you need a second email address). The one-address-per-site mechanism, which this setup deliberately excepts, is covered in full in the every-website guide (different email for every website).
The address also has to be one the holder opens. Banks use the address on file for fraud alerts and breach notifications, as SBI's notification on 23 October showed. A dedicated address that is never opened is a dead channel. The separation is not there to hide the address from the bank; it is there to make sure the bank's mail is the only mail that ever arrives there.
Isolation through aliases
The dedicated address stays clean because everything else gets something different. Shopping sites, forums, newsletters, free trials and one-off signups each get their own alias, so the banking address never enters those databases. Giving the banking address to a shop would undo the separation in a single signup, which is the habit the aliases exist to replace.
Credential stuffing replays leaked email and password pairs against login pages elsewhere, and the email half of the pair only works if it matches the account being attacked (how credential stuffing works). An address that appears in no non-bank breach file cannot be stuffed into a bank login from some other site's leak. And when a non-bank site leaks its alias, the alias names the source: mail about that site arriving on its own alias is expected, and mail claiming to be the bank on any other address is not (which website leaked my email).
AliasFleet and the banking address
AliasFleet is an email alias service. It creates forwarding addresses, one per site, so each site holds a different address and a leaked one can be paused without touching the rest (AliasFleet). The free tier covers 10 active aliases. In the banking setup described here, AliasFleet's role is the inversion: aliases for shopping, forums, newsletters and signups, which is what keeps the banking address out of non-bank databases (what an email alias is).
What AliasFleet does not do here is the point of the piece. The bank does not receive an alias. Banks need a permanent address tied to a verified identity for account recovery, statements and fraud alerts, and AliasFleet issues forwarding aliases rather than permanent mailboxes. The banking address is a real address owned by the account holder; the aliases are for everything else.
Top comments (0)