Fix DKIM Canonicalization Failures

Why are large attachments breaking DKIM signatures in SMTP?

You sent a 20MB PDF to a client. The email arrived. But the DKIM signature failed. No bounce, no error message — just a silent rejection. Why? It’s not the recipient. It’s not your mail server. It’s the way DKIM canonicalizes your message — especially when attachments stretch beyond typical limits.

DKIM signs the email body and headers before sending, but the canonicalization process normalizes whitespace, line breaks, and folding. When large binary data like PDFs or ZIP files are Base64-encoded, even minor differences in line wrapping or whitespace during this step can alter the signed content. The result? The recipient's server verifies the signature and finds a mismatch — your message is rejected, not because it’s spam, but because the signature doesn’t match the received content.

This isn’t a flaw in your email client or SMTP library. It’s a systemic issue in how some MTAs apply strict line-length rules during canonicalization. If the encoded data exceeds 78 characters per line without proper folding, the signature becomes invalid — even if the actual payload is intact.

Key takeaways

DKIM canonicalization can corrupt large binary data if Base64-encoded content isn't properly line-folded during transmission.
Some MTAs enforce strict 78-character line-length rules during canonicalization, especially for text bodies and encoded attachments.
Even small differences in whitespace or line breaks between the signed content and the received content cause DKIM signature mismatches.

What is DKIM canonicalization and how does it affect large files?

You’re seeing DKIM canonicalization failures when sending large attachments because the signing process normalizes line breaks and whitespace in the message body—especially during base64 encoding. If the encoded lines exceed the standard 78-character limit, they get truncated or misaligned during canonicalization, breaking the signature. This happens especially with large files where base64 output spans long lines without proper folding, causing verification to fail even if the email content is correct.

How DKIM canonicalization works with message content

DKIM uses two canonicalization modes: relaxed and simple. Relaxed mode ignores minor whitespace variations in headers and body, while simple mode treats every space and line break exactly as sent. For large files, relaxed is more forgiving, but even it can fail if headers or body aren’t properly formatted.

During signing, the body is normalized by removing leading spaces and folding long lines. Base64 encoding of large files can produce lines much longer than the typical 78-character limit. If these lines aren’t properly folded with line breaks after 78 characters, the canonicalizer treats them as one long line, breaking the signature alignment.

Why large attachments trigger these failures

Attachments larger than a few megabytes often result in base64 sections that exceed 78 characters per line, especially if the MIME structure lacks proper line folding. This misalignment causes the body hash to differ from the one the receiving server computes, triggering a DKIM verification failure.

This issue is common in SMTP servers or email platforms that don’t enforce proper line folding during message construction. Even if your email renders fine, the DKIM signature can still fail because the canonicalized version doesn’t match the original. You can test this using inbox placement tools that validate both deliverability and authentication integrity.

Learn more about how email standards handle encoding from the official MIME specification (RFC 2045), which defines how content is structured and folded. For a practical way to catch such issues early, you can verify your sender setup with tools that analyze authentication and content structure during real-world delivery.

If you're sending attachments regularly, use a service that checks both the technical integrity of your email and its deliverability. Test your email in real inboxes to ensure DKIM signatures hold up under actual conditions—before you send to your list.

How to test if your DKIM setup breaks with large attachments

You can test if your DKIM setup fails with large attachments by sending a controlled email via SMTP with a binary file (like a 5MB PDF) and full DKIM signing, then examining the received headers for dkim=fail or invalid signature. Compare the raw message before sending to the one received to spot differences in line breaks or whitespace—especially in the body or encoded content—that might trigger canonicalization errors.

Test setup: Simulate real-world conditions

Generate a test email with a large binary attachment. Use a 5MB PDF or ZIP file. Ensure the email body contains plain text and is not just a binary blob. This mimics real sender behavior where large attachments are common.
Enable full DKIM signing on the message. Use your mail server or library (e.g., Postfix with dkim-filter, Exim, or a custom SMTP client) to sign the entire message with your domain’s DKIM selector and private key. Do not skip any parts.
Send the message via SMTP using a test recipient. Use a known working mailbox (like a test inbox or a shared domain) to receive the email. Avoid sending to public test servers—it’s hard to control delivery logs.
Examine the full received headers. Look for Authentication-Results lines. If you see dkim=fail or invalid signature, your canonicalization process is failing. Check if this happens only with large attachments.
Compare the original and received raw message. Use a hex or binary diff tool to spot changes in line endings, whitespace, or encoding in the body or MIME parts. Even small changes—like CRLF vs LF—can alter the canonicalized body and break DKIM.

