Naver bounced my mail as spam but Gmail accepts it. Why the difference?

Because Naver weights two things Gmail is more forgiving about: strict authentication alignment and Korea-specific IP reputation. Gmail leans heavily on its own accumulated reputation data and will often deliver a slightly-misconfigured domain to Spam rather than reject it outright. Naver is quicker to refuse at the SMTP door, and it has no public reputation dashboard for you to consult. So a domain that only *mostly* has its SPF and DKIM in order — passing at Gmail, failing alignment at Naver — hits a wall specifically at naver.com and daum.net while everything else looks fine. Fix the alignment, not the message.

Will registering a KISA white domain fix this?

There is nothing left to register. KISA (Korea Internet & Security Agency) stopped taking new white-domain applications on June 14, 2024 and ended the service on June 28, 2024. Older articles still recommend it, but the only application left at spam.kisa.or.kr is SPF registration (the mail-server registration scheme). What gets you into Naver now are the signals the receiver checks itself: SPF and DKIM aligned with your From domain, a published DMARC record, forward-confirmed reverse DNS (PTR), and sending-IP reputation built up gradually.

One specific Naver user isn't getting my mail, but everyone else at naver.com is. Is that the same problem?

No, and it's important not to confuse them. A domain-wide spam rejection hits many or all naver.com recipients and shows up as an SMTP bounce. A single Naver user not receiving you — with no bounce at all — usually means that one person added your address to their personal block list (환경설정 → 스팸설정 → 수신허용/차단). Only that user can remove it; there is nothing to fix on your side. Check whether the failure is one mailbox or the whole domain before you start rewriting DNS records.

Naver Mail Rejected as Spam: Fix Bounced Delivery

Problem

Mail your server sends to @naver.com (and often @daum.net, @kakao.com, @nate.com) bounces back with a permanent rejection that cites spam suspicion, or it silently never arrives. The same mail reaches Gmail and Outlook without complaint. This is the classic asymmetry: your domain is almost correctly configured, and Naver is the receiver strict enough to punish the gap.

Symptoms

Outbound mail to naver.com bounces with a 5xx SMTP rejection referencing spam or blocking, while other providers accept the same message.
Delivery is slow or throttled — Naver accepts a few messages then starts deferring or refusing, especially from a new sending IP.
Mail to Gmail/Outlook lands (sometimes in Spam) but Naver rejects outright.
It started right after you moved to a new mail server, a new hosting provider, or a fresh IP address.
Some Naver recipients get your mail and others don’t — a sign you may be looking at individual block lists, not a domain problem.

What “Spam Suspected” From Naver Actually Means

Naver is telling you it does not trust this domain from this IP enough to accept the message — and unlike Gmail, it will not quietly file the doubt under Spam and move on. Two facts make Naver harder than the providers you’re used to.

First, there is no public postmaster dashboard. Google gives you Postmaster Tools; you can watch your spam rate, authentication pass rate, and sender-requirements compliance. Naver gives you nothing comparable. The bounce line and the behavior of your own test sends are the only telemetry you get, so you have to reason from cause rather than read a report.

Second, Naver enforces authentication alignment strictly and throttles unknown IPs by default. A brand-new sending IP has no reputation, so Naver rate-limits it until it earns trust — which reads exactly like a block when you’re trying to send a batch. And a domain whose SPF or DKIM is present but not aligned with the From address will pass a casual check at a lenient provider and still fail at Naver. The fix therefore lives in two places, in this order: your authentication records, then your IP’s reputation and reverse DNS. The Korea-specific shortcut people used to reach for, KISA’s white-domain program, ended in June 2024.

Top 3 Causes

SPF/DKIM missing or misaligned for the real sending path. The server actually sending the mail isn’t listed in your SPF record, or the message isn’t DKIM-signed by a domain that aligns with your From address. The tell: it fails specifically at Naver while Gmail delivers, and a header check shows spf=none/fail or dkim=none from the sending source. This is the most common and most fixable cause.
A new or low-reputation sending IP being throttled. Fresh IPs, shared hosting IPs, or an address with no Korean sending history get rate-limited or refused. The tell: it’s intermittent and volume-dependent — the first few messages get through, then Naver starts deferring — and it began the moment you changed servers or IPs. Missing or generic reverse DNS (PTR) on that IP makes it worse.
Bulk sending that still leans on the ended KISA white-domain program. If newsletters, transactional mail, or other real volume to Korean portals relied on an old white-domain registration, that program ended on June 28, 2024 and the registration no longer buys you anything. What remains are the signals the receiver checks itself. The tell: authentication is clean and the IP is fine, but sustained sending to Naver/Daum still gets throttled or rejected, and you have no DMARC record or ramped volume up all at once.

Diagnose with DechoNet

Email Check pulls your sending domain’s SPF, DKIM, and DMARC records and evaluates them — confirm the SPF record exists, stays within the 10-lookup limit (RFC 7208 §4.6.4), and actually include:s the service doing the sending. KISA’s SPF registration (the mail-server registration scheme at spam.kisa.or.kr, which is still open) also requires a published SPF record, so this is step one either way.
Reverse DNS Lookup checks whether your sending IP has a valid PTR record 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 receivers like Naver notice.

Resolution Checklist

Confirm the scope: is the failure a domain-wide SMTP bounce, or one Naver mailbox not receiving with no bounce? If it’s one mailbox, it’s a personal block list on their side — stop here.
Run Email Check on the domain in your From address and verify SPF, DKIM, and DMARC all exist and are valid, with SPF resolving inside the 10-lookup limit.
Verify alignment: the sending service is inside your SPF include:, and it DKIM-signs with a domain that matches your From — not just “some” DKIM signature.
Check the sending IP’s reverse DNS; set a real, forward-confirmed PTR record if it’s missing or generic.
For a new IP, warm it up — start with low volume and increase gradually rather than blasting a full batch on day one.
For sustained volume to Korean portals, publish a DMARC record (p=none is fine to start) and use its reports to confirm every sending path aligns. KISA’s white-domain program ended in June 2024, so don’t wait on a registration — SPF registration is the only thing spam.kisa.or.kr still offers.
Send a test message and re-check the headers for spf=pass, dkim=pass, and DMARC alignment before resuming normal sending.

When to Escalate

If your domain authenticates cleanly, the IP has good reverse DNS and reputation, DMARC alignment checks out, and Naver still rejects sustained sending, contact Naver’s mail/abuse support with the full bounce — at that point the block is a receiver-side decision only they can explain.
If the failure is a single Naver recipient with no bounce, there is nothing to escalate on the sending side: the recipient controls their own block list in 환경설정 → 스팸설정 → 수신허용/차단.

Check your own domain now

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