Why does DKIM fail when your email uses quoted-printable encoding?

You send an email with clean formatting. DKIM signs it. But the recipient’s server rejects the signature. No error message. No clear reason. You’re left troubleshooting a silent failure — one rooted in how quoted-printable encoding and relaxed canonicalization interact.

DKIM relies on a deterministic process: both sender and receiver must canonicalize the email body and headers the same way. When quoted-printable encoding splits long lines using soft line breaks (CRLF), the choice of where to break matters. If your MTA or email service treats these breaks differently during canonicalization than the original sender did, the digest changes — and the signature fails.

This is where relaxed canonicalization is supposed to help. It ignores minor folding differences. But it breaks down when the underlying encoding — like quoted-printable — is mismatched or inconsistently applied. The signed content isn’t mathematically equivalent anymore, even if the visible text is unchanged.

Key takeaways

  • DKIM signatures can fail when quoted-printable line folding isn’t preserved identically across canonicalization steps.
  • Relaxed canonicalization tolerates minor folding differences but not encoding mismatches in quoted-printable.
  • Even if the email looks correct in the client, a canonicalization mismatch during DKIM verification will cause rejection.

What is relaxed canonicalization in DKIM, and how does it work?

Relaxed canonicalization in DKIM normalizes line breaks and whitespace during signature verification, ensuring messages with minor formatting changes—like different line endings or extra spaces—still pass validation. It strips trailing whitespace and collapses multiple line breaks into a single CRLF, reducing false fails from routine routing adjustments. This policy applies to both headers and body content, but it doesn’t fix issues from mismatched quoted-printable line folding, which can still break the signature if the folding boundary differs between signing and verification.

Why relaxed canonicalization exists

Without it, even small changes in how a message is formatted—such as a line break added by a mail relay—could invalidate the DKIM signature and cause the email to be rejected as forged. That’s why relaxed canonicalization is the default setting in most DKIM implementations. It reflects the reality that messages often pass through multiple systems that alter formatting, but the core content should remain trusted.

For example, a mail server might insert a CRLF after every 78 characters during transmission, while another system might group lines differently. Relaxed canonicalization ensures both versions pass verification by standardizing the format before cryptographic checks. This behavior is defined in RFC 6376, which outlines how DKIM signatures should be processed to tolerate non-critical differences.

Where relaxed canonicalization falls short

Despite its utility, relaxed canonicalization doesn’t solve every issue. When an email body uses quoted-printable encoding, the way line breaks are inserted matters. If the original signature was created with one line folding boundary and the verifier processes it with another, the decoded content will differ—even if the meaning is the same. This mismatch can cause a DKIM failure, even though the message content is identical.

This is a known challenge in email delivery systems. Some providers report that quoted-printable line folding mismatches contribute to 5–10% of otherwise valid DKIM failures in high-volume sending environments. The issue is especially visible when using third-party services, email clients, or legacy systems that don’t follow strict formatting rules.

You can test if your messages are vulnerable to such issues by verifying deliverability with real-world inbox testing. Tools like inbox placement testing help identify signature-related delivery problems before they impact your send rates.

How does quoted-printable line folding mismatch cause DKIM failure?

When an email uses quoted-printable encoding, each line must end with CRLF and be no longer than 76 characters. If the sender and verifier split lines at different positions—say, due to differing assumptions about line width—the encoded content differs. Since relaxed canonicalization works on raw transfer data and doesn’t re-parse or re-encode the body, these small folding differences change the body hash. Even with relaxed canonicalization, that mismatch breaks the DKIM signature.

Why relaxed canonicalization doesn’t fix this

Relaxed canonicalization is designed to handle whitespace and line-break normalization in the header and body, but it does not re-encode quoted-printable content. It only normalizes the existing structure—removing extra whitespace, standardizing line breaks—without touching the actual encoded bytes of the quoted-printable section.

This means that if the sender folds long lines at 76 characters and your verifier treats the body as a different length due to rendering or parsing assumptions, the resulting byte streams diverge. Even tiny changes in line splits alter the digest, which invalidates DKIM verification.

The role of line length in encoding

Quoted-printable encoding requires that no line exceed 76 characters. Lines longer than that must be split, using = at the end to indicate continuation. But the exact split point affects the encoded output. For example, “hello world” might be split differently in a 76-character margin vs. a 78-character one.

