Email spoofing: we tested 10,000+ Korean domains

People often underestimate how insecure "default" settings are for an Email setup. Email has been around since forever, and as such it was built during an age where security wasn't taken seriously. By default, anybody can impersonate any email domain and the receiver will have NO way of checking. The only way to prevent this is to maintain proper DMARC, SPF and DKIM. In this post, let's focus on DMARC.

To show how NOT to configure DMARC, we tested 10,135 Korean domains. We found that 85.4% of the domains either don't have DMARC configured or have a useless policy in place.

How to protect the "From" field

As mentioned before, to get Email right you need to set up SPF, DMARC and DKIM.

SPF checks the sender server during an SMTP (Simple Message Transfer Protocol) conversation. DKIM checks a cryptographic signature associated with a domain specified in an email header.

However, the From address displayed in the recipient's email client can use a third domain, and neither SPF nor DKIM is required to match it.

DMARC ties these mechanisms together. It requires the domain visible to the recipient to align with a domain that successfully passed SPF or DKIM authentication. It also allows the domain owner to specify how receiving servers should handle messages when neither mechanism aligns.

To find out what the owner wants, a receiver has to look the policy up. RFC 9989, published in May 2026 and the first version of DMARC on the IETF Standards Track, defines that lookup as a DNS tree walk starting at _dmarc.<domain> and climbing label by label toward the top of the name.

The standard is explicit about a walk that finds nothing:

RFC 9989 §4.10.1: "If the set produced by the DNS Tree Walk contains no DMARC Policy Record (i.e., any indication that there is no such record as opposed to a transient DNS error), Mail Receivers MUST NOT apply the DMARC mechanism to the message."

For a .co.kr domain, the walk climbs to _dmarc.co.kr and then _dmarc.kr. We did try querying both, but the results were empty. That means that testing a .co.kr domain is as simple as testing only the domain itself: _dmarc.example.co.kr.

An absent record tells the receiver to SKIP the check. The only other thing the receiving server can do if you don't have a DMARC policy is apply generic spam filtering, which is very unreliable, especially in the age of AI.

Experiment Target

The population of the experiment is a Tranco snapshot. 14,274 Korean hostnames collapsed to 10,135 registrable domains, 10,123 of them .co.kr. Ranks run from 1,653 to roughly 7,000,649, so this is a long tail of ordinary commercial domains.

According to KRNIC, there are 635,934 registered co.kr domains as of July 2026. That means that our sample is about 1.6%. However, we took the "head" of that list - the most visited websites, so the websites here are better-resourced than most of the other ones.

Korea has been measured before at a different scale. Proofpoint, reported by CIO Korea on 28 November 2024, analysed the KOSPI 200 — 200 listed large caps — and found 62.7% with no DMARC record, 35.8% at p=none, 1% at p=quarantine and 0.5% at p=reject. This census covers roughly 10,000 ordinary commercial domains, publishes its method, and is measured against RFC 9989, which obsoleted RFC 7489 in May 2026.

Experiment Method

We ran three DNS queries against each domain:

1. _dmarc.{domain} TXT
2. {domain} MX
3. {domain} TXT (for SPF)

201 lookups (2.0%) came back as a SERVFAIL or a timeout. A failed lookup is no evidence that a company published nothing, so those domains are excluded from every percentage below. The denominator is 9,934.

Experiment Results

8,484 domains — 85.4% — have no usable DMARC policy.

The share climbs as the ranks fall:

• 57.3% between rank 10,000 and 100,000
• 73.5% between 100,000 and 1 million
• 88.1% past rank 1 million

Of the domains that receive mail, four in five are in the count. Of the 6,568 that publish an MX record, 80.0% have no usable policy. Of the 3,364 with no MX, 95.9% have none, and only 11 domains in the entire population publish a null MX. Two MX lookups failed, so that cut covers 9,932 of the 9,934.

5,798 (58.4%) publish SPF, and 4,412 publish SPF and no DMARC.

Publishing a DMARC record is not the end

1,450 domains published a policy, but 1,131 of them set p=none.

RFC 9989 §4.7 defines that value as: "none: The Domain Owner offers no expression of preference."

131 domains set p=quarantine and 188 set p=reject. 319 domains ask a receiver to do anything at all — 3.2% of the population.

Some domain owners set p=none as a cheap way of satisfying Google's sender guidelines. Since 1 Feb 2024, these guidelines require DMARC to "exist" for anyone sending more than 5,000 messages a day to personal Gmail accounts. They explicitly mention that "Your DMARC enforcement policy can be set to none."

DMARC also allows for monitoring. This is done through a rua address.

666 of the 1,450 publishers set a rua address.

In practice, that means that fewer than half of the domains that adopted DMARC receive the reports that would tell them if they are being impersonated. Another 134 records still carry pct=, a tag RFC 9989 removed in May 2026.

If you don't send mail

If your domain sends no mail at all, the best thing you can do is to prevent other people from impersonating that domain.

RFC 7505 §4.2: "Operators of domains that do not send mail can publish Sender Policy Framework (SPF) '-all' policies [RFC7208] to make an explicit declaration that the domains send no mail."

To complete the work, pair that with a null MX record and p=reject in the DMARC TXT record.

As always with DMARC, start small:

1. Publish p=none with a rua address on day one.
2. Read the reports for a week or two. They are what tell you which of your own tools — payroll, CRM, ticketing, the marketing app someone signed up for three years ago — still need SPF or DKIM fixed.
3. Then move to p=quarantine, and then to p=reject. Each step is safe once the reports show your own mail aligning.

How to check your domain

Run this (need dig installed) to check your DMARC record:

dig +short _dmarc.yourcompany.co.kr TXT

---

Do you know how many separate services send email using your company's domain?

References

1. IETF — RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) (May 2026; obsoletes RFC 7489 and RFC 9091)
2. IETF — RFC 7505: A "Null MX" No Service Resource Record for Domains That Accept No Mail
3. Gmail Help — Email sender guidelines
4. CIO Korea — Proofpoint's DMARC analysis of the KOSPI 200 (28 November 2024)