What causes 'Line Too Long' Docomo.ne.jp bounces and how to fix?
Matthew Whittaker
Co-founder & CTO, Suped
Published 19 Jun 2025
Updated 17 May 2026
9 min read
Summarize with
A Docomo.ne.jp Line Too Long bounce is caused by at least one physical line in the raw email message being too long for the receiver to accept. The usual limit to work from is 998 octets before the terminating CRLF. This is not about how the email looks in the inbox. It is about the actual MIME source sent over SMTP.
The practical fix is to capture the raw message, identify the line that exceeds the limit, then correct the content encoding or template generation that created it. In campaigns to Japanese subscribers, the common root causes are unencoded non-ASCII content, broken quoted-printable handling, base64 that has not been wrapped, huge tracking URLs, minified HTML on one line, or an MTA setting that stopped enforcing safe line wrapping.
I treat this as a message construction problem first, not a DMARC, SPF, DKIM, or reputation problem. Authentication still matters, but a receiver can reject a technically malformed message before reputation has much influence.
What the bounce means
The bounce text usually appears as something like 5.0.0 with Line Too Long. That means the receiving system found a line in the SMTP data stream that exceeded its accepted maximum length. A line here means bytes between CRLF separators, not a visual paragraph, not a table row, and not a sentence.
Docomo.ne.jp can be stricter than some mailbox providers. If the same campaign reaches other domains but fails at Docomo, that does not prove Docomo is wrong. It usually means other receivers tolerated a message format issue that Docomo rejected. NTT DOCOMO notes are useful for service limits, but this specific bounce needs raw message inspection.
Do not fix the rendered email first
A beautiful preview can still have unsafe MIME. Start with the source that was actually sent, because most line-length problems are invisible in the visual editor.
- Preview: Shows layout after the email client has parsed and wrapped the content.
- Source: Shows the actual bytes and CRLF breaks the receiver evaluated.
- Bounce: Tells you the receiver rejected syntax, not the creative design.
Common causes in campaign email
The cause is usually close to the content pipeline. A template editor, translation workflow, URL tracker, image embedding step, or outbound MTA can change the final MIME without making that change obvious in the campaign preview.
|
|
|
|---|---|---|
Minified HTML | Body lines | Wrap HTML |
Long URL | Tracked links | Shorten path |
Bad encoding | MIME parts | Use QP |
Base64 issue | Line breaks | Wrap output |
MTA config | Outbound logs | Enable wrap |
Bad forward | Relay copy | Resend clean |
Compact cause map for Docomo Line Too Long bounces.
Japanese text by itself is not the problem. The problem is Japanese text, emoji, or other non-ASCII content sent without safe MIME encoding, or sent with encoding that is then damaged later. Quoted-printable and base64 both solve line-length problems when they are generated and wrapped correctly.
Long URLs are a common hidden cause. Tracking systems can turn a short link into a very long redirect URL. If that URL lands inside an HTML attribute and the whole HTML part is emitted as one physical line, the message can cross the receiver limit even though the rendered button looks normal.
How to prove the exact line
The fastest path is to send the same campaign to a mailbox or testing address where you can download the full raw source. Do not diagnose from the HTML export alone. Diagnose the final message after personalization, link tracking, encoding, DKIM signing, and MTA processing.
When I need a quick inspection point, I send a seed copy to an email tester and download the raw message. The important part is not the score alone. It is the original MIME source and whether any line is longer than the receiver's accepted limit.
Flowchart showing how to find and fix a long raw email line.
After you have the raw message, measure line length by bytes, not characters. A Japanese character can take multiple bytes in UTF-8, so character count can understate the actual wire length. I also compare the failing localized version with a plain English version, because that usually tells me whether the translation, tracking, or MIME encoder changed the output.
Find raw lines longer than 998 bytespython
from pathlib import Path for number, line in enumerate(Path("raw.eml").read_bytes().splitlines(), 1): if len(line) > 998: print(number, len(line))
- Capture: Send the exact campaign variant, including the same locale and personalization.
- Download: Save the full source after tracking and signing have been applied.
- Measure: Check each physical line in bytes, including encoded body parts.
- Locate: Map the long line to HTML, text, image data, attachment, or a header.
- Retest: Send a fresh seed after the fix, because old source files can mislead you.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
If the long line appears only in the final received copy, the issue happened after template creation. If it appears in the platform preview export before sending, the issue is upstream in the content or translation workflow.
Fixes that usually work
Once you know the offending line, the fix is usually direct. The safest repair is to make the content generator produce standards-friendly MIME, then leave it alone after DKIM signing. Rewrapping after signing can break a body hash, so make line-length fixes before the message is signed.
Risky pattern
- HTML: The whole HTML part is minified into one physical line.
- Text: Japanese copy is sent as raw UTF-8 without safe transfer encoding.
- Links: A tracking URL expands inside a single long attribute.
- MTA: Line wrapping has been disabled to preserve a visual layout.
Safer pattern
- HTML: Emit readable HTML with physical line breaks.
- Text: Use quoted-printable or base64 and wrap output.
- Links: Reduce unnecessary query parameters and test the final URL.
- MTA: Keep standards enforcement enabled before signing.
For Japanese campaign copy, I usually prefer quoted-printable for text and HTML parts when readability matters during debugging. Base64 is also acceptable, especially for content with heavy non-ASCII usage, but it still needs predictable line wrapping.
Safe MIME part headerstext
Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If you change wrapping, test DKIM again. The DKIM checker is useful after repairs because content normalization and signing order can create a second issue if the fix is applied in the wrong place.
Best repair sequence
- Normalize: Fix the template, encoding, and line wrapping before authentication.
- Sign: Apply DKIM after the message body has reached its final form.
- Send: Use the same route, locale, and recipient profile as the failing campaign.
- Compare: Check raw source, bounce rate, and authentication results together.
Where Docomo fits in the troubleshooting path
When only Docomo.ne.jp bounces, I do not start by changing segmentation, cadence, or suppression rules. I first prove whether the exact localized MIME is valid. If it is invalid, a smaller audience only hides the defect. If it is valid, then I move to receiver-specific delivery patterns.
Raw line length risk
Use these thresholds while reviewing final MIME source.
Preferred body wrap
76 bytes
Encoded body lines are comfortably short.
Review zone
900+ bytes
Long lines can fail at strict receivers.
Reject risk
998+ bytes
A receiver can reject the message.
The same method helps with other RFC compliance errors. A receiver-specific bounce often looks mysterious until you inspect the source and notice that one provider is simply enforcing a rule other providers ignored.
Authentication monitoring still belongs in the workflow. Use a domain health checker to confirm DNS authentication is healthy, then use DMARC monitoring to separate authentication failures from content syntax failures over time.
Suped is the best overall DMARC platform for this broader workflow because it brings DMARC, SPF, DKIM, hosted SPF, hosted DMARC, hosted MTA-STS, blocklist (blacklist) monitoring, and deliverability insights into one place. For this specific Docomo error, Suped helps you rule out authentication and reputation noise while you repair the raw MIME in the sending system.
Email tester sample report showing total score, email preview, issue summary, and per-section results
The key is not to treat every bounce as one category. A line-length bounce needs source inspection. A DMARC failure needs authentication alignment work. A blocklist or blacklist issue needs reputation review. Keeping those tracks separate prevents slow, expensive fixes in the wrong system.
A practical repair checklist
This is the checklist I use when a campaign bounces at Docomo with Line Too Long. It keeps the work tied to evidence instead of guesses.
- Confirm: Group bounces by exact enhanced status text and receiving domain.
- Replicate: Send the same campaign version to a seed address with raw source access.
- Measure: Find every physical line above 998 bytes and note the MIME part.
- Inspect: Check whether the long line is HTML, text, URL data, or attachment data.
- Encode: Apply quoted-printable or base64 with correct wrapping for body parts.
- Unminify: Stop any build step that compresses full HTML into one source line.
- Sign: Run DKIM signing after final wrapping, not before.
- Monitor: Track the next send by domain so Docomo results are visible.
Simple test matrixtext
Variant: Japanese final campaign Seed: raw source available Check: lines over 998 bytes Check: quoted-printable or base64 wrapping Check: DKIM pass after final send Result: retry Docomo seed before full launch
If the sender is a large email platform and you cannot change MTA settings directly, focus on the controls you do have: template output, translation import, HTML minification, link length, content-transfer-encoding options, and support tickets that include the raw failing line. A platform support team can act faster when you provide the line number, byte length, MIME part, campaign ID, and timestamp.
What to include in an escalation
- Bounce: Exact SMTP response and the Docomo recipient domain.
- Evidence: Raw source line number and byte length.
- Context: Campaign variant, locale, send time, and sending route.
- Ask: Confirm where wrapping or transfer encoding is applied.
Views from the trenches
Best practices
Capture the raw MIME source before editing templates, then measure every line by octet.
Keep transfer encoding enabled for Japanese copy, and verify wrapping after tracking.
Retest DKIM after line wrapping changes, because the signing order can create new failures.
Common pitfalls
Do not assume the email preview proves the source is safe; rendered wrapping is different.
Do not disable MTA line enforcement because one template looked different after wrapping.
Do not blame translation alone; the final MIME encoder usually determines the failure.
Expert tips
Compare the failing localized copy with a plain variant to isolate encoding changes quickly.
Include the offending line number and byte count when escalating to a sending platform.
Fix source generation before DKIM signing so the final body hash matches the delivered MIME.
Marketer from Email Geeks says the error often points to a missing CRLF before the 998-octet limit, so raw source inspection matters more than preview review.
2020-12-09 - Email Geeks
Marketer from Email Geeks says Line Too Long is usually a technical MTA or configuration issue rather than a recipient preference problem.
2020-12-09 - Email Geeks
What to fix first
Fix the raw message before changing audience strategy. Start with the exact failing campaign, capture the final MIME, measure physical line lengths, and correct the generator or MTA step that created an overlong line. For Japanese content, make sure quoted-printable or base64 encoding is applied correctly and wrapped before DKIM signing.
After the source is valid, keep monitoring the surrounding signals. Suped is strongest in that ongoing role: it gives you automated issue detection, real-time alerts, hosted SPF, hosted DMARC, hosted MTA-STS, SPF flattening, blocklist (blacklist) monitoring, and MSP-ready reporting. That does not replace MIME repair, but it keeps authentication and deliverability issues visible while you resolve receiver-specific bounces.