As defined in RFC 2045, the standard specifies the 76-character limit, but implementation details vary. Some systems assume strict 76-character width, while others allow flexible handling. This inconsistency shows up during DKIM signing and validation. The sender and recipient (or verifier) must agree on the exact line folding to preserve the body hash.

You can test for these mismatches by validating how your email infrastructure handles quoted-printable output. Many tools—including MailTester’s inbox placement tester—can simulate end-to-end delivery and help spot signature failures caused by encoding discrepancies before they reach customers.

Can relaxed canonicalization handle all quoted-printable line folding variations?

No. Relaxed canonicalization ignores line breaks and whitespace in the body, but it does not reprocess or standardize quoted-printable encoding. If the original message uses different line breaks than the delivered version—common when email clients or transport tools reformat the body during delivery—then the body hash changes, causing DKIM signature validation to fail. This mismatch happens because the hash is computed on the original encoded form; any change in line length or spacing breaks the signature.

Why encoding matters more than line breaks

Relaxed canonicalization only normalizes whitespace and line breaks. It does not re-encode or normalize the quoted-printable text itself. So if your email’s body was encoded with soft line breaks at character 76, and a relay or client rewraps it at 72 due to display constraints or transport rules, the encoded bytes change even if the visible content looks identical.

This is especially common when messages pass through multiple systems—like when a CRM exports a template, then a marketing platform reflows the content, and finally it lands in a user’s inbox. Even small changes in line length alter the quoted-printable byte stream, which invalidates the DKIM digest. The signature was signed on one version, but the verifier sees a different one.

How to prevent DKIM failures from encoding mismatches

Let’s be clear: relaxed canonicalization cannot protect you from incorrect quoting or inconsistent line folding during delivery. It only handles line breaks and spaces in a limited, fixed way. If the underlying content—especially quoted-printable encoded content—is not consistently formatted before signing, DKIM will fail regardless of the canonicalization setting.

Some tools, like SendGrid or Mailchimp, apply automatic reformatting to improve readability. If you're using such platforms and see DKIM issues after sending, check whether your message body was re-encoded on the way out. This is especially relevant when generating dynamic content where line breaks are not preserved.

For validation, use a real-time email checker like MailTester’s email checker to test deliverability and detect encoding-related red flags before sending. For bulk sends, verify your list with MailTester’s bulk verification to catch invalid, malformed, or suspicious addresses early. These tools detect issues like improper DKIM alignment and malformed headers, giving you insight before you hit inbox filters.

For deeper technical insight, refer to RFC 6376, Section 3.4, which defines how DKIM handles body canonicalization and explains why quoted-printable encoding must remain consistent for signature validation. IETF RFC 6376 remains the definitive guide on how DKIM should be implemented—and where it can fail.

What happens when DKIM fails due to this line folding mismatch?

When DKIM fails due to a relaxed canonicalization mismatch in quoted-printable line folding, the email is flagged as unverified in the header, often leading to rejection by major providers like Gmail and Outlook. Even a single failure can trigger spam filters, especially if your sender reputation is weak, and repeated failures gradually degrade your deliverability over time.

DKIM failure signals to gatekeepers

Reputable email receivers such as Google and Microsoft treat DKIM: FAIL as one of several signals in their spam scoring systems. While it’s rarely the sole reason for blocking, consistent failures—like the kind caused by improper line folding—can push an email into the spam folder or outright reject it.

Even if your other authentication (SPF, DMARC) is solid, a DKIM failure means your message lacks cryptographic proof of origin. Receivers use this to assess trust, and if you’re sending at scale, they expect consistency. A single mismatch in line folding during transmission can break the signature verification chain, especially when the canonicalization mode is relaxed.

Why this specific folding issue matters

Quoted-printable encoding allows line breaks for readability, but only within strict rules. Some mail servers or tools apply relaxed canonicalization, which ignores or normalizes folding differences. However, if the signing and verifying endpoints disagree on how to process line breaks—say, one treats a soft line break as invisible and another does not—the hash will differ, causing the signature to fail.

This issue isn’t about misconfiguring keys or domains; it’s about how content is reformatted during transit. The problem often shows up in automated systems, especially when sending bulk or transactional emails with rich content that relies on encoding. It’s common with tools that don’t preserve header and body structure exactly as intended.

Because DKIM verification is deterministic, even a small change in whitespace or line breaks can invalidate the signature. It’s not a flaw in the standard—RFC 6376 (the DKIM specification) defines both relaxed and simple canonicalization—but a common trap in implementation. The same email may pass on one system and fail on another if the folding is handled inconsistently.

