What Is Phishing? DMARC at 20 Indonesian Financial Institutions

Phishing is fraud that impersonates a trusted institution's official channel (its email domain, website, app or sender number) to get the victim to hand over a password, PIN or one-time code. When the institution being impersonated is a bank, the attacker is borrowing the bank's own identity, so part of the attack surface is controlled by whoever owns that channel. We measured 20 Indonesian banks, insurers and a multifinance company on 26 October 2026: 10 still publish DMARC at p=quarantine rather than p=reject, only 3 have BIMI backed by a Verified Mark Certificate, and none publishes MTA-STS.

The fraud it feeds isn't small. OJK press release SP 185/OJK/DKPU/X/2026 (5 October 2026) reports that the Indonesia Anti-Scam Centre (IASC) received 702,342 reports between its launch on 22 November 2024 and 30 September 2026, blocked 702,833 accounts and froze Rp811.1 billion. Those figures cover every kind of financial-transaction scam, not phishing alone; OJK doesn't break them down by method.

What is phishing, from the channel owner's side: three attacks, and DMARC stops one

When we checked Google in Indonesia for "what is phishing" on 26 October 2026, the AI Overview cited Wikipedia, IBM, Microsoft and Cisco, and the organic results under it ran from Check Point and Imperva to Telkom University and the US Office of the Comptroller of the Currency. Every one is written for the person who receives the message: don't click, check the spelling, distrust urgency. The Head of Digital who signs off a bank's channels has a different question. Which part of the impersonation can we close from our side?

That depends on the kind of impersonation. There are three, and they get blurred together:

• Exact-domain spoofing. Mail that genuinely carries the bank's domain in the From address, say notifications@yourbank.co.id, sent from a fraudster's server. DMARC closes this.
• Display-name spoofing. The display name reads "Your Bank", but the address behind it is a Gmail account or a random domain. DMARC never sees it.
• Lookalike domains. A near-miss domain: swapped letters, an added hyphen, a different extension. DMARC doesn't see this either, because the fraudster owns that domain and can publish perfectly valid SPF, DKIM and DMARC for it.

The standard states its own limit. RFC 9989 (May 2026), which now replaces RFC 7489 as the DMARC specification, says in §2.2 that DMARC counters exact-domain impersonation only, and doesn't address visually similar domain names or display-name abuse. Two of the top ten Indonesian-language results for phishing adalah call lookalike domains "domain spoofing" or treat them as DNS spoofing. Those are three different things with three different controls.

Phishing email vs email spoofing

"Phishing email" is the lure; "email spoofing" is one way of dressing it up. A phishing email from yourbank-secure.com isn't spoofed at all: it's sent, authenticated and signed by the domain the fraudster registered. Only the first of the three cases above is spoofing in the strict sense, and only that case is in DMARC's reach. In Indonesia almost nobody searches this in English: "what is phishing" draws 390 searches a month, against 22,200 for the misspelt Indonesian phising adalah and 8,100 for phishing adalah (Google Ads volume via DataForSEO, 23 and 26 October 2026). Any customer-facing warning a bank writes has to work in Bahasa Indonesia, misspelling included.

The measurement: email authentication at 20 financial institutions, 26 October 2026

We ran dig against the public resolver 1.1.1.1 from our server in Jakarta at 05:01 UTC on 26 October 2026, on the apex domains of 20 institutions: 17 banks, 2 insurers and 1 multifinance company. We read the DMARC policy, the SPF terminator, the BIMI record and its certificate, MTA-STS, TLS-RPT and CAA.

The same run found:

