DKIM c=relaxed Line Folding Issues

Why does DKIM c=relaxed fail when your email has line folding?

You send a perfectly valid email. DKIM signs it. Yet it still fails to verify—though the error is invisible in most mail clients. The real issue? Line folding in quoted-printable encoded headers.

DKIM’s c=relaxed tag gives some leeway. It allows minor header normalization, like trimming whitespace. But it depends on folding preserving the original encoding structure. Break that, and DKIM’s hash check fails silently.

Key takeaways

DKIM validation fails silently when quoted-printable headers exceed 78 characters and are folded mid-character.
Relaxed canonicalization only works if line breaks align with encoding boundaries—no mid-encoding breaks allowed.
Even if the email renders correctly to users, improper folding can invalidate DKIM and harm sender reputation.

What is quoted-printable encoding and why does it matter for DKIM?

Quoted-printable (QP) encoding allows non-ASCII characters—like accents or symbols—to be safely included in email headers and bodies by representing them as =XX sequences. When a QP-encoded line exceeds 76 characters and gets split mid-sequence (e.g., =AB broken into =A and B), the receiving parser may reconstruct it incorrectly, corrupting the message. This corruption breaks DKIM’s cryptographic signature verification, causing a c=relaxed fail even if the rest of the email is valid.

How QP line folding breaks DKIM validation

DKIM signs the raw, canonicalized form of the message body and headers. The signing process assumes the encoded content remains intact. If you’re not careful with line breaks in encoded content, you can introduce subtle changes that the DKIM signature won’t match.

Consider a QP line like =C3=83=83=83=83=C3=83 (representing a sequence of non-ASCII characters). If this line gets split mid-encoding—say, after =C3=83—the receiving server might reassemble it as =C3=83=83=83=C3=83, introducing a spurious =83=83 sequence where there shouldn’t be one. This change invalidates the DKIM check.

A real-world example is the RFC 2045, which specifies that QP encoding must preserve character boundaries across line breaks. Violating this rule isn’t an SMTP error, but it can silently break DKIM if the signature is based on unaltered content.

Why this matters for email deliverability

Many email systems use c=relaxed in DKIM verification, which tolerates minor formatting differences—like whitespace or header order changes. But relaxed does not overlook changes caused by improper line folding. If the message body or headers are encoded and folded incorrectly, even relaxed verification can fail.

For marketers, this means your carefully crafted campaign email might get flagged or filtered as suspicious—even without malicious content—just because of a hidden encoding misstep. This is especially common when using legacy email tools or template engines that don’t respect QP line length limits.

If you're sending bulk messages, catching these issues early is essential. Use an email list verification tool to test the integrity of your email content before sending. Tools like MailTester’s bulk verification can spot encoding issues in a list of addresses, helping you avoid deliverability problems before they hit your inbox.

How does line folding break DKIM when c=relaxed is used?

DKIM signatures are based on the exact byte sequence of header fields, including encoded characters. When c=relaxed canonicalization is used, some whitespace normalization is allowed, but line folding—especially when it splits encoded sequences like =AB=CD into =A
B=CD—alters the original character stream. This breaks the hash comparison, causing signature verification to fail even if the content is otherwise valid.

The Problem with Line Folding in Encoded Headers

When headers contain quoted-printable encoding, the original sequence of bytes is critical. For example, =AB=CD must remain intact; splitting it across line breaks as =A
B=CD changes the encoded output, making the signed and received versions mismatched.

Even with c=relaxed, which allows minor whitespace adjustments, the canonicalization process still expects the encoded characters to stay in their original order. Line folding that breaks this rule—especially in multipart encoded text—invalidates the DKIM signature.

Why This Matters in Real-World Email Systems

Many email clients and servers apply their own line folding to headers, often at 78 or 99 characters. If that folding occurs mid-quoted-printable sequence, the result is a broken signature.

According to RFC 6376 (the DKIM specification), canonicalization rules must preserve the original content’s byte sequence. Missteps here undermine trust in sender authentication. The issue shows up most often in headers like Subject, From, or Message-ID when they contain non-ASCII characters or are long.

Tools that validate DKIM often detect this issue. You can test a message’s DKIM integrity using a real-time verification API like the one from MailTester’s email verification API, which checks deliverability and header consistency before you send.

How to Prevent It

Let’s be clear: the fix isn’t avoiding line folding—it’s ensuring that folding doesn’t split encoded sequences. This means keeping quoted-printable content within a single line or using text/plain encoding if you’re generating complex headers.