To avoid this, validate your outbound email streams using tools that simulate real-world recipient checks. MailTester’s inbox placement tester checks deliverability across major inboxes, including Gmail and Outlook, helping you spot authentication failures before they impact campaigns. It also reveals if your DKIM setup holds under live conditions.

How do you detect relaxed canonicalization DKIM failures before they hit your deliverability?

You can catch relaxed canonicalization DKIM failures early by using real-time email-verification tools that simulate the full SMTP and DKIM validation process on actual recipient infrastructure — not just syntax checks. Tools like MailTester go beyond basic syntax and existence checks to validate message encoding and canonicalization behavior under real-world conditions, including how quoted-printable line folding interacts with relaxed DKIM signing. This prevents hard bounces and inbox placement issues caused by signature mismatches due to subtle formatting differences.

Simulating real delivery conditions

DKIM signatures break when the message body is altered during transit — especially during relaxed canonicalization, where line folding is normalized. The same body sent via different mail servers may be folded differently, and a mismatch between expected and actual folding results in a failed signature. This happens frequently with quoted-printable content, where line breaks are added after 76 characters, but some servers apply different logic. A tool that only checks syntax won’t catch this.

MailTester doesn’t just validate addresses — it runs the full validation stack. It checks whether an address responds to SMTP, whether it’s a catch-all or role account, and importantly, whether the DKIM signature would pass under relaxed canonicalization. It tests the message under realistic conditions, including how line folding during encoding affects signature verification.

API verification catches hidden failures

The MailTester API includes layered checks: SPF, DKIM, and DMARC verification, all applied with real-world behavior in mind. When you verify an address via the API, it simulates how the message would pass through multiple recipient systems — including how each step affects encoding, folding, and signature validation.

For instance, if a message uses quoted-printable encoding and is folded differently during transmission than expected by the DKIM signer, the signature will fail. MailTester detects this risk during verification and flags the address as “risky” or “invalid” if DKIM would likely fail. This prevents sending to addresses where your message, despite being technically sent, will be rejected or marked as spam.

For teams using automation, the MailTester API lets you integrate verification into your delivery pipeline, catching problems before a single message is sent. You can also use the inbox placement tester to see how your message lands in real inboxes across providers.

DKIM relaxation behavior is defined in RFC 6376, which outlines how header and body canonicalization work. The standard allows for differences in line folding during relaxed body canonicalization, but this creates real-world risks. The IETF’s specification acknowledges these edge cases — and tools that don’t account for them fail in production. RFC 6376 details the correct process, but real systems often diverge.

You can catch DKIM-related delivery failures before they happen. MailTester’s bulk verification scans your email list for high-risk patterns—especially inconsistent DKIM signatures and quoted-printable line folding mismatches—that break signature validation. It doesn’t just check syntax; it tests real SMTP delivery and validates how headers and body content are canonicalized during transport, identifying domains where small encoding differences silently break DKIM.

Real-world testing, not just rules

Many tools flag invalid addresses based on syntax alone, but DKIM failures often stem from subtle differences in how messages are encoded during transit. MailTester goes beyond syntax by simulating real delivery through actual SMTP connections. During the verification process, it checks whether the domain’s DKIM signature remains valid after the message is processed through the wire—this includes detecting when quoted-printable encoding causes line folding mismatches that invalidate the signature.

For example, if a DKIM signer uses quoted-printable encoding but folds lines at 76 characters, and the receiving server uses 78-character folding, the body canonicalization no longer matches the signed content. This causes a failure even when the email is otherwise correct. MailTester identifies these issues because it measures how the message is canonicalized at both ends, not just what it looks like in a static format.

It’s a silent issue many teams overlook. According to RFC 6376, DKIM canonicalization must be consistent across signing and verification. Even minor deviations break the signature. This is why MailTester doesn't guess—each email is tested under realistic conditions, with results broken into clear verdicts: valid, invalid, catch-all, or risky.

When “risky” isn’t just a warning—it’s a flag for delivery

When an address is flagged as risky, it means the system detected a known pattern that leads to DKIM validation failure. This includes domains with inconsistent DKIM records, known quoting issues, or those that use quoted-printable encoding without stable line folding rules. You don't have to guess—MailTester tells you exactly what’s wrong, and why.

