Tencent Cloud Payment Verification Fix Tencent Cloud DirectMail attachment size limit error

Tencent Cloud / 2026-07-21 18:15:43

You’re seeing a “DirectMail attachment size limit” error, and you don’t want a long theory lesson—you want a working path to get your emails sent without getting stuck in Tencent Cloud account checks, payment issues, or risk controls.

Below is how I typically troubleshoot this in real operations: first isolate the exact error meaning, then adjust your sending flow (payload vs. MIME attachments), and only after that check account/payment/security constraints that can indirectly trigger the same error string.

1) What you actually need to confirm first (before changing code)

Users usually search “attachment size limit error” thinking it’s only a coding problem. In practice, three different root causes can produce similar-looking failures.

Payload too large: your HTTP request (body) or encoded MIME content exceeds the allowed limit.
Attachment-specific limit: DirectMail enforces a per-attachment or per-message size ceiling (often after base64 expansion).
Account/verification/risk constraints: occasionally the API returns a generic limit error when the account is in a restricted state (new accounts, failed KYC, payment not verified, or risk review pending).

Actionable checks (fast):

Open the API response body (not just the UI toast/error line).
Look for error fields like code, message, and any “request size”, “attachment”, “MIME”, or “quota” hints.
Log your final request size right before sending.
If you’re sending multipart/form-data or a JSON body with base64, check the actual bytes on the wire. Base64 typically increases size by ~33%.
Compare raw file size vs. encoded attachment size.
Example: 5MB PDF becomes ~6.7MB after base64, plus MIME headers and boundaries—your “size limit” math might be wrong.

If you can paste the exact code/message you see (or a screenshot), I can map it to which bucket (payload vs attachment vs account state) is most likely.

2) The most common cause: base64 expansion and MIME overhead

In many DirectMail integrations, developers calculate “attachment size” using the original file size on disk. But DirectMail typically evaluates the encoded MIME content, not the raw file.

Why your “small” attachment still fails:

Base64 overhead: increases payload size ~33%.
Headers & boundaries: MIME adds content-type, content-disposition, filename, encoding lines.
Line wrapping: some libraries insert line breaks, adding a few bytes each chunk.

Fix approach that works in production:

Compute the encoded size before sending.
In Node/Python, calculate the base64 string length and estimate bytes as base64Len * 3 / 4 (or just measure the encoded string byte length).
Set a client-side safe cap.
Even if the limit is “X MB”, assume your effective max is smaller due to base64 + MIME. Example practice: use limit * 0.75 as a conservative threshold.
Use a “download link” pattern for large files.
Instead of attaching, send a mail with a pre-signed download URL (e.g., Tencent COS signed URL). This avoids attachment limit logic entirely.

Mini case I’ve seen:
A team attached a ~4.8MB PDF. Locally it looked fine. In logs, the base64+MIME exceeded their target by ~2MB; DirectMail returned a “size limit” error. After switching to a download-link flow (COS signed URL), the failure rate dropped to near zero without changing recipient behavior.

3) DirectMail attachment vs request payload: different limits, different fixes

If your request is built incorrectly, the API can reject it as “attachment too large” even when each attachment file seems under the cap.

Common implementation traps:

Sending the whole MIME message as one giant base64 field (double-encoding).
Some wrappers convert MIME to base64 again “for transport”. That can multiply payload size unexpectedly.
Using nested base64 for embedded images.
Inline images in HTML (data URIs) can silently balloon content size.
Multiple attachments where each is under limit, but total MIME message exceeds limit.
Some systems enforce both per-attachment and total-message caps.

Tencent Cloud Payment Verification What to do:

Separate “inline content” from “attachments”.
For inline images, host them externally or use CID attachments properly instead of data URIs.
Ensure you only encode once.
If the API expects base64, don’t base64 the whole MIME package again.
Calculate total MIME size.
Sum base64 sizes of all attachments + HTML size + MIME headers. If total exceeds, reduce number of attachments or move to link delivery.