For automated systems, validate the raw headers before signing. If you’re using a mailer with built-in DKIM signing, make sure it disables line folding during the signing phase. You can also verify your signed messages using tools like MxToolbox’s DKIM Lookup or DKIM Analyzer.

Even with c=relaxed, the signature still depends on precise byte-level fidelity. If you’re seeing a sudden increase in DKIM failures, check your header generation process for accidental line breaks in encoded fields.

Step-by-step: How to detect QP line folding issues in email headers

When DKIM c=relaxed fails due to quoted-printable line folding, it’s usually because encoded text was split across lines with line breaks mid-sequence (like =A
B instead of =AB). This breaks the signature’s math. You detect it by pulling the raw message, finding MIME-encoded headers, and checking if = signs are split across lines using a parser that respects MIME line folding rules. Let's walk through it.

Extract and inspect the raw email

Access the raw source of a delivered email or bounce report (typically via email client "Show Original" or mail server logs).
Look for headers using Q encoding, such as Subject: =?UTF-8?Q?H=EC=9E=8D=9F?=—these are common in non-ASCII content.
Check for visible line breaks inside such sequences: look for =A\nB where a line break appears between two encoded hex digits.
Normal MIME line folding allows soft line breaks, but the encoding must be continuous. Any break between = and the next hex digit breaks the QP decoding process.

Validate with a correct MIME parser

Use a real MIME parser (like Python’smodule or a tool such as RFC 2047) that handles fold continuation properly.
Recombine folded lines only when they follow RFC 2047’s rule: a soft line break after a CRLF must be ignored if it’s not after a space or tab.
Compare the decoded string after proper reassembly with the original content in the header. If they differ, the signature will fail.
Fix broken line folding in your email generator or mail server by ensuring no line breaks occur between = and the hex digits in =XX sequences.

These issues often appear in poorly implemented MTAs or email builders that break long lines without respecting MIME rules. The problem is especially common when sending through legacy systems or poorly configured templates.

The 4 steps described in “Extract and inspect the raw email”, in order.

If you're verifying email infrastructure or testing deliverability, tools that parse raw messages correctly can catch these edge cases before they cause DKIM failures. MailTester’s inbox placement tests help you validate full message delivery and header consistency across real inboxes.

Real-world example: A c=relaxed failure caused by folded QP

DKIM’s c=relaxed canonicalization fails when a quoted-printable encoded header is split mid-encoding across line breaks, due to improper line folding. In one case, a subject line with Unicode characters was encoded as =?UTF-8?Q?T=ED=EF=90=AB?=, but a legacy system broke it mid-sequence as =T\nED=EF=90=AB=?. DKIM validators reconstructed this as TED=EF=90=AB, which didn’t match the original signature—even with c=relaxed, because the folding introduced a semantic error in the encoding structure.

The problem: folding breaks the Quoted-Printable structure

Quoted-printable encoding requires that encoded sequences remain intact. When a line is folded mid-sequence—especially in an encoding like =ED=EF=90=AB—the parser receives a malformed chunk. DKIM’s c=relaxed mode only adjusts for whitespace and case; it does not reassemble broken encoding sequences.

Let’s say you send an email with a subject like “Téchnologie” from a system that doesn’t properly handle line length limits. The encoding =?UTF-8?Q?T=ED=EF=90=AB?= gets split like this:

=?UTF-8?Q?T=ED=EF=90=AB?=\n
=?UTF-8?Q?T=ED=EF=90=AB?=

But if the break lands mid-sequence—such as after =T—the result becomes =T\nED=EF=90=AB=?. The parser sees TED=EF=90=AB as a single unit, which is not the original string. DKIM validation fails because the signed value doesn’t match the reconstructed one.

Why c=relaxed doesn’t fix this

Relaxed canonicalization is meant to absorb minor formatting differences, like variable whitespace or case mismatches. But it does not repair syntax errors introduced by improper line folding. The core issue isn’t case or spaces—it’s a structural violation of the quoted-printable standard.

This is why even well-signed emails fail DKIM verification. It’s not about keys or headers—it’s about how the message body is constructed and transmitted. The MIME standard (RFC 2045) explicitly requires encoded lines to be folded only at specific points—after = characters, not within them.

