How to resolve QQ.com IP block issues and improve email delivery?
Published 20 Jun 2025
Updated 8 Oct 2026
13 min read
Summarize with
Updated on 8 Oct 2026: We clarified QQ rejection codes, shared IP responsibilities and the checks needed before resuming delivery.
The fastest way to resolve QQ.com IP block issues is to distinguish a sending IP or domain rejection from a recipient's personal filter. If the bounce points to QQ detail code 0/92 and says the recipient rejected the message, follow the recipient-filter recovery path.
For that specific pattern, the practical fix is to suppress those QQ recipients, confirm where the addresses came from, and only resume after the user confirms they want the mail and removes or corrects the blocking rule. In parallel, fix sender-side reputation signals so the remaining QQ mail has clean authentication, stable volume, low complaints, and low unknown-user rates.
Do not assume every QQ.com rejection is an IP blacklist issue. The Chinese phrase 用户设置个人黑名单或者过滤器拒收 means the user set a personal blacklist or filter to reject the mail. That needs recipient-level cleanup, not a generic blocklist removal request. QQ's SMTP help confirms that 0/92 is a personal blacklist or filter rejection.
What the QQ.com rejection means
A QQ.com rejection that includes an opaque token, the sending IP, and a QQ detail page is often more specific than it looks. The important clue is whether the failure affects all QQ recipients or only a subset. Successful deliveries show that the same IP was accepted for some messages. They do not establish why other messages failed: compare the exact error, receiving MX and timestamp before diagnosing a personal filter.
Example QQ rejection patterntext
550 Mail is rejected by recipients. [opaque-token IP: 203.0.113.10]. QQ detail code: 0/92
With partial failure, separate the problem into two tracks. First, suppress recipients whose bounce explicitly confirms a personal blacklist or filter. Second, investigate the remaining errors for IP reputation, authentication or sending-rate problems.
QQ Mail settings showing a personal blacklist and sender filter controls.
User-level rejection
- Scope: Usually affects a subset of recipients; the bounce text must identify a personal blacklist or filter.
- Cause: The recipient has a personal sender blacklist or filter rule that rejects the message.
- Fix: Suppress the address until the recipient reconfirms and removes or corrects the blocking rule.
IP or domain block
- Scope: Rejections follow a sending IP or domain, sometimes across only part of a pool or receiving MX.
- Cause: Investigate poor IP reputation, authentication gaps, bad list hygiene, or abuse.
- Fix: Pause risky traffic, repair the sender, then resume with controlled volume.
Diagnose QQ SMTP errors before mitigation
Before asking QQ for mitigation, build a small evidence set. Determine whether the block is per recipient, per campaign, per IP, per sending domain, or tied to a specific type of message. Without that split, the next step becomes guesswork.
- Bounce split: Group QQ bounces by SMTP code, QQ detail code, sending IP, receiving MX, timestamp, domain, campaign, and recipient age.
- Recipient history: Check replies, confirmed account activity, complaints, unsubscribes, last consent date, and last successful delivery. Treat opens alone as weak engagement evidence.
- Authentication: Configure both SPF and DKIM; at least one must pass with the required relationship between its authenticated domain and the visible From domain for a DMARC pass.
- Reputation: Check the exact outbound IP and sending domains for current blocklist (blacklist) listings, then compare them with QQ-only failures.
- Content: Review the subject, URLs, tracking domain, attachment size, language, and an easy unsubscribe option for marketing mail.
QQ's SMTP error help lists IP and domain frequency-limit errors separately from personal filters. Reduce the QQ sending rate and concurrent connections when those errors appear. Under RFC 5321, a 4xx response is a temporary deferral for the MTA to retry with backoff; a 5xx response ends that delivery attempt, even when its text mentions a frequency limit. Do not permanently suppress every address after a rate-related 5xx; correct the cause before a controlled new send.
Use Suped's blocklist monitoring for ongoing visibility after QQ starts rejecting mail. A sender can pass DMARC and still have poor IP or domain reputation, so compare authentication results with QQ bounce logs.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Suped's domain health check helps review DMARC, SPF, DKIM and DNS. Compare those results with sending logs and QQ bounce data to establish the affected IPs and messages.
Fix sender-side causes first
Even when the immediate QQ rejection is user-level, sender-side fixes still matter. Weak authentication, inconsistent volume, recycled addresses, or old consent create additional delivery risks. Investigate those signals separately from confirmed personal filters.
|
|
|
|---|---|---|
DMARC | Policy and pass rate | Verify legitimate sources and forwarding paths before changing DMARC policy. |
SPF | Lookup-triggering terms and MAIL FROM | Authorize the actual outbound hosts and stay within SPF's 10-term DNS lookup limit, including nested includes. Use a MAIL FROM domain with the same organizational domain as From, or an exact match for aspf=s. |
DKIM | Signing domain and valid signature | Use a valid signature with a d= domain that shares the From organizational domain, or an exact domain match for adkim=s. |
SMTP identity | PTR, forward DNS, and EHLO | Set PTR to a stable hostname with an A or AAAA record that returns the sending IP; use a valid EHLO hostname. |
IP | Sending rate and complaints | Reduce volume and send only to engaged recipients. |
List | Consent age | Suppress invalid addresses and confirmed personal filters; review stale contacts before new campaigns. |
Use this table to decide which fix to prioritize before retrying QQ traffic.
Baseline DNS records to verifydns
; Illustrative records: replace the sender include and DKIM key. example.com. TXT "v=spf1 include:_spf.senders.example -all" selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=BASE64KEY" _dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
RFC 9989 made the DMARC pct tag historic, so pct=25 does not provide a standards-defined percentage rollout. Monitor with p=none and inspect authentication and forwarding paths before changing policy. For domains whose users post to Internet mailing lists, RFC 9989 advises against p=reject. Domains using p=reject must use valid DKIM signatures rather than depend only on SPF. Changing DMARC policy does not clear QQ's IP blacklist.
Suped's product combines DMARC reporting with blocklist monitoring and issue-specific remediation steps. For a QQ incident, use reports to associate observed sending IPs with authenticated domains, then compare them with bounce logs and public blacklist status before a controlled retry.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
After DNS and authentication fixes, send a real test message to an authorized QQ mailbox and inspect its receiver-added Authentication-Results and Received headers. Suped's email tester helps check authentication and formatting on a separate test message; QQ acceptance and inbox placement need verification in the QQ mailbox itself.
Handle user-level QQ blocks
If QQ subscribers bounce with the confirmed personal blacklist or filter rejection, do not keep retrying them. The rejection is enough reason to suppress the address, even when the recipient's reason for setting the rule is unknown. The next step is consent confirmation outside email.
Decision flow for resolving partial QQ.com email delivery failures.
- Suppress: Move the affected QQ addresses into a no-email segment after the first confirmed personal filter rejection.
- Verify: Check whether the subscriber has recent engagement, paid status, active enrollment, or a support relationship.
- Contact: Use an agreed account portal, SMS, app notification, or support channel to help a user who requests delivery remove or correct the blacklist entry or filter rule.
- Reconfirm: Send again only after the user reconfirms they want the messages and removes or corrects the blocking rule.
A fixed wait time does not clear a recipient's personal QQ blacklist. Keep the address suppressed until the user reconfirms and removes or corrects the filter, including when they need account or education mail.
Use the QQ segment's consent and rejection data to set an appropriate sending frequency. The QQ.com best practices guidance helps plan segmentation and list cleanup without assuming every QQ recipient needs the same schedule.
Handle a named RBL or DNSBL rejection
A 554 SMTP response or 5.7.1 enhanced status code does not identify the cause by itself. If the full reply names a real-time blackhole list (RBL) or DNS-based blocklist (DNSBL) and an IP address, investigate that exact IP. Capture the full bounce before checking status because an IP pool can make it easy to investigate the wrong address.
- Save the evidence: Record the complete SMTP response and diagnostic token, timestamp with time zone, receiving MX, SMTP stage, message ID, envelope sender, and connecting IPv4 or IPv6 address.
- Match the IP: Confirm that the IP in the bounce belongs to the affected sending stream rather than another IP in a shared or rotating pool.
- Check the listing: Verify the exact IP's current status. If listed, stop the cause, complete the blacklist owner's removal process, and keep proof of delisting.
- Repair SMTP identity: Confirm the PTR hostname resolves forward to the same IP and use a stable, valid EHLO or HELO name.
- Retry correctly: Let the sending MTA retry temporary 4xx responses with backoff. A 5xx failure ends that delivery attempt; classify its cause before deciding whether to suppress the address or send a new message after repair.
If the exact IP is no longer listed, compare the delisting time with the rejection time and verify every IP in the sending pool. Check whether rejections follow one receiving MX to investigate a receiver-side cache difference. A clear public blacklist result does not rule out QQ's internal reputation or content filtering. Do not rotate traffic to a fresh IP to bypass the block because that carries the same unresolved sending behaviour into a new reputation.
A QQ recipient's allowlist changes mailbox filtering. Check SMTP logs to establish whether rejection occurred at connection time, before QQ knew the recipient. If a reply arrives, compare its sending IP and receiving MX with rejected messages before concluding that the IP block has cleared.
Resolve shared IP blocks with your mail provider
If your outbound mail uses a shared IP address, other customers' sending activity affects that IP's reputation. Google describes this infrastructure risk in its sender guidelines. For a QQ incident, involve the hosting provider or mail server operator that controls the blocked IP.
- Ask the provider to confirm the actual outbound IPv4 or IPv6 address and whether the affected sending pool is shared or dedicated.
- Have the IP owner verify reverse DNS and EHLO, investigate abuse on the server, and stop any compromised-account traffic before requesting removal.
- Give the provider the complete bounce and receiving MX evidence. Agree who will request removal from the named blacklist or escalate QQ-specific rejection after repairs.
- If the provider proposes a dedicated IP or another managed route, require a clear remediation plan and gradual IP warm-up with consenting recipients.
Changing a domain's DNS records does not repair another customer's abuse on a shared server. A dedicated IP still needs a sending history and controlled volume; its purchase is not a guarantee of QQ delivery.
When to pause or contact QQ
If the pattern changes and most QQ mail starts failing, pause risky QQ traffic and investigate the shared error pattern. A pause stops further failed attempts while you clean up the list, DNS, content, and volume plan. Use a staged restart after the cause is repaired.
Example internal QQ rejection bands
Example internal QQ rejection-rate bands, not QQ requirements. Rate = rejected QQ messages / attempted QQ messages. Suppress confirmed personal filters at any rate, and investigate widespread failures even below 5%.
Isolated failures
under 1%
Small number of confirmed personal filters; suppress affected addresses
Investigate
1-5%
Concentrated failures in old or inactive QQ segments
Pause broad sends
over 5%
Failures spread across recent and engaged QQ recipients
Contact QQ when you have evidence of a broad block and have repaired sender-side causes. Use the support route linked from QQ's SMTP help or the instructions in the exact bounce rather than assuming a generic delisting portal applies. The mitigation package should include timestamps with time zones, source IPs, receiving MX, envelope sender, From domain, sample message IDs, complete bounce text, authentication results, consent evidence, and a short explanation of what changed.
|
|
|
|---|---|---|
Confirmed personal filters | Suppress affected recipients | After reconfirmation and filter correction |
Old segment | Pause and clean list | Restart with engaged users |
All QQ mail | Pause risky streams | Ramp after clean tests |
All domains | Investigate IP reputation | Restart after root cause |
The right mitigation path depends on the bounce pattern.
For China-specific sending, also check whether your content, consent flow, and local expectations fit the recipient base. The Chinese market rules matter more when you send at volume to QQ, NetEase, Sina, and other Chinese mailbox providers.
Monitor recovery and keep it stable
Keep confirmed personal filters suppressed while fixing DNS and sending reputation. Monitor engaged and inactive QQ users separately, and only restore a filtered address after reconfirmation and rule correction. These groups need separate recovery decisions.
Blocklist monitoring page showing domain and IP checks across blocklists with importance and status
Suped's product keeps DMARC reports, authentication failures, alerts and blocklist (blacklist) status in the same workflow. For teams managing many domains, compare domain-level findings with QQ sending logs. Early SMTP rejections do not necessarily produce DMARC reports, so report absence is not evidence of successful QQ delivery.
Example QQ restart plan
Illustrative percentages only. Increase volume when QQ acceptance, deferrals and available complaint signals stay stable; these dates are not recovery deadlines.
QQ segment volume restored
Keep a daily view of SMTP acceptance, temporary deferrals, hard bounce causes, QQ-only rejection rate, available complaint data, DMARC pass rate, and blacklist status. A public blocklists reference helps explain what an IP listing means. SMTP acceptance is different from inbox placement: check the inbox and spam folder in an authorized QQ test mailbox after controlled sends.
- Clean start: Restart only with consenting QQ users who replied, logged in, purchased, or requested mail recently; do not rely on opens alone.
- Strict stop: Suppress any QQ address that returns another personal blacklist or filter rejection.
- Separate streams: Keep transactional and marketing mail on separate, clearly governed sending streams.
- Daily review: Review QQ-specific outcomes daily during recovery, not only aggregate campaign metrics.
Views from the trenches
Best practices
Segment QQ users separately so partial rejections do not distort the whole campaign.
Suppress confirmed personal filter bounces and require renewed consent before resuming mail.
Keep authentication, IP reputation, and list source evidence ready before escalation.
Common pitfalls
Assuming every QQ bounce is a global IP block wastes time and keeps bad mail flowing.
Retrying QQ users after a confirmed personal filter rejection ignores their mailbox settings.
Mixing inactive QQ users with engaged users makes the resulting recovery data harder to trust.
Expert tips
Translate QQ detail pages carefully because one phrase can change the fix completely.
Restart QQ traffic with a small engaged cohort before expanding the consenting recipient group.
Use non-email channels for real users who need account mail after blocking a sender.
Expert view
A partial QQ failure with that rejection text usually means specific subscribers blocked the sender, not that QQ applied a global IP block.
2024-08-07 - Email Geeks
Expert view
Those recipients should stop receiving mail unless they remove the block through another channel and clearly want the messages again.
2024-08-07 - Email Geeks