4) When it’s not “attachment size”: account/payment/risk control can mimic limits

Users often assume the problem is purely technical. But I’ve also observed situations where DirectMail calls fail due to account status or risk constraints—then the error text doesn’t clearly point to KYC or compliance.

Operational signals that suggest an account/state issue:

You created the Tencent Cloud account recently (or switched regions / renewed org settings).
Your KYC is “in review”, “rejected”, or “not completed”.
You just changed payment method or recharged a small amount and DirectMail quota didn’t settle.
Only certain recipients/domains fail while others succeed.
API failures started after a campaign that triggered anti-spam/risk scoring.

How to validate quickly:

Check DirectMail service dashboard → sending status / quota / restrictions.
Look for any “restricted”, “under review”, “verification required”, or “quota limited” labels.
Verify identity status (KYC) under your Tencent Cloud account.
If KYC is incomplete, complete it before debugging payload logic too deeply.
Check whether you can send small test messages with no attachments.
If small messages work but attachments always fail, it’s likely payload/MIME limits. If all sending fails or is throttled, it’s more likely account/risk state.

Practical advice:
Before you invest time optimizing MIME, run a controlled A/B test:

Same request, remove attachment: does it send?
Add a tiny attachment (e.g., 50KB): does it send?
Increase attachment size gradually: identify threshold where it starts failing.

This tells you whether the limit is real and what boundary you’re hitting.

5) KYC (identity verification) and enterprise verification: what commonly breaks

If you’re purchasing cloud services or setting up DirectMail for an organization, KYC issues can lead to inconsistent sending behavior and sometimes misleading errors.

Common KYC/KR (risk review) failure reasons I’ve seen:

Mismatch between account name and payment/receipts (especially if you fund via third-party means).
Unclear business scope in enterprise verification (DirectMail often gets associated with marketing/notifications; scope should be consistent).
Insufficient supporting documents for enterprise signatory or authorized representative.
Frequent account changes: new account → KYC review → new payment → reconfiguration.

What you can do right now:

If you see “verification required”, complete KYC first—even if you can send basic emails.
If you’re operating from a company, prepare your business license and the responsible person’s ID early.
Use consistent company identity across Tencent Cloud, billing, and any outbound branding (sender name/domain).

Tencent Cloud Payment Verification 6) Payment method differences that affect quotas and renewals

Attachment-size errors rarely come from payment type directly, but they can appear after quota changes, service suspension, or partial activation.

How to think about payment when troubleshooting DirectMail:

Payment scenario	What often happens	What to check
New account / first recharge	Quotas may not be fully effective immediately; some APIs fail or behave inconsistently.	Sending quota status; wait for billing activation, then retest with small attachment.
Auto-renew / subscription renewal pending	Service restrictions can kick in during renewal window.	Renewal status, last payment time, and whether the service is in “active”.
Pay-as-you-go vs package	Different rate limits / throttles may apply; large payloads can be more likely to hit caps when quota is tight.	Check daily/monthly sending metrics and any throttling indicators.
Payment via different rails (bank/credit/online transfers)	Occasionally triggers risk control or delays identity/payment linkage.	Billing account matches KYC; review any alerts in the console.

Practical test: If you can, switch to a known-good sending template and send a small attachment. If that works, your account/payment is likely fine, and you can focus on MIME/payload size.

7) Risk control & compliance reviews: what matters for attachments

DirectMail is not just “SMTP with an API.” Sending behavior and content can trigger risk scoring. Attachments can be a bigger trigger than plain text because they increase the likelihood of spam/malware patterns.

Things that can worsen risk scoring and indirectly cause delivery/API failures:

High volume or sudden spikes in recipient count.
Recipients are new/unverified domains.
Attachment types that are common malware carriers (some orgs flag certain extensions more aggressively).
Shortened links or unusual URL patterns (especially with tracking parameters).