Fix this at the sending stage. Validate your email content before sending, especially when using non-ASCII characters. Use tools that flag malformed encoding or line breaks. MailTester’s email checker or inbox placement tester can help preview how an email behaves across infrastructure—catching these edge cases before delivery.

How to prevent QP line folding issues in email content

DKIM signatures can fail with c=relaxed when quoted-printable encoded headers or bodies are split mid-character due to improper line folding. This happens when line breaks are manually inserted or when encoding tools don't follow RFC 2047 rules. To prevent this, ensure all QP content is folded strictly at 76-character boundaries, never mid-word, and test headers with a strict parser before sending.

Guard against improper line folding in QP encoding

Only apply quoted-printable encoding to headers and bodies when required—avoid it for plain text or already encoded content.
Never insert hard line breaks in MIME parts. Let your email engine or library handle wrapping automatically at 76 characters.
Use libraries like PHP's mb_encode_mimeheader() or Python'sthat follow RFC 2047’s line folding rules—these prevent mid-character splits and maintain integrity.
Test your generated messages with a strict header parser such as RFC 2047 validators to catch folding issues before sending.
When in doubt, validate the raw message output using tools like MxToolbox to check how headers and bodies are being interpreted by mail servers.

Verify encoding correctness in practice

Review the raw MIME structure of your email—especially the Subject, From, and To headers—before sending.
Use MailTester’s email checker to test individual addresses and validate that their email content passes basic parsing rules.
For bulk sends, run your list through bulk verification to catch malformed addresses or content that could trigger encoding errors.
Keep your email generation pipeline consistent: if your tool allows, enforce a single, standardized encoding method across all headers and body parts.
Log and audit your sent messages—especially those that trigger DKIM failures—with c=relaxed—to identify recurring folding patterns.

Line breaks in quoted-printable content must not occur within a single encoded character or mid-word. Proper folding preserves both readability and cryptographic integrity.

Why your email verification service might miss this issue

Most email verification services only check basic syntax, MX records, and whether a domain accepts all emails (catch-all). They don’t validate the full MIME structure—like how headers are encoded or folded. This means issues like quoted-printable line folding breaking DKIM’s c=relaxed signature aren’t caught, even though they cause real delivery failures. If the service doesn’t simulate the full email sending process, you’ll miss these subtle but critical errors.

What most verifiers don’t test

MailTester checks more than just whether an address exists. It validates the full email structure, including how MIME headers are folded and encoded—especially important for DKIM with relaxed alignment.

Many services stop at the domain level: “Does the domain have an MX? Is this address syntactically correct?” But that’s not enough. A valid address with misfolded headers can still fail DKIM verification when sent, especially under relaxed signing.

When DKIM uses c=relaxed, it allows some header changes during transit—like line breaks or whitespace tweaks—as long as the content remains identical. But if the original header was incorrectly folded using quoted-printable encoding, even small changes during transport can break the signature validation. This is common when mail servers or libraries handle headers improperly.

Why DKIM validation isn’t automatic

Most verification tools don’t attempt DKIM signature validation unless they know the sending domain and have access to the signing key. Since email address verification is often done without sending, that step is skipped.

DKIM checks require full email simulation, including signing and transmission logic. That means only services that test deliverability—like inbox placement tools—can validate the real-world behavior of DKIM. You can’t verify DKIM’s effectiveness by checking an address in isolation.

According to RFC 6376 (the DKIM spec), relaxed canonicalization is designed to be tolerant of formatting changes—but only if the original encoding follows strict rules. Quoted-printable line folding can break relaxed alignment if the folding point is incorrect or if the decoder misinterprets soft line breaks.

Even if you’re using a service that checks catch-all status and MX records, you’re still at risk of sending to addresses that appear valid but fail DKIM in production. That leads to bounces, spam filtering, or silent delivery loss.

For a deeper check, simulate how your emails actually render when sent. Test inbox placement with real headers and DKIM alignment to ensure your messages will pass not just syntax checks, but actual email server validation.

How MailTester detects QP line folding issues before they cost you deliverability

You can’t afford to learn about DKIM c=relaxed failures after sending thousands of emails. MailTester’s inbox-placement testing catches quoted-printable line folding issues—like mid-character breaks—before they trigger rejection. It parses your full MIME structure, ensures encoded content is folded correctly at line boundaries, and flags any issue that would break relaxed signature validation, even if the email address is perfectly valid.

Why QP line folding breaks DKIM c=relaxed