What to prioritize in the diff

Focus on the body and any embedded binary sections. DKIM canonicalization treats LF as CRLF, but some systems normalize differently. If the attachment is base64-encoded, look for changes in line breaks within the encoded block. Even a single line break adjustment can invalidate the signature.

The 5 steps described in “Test setup: Simulate real-world conditions”, in order.

According to RFC 6376, the canonicalization algorithm specifies how body and header fields are normalized before signing. Deviations in line length, folding, or encoding can result in signature mismatches. This is especially common in mail delivery chains that process large payloads.

For real-world reproducibility, use a tool like Spamhaus' MailTester to test how your signed messages are interpreted in practice. You can also run an inbox-placement test to see if canonicalization failures affect delivery or lead to spam filtering.

Which DKIM canonicalization mode commonly fails with large files?

Relaxed canonicalization often fails with large attachments when the message body isn't properly line-wrapped during base64 encoding. Even small changes to whitespace or line breaks—common during SMTP transmission—break the signature if the canonicalized body doesn’t match the signed version exactly.

Why relaxed mode can still break

Relaxed canonicalization is designed to tolerate minor formatting differences, like extra spaces or line breaks in headers. But it still requires the body to be canonicalized exactly as it was when the signature was created. If you’re sending a large file, and the body undergoes even slight changes—like being re-wrapped during transport—the DKIM signature becomes invalid.

This usually happens during base64 encoding. Large attachments often result in long, unbroken lines of encoded data. Some mail servers or libraries will auto-wrap these lines to 76 characters, which alters the body content and breaks the canonicalization process. Even a single missing newline can invalidate the signature.

Simple mode: strict, but less forgiving of body changes

Simple canonicalization applies stricter rules. It requires a perfect match between the signed version of the message body and the one received at the recipient’s server. If any character—including a space or line break—is altered during transmission, the signature fails.

This makes simple mode more reliable for consistent environments, but it’s brittle. Any change, even one caused by mail server processing, can cause a failure. For large files, this means even minor formatting tweaks during SMTP delivery can invalidate the signature.

When sending large attachments, the most common failure isn’t the canonicalization mode itself—but the lack of consistent base64 line wrapping. The standard recommends wrapping encoded data at 76 characters, per RFC 2047. Tools that don’t follow this can produce signatures that fail verification, regardless of mode.

If you're seeing DKIM failures only with large messages, check that your encoder or library is respecting line breaks in the body. Use a tool like inbox placement testing to simulate delivery and catch signature issues before sending to real users. This helps avoid problems caused by subtle differences in how mail servers handle large content.

Common fixes for DKIM canonicalization errors with large attachments

DKIM canonicalization fails with large attachments when header or body content isn't processed exactly as the receiving MTA expects. Use relaxed canonicalization for both headers and body, ensure base64 encoding lines wrap at exactly 76 characters, preserve no extra whitespace after encoded content, and test with tools mimicking real-world delivery conditions like greylisting and MTA rewriting. These steps align your email with SMTP and RFC standards.

Relaxed canonicalization is essential for attachment-heavy messages

Configure DKIM to use relaxed canonicalization for both headers and body—not just headers. Some MTAs rewrite or normalize whitespace in the body during transit, so strict canonicalization will fail even if your message is otherwise valid.
Large attachments often trigger body canonicalization issues because the encoded data may be altered by intermediate MTAs. Using relaxed body canonicalization reduces the chance of signature mismatch due to formatting changes.
Test your DKIM signature against real-world handling by simulating SMTP delivery with tools that include greylisting and MTA rewriting behavior.

Strict base64 formatting rules apply to large encoded payloads

