I Checked DMARC on 4,437 Indonesian .id Domains. 47% of go.id Can Still Be Spoofed

When someone asks me during phishing training how to spot a fake email from a government office, the honest answer depends on the domain. If the domain owner has published a DMARC policy that tells receivers to reject forged mail, a message with that exact domain in the From line will usually never reach the inbox. If not, it can. So on 25 October 2026 I checked 4,437 Indonesian .id domains. Of the 469 go.id domains, 222 (47.3%) either have no DMARC record or have one set to p=none. Their name can still be put on a fake email, and receivers have not been asked to stop it.

TL;DR (for non-technical readers)

• DMARC is a DNS record that tells Gmail, Outlook and others what to do with email that falsely claims to come from your domain. Without it, or with it set to “none”, nothing is blocked on your behalf.
• I checked 4,437 popular .id domains on 25 October 2026. 3,301 of them (74.4%) can still be spoofed this way.
• Government domains (go.id) do best, and still 47.3% are spoofable. Universities (ac.id) are at 84.2%, schools (sch.id) at 91.7%.
• Domains that never send email need protection too. Of 929 domains without a mail server, only 40 have the records that say “nothing legitimate ever comes from here”.

Why this matters

Phishing in Indonesia leans on trust in official names. In April 2024 the Ministry of Health warned about phishing emails impersonating SATUSEHAT, sent from non-official domains. On 9 July 2026, the tax directorate (DJP) reminded taxpayers that its reminder emails come only from @pajak.go.id. Advice like “check the sender’s domain” is only as good as the domain’s protection against exact-domain forgery. That protection is DMARC.

The big mailbox providers already expect it. Since 1 February 2024, Google requires senders of more than 5,000 messages a day to Gmail accounts to set up DMARC, though the policy “can be set to none”. Yahoo asks bulk senders for “a valid DMARC policy with at least p=none”. Both rules are about deliverability. Neither forces anyone to block forgeries, and that gap is what this scan measures.

I looked for Indonesian guidance. BSSN Regulation No. 4 of 2021, the SPBE security standard, does not mention SPF, DKIM or DMARC anywhere in its text, and I could not find a BSSN or PANDI document that does. If one exists, I would like to read it.

Method

The Tranco list GQ32K (generated 24 October 2026) contains 4,814 .id domains. I kept every domain under go.id, ac.id, co.id, or.id, sch.id, web.id, my.id, biz.id and plain .id: 4,573 domains. 91 returned NXDOMAIN and 45 failed with SERVFAIL or timeouts on every attempt (30 of them ac.id), so 4,437 domains are analysed.

A Python script (dnspython, run with uv) sent only DNS queries, to 1.1.1.1 and 8.8.8.8 alternately, with up to 4 attempts and a global cap of 45 queries per second. For each domain it asked for MX, apex TXT (SPF), _dmarc TXT, _mta-sts TXT, _smtp._tls TXT, default._bimi TXT and DS. It followed SPF include: and redirect= to count DNS-querying terms against the limit of 10 in RFC 7208. The run started at 11:17 WIB and took 813 seconds and 33,336 queries.

DMARC records were parsed per RFC 7489: exactly one v=DMARC1 record with a usable p=. Two records means no policy. RFC 7489 is now obsoleted by RFC 9989 (2026), which keeps none, quarantine and reject but drops pct in favour of a t= testing flag.

Spoofable here means no valid DMARC record, or p=none. Why count p=none? RFC 9989 says a p=none policy “MUST NOT modify existing mail handling”. The domain only asks for reports. SPF alone does not fill the gap: it checks the hidden envelope sender, not the From address people read, and RFC 7208 says a ~all softfail “SHOULD NOT” be the sole reason to reject. So p=none plus ~all leaves forgery of the exact domain unblocked at most receivers, unless their own spam filters catch it. 1,104 of the 1,329 p=none domains pair it with ~all, ?all, +all or no SPF at all.

Results

Group	Analysed	No DMARC	p=none	p=quarantine	p=reject	Spoofable
go.id	469	87	135	156	91	222 (47.3%)
co.id	1,029	341	271	217	200	612 (59.5%)
or.id	50	25	12	9	4	37 (74.0%)
.id	1,607	957	357	169	124	1,314 (81.8%)
ac.id	942	318	475	97	52	793 (84.2%)
sch.id	133	83	39	7	4	122 (91.7%)
biz.id	23	16	6	0	1	22 (95.7%)
web.id	70	57	11	1	1	68 (97.1%)
my.id	114	88	23	0	3	111 (97.4%)
All	4,437	1,972	1,329	656	480	3,301 (74.4%)

70.9% of domains publish one SPF record, and 113 publish two or more, which is a permanent error. Of the single SPF records, 71.1% end in ~all and 26.9% in -all. 84 of them (2.7%) exceed 10 DNS lookups, so they fail at receivers that enforce the limit.