When a DKIM signature uses c=relaxed, the receiving server allows some flexibility in whitespace and line breaks. But this relaxation doesn’t extend to breaking quoted-printable encoding mid-character. If a long line is split in the middle of a =XX sequence, the decoder sees invalid data—resulting in a signature failure.

This isn’t a rare quirk. It’s a documented edge case in RFC 2045, which defines the quoted-printable encoding. The standard explicitly requires that encoded lines be broken only at boundary points, not within escape sequences. You might think it’s a minor detail, but it’s a common cause of DKIM failures that only surface in production.

How MailTester prevents delivery issues in practice

MailTester’s inbox-placement tester simulates real-world reception by parsing your complete email template—headers, body, and MIME structure—to validate how it will be processed. It checks for correct line folding in quoted-printable sections, especially in base64-like encoded parts of HTML or inline images.

Let’s say you’re sending a campaign with an HTML template embedded in a multipart message. If your email client or server accidentally breaks a =3D line in the middle (e.g., =3D at the end of a line, then D on the next), that’s a structural error. DKIM c=relaxed will fail, and the message may be rejected or sent to spam.

MailTester flags this instantly. You get a clear alert: "Quoted-printable line folding violation detected — likely to cause c=relaxed DKIM failure." This lets you fix the issue in your template before sending to real recipients.

You don’t need to wait for hard bounces or spam complaints. The tool acts as a real-time, pre-send validator for your email infrastructure. If you’re using a tool like SendGrid or Mailchimp, you can test the final deliverable version before sending via our inbox placement tester.

Unlike some checkers that only validate domains or syntax, MailTester goes deeper—validating how your entire message will be interpreted. This is especially critical for campaigns involving dynamic content or third-party templating systems where encoding glitches are easily introduced.

What happens when a DKIM c=relaxed signature fails due to folding?

When a DKIM signature with c=relaxed fails because of quoted-printable line folding issues, the receiving server may reject the message outright or assign it a lower reputation score. This failure can trigger spam filters to flag the email as potentially forged or poorly configured, even if the message is legitimate. As a result, valid emails may end up in bulk folders or be marked as spam—especially if such issues occur frequently.

How folding impacts DKIM verification

DKIM uses relaxed canonicalization to tolerate minor formatting changes in headers and bodies, but quoted-printable encoding with improper line folding can disrupt the expected structure during signature validation. When lines are broken incorrectly—especially within quoted-printable sections—the verifier cannot reconstruct the original content, causing the hash comparison to fail.

This often happens when mail systems insert line breaks at 76 characters without respecting the boundaries of quoted-printable encoded data. The result is a mismatch between the signed content and the content being verified, even if the actual message content is unchanged.

Consequences of repeated failures

Receiving servers treat repeated DKIM signature failures as a red flag. Even with correct domain alignment, a consistently invalid signature may lead to a drop in sender reputation. Some providers use this data to lower trust scores, increasing the likelihood of filtering.

According to reports from major email providers, messages with inconsistent or malformed DKIM signatures are more likely to be quarantined or pushed to spam folders, especially if other signals (like sending volume or engagement) are weak. The RFC 3986 defines how MIME-encoded content should be handled, and compliance is essential for reliable validation.

Let’s be clear: a broken DKIM isn’t just a technical bug—it’s a deliverability signal. Even one poorly folded message can trigger filtering behavior over time.

Use tools like MailTester’s email checker to validate individual addresses and catch signature-related issues before they impact your sending reputation. Regular testing of email infrastructure—including MIME content and header formatting—can prevent these problems from slipping through.

How your email delivery stack can silently introduce this problem

DKIM c=relaxed relaxed fails when long headers are split mid-encoding due to quoted-printable line folding that ignores character boundaries. Many email systems auto-wrap headers at 76 characters without checking if those breaks fall within encoded chunks, corrupting the signature’s hash. This often happens in legacy tools, misconfigured MTAs, or CMS-generated headers that insert line breaks in unexpected places.

SMTP and MTA chains don’t always respect QP encoding rules

Even when you use proper DKIM signing, your delivery stack might still break the signature. SMTP servers and older MTAs often apply line folding without considering the quoted-printable encoding rules defined in RFC 2045. A 78-character line might be folded at character 76, even if it cuts through a =XX encoded sequence—invalidating the DKIM signature.

