Can Attackers Send Email as Your Bank? Email Spoofing Defences at Indian Banks and Insurers, 2026

From a bank's main email domain, it is now hard. From its .bank.in domain, often it is not. On 2026-10-04 all 45 Indian public sector, private, small finance and payments banks enforced DMARC on their main email domain. Yet 8 of the 49 .bank.in domains the RBI lists for those same banks (16%) had no DMARC record at all.

The .bank.in gap

The RBI's "Banks in India" page links banks to their websites on .bank.in. A customer who sees an address on that domain has every reason to believe it is the bank. When the domain carries no DMARC record, mail providers get no instruction to reject a forged message sent from it, and the bank gets no report that anyone tried.

The odd part is that the 8 banks behind those domains already know how to do this. All 8 publish DMARC on their main email domain. The .bank.in domain simply never got the same record. Widen the view to every .bank.in domain on the RBI page that resolves, including regional rural and foreign banks, and 20 of 93 (22%) have no DMARC record.

Main domains: banks lead, insurers and NBFCs trail

DMARC has three policy levels. p=none only watches, p=quarantine sends failing mail to spam, and p=reject tells the receiver to refuse it. Reject is the one that actually stops a forged message from reaching the inbox.

Insurers have mostly started but stopped halfway: of 60 insurers registered with IRDAI, 22 (37%) sit at p=quarantine. Among the 17 NBFCs in the RBI upper layer for 2026-27, one publishes two DMARC records on the same domain, a setup mail receivers must ignore.

Beyond DMARC

MTA-STS stops an attacker on the network from forcing mail onto an unencrypted connection. Only 1 of 45 domestic commercial banks and 3 of 60 insurers publish it.

BIMI puts a verified brand logo next to the message in supporting inboxes. 13 of 18 private sector banks (72%) publish a BIMI record, against 2 of 12 public sector banks (17%).

SPF is present almost everywhere but often soft: 28 of 45 domestic commercial banks (62%) end their SPF record with a hard fail (-all) and 17 use a soft fail (~all). Among insurers the split is 27 hard fail and 30 soft fail out of 60.

Four fixes for a bank or insurer

1. Move to p=reject. If your DMARC reports show every legitimate sender passing, going from quarantine to reject is a one-line DNS change. Spoofed mail in a spam folder can still be found and trusted.
2. Cover .bank.in and every other domain you own. Copy the DMARC policy from your main domain. A domain that never sends mail can take p=reject and an SPF record of v=spf1 -all straight away.
3. Publish MTA-STS and TLS-RPT. MTA-STS tells sending servers to refuse an unencrypted or unverified connection to you, and TLS-RPT reports when that happens. Two DNS records and a small policy file.
4. Add BIMI once you are enforcing. BIMI only works with DMARC at quarantine or reject, and the larger mailbox providers also want a mark certificate. The logo gives customers one more thing to check before they click.

None of this stops lookalike domains, which pass every check because the attacker owns them. Those need monitoring and takedown. Our DMARC+ service handles the move to enforcement, and the domain name monitoring service watches for lookalikes.

About the data

We read public DNS records for the scheduled commercial banks on the RBI "Banks in India" page, the insurers on IRDAI's lists and the NBFCs in the RBI upper layer, all on 2026-10-04. Only organisations whose email domain we could verify are counted. Foreign banks were scanned on their global group domain. A DMARC policy tells receivers what to do with failing mail; it is not proof that a domain is never spoofed.

The full sector tables, the Nifty 100 comparison, the method, the limitations and a CSV download are on the India Email Authentication Census 2026 published by Hunto, part of the TIKAJ group. We publish sector totals only and do not name any organisation.