Operational workaround:

Prefer COS signed URLs and plain-text/HTML templates over direct attachments for marketing/notification use cases.
Stage rollouts: ramp up sending gradually after any account changes.
Keep attachment count low and file names consistent with your verified sender identity.

8) Fix checklist (do this in order)

Here’s the order I recommend on live incidents, so you don’t waste time bouncing between code and account settings.

Reproduce with controlled test emails
- No attachment → confirm baseline sending.
- 50KB attachment → confirm attachment pipeline works.
- Tencent Cloud Payment Verification Binary search up to failure threshold to find the real limit.
Measure encoded size
- Tencent Cloud Payment Verification Check base64 length and final request bytes.
- Ensure you’re not double-encoding MIME.
- Check inline images (data URIs) inflate HTML size.
Reduce payload complexity
- Remove inline images or externalize them.
- Reduce number of attachments and total MIME size.
- Switch large files to a download URL (COS signed URL).
Check account status
- KYC completed and accepted (enterprise verification if needed).
- Service active and quota not restricted.
- No recent risk review flags (especially after a failed campaign).
Validate payment/renewal state
- Confirm billing is active and quotas updated.
- After recharge/renewal, wait for console status to reflect actual activation.

9) Cost comparison: attachment vs signed URL delivery (what users usually overlook)

Tencent Cloud Payment Verification Even if you can make attachments work under the limit, the “cost of failure” can be higher than using links. Attachment size limits cause retries, failed API calls, and support cycles.

Common cost trade-offs:

DirectMail attachments: you pay for the email sending; additional failed attempts waste API calls and can hurt risk reputation if retries are aggressive.
Download URL pattern: you pay for object storage + egress + signed URL requests (depending on your setup), but you dramatically reduce email payload size issues.

Tencent Cloud Payment Verification Decision rule I use:
If attachments are near the boundary (e.g., 3–10MB range depending on your account/template), switch to links. If attachments are always tiny (tens of KB) and volume is low, attachments are simpler.

10) Frequently asked questions (the questions behind the search)

Q1: “What’s the maximum attachment size in Tencent Cloud DirectMail?”

The hard limit depends on the sending API/template and how Tencent evaluates the MIME/encoded payload. In real troubleshooting, don’t rely on memory—run an incremental test to locate your effective threshold (and remember base64 overhead).

Q2: “My attachment is under the limit by file size—why still error?”

Most likely causes are base64 expansion, inline data URIs in HTML, double-encoding, or total MIME size (multiple attachments + HTML) exceeding the ceiling.

Q3: “Can I bypass the limit by compressing the file?”

Often yes, but only if the final encoded MIME size fits. Also ensure the compressed format is not flagged by risk rules and that recipients can open it.

Q4: “Does KYC affect attachment size errors?”

Usually it affects whether you can send at all or whether sending is restricted. However, I’ve seen generic error messaging during risk-restricted states. That’s why the test order matters: confirm no-attachment sending first.

Q5: “Does payment method matter?”

Payment method doesn’t change the attachment byte limit, but it can delay or restrict service activation/quota updates. If your errors started after funding/renewal changes, check billing status and sending quota.

Q6: “I only send to a few recipients—still failing?”

Then focus on encoding/MIME size and template correctness. Recipient count is less relevant when the API rejects the request before delivery.

11) What I need from you to pinpoint the fix

If you want a precise recommendation (instead of generic troubleshooting), reply with:

The exact error code and message from the API response
Your attachment type(s) and original file size(s)
Whether you embed images via data URIs
How you build the request (JSON with base64? multipart? any wrapper libraries?)
Whether no-attachment emails send successfully
Your account state: KYC status + whether sending quota shows restrictions

Tencent Cloud Payment Verification With those, I can tell you whether this is a pure payload limit, a MIME construction bug, or an account/risk/quota state that’s surfacing as a “size limit” error.