Let’s say you have a header like Subject: =?utf-8?q?Meeting_notes_for_Tuesday?=. Inserting a line break after 76 characters might split the =q? or ? from the encoded content. When the receiving server reconstructs the header, the original hash no longer matches. DKIM validation fails — but not because the signature is wrong, just because it was signed on a different string.

CMS and dynamic content tools often worsen the issue

Content Management Systems that embed dynamic metadata into email headers—like campaign IDs or tracking tokens—can inject line breaks during rendering. Even if the full header is encoded correctly initially, a backend system processing it may reformat long lines for display or logging, introducing invalid breaks.

For example, a system generating a Reply-To header with a long tracking URL might apply automatic wrapping at 76 characters, unaware the content is MIME-encoded. The resulting output won’t match the original hash used in the DKIM signature.

While tools like MailTester’s email checker won’t catch DKIM alignment issues directly, they do verify if an address is valid and responsive—ensuring your messages reach the inbox in the first place. That’s a step toward reliable delivery, even if internal stack quirks remain.

The fix starts with ensuring your MTA, gateway, and rendering pipeline preserve quoted-printable boundaries. Check header normalization behavior across your stack. If you’re using tools like SendGrid, Amazon SES, or Mailchimp, confirm whether they apply header folding during delivery. Always validate your DKIM setup using tools that test both signing and receiving behavior.

Fix it now: The path to reliable DKIM authentication

DKIM c=relaxed relaxed fails due to strict parsing of QP-encoded headers, especially when line folding breaks the structure mid-sequence. This isn’t a flaw in the signature itself—it’s a parsing inconsistency triggered by malformed MIME output.

Even small errors in header encoding can cause validation to fail in production. The only way to catch them is to audit raw MIME output using a strict parser, ensure QP-encoded values don’t break mid-field, and test in real-world scenarios.

Proactive steps to prevent DKIM failures

Use a strict MIME parser to inspect every outgoing message’s raw payload.
Validate QP-encoded headers for mid-sequence line breaks—especially in From, Subject, and Content-Type.
Simulate real delivery conditions with inbox-placement testing that includes full MIME analysis.
Integrate MailTester’s real-time API during onboarding or list uploads to block malformed templates before sending.

Reliable DKIM isn’t about perfect alignment—it’s about catching the edge cases that break parsing in production.

Sources

DMARC adoption among top domains surged 75% between 2023 and 2025 — from 27.2% to 47.7% — in the wake of Google and Yahoo's bulk-sender authentication requirements. — EasyDMARC 2025 DMARC Adoption Report (2025)
Since May 5, 2025, Microsoft Outlook requires SPF, DKIM, and DMARC from domains sending 5,000+ emails per day, rejecting non-compliant mail outright at the SMTP level with error 550 5.7.515. — Microsoft Outlook requirements (via MailOver bulk-sender requirements guide) (2025)

Keep reading

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

What does DKIM c=relaxed mean?

c=relaxed is a canonicalization mode in DKIM that allows minor header normalization, such as ignoring whitespace variation, to reduce false fails from formatting differences.

Why does c=relaxed fail even when my DKIM is set up correctly?

Because c=relaxed only permits legal header normalization. If the message has incorrect line folding in quoted-printable encoded content, the hash no longer matches, causing validation to fail.

Can MailTester detect line folding issues in emails?

Yes. MailTester includes full MIME parsing in its inbox-placement tests to identify malformed headers, including QP line folding errors that break DKIM.

Does every email client handle QP line folding the same way?

No. Some enforce RFC-2047 strictly; others tolerate minor deviations. But a broken fold can still cause DKIM to fail on strict servers.

How many emails can I verify for free with MailTester?

You get 100 free verifications to start, with no expiration on purchased credits.

Can I test my email templates before sending?

Yes. MailTester’s inbox-placement tests simulate real sender environments to catch deliverability blockers like improper MIME structure.

What email platforms does MailTester integrate with?

MailTester integrates with Mailchimp, HubSpot, Klaviyo, and SendGrid to verify lists and test campaigns.

Is DKIM c=relaxed more forgiving than c=simple?

Yes, c=relaxed is designed to tolerate minor formatting changes, but it only works if the changes are legal. Illegal line folding still breaks the signature.

Why does my email pass address validation but fail DKIM?

Address validation confirms syntax and domain existence. DKIM validation checks message integrity and signature alignment. A valid address can still send a malformed message.

How does MailTester score its accuracy?

MailTester has a 98.9% accuracy rate across verified addresses and deliverability indicators.