• SPF: 15 domains end in -all (reject unlisted senders) and 5 end in ~all: BTN, OCBC, Panin, Allianz and HSBC. btpn.com resolves and ends in -all, but it has SERVFAILed intermittently on public resolvers (DNSSEC), so receivers may sometimes get a temperror for it. Under RFC 7208 §8.5, the softfail that ~all produces shouldn't be a receiver's sole reason to reject a message.
• An explicit subdomain policy, sp=reject, appears on only 4 domains: BCA, BRI, Maybank and Bank Mega.
• BIMI with a VMC: all three certificates (BCA, BRI, OCBC) were issued by DigiCert and run until April, June and August 2027. Adira's default._bimi record holds a token, not a BIMI record.
• MTA-STS: 0 of 20. TLS-RPT: 0 of 20.

How to read these numbers. We checked apex domains only; banks also send from other domains and subdomains we didn't look at. BIMI with a VMC makes a domain eligible to show its logo in inboxes that support BIMI. It doesn't guarantee the logo appears. And "exact-domain spoofing is closed" holds only for the 10 domains at p=reject: p=quarantine sends failing mail to the spam folder, where a customer can still open it. BTPN now operates as SMBC Indonesia; its new domain, smbci.com, is also at quarantine, with SPF -all and no BIMI.

Our view: on a bank's apex domain, quarantine is half a step. Once every legitimate sender is listed in SPF and signing with DKIM, mail that fails DMARC in the bank's name is almost certainly forged, and filing it under spam still delivers it to the customer.

For fairness, our own numbers: webarq.com publishes DMARC p=reject and SPF -all, but our BIMI record carries no VMC, and we haven't published MTA-STS, TLS-RPT or CAA. So webarq.com isn't logo-eligible in Gmail either.

What Indonesian regulation requires, and what it leaves out

The word "phishing" appears zero times in POJK 22/2023 on consumer protection, in POJK 12/2024 on anti-fraud strategy, in PBI 2/2024 and in PADG 24/2024, by our count of each official text. The instrument that does use it is SEOJK 29/SEOJK.03/2022 on cyber resilience and security for commercial banks (27 December 2022), seven times. In Appendix I.b, control 4.1.b item 19, it names DMARC outright:

implementasi kebijakan Domain-based Message Authentication and Conformance (DMARC) atau protokol autentikasi surat elektronik untuk melindungi domain dari penggunaan yang tidak sah agar tidak digunakan dalam serangan atau aktivitas ancaman keamanan siber antara lain penyusupan surat elektronik bisnis (business email intrusion) dan phishing melalui surat elektronik (email phishing);

In English: implement a DMARC policy, or an email authentication protocol, to protect the domain from unauthorised use in cyber attacks such as business email intrusion and email phishing. Note what the sentence doesn't contain: a policy level. p=quarantine satisfies its wording. The case for p=reject comes from RFC 9989 §4.7, not from OJK: quarantine means the domain owner considers failing mail "suspicious", while reject means the owner treats a failure as a clear sign the domain is being used without authorisation. The big receivers don't force it either. Gmail's sender guidelines for senders above 5,000 messages a day accept DMARC at p=none. SEOJK 29 also binds only commercial banks; for insurers and multifinance companies we haven't yet read an equivalent cyber circular.

On Bank Indonesia's side, PADG 24/2024 (31 December 2024) Article 13 requires a cyber-security culture programme of awareness, training and/or education, for internal staff, third parties and consumers, at least once a year. The elucidation of Article 13(2) then splits the audiences: only awareness (videos, bulletins, posters) goes to consumers; training goes to internal staff and third parties, education to internal staff alone. Article 23(e) asks for authentication methods matched to the cyber risk profile. In POJK 22/2023 (20 December 2023), Article 24(1) requires financial service providers to secure their information systems and cyber resilience for consumer protection, and Article 24(5) defers to sectoral rules, which for banks means SEOJK 29. We set out the screen-by-screen obligations in our reading of OJK consumer protection regulation POJK 22/2023.

In short, regulation asks banks to educate customers and to run DMARC in some form. Everything else, the technical surface that makes impersonating a bank harder, is left to the institution. Reporting the loss once fraud has happened falls under POJK 12/2024, which this cluster covers separately on Wednesday.