You can test your list before sending, or integrate verification into your workflow using our real-time verification API. This keeps your sender reputation safe and ensures your emails reach inboxes. Whether you’re sending to 1,000 or 100,000 addresses, catching these edge cases early prevents bounces, reputational damage, and inbox placement drops.

For teams who send at scale, the insight from MailTester’s bulk verification helps avoid common pitfalls that third-party tools miss. It’s not about checking email format anymore—it’s about ensuring the message remains intact, verifiable, and trustworthy from send to receipt.

How to fix quoted-printable line folding in your email content

Use explicit line breaks at exactly 76 characters when encoding email content in quoted-printable. Never rely on rendering engines to break lines automatically. Ensure consistency across your email tools and test templates with real DKIM verification under relaxed canonicalization to prevent signature failures. Tools like MailTester’s inbox placement tester can help validate your full email flow.

Line folding is not optional — it’s required

  • Always split content lines at exactly 76 characters. This is mandated by RFC 2045, the standard for MIME encoding.
  • Do not let your email client or editor insert soft line breaks. These are not preserved in transport and break quoted-printable decoding.
  • Manually enforce line breaks after 76 characters, even if the content looks continuous in the editor.
  • Test your templates by exporting raw email content and verifying the line length matches — every line should be ≤76 characters.

Fix encoding consistency across your workflow

  • Use the same quoted-printable encoder across all templates, email builders, and senders. Inconsistencies cause signature validation failures.
  • Never mix auto-generated line breaks with manual ones. If you're using a mailer tool, check if it applies folding automatically — if yes, disable it or verify the output.
  • Validate templates before sending: any change in encoding can break DKIM signature verification, especially when relaxed canonicalization is used by the receiving server.
  • You can test how your content’s encoding affects deliverability by using MailTester’s inbox placement tester — it checks full email headers, content, and DKIM signing in real ISP environments.

What to do if your emails are failing DKIM due to encoding issues

If your emails are failing DKIM because of a relaxed canonicalization mismatch tied to quoted-printable line folding, you’re likely experiencing a decoding inconsistency between how your email was signed and how it’s being verified. This happens when your server folds long lines during transmission differently than the verifier expects—especially under relaxed canonicalization. The fix starts with ensuring consistent line-folding logic across your entire stack, from template rendering to SMTP delivery. Use inbox-testing tools to catch the failure before it hits real inboxes.

Check your entire email stack for inconsistent encoding

  • Review your email templates: Are they using hard-coded line breaks or relying on the rendering engine to fold lines? Even slight differences between how the template is processed and how it’s delivered can break DKIM.
  • Verify that your email service provider (ESP) and SMTP client apply the same line-folding rules. Some systems fold after 76 characters, others after 78. If one side folds early and the other doesn’t, the signature will fail.
  • Ensure that all content—headers, body, attachments—is processed through the same encoding pipeline. If one part is quoted-printable but another is plain UTF-8, the canonicalization steps will misalign.
  • Test with tools that mimic real-world email delivery, like MailTester’s inbox-placement tester, to simulate how your message appears end-to-end—including how folding affects DKIM verification.

Diagnose and correlate DKIM failures with line folding patterns

  • Check your email logs for "DKIM signature verification failed" errors. Look for patterns: do failures cluster in domains with high-volume or long-text content?
  • Extract failing messages in raw format and compare them to the original signed version. Manually inspect where line breaks occur. The most common misalignment is when one system folds at 76 characters and another at 78.
  • Use RFC 2045 Section 6.7 as a reference: quoted-printable encoding specifies that soft line breaks must not affect the message content, but relaxed canonicalization treats them as variable.
  • Apply consistent preprocessing: enforce line folding at 78 characters before signing, and ensure all systems downstream handle this same rule. If you're using a library like PHPMailer or SendGrid’s SMTP, audit its line-folding behavior in the source code or documentation.
DKIM fails not because of bad cryptography, but because of subtle differences in how the same message is interpreted across systems. The fix isn’t in signing more securely—it’s in processing the message identically every time.

How MailTester’s AI assistant helps diagnose DKIM issues

You can diagnose why a DKIM signature passes validation but still fails delivery due to relaxed canonicalization mismatches—especially those caused by quoted-printable line folding differences—by feeding raw headers into MailTester’s in-app AI assistant. It detects encoding inconsistencies between the signed body and the actual message body, even when the signature math checks out. This is especially critical because some servers apply relaxed canonicalization while others enforce strict folding rules, leading to silent delivery failures.

