Daum rejects my mail but Gmail accepts it. Where do I even start?

Start by deciding which of two very different failures you have. If Daum returns a permanent bounce that names blocking or spam, your sending IP has most likely landed on Daum's block list and you need Daum's own unblock request (cs.daum.net/question/43.html) plus clean authentication. If the mail is deferred or throttled rather than hard-rejected, you are usually hitting Daum's connection limit — it caps simultaneous connections from one IP (100 for a White IP) — and the fix is to slow your delivery down, not to file a ticket. Read the bounce class first: a 5xx is a block, a 4xx is a speed limit.

Is Daum mail the same as Kakao mail? They're both Kakao.

Same company, and the anti-spam basics (SPF, DKIM, reverse DNS, IP reputation) are identical, but the mailbox domains and the recipient-side controls differ. daum.net and hanmail.net are the classic Daum webmail addresses; kakao.com is Kakao Mail. When your problem is a sending-side block or reputation issue, treat them together and fix your domain and IP once. When a single recipient isn't getting your mail with no bounce at all, that's a per-user receive filter on their account, and only that user can change it — nothing on your side is broken.

Do I have to register a KISA white domain to reach Daum?

Not to reach it at all, but for any real sending volume to Korean portals it is the strongest single lever you have. KISA runs a white-domain program (spam.kisa.or.kr) where you pre-register your sending domain and its mail-server IPs; once approved, Naver, Daum/Kakao, and Nate treat legitimate mail from that domain far more leniently. You must publish a valid SPF record before you apply — the program uses SPF as the identity anchor — so fixing your authentication is step one whether or not you register.

hanmail.net / Daum Mail Rejected: Fix the Bounce

Problem

Mail your server sends to @daum.net or @hanmail.net (and often @kakao.com) either bounces with a permanent rejection that cites spam or blocking, or it silently never arrives. The same message reaches Gmail and Outlook without complaint. Daum runs one of Korea’s two largest consumer mail systems, and — like Naver — it is strict enough to punish a domain that is only almost correctly configured.

Symptoms

Outbound mail to daum.net / hanmail.net bounces with a 5xx SMTP rejection referencing spam or a blocked sender, while other providers accept the same message.
Delivery is slow or deferred instead of rejected — Daum accepts a few messages, then starts refusing connections from your IP.
Mail to Gmail/Outlook lands (sometimes in Spam) but Daum rejects outright.
It started right after you moved to a new mail server, a new hosting provider, or a fresh IP address.
One specific Daum recipient never gets your mail, but everyone else at daum.net does — a sign you’re looking at that person’s receive filter, not a domain block.

What a Daum Rejection Actually Means

Daum’s mail platform makes its accept/reject decision on SPF first, then runs the message through a second spam-filtering stage. So a rejection is telling you one of two things, and they have opposite fixes.

A permanent block (5xx) means Daum does not trust this IP: the address is on its block list, usually because of poor reputation, a missing or generic PTR record, or spam-like sending history. Daum publishes an operations policy (policy.daum.net) and, crucially, a self-service path to request removal — you don’t have to guess. The unblock request lives at cs.daum.net/question/43.html; you submit the blocked IP and Daum reviews it.

A temporary deferral (4xx) is a speed limit, not a verdict. Daum caps how many simultaneous connections one IP may open — 100 for a White IP — and connections beyond that are simply refused. A well-behaved mail server treats a 4xx as “try again later” and retries on its own; the fix is to send more slowly, not to open a ticket. Reading the bounce class before you act saves you from filing an unblock request for a problem that was never a block.

Top 3 Causes

Your sending IP is on Daum’s block list. Reputation, a missing or generic reverse-DNS (PTR) record, or a spammy neighbor on a shared IP got the address blocked. The tell: a permanent 5xx naming spam or blocking, hitting daum.net broadly, that other providers don’t reproduce. This is the case that Daum’s unblock request page exists for — but file it only after your authentication and PTR are clean, or you’ll be re-blocked.
SPF missing or not aligned with your From domain. Because Daum decides on SPF first, a domain whose SPF doesn’t list the real sending server — or a message whose authenticated domain doesn’t match the visible From — fails here while a lenient provider waves it through. The tell: a header check shows spf=none or spf=fail from the sending source.
You’re exceeding Daum’s connection/rate limit. A batch send opens too many parallel connections and trips the per-IP cap, so Daum defers. The tell: it’s a 4xx, it’s volume-dependent, and the first few messages get through before delivery slows to a crawl.

Diagnose with DechoNet

Email Check pulls your sending domain’s SPF, DKIM, and DMARC records and evaluates them — confirm SPF exists, stays inside the 10-lookup limit (RFC 7208 §4.6.4), and actually include:s the service doing the sending. A published SPF record is also the prerequisite for a KISA white-domain application, so this is step one either way.
Reverse DNS Lookup checks whether your sending IP has a valid PTR that resolves back to a real hostname. A missing or generic PTR (the kind cloud providers hand out by default) is a reputation drag that Daum notices — and worth fixing before you request an unblock.

Resolution Checklist

Read the bounce class first: 5xx = a block (needs an unblock request + clean setup), 4xx = a speed limit (slow down and let your server retry). Don’t file a ticket for a 4xx.
Confirm scope: a domain-wide bounce vs. one Daum mailbox not receiving with no bounce. If it’s one mailbox, it’s that user’s own receive filter — stop here.
Run Email Check on your From domain and verify SPF, DKIM, and DMARC exist and are valid, with SPF resolving inside the 10-lookup limit and listing the real sending server.
Check the sending IP’s reverse DNS and set a real, forward-confirmed PTR if it’s missing or generic.
For a 4xx, reduce concurrency — stay well under Daum’s per-IP connection cap and warm a new IP up gradually instead of blasting a full batch on day one.
Only after authentication and PTR are clean, submit the blocked IP to Daum’s unblock request at cs.daum.net/question/43.html.
For sustained volume to Korean portals, register the domain and its sending IPs at KISA’s white-domain service (spam.kisa.or.kr). Publish SPF first.
Send a test message and confirm spf=pass and DKIM alignment in the headers before resuming normal sending.

When to Escalate

If your domain authenticates cleanly, the IP has good reverse DNS and reputation, and you’ve already filed the unblock request but Daum still rejects sustained sending, follow up through Daum’s customer center with the full bounce text — at that point the decision is receiver-side and only Daum can explain it.
If the failure is a single Daum recipient with no bounce, there is nothing to escalate on the sending side: that user controls their own receive/block settings.

Check your own domain now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.