Hi everyone, this is Neo.

A few days ago, a friend in foreign trade came to me in a panic. She’d just finished setting up her Tencent Enterprise Mail with her own custom domain, and was all excited to start sending cold outreach emails to clients — only to find that emails wouldn’t go out at all! Her clients also reported they never received anything. She was beside herself.

For those of us running independent sites, email is the lifeline of communication — especially for B2B. Cold outreach, order confirmations, customer service — it all runs on email. If that breaks, the damage can be huge.

I logged into her DNS management panel remotely and checked everything carefully. MX and SPF records both looked fine. Finally, my attention landed on a record called “DMARC.” Sure enough, that was the culprit! In her DMARC record, the policy parameter (the p value) was set to p=reject.

I breathed a sigh of relief — problem found! Today, using this case as an example, I’m going to explain exactly what’s going on when your business email can’t send — especially this DMARC record.

What Exactly Is DMARC, the “Culprit”?

DMARC (Domain-based Message Authentication, Reporting, and Conformance) — the full name is a mouthful, but don’t let it scare you.

Despite the complicated name, its job is simple: it tells email servers around the world what to do with forged emails that spoof your domain (like @yourdomain.com). It’s the “powered-up version” of SPF and DKIM (the other two email authentication technologies).

Inside a DMARC record, the most important part is the p parameter, which stands for “Policy.” It has three options:

1. p=none: No action (monitoring mode). Even if a forged email is detected, don’t block it — deliver it normally. But log the event and send me a report (to the email specified in the rua parameter). This mode is usually used in the early setup phase, to observe and collect data.

2. p=quarantine: Quarantine. If a forged email is detected, drop it into the recipient’s “spam” folder. Stricter than none, but at least the customer can still find it in the junk folder.

3. p=reject: Reject. The strictest mode. The moment a forged email is detected, it’s refused outright — it never even enters the recipient’s server. My friend made the mistake of using this, so her own emails from her business mailbox got “friendly-fired” by the DMARC policy when some step in the verification chain failed — the receiving server simply rejected them.

For anyone just starting with enterprise email, or not yet familiar with email authentication config, I strongly recommend starting with p=none!

The “Three-Step” Correct Configuration for Tencent Enterprise Mail

Now that we understand DMARC, let’s walk through the full domain configuration process for Tencent Enterprise Mail. It’s actually simple — basically three DNS records: MX, SPF, and TXT (DMARC).

Say your domain is yourdomain.com.

Step 1: Configure the MX Record (Mail Exchange Record)

The MX record tells all mail servers: “Hey, any mail addressed to @yourdomain.com should be delivered to these two servers.” It’s the most basic record — without it, you can’t receive a single email.

You need to add two MX records:

Host	Type	Value	Priority
@	MX	mxbiz1.qq.com.	5
@	MX	mxbiz2.qq.com.	10

Note:

• Set the host to @, which represents your main domain.
• Don’t skip the trailing dot . in the value — many DNS providers add it automatically, but it’s safest to include it yourself.

Step 2: Configure the SPF Record (Sender Policy Framework)

The SPF record tells the world: “Only emails sent from servers authorized by me (Tencent Enterprise Mail) are legitimate.” It’s the first line of defense against someone spoofing your domain.

You need to add one TXT record:

Host	Type	Value
@	TXT	v=spf1 include:spf.mail.qq.com ~all

The include:spf.mail.qq.com part authorizes Tencent’s mail servers to send emails on your behalf. ~all marks emails from other servers as “soft fail” — a relatively gentle setting.

Step 3: Configure the DMARC Record (The Ultimate Move)

Finally, the star of today’s show. The DMARC record combines the verification results of SPF and DKIM and tells the receiving server how to handle emails that fail verification.

You need to add one more TXT record:

Host	Type	Value
_dmarc	TXT	v=DMARC1; p=none; rua=mailto:your-report-email@qq.com

Key points:

• The host must be _dmarc.
• v=DMARC1 is the version number — copy it as-is.
• p=none is the policy I recommend for beginners — observe first, don’t rush to reject.
• rua=mailto:your-report-email@qq.com is optional, but I recommend adding it. It makes the email you specify (like your QQ mailbox) receive regular DMARC reports telling you which emails passed verification and which failed. That’s incredibly useful for troubleshooting.

Once your mailbox has been running stably for a while, you can analyze the reports and consider upgrading the policy to p=quarantine.

Summary

Email systems look complicated, but once you understand the principles behind these core records (MX, SPF, DMARC), configuration becomes second nature.

Remember this key point: DMARC’s p=reject is a double-edged sword — extremely powerful, and never use it lightly before you fully understand it! For independent site owners and foreign trade folks, reliable email delivery comes first. Starting with p=none and building up steadily is the smartest move.

Hope today’s share helps. If you run into other issues while setting up enterprise email, drop a comment below and let’s figure it out together!