Base64 encoded data must be line-wrapped every exactly 76 characters, never 77 or 78. RFC 2045 (https://datatracker.ietf.org/doc/html/rfc2045) specifies this limit explicitly for MIME content. Any deviation breaks canonicalization.
Do not add spaces, blank lines, or extra CR/LF characters after the encoded body content. Even one extra character can cause DKIM verification to fail, especially with relaxed body canonicalization.
Use a reliable MIME library or email client that respects line-length limits and avoids implicit formatting. Manual encoding increases the risk of errors.
Verify your message structure before sending using a tool that tests against real-world recipient behavior—like inbox placement tests that simulate actual email infrastructure.

“DKIM signature validation fails not because the key is wrong, but because the canonicalized content doesn’t match what was signed.” – RFC 6376: DomainKeys Identified Mail (DKIM) Signatures

Before sending large attachments at scale, test your DKIM configuration with a service that simulates real recipient handling, including greylisting and MTA processing. You can check deliverability and inbox placement with MailTester’s inbox placement tool, which validates the full email path from sender to inbox.

How to verify DKIM signing correctness across real mail servers

You can confirm DKIM signing works correctly with large attachments by sending real test emails through an SMTP server, capturing full headers, and validating the signature against multiple email providers using tools like MailTester’s inbox placement tester. This ensures your message clears authentication checks in actual inboxes, not just lab environments.

Send test emails with large attachments via your SMTP server. Use a production-equivalent setup to trigger real-world handling of message body and header normalization. Large files often trigger canonicalization differences between servers, so testing in this context is essential. You’ll need the full email headers from the delivered message, including the original raw headers recorded at delivery.
Extract and preserve the full message headers. Most mail servers include received headers and the original envelope data. Use tools like RFC 5322 standards to confirm the message format adheres to expected syntax. The headers must include all DKIM-Signature fields exactly as they appear in the final delivered message.
Use MailTester’s inbox placement testing to check delivery across providers. Send your test message through MailTester’s inbox testing tool to see how Gmail, Outlook, and Yahoo handle it. This shows whether DKIM passes, whether the message is flagged as suspicious, or if it’s dropped due to canonicalization issues. MailTester checks delivery in real inboxes, not just test environments.
Verify DKIM signature consistency on major platforms. Paste your full header into tools like MXToolbox or MailTester’s header analyzer to check if the signature validates on each provider. Differences in how Gmail and Outlook parse line breaks or whitespace can break DKIM if you’re not handling canonicalization correctly.
Check alignment with SPF and DMARC. DKIM is only effective if it aligns with the From domain. Use DNS tools to verify your SPF and DMARC records are properly set. Misalignment between DKIM, SPF, and the reported From domain can cause rejection even if signature validation passes.

Common pitfalls to watch for

Canonicalization issues often arise when the mail server normalizes line endings or whitespace in a way that contradicts the DKIM signature’s assumptions. For example, some servers change CR-LF to LF, or collapse multiple spaces. Your signing process must match the final message format exactly.

Large attachments can trigger content filtering or MIME reformatting during transit. Some providers re-encode or restructure the body, which invalidates the DKIM signature if unsigned content changes. Always test with content that mirrors your production load.

Why email verification tools like MailTester are essential here

You can’t fix a DKIM canonicalization failure in large attachments without knowing it exists first. MailTester detects these issues early by testing real server behavior—checking if destination mail servers accept large messages, verifying DKIM validity under realistic conditions, and flagging canonicalization problems before you send at scale. This prevents bounces, spam traps, and wasted bandwidth.

Real-world testing beats theory

DKIM canonicalization failures often emerge only when sending large attachments via SMTP—especially with non-standard header formatting. Many tools only test syntax, not real server response. MailTester’s inbox placement test sends a realistic message with a large attachment and checks how the receiving server handles it, including header normalization during DKIM validation. It returns a pass/fail result with a full breakdown of headers, so you know exactly where the failure occurs.

Let’s say your list includes 10,000 addresses. Sending to all of them without validation risks hard bounces, sender reputation damage, and possible blocklisting. MailTester lets you run bulk verification on your full list, identifying addresses with weak or broken DKIM, catch-all setups, or known delivery barriers. You learn which domains reject large payloads, which need header adjustments, and which are outright invalid. This prevents you from sending emails that fail to deliver—or worse, get flagged as spam.

How it fits into your workflow

Integrate MailTester into your email campaign pipeline with a simple API call or use the bulk verification tool to scan entire lists. You’ll get a clear report: valid, invalid, catch-all, risky, or DKIM-failed. The API also returns detailed feedback, so developers know if a failure stems from header whitespace, encoding, or signature mismatch—directly tied to canonicalization.

Tools like this are non-negotiable when sending to enterprise or government domains. These often enforce strict DKIM requirements and are sensitive to header inconsistencies. The RFC 6376 specification outlines DKIM canonicalization rules, but implementation varies across mail servers. Testing across real infrastructure is the only reliable way to verify compliance—something no internal test can replicate.

You’re not just checking if an email exists. You’re checking if it gets delivered, validated, and received—especially when you’re sending a 50MB PDF or a video attachment. MailTester gives you that validation, so you can fix problems before they hurt your deliverability. Use the inbox placement tester to simulate real-world delivery, and adjust your headers or attachments before sending.

What happens if you ignore DKIM canonicalization issues with large attachments?

If you ignore DKIM canonicalization failures when sending large attachments via SMTP, your emails may be silently rejected with hard bounces, flagged as spam by recipient filters, or throttled due to authentication spikes. These issues degrade sender reputation over time, leading to broader delivery failures across all future sends—even for valid messages—because ISPs correlate authentication problems with spammy behavior. You don't get a warning; the failure happens silently, and the damage compounds.

Why silent failures hurt more than obvious ones

When DKIM canonicalization fails due to large attachments, the signature doesn't match the received message body. Most receiving servers won’t send a detailed bounce message; they just drop the email outright or mark it as spam. This is especially common with large files that trigger MIME encoding or line-length changes during transit, which DKIM's canonicalization process must handle correctly.

Receiving servers like Gmail, Outlook, and Yahoo rely heavily on DKIM as a signal of sender legitimacy. If your domain shows repeated authentication failures, even on messages with large attachments that technically arrive, your sender IP and domain can be flagged as high-risk. This often leads to increased spam placement, delayed delivery, or outright blocking—especially if the issue happens across multiple messages in a short time.

The long-term cost of ignored issues

Repeated DKIM failures create a reputation debt. Major email providers track authentication failure rates as part of their reputation scoring models. For example, tools like the Spamhaus PBL or MXToolbox can show if your domain is on a blacklist due to poor authentication practices, even if the sender wasn’t intentionally malicious.

Some providers use rate-limiting or threshold-based blocking when they see repeated authentication drops from a single IP. Once this threshold is crossed, your server might be throttled or blocked entirely—sometimes for days. Recovery is slow and often requires full re-authentication audits and coordination with your email service provider.

DKIM canonicalization issues are rarely visible to the end user, making them easy to miss. But they’re not harmless. They’re one of the stealthier reasons for delivery failure, especially when large file attachments are involved. If you’re sending marketing emails, transactional messages, or file-heavy updates, validating your DKIM configuration with real-world testing is essential. Tools like MailTester’s inbox placement test can simulate real recipient behavior and reveal whether your messages pass authentication with large attachments intact.

How to verify DKIM signature integrity post-send

You can verify DKIM signature integrity after sending by checking the raw message headers and body against your original, using tools that simulate how mail servers validate signatures. Run your message through MailTester’s verify endpoint to catch canonicalization errors caused by large attachments, especially if the body has been altered during transport or processing.

Test signature validity using real-world validation

Send a test message with a large attachment and extract the full raw message — including headers and body — from your mail server or mailbox provider. DKIM signing is applied to specific parts of the message, so exact reproduction matters.
Use MailTester’s verification API to validate the DKIM configuration — send the raw message to our API endpoint to check if your signing key, selector, domain, and DNS records are correctly published and matched during validation.
Confirm the DKIM record syntax is complete and correct — check that the DNS TXT record includes all required fields: v=DKIM1;, k=rsa;, p=..., and crucially, a properly formatted b= field with a base64-encoded signature of the correct length and structure. Missing or malformed fields cause immediate failure.
Compare the signed body to the original before sending — even minor changes like line breaks, whitespace, or header normalization (common when relaying large MIME bodies) can break canonicalization. Use tools like the DKIM standard’s canonicalization rules to test how the body should be processed before signing.
Reproduce the issue locally using a debugging tool — if your message fails DKIM check after sending, try sending the same message via another SMTP service or tool that preserves raw formatting. This helps isolate whether the failure is due to your server’s processing or your signature’s content.

Common causes of canonicalization failure

Large attachments can trigger canonicalization issues if the message body is reordered, line-wrapped, or re-encoded during transit. Some servers normalize whitespace or apply different MIME parsing rules — even a single space or line feed added during relay can invalidate the signature.

Always ensure your signing process applies the same canonicalization algorithm (relaxed or simple) used by receiving servers. The DKIM specification defines how headers and body content should be normalized before signing. If your system alters content during processing, you’re at risk of signing a different body than what’s received.

Let’s be clear: a DKIM failure isn’t always your DNS record’s fault. The signature may be well-formed, but the message body differs from what was signed. Using inbox placement testing helps confirm whether delivery and validation pass at the receiving end.

Best practices for handling large attachments in secure email delivery

DKIM canonicalization failures with large attachments often stem from improper header/body normalization during signing. Compress large files, avoid inline embedding, and test your full message structure with tools that simulate real SMTP delivery. Always verify DKIM alignment and sender reputation before sending at scale.

File handling: Reduce risk at the source

Prefer ZIP or TAR.GZ over uncompressed formats like .DOCX or .PDF to reduce encoding inconsistencies during DKIM signing.
Never embed files larger than 10MB directly in the body—use secure, time-limited links hosted on trusted infrastructure (e.g., AWS S3 with signed URLs).
Validate that your email client or MTA preserves whitespace and line endings—this is critical for DKIM header canonicalization.

Testing and verification: Prove it works before you send

Use tools that test full message delivery end-to-end—including SMTP handshake, DKIM signing, and inbox placement. RFC 6376 defines the DKIM standard; refer to it for implementation clarity RFC 6376.
Test your DKIM signature with real-world validators like MXToolbox DKIM Lookup or Mail-Tester to catch canonicalization issues early.
Preemptively check sender reputation and domain health with MailTester’s bulk verification to catch issues that could block large attachments even if the signature is correct.
Use MailTester’s inbox placement testing to validate if messages with attachments actually reach inboxes—not just spam folders.

DKIM canonicalization is not just about signing—it’s about matching the exact structure a receiving server expects. A newline, a missing header, or a poorly encoded attachment can break the chain.

Let’s be clear: you can’t rely on a single email client to simulate a real delivery. Always test under conditions that mirror actual SMTP behavior, with real domains, real headers, and real attachments. If you're sending large files at scale, automation is not optional. Use the verification API to check every address in your list before sending—and detect risky or catch-all domains that may silently reject your messages.

Even if your DKIM passes in theory, a broken sender reputation or misconfigured MTA can still prevent delivery. That’s why you need to test the whole stack—from DNS records to the final inbox check.

Fixing DKIM canonicalization failure is not optional—here’s how to do it right

Large attachments strain email authentication systems, exposing flaws in DKIM signing and canonicalization that can break deliverability. Ignoring these issues leads to bounces, spam filtering, and reputational damage.

Real-time verification and inbox placement testing catch these failures before they impact your audience. They expose problems in header and body canonicalization that standard checks miss, especially under load.

With accurate tools like MailTester, you can detect and resolve DKIM failures early—before they degrade your sender reputation or disrupt mass sends. Authentication isn’t a one-time setup; it’s a continuous check for edge cases like large files.

Sources

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)
A new large language model deployed in Gmail's defenses blocks 20% more spam than before and reviews 1,000 times more user-reported spam every day. — Google (The Keyword blog) (2024)

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 DKIM canonicalization failure?

