China Email Providers Compared: Mailboxes vs Sending APIs

Choosing a mail provider in China is two decisions, not one. The first is whether you need mailboxes (people read and write mail) or a sending API (software sends notifications). The second is which vendor fits your compliance, network and support requirements. Companies routinely buy the wrong category, then spend a month trying to make DNS records do something the product was never designed for.

This page maps the main services, their published DNS values, and the migration sequence that applies regardless of vendor. Each provider has a dedicated setup guide linked below.

Mailbox hosts

Two values in that table are worth flagging because they contradict most third-party tutorials. Huawei Cloud publishes DKIM as a CNAME delegation, not a TXT public key; publishing a TXT at that host will not verify. Sina's SPF include is spf.sinamail.sina.com.cn, not anything ending in sina.com.

Sending APIs

These services send mail but do not host inboxes. Their DNS records belong on a subdomain, and their MX record (when used at all) is for bounce handling — never for your corporate apex.

How to choose

• Small company, already using WeCom: Tencent Exmail. The mailbox is bundled with the admin console your HR team already uses, and the record set is the simplest of the group.
• Already on Alibaba Cloud, or using DingTalk: Alibaba Mail. Three MX records give better inbound resilience than the two-record providers, and the DKIM console is the clearest of the Chinese vendors.
• Manufacturing, trading, government-adjacent: NetEase or 263. Both have long operational histories and domestic-stack editions. 263 in particular is common in state-owned enterprises and financial institutions.
• Huawei Cloud infrastructure already in place: Huawei Cloud Enterprise Mail. The CNAME-based DKIM means no key rotation work on your side.
• Feishu / Lark is your collaboration suite: Feishu Mail. Cheapest integration, but its validation refuses to pass while any other MX record exists — plan the cutover carefully.
• Self-hosted or a university/carrier platform: Coremail. Expect to manage DKIM keys and egress IPs yourself.
• Only need transactional mail: SendCloud, DirectMail or Tencent Cloud SES. Do not buy a mailbox product for this.

The four records, in the order that matters

1. MX. Determines whether mail arrives at all. Get the priority order right; several Chinese providers use counter-intuitive values (263's primary is priority 5 on mxw).
2. SPF. One record, all senders merged. Two v=spf1 records is a permanent error, not a "best of both" situation.
3. DKIM. Per-domain key, selector assigned by the vendor. Publish exactly what the console shows, and enable signing as a separate step.
4. DMARC. Always start at p=none with a reporting address. Enforce only after the reports are clean.

Migration sequence that works for every vendor

1. Create and verify all mailboxes at the new provider before touching MX. Otherwise inbound mail is accepted and bounced as unknown recipient.
2. Lower the TTL on existing MX records to 600 seconds at least 24 hours before the cutover.
3. Add the new provider's SPF include to the existing record. Do not remove the old one yet.
4. Publish the new DKIM record and confirm it resolves.
5. Switch MX in one change. Remove old MX records in the same edit.
6. Send test messages in both directions, including from an external Gmail account.
7. Wait a full business day, then remove the old SPF include.
8. Raise TTL back to 3600 and tighten DMARC only after two to four weeks of clean reports.

The email authentication overview explains why each record exists; the DMARC guide covers policy rollout in detail. If mail is already flowing but landing in spam, the problem is usually reputation or content rather than DNS — see why is my email going to spam.

Common mistakes across all Chinese providers

• Mixing a mailbox product with its sibling sending API. Alibaba Mail vs DirectMail, Tencent Exmail vs Tencent Cloud SES. Different MX, different SPF, different selector, different domain registration rules.
• Copying an SPF include from a blog. Sina, NetEase and Huawei all have commonly misquoted values.
• Publishing two SPF records. Merge, always.
• Forgetting the ICP filing. Branded webmail hostnames in mainland China require it; a login page that does not load is usually a filing problem, not DNS.
• Enforcing DMARC on day one. Every provider's template suggests something stricter than a domain with unknown senders can survive.

Frequently asked questions

Can I use a foreign mailbox provider and a Chinese sending API together?

Yes, and it is common for companies with overseas staff. Keep the mailbox MX at the foreign provider, send transactional mail from a subdomain through the Chinese API, and publish separate SPF and DKIM records for each hostname.

Do Chinese providers require an ICP filing for mail?

Not for receiving mail on your own domain, but yes for branded webmail hostnames and for any domain served from mainland infrastructure. Several providers also require a filing before enabling a custom login page.

Which provider has the best deliverability to Gmail?

All of them can reach Gmail when SPF, DKIM and DMARC are correctly aligned. Differences come from IP reputation management and from whether you send from a warmed subdomain. The reputation warm-up guide matters more than the vendor choice for new domains.

Is a free enterprise mailbox worth it?

Free tiers in China have largely disappeared or been folded into paid suites, and they usually lack DKIM console access and DMARC reporting. For a domain that sends business mail, the paid tier is cheaper than the deliverability loss.