The controls a channel owner can ship

None of the rows below DMARC is required by any OJK or BI instrument we read.

Some notes on that table. RFC 9989 drops the pct tag and adds np for non-existent subdomains and t for test mode. Google's BIMI guide requires DMARC at quarantine or stricter and a VMC or CMC from a third-party CA; a BIMI record without a certificate, like ours, shows no logo in Gmail. MTA-STS protects mail sent to the bank's domain from interception in transit; it doesn't stop spoofing. CAA stops other CAs issuing certificates for the bank's domain, and does nothing about a lookalike domain a fraudster registers.

Lookalike domains and fake apps

Registering a .co.id name under PANDI's Domain Name Registration Policy version 9.0 (30 September 2024) §8.1 requires a business identification number (NIB) and the registrant's identity, so fraudsters tend to use .com, .id or another generic extension. Useful monitoring covers all of those, plus the app stores and APK files passed around outside them. SEOJK 29 Appendix I.c control 3.c item 3 asks for "malicious domain" detection through DNS query logging, but that's the bank's internal DNS log, not monitoring for lookalike domains on the open internet.

OTP and transaction prompt wording

SMS and in-app OTPs can be phished in real time: the fake site relays the password and code the customer types to the real bank while the code is still valid. An OTP message that names the transaction type, amount and payee lets the customer see that what they're approving is a transfer, not an "account verification". The control that genuinely resists phishing is FIDO2 or passkey authentication, which is bound to the real domain and won't work on a copy.

One official "we will never ask" page

We found no OJK, BI or Komdigi rule requiring a "we will never ask for your OTP or PIN" statement; it's practice, not obligation. To be useful it has to be one-directional and complete: a single page on the bank's main domain listing every sending email domain, WhatsApp Business number, SMS sender ID and official app, with a plain statement of what the bank will never ask for through any of them.

Phishing red flags, and the control behind each

Red-flag lists usually stop at the customer. Each flag has a counterpart on the bank's side:

• An odd sender address → DMARC at reject closes exact-domain spoofing; monitoring catches lookalikes.
• No verified logo → BIMI with a VMC makes genuine mail distinguishable, in inboxes that support it.
• Asked for an OTP by chat or phone → transaction-specific OTP wording and the official-channels page.
• "There's a padlock, so it's safe" → wrong. HTTPS proves the connection is encrypted, not that the site belongs to the bank. A bank page telling customers to trust links that start with "https://" is teaching the habit fraudsters rely on.

Phishing over WhatsApp and SMS

On WhatsApp and SMS, DMARC, SPF and BIMI don't apply at all; they're email protocols. What's left to the bank is a published list of official channels and consistent message wording, so anything outside that list is easy to spot. We found no Komdigi or BRTI rule governing bank-specific SMS sender IDs.

After a customer is hit

The reporting route in Indonesia that has published numbers is IASC: of its 702,342 reports, 334,756 came in through banks and payment service providers, and Rp207.16 billion was returned from accounts at 24 banks. How those losses are recorded and reported to OJK is set by POJK 12/2024, the subject of this cluster's Wednesday article.

For the Head of Digital: the order of work

1. Inventory every domain and subdomain that sends mail in the bank's name, not just the apex.
2. Move DMARC to p=reject with explicit sp/np, once aggregate reports show every legitimate sender passing.
3. Change SPF ~all to -all.
4. Apply for a VMC or CMC and publish BIMI with a=.
5. Publish MTA-STS, TLS-RPT and CAA: three DNS records and one policy file.
6. Contract lookalike-domain and fake-app monitoring, with a takedown SLA.
7. Rewrite the OTP wording and publish the official-channels page.

Steps 1 to 5 are DNS and certificate work. Steps 6 and 7 touch the bank's website and app, usually done with the website development and mobile app development teams. To place these controls among the other security layers, see 10 types of cyber security and the documents that prove them.