It occurs when the email’s body or header is altered during transmission in a way that breaks the DKIM signature, even though the content is unchanged. This commonly happens with large attachments due to improper line wrapping.

Why do large attachments trigger DKIM errors more often?

Large attachments encoded in base64 often exceed default line length limits. If not wrapped properly (e.g., every 76 characters), canonicalization processes may alter the message in ways that invalidate the signature.

Can I use simple canonicalization with large files?

Simple canonicalization is strict and sensitive to whitespace. It increases the risk of failure with large, encoded content. Relaxed mode is more resilient and recommended in practice.

How do I know if my DKIM signature is failing due to canonicalization?

Check the received headers for 'dkim=fail' or 'Authentication-Results' with 'invalid signature'. Compare the original and received message body to find unexpected line breaks or truncations.

Can email verification tools detect DKIM canonicalization issues?

Yes—tools like MailTester simulate real inbox behavior, including DKIM validation, and return detailed reports showing whether the signature passes or fails across recipients.

Does base64 encoding affect DKIM canonicalization?

Yes. Base64 must be line-wrapped every 76 characters. If you use 78 or break lines inconsistently, canonicalization can interpret the body differently, causing a signature mismatch.

What’s the best way to test large attachment delivery?

Send test messages with real attachments via your production SMTP, then use inbox placement tools to verify DKIM results, header integrity, and delivery to major providers.

How does sender reputation relate to DKIM canonicalization issues?

Repeated DKIM failures trigger spam filters. If multiple emails fail authentication, the sender’s IP or domain may be blacklisted, affecting all future campaigns.

Can I fix canonicalization issues with email headers?

No. The issue lies in how the body is formatted and encoded. Fixing headers won’t resolve signature mismatches caused by incorrect line breaks in the attachment data.

Is there a tool to validate DKIM signatures across multiple providers?

Yes—MailTester’s inbox placement testing sends emails through multiple real provider inboxes and returns full header analysis, including DKIM validity and canonicalization results.

Do all mail servers interpret DKIM canonicalization the same way?

No. Some servers are stricter than others. A message that passes on Gmail may fail on Outlook or Yahoo due to differences in canonicalization enforcement.

What should I do if my DKIM signature shows as invalid after sending?

Check for line break issues in the base64 body. Re-send using proper 76-character line wrapping and verify with a real-time testing tool to confirm the fix.