I moved my domain to Naver Works but some mail still lands in the old inbox. Why?

Because both mail systems are still authoritative for your domain at the same time — a split MX. A domain has one MX record set, and receivers pick a host from it. If your old provider's MX host is still published alongside Naver Works', inbound mail gets distributed across both depending on which record a sender's server chooses and its priority. Some messages land in Naver Works, some in the dead old mailbox, and the pattern looks random because it depends on the sender, not on you. The fix is to remove every MX host that isn't Naver Works, so the domain points at exactly one mail system.

My outbound Naver Works mail passes DKIM as worksmobile.com, not my own domain. Is that a problem?

It's fine for basic delivery but not enough for DMARC. Naver Works signs outbound mail with its own worksmobile.com DKIM key by default, so the signature is valid but it doesn't *align* with your From domain. DMARC passes only when SPF or DKIM aligns with the domain a recipient sees in From. If you publish a DMARC record at p=quarantine or p=reject, that worksmobile.com-only signature won't satisfy it, and strict receivers can quarantine you. To align, create a DKIM selector for your own domain in the Naver Works admin console and publish the TXT/host value it gives you.

I published two SPF records — one for Naver Works and one from my old host. Now nothing authenticates. Why?

Because a domain is allowed exactly one SPF record. RFC 7208 §3.2 says a domain that publishes more than one v=spf1 record produces a permerror, and most receivers treat permerror as an authentication failure rather than picking one. Delete the extra record and merge every legitimate sender into a single v=spf1 line — for Naver Works that means adding include:spf.worksmobile.com to your one SPF record, not creating a second TXT record beside it.

Views: 32

Naver Works Mail Not Receiving: Fix MX, SPF, DKIM

Naver Works mail not arriving or landing in spam? Fix it in 4 checks: MX host, split MX, SPF include, DKIM selector. Free instant check, no sign-up.

Check your domain for this issue now

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

Problem

You pointed your custom domain at Naver Works, and mail is unreliable: some inbound messages never arrive, some outbound mail lands in the recipient’s spam folder, and the failures look random rather than total. This is almost always a half-finished migration — the DNS records that decide where your mail goes and how it authenticates are in an in-between state, with the old system and the new one both partly in charge.

Symptoms

Some senders reach your Naver Works inbox and others don’t, with no bounce — a sign inbound mail is being split between two mail systems.
Outbound mail from Naver Works lands in Gmail/Outlook Spam, or bounces from strict receivers, after you added a DMARC record.
You published an SPF record and now everything fails authentication — the classic two-SPF-records permerror.
Mail behaved during testing, then broke for real senders once DNS finished propagating (24–48 hours after the change).
It started right after you migrated the domain from a previous mail host to Naver Works.

What’s Actually Going Wrong

Custom-domain mail on Naver Works rests on three DNS records that each answer a different question, and a migration breaks them one at a time.

MX answers “where does inbound mail go?” Your domain must publish Naver Works’ inbound mail host as its MX — the exact value shown in your Naver Works admin console when you verify the domain. Receiving mail simply cannot work until that record resolves. The failure mode that catches people isn’t a missing MX; it’s a leftover one. If the previous provider’s MX host is still published next to Naver Works’, you have a split MX, and inbound mail scatters between two systems.

SPF answers “which servers may send as this domain?” Naver Works publishes its sending infrastructure under spf.worksmobile.com, and your SPF record has to include: it. The trap here is that a domain may publish only one SPF record; a second one is a permerror under RFC 7208 §3.2, and receivers reject rather than guess.

DKIM answers “did this domain really sign this message?” Naver Works signs outbound mail by default with its own worksmobile.com key, which passes but doesn’t align with your From domain — good enough until you turn on a DMARC policy stricter than p=none, at which point the lack of a domain-aligned signature starts costing you. Aligning it means creating a DKIM selector for your own domain in the admin console. Note that some DNS providers can’t store a 2048-bit key in a single TXT value; Naver Works lets you generate a 1024-bit key for those.

Top 3 Causes

Split MX from a half-finished migration. The old provider’s MX host is still published alongside Naver Works’, so inbound mail is distributed across both systems and some of it vanishes into a mailbox nobody reads. The tell: reception is intermittent and sender-dependent, with no bounce, and it started when you switched to Naver Works. This is the single most common Naver Works receiving bug.
SPF broken — either not including Naver Works, or two SPF records. Either your SPF line never added include:spf.worksmobile.com (so Naver Works’ own sending path isn’t authorized), or you published a second v=spf1 record beside your existing one and triggered a permerror. The tell: outbound mail fails SPF at the receiver, or authentication fails entirely with no obvious single fault.
DKIM signs only as worksmobile.com, with a strict DMARC policy. You enabled p=quarantine or p=reject on your domain but never created a domain-aligned DKIM selector, so the only signature on your mail is worksmobile.com’s — valid, unaligned, and unable to satisfy your own DMARC. The tell: outbound mail is quarantined at strict receivers, and DMARC reports show DKIM passing on worksmobile.com but not your domain.

Diagnose with DechoNet

Email Check pulls your domain’s MX, SPF, DKIM, and DMARC records in one pass — so you can confirm the MX resolves to exactly one mail host, your SPF is a single record that include:s Naver Works and stays under the 10-lookup limit (RFC 7208 §4.6.4), and a DMARC record exists before you tighten its policy.
DNS Lookup shows every MX host your domain currently publishes and their priorities — the fastest way to catch a leftover MX from the old provider sitting next to Naver Works’.

Resolution Checklist

Run Email Check on your domain and read the MX list: it must contain only Naver Works’ inbound host (the value from your admin console). Delete any MX left over from a previous provider.
Verify you have exactly one SPF record, and that it contains include:spf.worksmobile.com. If two v=spf1 records exist, merge them into one — two records is a permerror.
Keep total SPF DNS lookups under 10 so the record doesn’t permerror on lookup count (RFC 7208 §4.6.4).
If you run DMARC at p=quarantine or p=reject, create a DKIM selector for your own domain in the Naver Works admin console and publish the host/TXT value it gives you (use the 1024-bit option if your DNS provider rejects the 2048-bit record).
After any DNS change, wait for propagation — up to 24–48 hours — before concluding a fix didn’t work, and re-test with a real external sender, not just an internal account.
Send a test message out and check the headers for spf=pass and, if you need DMARC alignment, dkim=pass signed by your domain rather than worksmobile.com.

When to Escalate

If the MX is clean (Naver Works only), SPF is a single record that includes spf.worksmobile.com, and inbound mail still goes missing for specific senders, capture a failing sender’s bounce or delay report and open a ticket with Naver Works support — at that point the routing decision is on their side.
If domain-aligned DKIM is published and DMARC still fails alignment in your reports, confirm the selector the admin console generated actually matches the TXT record you deployed; a copy-paste truncation of the long key is the usual culprit before it’s ever a Naver Works bug.