The newer controls are rare. MTA-STS: 35 domains (0.8%). TLS-RPT: 35 (0.8%). BIMI: 38 (0.9%). DNSSEC, measured as a DS record at the parent: 190 (4.3%), led by go.id at 74 (15.8%).

Three findings

1. go.id is ahead, and stuck halfway. 247 go.id domains (52.7%) enforce quarantine or reject, the best of any group. But 135 sit at p=none, and 97 of those (71.9%) already send aggregate reports to an rua address. Somebody turned on monitoring and never finished the rollout. Only 54 go.id domains (11.5%) have the strict combination: p=reject at 100% plus SPF -all.

2. Campuses and schools are wide open. ac.id has the most p=none records of any group: 475, half of all analysed university domains. 86.1% of ac.id SPF records end in ~all. Universities send mail from many places (the academic system, LMS, newsletters, helpdesk), which makes reject feel risky, and that is exactly the case rua reports are built for: 367 of those 475 already collect them. sch.id is worse at 91.7% spoofable, and 83 of 133 school domains have no DMARC at all.

3. Domains that send no mail are the easiest target and the easiest fix. 929 domains have no MX record. Only 40 of them (4.3%) publish both SPF -all and DMARC p=reject, the lockdown the M3AAWG parked-domain practice recommends. 786 publish neither SPF nor valid DMARC. In go.id, 19 domains have no MX and none of them is locked down. Domains with mail servers fare better but not well: 2,440 of 3,508 (69.6%) are spoofable.

Fix checklist

Replace example.go.id and the report addresses with your own.

1. Start DMARC in monitoring mode, with reports.

_dmarc.example.go.id.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.go.id"

Read the aggregate reports for two to four weeks. Every legitimate sender (your mail platform, the academic system, the bulk mail tool, the ticketing system) must pass SPF or DKIM with an aligned domain. Fix the ones that do not. If the rua address is on another domain, that domain must publish an authorization record for you.

2. Move to quarantine.

_dmarc.example.go.id.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.go.id"

RFC 7489 allowed pct=25 for a partial rollout. 66 domains in this scan enforce with pct below 100. RFC 9989 removes pct, so do not plan around it. Move the whole domain once the reports are clean.

3. Reject.

_dmarc.example.go.id.  TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@example.go.id"

Keep reading reports afterwards. Also check SPF: one record only, at most 10 lookups, ending in -all once you know your senders.

4. Domains that never send mail. Per M3AAWG, plus a null MX (RFC 7505):

example.go.id.         MX   0 .
example.go.id.         TXT  "v=spf1 -all"
_dmarc.example.go.id.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.go.id"

This takes five minutes and needs no testing, because there is no legitimate mail to break.

5. MTA-STS and TLS-RPT for inbound mail. These protect mail coming to you against downgrade attacks, not spoofing, but the work is small:

_mta-sts.example.go.id.    TXT  "v=STSv1; id=20261025T000000"
_smtp._tls.example.go.id.  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.go.id"

Then serve https://mta-sts.example.go.id/.well-known/mta-sts.txt with a valid certificate:

version: STSv1
mode: testing
mx: mail.example.go.id
max_age: 86400

Switch mode to enforce and raise max_age once the TLS reports are clean, and change id whenever the policy changes.

Caveats

• Sample. These are the most popular .id domains in Tranco, so they skew towards bigger organisations. biz.id has only 23 analysed domains.
• Apex only. I checked the registered domain, not subdomains. sp= and the parent policy cover subdomains, and I did not measure them separately.
• No DKIM. DKIM keys live under selectors that DNS cannot list, so I did not measure DKIM.
• “Spoofable” is about the policy, not the outcome. Many receivers run their own filters and will catch some forged mail even at p=none. The point is that the domain owner has not asked them to.
• MTA-STS was checked by TXT record only. Fetching the policy file would mean contacting the domains, and this scan sends DNS queries only.
• DMARC does not stop look-alike domains or stolen accounts. The SATUSEHAT campaign used other domains. In April 2022, Kompas reported leaked email credentials across 28 government domains and subdomains. Mail sent from a real hacked account passes DMARC.
• One point in time, one place. 25 October 2026, from Batam, through two public resolvers. 45 domains with failing DNS were excluded.

I am publishing aggregates only, not per-domain results.

Closing

The fix here is a few TXT records, not a project. go.id has shown it can move: more than half of its domains enforce DMARC. The rest are mostly stuck at p=none, often with reports already arriving in someone’s inbox.

If you run mail for a pemda, a campus or a school: what keeps your domain at p=none? Is it fear of breaking a legacy system, nobody reading the reports, or nobody owning DNS?

Versi bahasa Indonesia: https://www.kielltampubolon.id/writing/saya-cek-dmarc-4437-domain-id-go-id-masih-bisa-dipalsukan/

Related: Let’s Encrypt Is Going to 64 Days. I Checked 520 .id Sites