Spotting Hidden Body Encoding Mismatches

DKIM signatures depend on how the body is formatted before signing. If your email uses quoted-printable encoding with line breaks that don’t align with the canonicalized version, the signature appears valid—but the receiver’s server may reject it anyway. MailTester’s AI assistant parses the raw headers and body, identifying whether line folding behavior during encoding deviates from the canonical standard. It doesn’t just flag a failure; it tells you *why* the canonicalization failed—such as mismatched line breaks in a quoted-printable body.

Let’s say your mail system wraps lines at 76 characters, but the receiving server expects strict folding with a 78-character limit. The signature passes on paper, but the message won’t land in Gmail or Outlook. The AI assistant detects this mismatch by comparing actual delivery behavior across known mail servers and correlates it with real-world DKIM validation logs. This is based on industry-standard expectations outlined in RFC 6376, which defines how canonicalization must work across compliant implementations.

Actionable Fixes, Built for Real-World Use

Once the root cause is found, the assistant suggests specific fixes. It might recommend adjusting line-folding settings in your email client or ESP, switching to strict canonicalization, or ensuring body encoding matches the signing process. These aren’t theoretical suggestions—each recommendation is drawn from patterns observed in actual message delivery across domains like Gmail, Yahoo, and Microsoft.

You can test these changes in real time with the inbox placement tool at MailTester’s inbox placement tester, which simulates delivery across major providers. This includes checking DKIM results with and without the fix. Whether you're using SendGrid, Mailchimp, Klaviyo, or HubSpot, the assistant integrates with all four to validate authenticated messages before they go out—ensuring you don’t send a single message with a silent DKIM failure. You can catch and fix these issues early, without needing to parse logs manually.

Summary: Prevent DKIM failure from encoding mismatches

Relaxed canonicalization does not resolve issues caused by quoted-printable line folding mismatches. DKIM relies on bitwise identical content between signing and verification, and even minor differences in line breaks can invalidate the signature.

Body content is hashed before signing. If the line folding changes during transit or processing—due to different email clients, servers, or templates—the hash no longer matches, causing DKIM failure. This is especially common in emails using quoted-printable encoding.

Key steps to avoid failure

  • Use consistent line-folding rules in your email templates and delivery infrastructure.
  • Test your email content with real-time verification tools before sending.
  • Verify your templates using MailTester’s bulk and real-time API to catch encoding mismatches early.

Sources

Keep reading

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

Frequently asked questions

What is relaxed canonicalization in DKIM?

Relaxed canonicalization normalizes whitespace and line breaks in DKIM-signed emails to reduce false negatives. It does not re-encode or re-process quoted-printable body content.

Can quoted-printable line folding cause DKIM to fail?

Yes. If the line folding positions in the encoded body differ between signing and verification, the body hash changes, causing DKIM failure even with relaxed canonicalization.

Does relaxed canonicalization fix all DKIM failures?

No. It only handles whitespace and line breaks in headers and body, not differences in quoted-printable encoding line-splitting.

How can I test if my DKIM signature will fail in production?

Use MailTester’s inbox-placement testing or real-time verification API to check DKIM, SPF, and DMARC status before sending.

Are there tools that detect line folding issues in emails?

Yes — MailTester detects known encoding mismatches during verification by simulating full SMTP delivery and canonicalization behavior.

What is a 'risky' email verdict in MailTester?

A 'risky' verdict means the address may be valid but has a known risk, such as DKIM failure due to encoding inconsistencies or high bounce history.

How does MailTester’s AI assistant help with DKIM problems?

It analyzes email headers and content to identify canonicalization mismatches, including quoted-printable line folding issues, and suggests fixes.

Can MailTester verify DKIM on non-sending emails?

Yes — MailTester performs full SMTP verification, including DKIM and SPF checks, using live connections to target domains.

Do DKIM failures hurt sender reputation?

Yes. Repeated DKIM failures signal poor sending practices to major providers, which can reduce inbox placement or trigger filtering.

Does line folding affect all email formats?

No — it primarily impacts quoted-printable encoded content. Plain-text and base64-encoded content are less sensitive to line folding.

Is there a standard for quoted-printable line length?

Yes — RFC 2045 specifies 76 characters per line, including the =XX encoding sequence. Strict adherence prevents folding mismatches.

Can email service providers handle line folding automatically?

Many do, but not consistently. Some systems reformat during rendering. This leads to mismatched body hashes during DKIM validation.