Prevent DKIM Truncation in SMTP Settings

Why Does DKIM Signature Truncation Break Email Authentication?

You send a message. It passes every filter. Yet it lands in spam, or vanishes without a trace. Why? One hidden culprit: DKIM signature truncation.

DKIM isn’t just a technical detail—it’s the backbone of email authentication. It appends a cryptographic hash to your message’s headers, proving the sender is who they claim to be and that the content hasn’t been altered. When that signature gets cut off during SMTP transmission, the proof fails. The result? Rejection. Reputation damage. Deliverability loss.

Truncation doesn’t happen randomly. It’s often the side effect of SMTP server settings that impose arbitrary line length limits—especially when using outdated or misconfigured MTAs. The signature can exceed 78 characters per line, and if the server doesn’t handle folding correctly, the hash gets sliced. You might think the message is fine, but the receiving server sees only half the proof. That’s not a glitch. It’s a break in trust.

Key takeaways

DKIM signatures are cryptographic proofs that validate sender identity and message integrity.
SMTP server settings that enforce rigid line-length limits can truncate DKIM signatures during transmission.
Truncated signatures are invalid—receiving servers reject the message, leading to deliverability failure and reputational harm.

What SMTP Server Settings Actually Cause DKIM Signature Truncation?

SMTP servers that enforce a maximum line length of 998 characters can truncate DKIM signatures if they exceed this limit, especially when MTAs like Exim, Postfix, or Sendmail break lines in the header without preserving the DKIM signature block. This often happens when folding is applied improperly—inserting CRLF sequences in the middle of a DKIM signature—corrupting the hash and breaking authentication. The root issue isn’t DKIM itself, but how legacy or misconfigured MTAs process long headers.

Line Length Limits and SMTP Header Processing

Most SMTP servers follow the RFC 5321 rule that limits line length to 998 characters, including the CRLF. While this is meant to ensure compatibility across systems, it becomes problematic for DKIM-signed messages, where the signature can span several hundred characters. If this signature, when combined with the header fields, exceeds the limit, the MTA may insert line breaks mid-signature—especially during header normalization.

Let’s say your DKIM-Signature header has a value like v=1; a=rsa-sha256; d=example.com; s=selector; plus a long b= value. When the line is broken incorrectly—say, between ; and b=—the resulting digest no longer matches the one computed at send time, causing verification to fail. The receiver sees the signature as invalid, not due to a bad key, but because the signature was corrupted in transit.

MTAs That Break DKIM Signatures

MTAs such as Exim, Postfix, and older versions of Sendmail are known to apply line breaks without analyzing the structure of the header fields. They treat all headers like plain text and break lines at fixed points, ignoring syntax boundaries like those in DKIM. This is especially risky when using configuration options like smtpd_milter_limit or header_checks that alter header delivery without preserving integrity.

Some of these systems allow you to adjust the line length limit, but many don’t expose this in their configuration defaults. If you’re using a managed service, your provider may enforce line-breaking policies without transparency. Checking whether your MTA respects header structure is a critical step in preventing signature truncation.

“The DKIM signature must remain intact from the moment it’s generated to the moment it’s verified.” – Internet Draft: DKIM Specification

Proper validation and testing are essential. You can verify delivery readiness by simulating sending through real infrastructure. Tools like inbox placement testing can help you validate not just deliverability, but whether the full signature is preserved. If you’re sending bulk mail or managing sender reputation, catching these issues early avoids unnecessary bounces and inbox placement drops.

How to Fix DKIM Truncation: SMTP Server Configuration Checklist

If your DKIM signatures are getting truncated, it’s likely due to incorrect line-length handling in your MTA. To fix it, ensure your SMTP server allows at least 1000 characters per line, disables auto-folding of DKIM headers, preserves header order, and uses tools like milters that respect formatting boundaries. This avoids signature rejection and maintains email authenticity.

Core Configuration Steps

Set your MTA’s maximum line length to at least 1000 characters—many older MTAs default to 78 or 99, which breaks long DKIM headers.
Disable automatic line folding in your SMTP server unless absolutely needed for non-DKIM headers; DKIM signatures must remain intact across a single line.
Ensure that during MTA relay or TLS handshake, no intermediate system modifies the DKIM-Signature header by breaking it across lines.
Configure your server to preserve the original order of header fields and avoid reordering or reformatting lines with leading whitespace—small changes break DKIM validation.
Use consistent, well-tested DKIM signing agents or milters (like OpenDKIM or Mailgun’s milter) that are designed to respect and enforce line-length limits.

Validation and Monitoring

After adjusting your settings, test signature integrity using tools like MXToolbox’s Email Header Parser or RFC 6376, which defines DKIM’s signature format and line restrictions. These tools will flag truncated signatures or malformed headers.

Let’s be clear: even small formatting changes—like folding a line in the middle of a DKIM-Signature or trimming whitespace—can invalidate the entire signature. This isn’t a minor formatting issue—it breaks sender verification and harms deliverability.

Regularly verify your setup using a real-time email verification service. You can validate the structural integrity of your emails before sending. For example, MailTester’s email checker tests not just syntax but also how headers are processed during transit, helping catch issues early.

DKIM relies on byte-identical header content from signing to verification. Any change, even a newline, invalidates the signature.

The Role of SMTP in Preserving DKIM Integrity

SMTP must transport your email exactly as sent—headers, line endings, and all—because DKIM relies on cryptographic validation of the entire header field, including the signature itself. Even a single altered character due to improper line folding or CRLF insertion corrupts the signature, invalidating it. Use tools like MailTester’s email checker to catch malformed addresses or server configurations that risk this kind of breakage early.

How SMTP Line Handling Corrupts DKIM

DKIM signs a subset of email headers using a defined structure. If your SMTP server inserts line breaks where they don’t belong, especially within the DKIM-Signature header, it alters the signed canonicalized content. The receiving MTA recalculates the signature based on the actual received data. Any deviation—even a misplaced CRLF—causes a mismatch, resulting in authentication failure.

Many mail transfer agents (MTAs) automatically fold long headers at 78 characters by default, but this is dangerous if the fold occurs within a DKIM-signed field. The DKIM specification mandates that the DKIM-Signature header must remain intact, with no changes made after signing. Line folding that breaks this rule is not just a formatting issue—it’s a cryptographic failure.

Let’s be clear: the sender’s MTA doesn’t just “deliver” emails. It’s responsible for preserving the data’s integrity through delivery. If your MTA adds, removes, or changes whitespace inside DKIM-signed fields, the signature becomes invalid no matter how well it was generated. This isn’t a bug—it’s a design flaw in how some MTAs handle header transmission.

What You Can Do to Prevent It

Check your SMTP server settings to ensure it doesn’t apply default line folding to header fields containing DKIM signatures. Some MTAs offer a configuration option to disable auto-folding of specific fields (like DKIM-Signature), or to avoid inserting CRLF characters within signed content.

You can test if a particular mailbox is accepting signatures correctly by simulating a mail flow with real headers—use MailTester’s inbox placement tool to send a test message through actual recipient servers and verify whether the DKIM signature holds up end-to-end. It’s the only way to confirm that your SMTP transport stack isn’t silently corrupting cryptographic fields.

When setting up mailing infrastructure, always verify that your mail server or service respects header integrity. If you're using a third-party platform, ask whether it applies header-level transformations that could affect DKIM. The signature is only as strong as the transport chain that carries it.

How to Test for DKIM Truncation in Real-World Email Flows

Send real emails through your production MTA, pull the raw header from the recipient’s server using POP3 or IMAP, and validate the DKIM signature against your original version. Use a DKIM validator to catch shortened signatures, malformed Base64, or missing parameters—these indicate truncation during transit or due to MTA configuration.

Send an email via your production MTA with a full DKIM signature. Ensure the original message includes a complete, properly generated DKIM signature with all required fields. This establishes your baseline.
Retrieve the raw email from the recipient’s mail server using IMAP or POP3. Use a test account on the target domain (e.g., Gmail, Outlook) to fetch the message in full. This captures the version as it was received, not as it left your server.
Extract the DKIM-Signature header from the received email. Inspect the raw message to locate the DKIM-Signature header. It may appear multiple times if multiple MTAs signed it, but focus on the last one applied by your system.
Compare the received DKIM signature to the original sent version. Use a DKIM validation tool to check for discrepancies. Look for missing or truncated fields like sig (the signature value), b, or h. A signature that’s shorter than expected likely indicates truncation.
Check for structural or syntax issues in the signature. Validate that Base64-encoded values are correctly padded and within expected length ranges. A malformed Base64 string or a missing d= or s= parameter usually points to encoding or truncation errors during transmission.

The 5 steps described in “How to Test for DKIM Truncation in Real-World Email Flows”, in order.

Common Causes of DKIM Truncation in Practice

DKIM signatures can be cut short by MTA-level filtering, header size limits, or misconfigured content sanitization. For example, some MTAs impose maximum header lengths (often 78 characters per line, but more per RFC 2822), which can break long signature lines. Others strip headers they deem suspicious—especially when signatures span multiple lines with line breaks that aren’t properly preserved.

Additionally, some email security plugins or gateway services trim long headers without warning, especially in enterprise environments. Always test with real-world receivers—tools that simulate delivery internally miss these edge cases.

Tools and Methods to Detect Truncation

Use a DKIM validator like the one built into MailTester’s email checker to validate signatures in real-time. It checks not only for basic syntax but also for structural integrity, such as correct line wrapping and proper Base64 encoding.

For bulk validation, MailTester’s bulk verification can test multiple sender addresses with DKIM signature validation built in. This helps catch systematic issues across sender domains or configurations. While not every MTA will preserve every signature, you can use this to identify patterns in truncation across domains.

MailTester Can Help You Catch Truncation Before It Hurts Deliverability

You can prevent DKIM signature truncation by validating how your SMTP server settings handle header length during message transmission. Use MailTester’s inbox-placement testing to send real test messages to major providers and confirm DKIM signatures appear intact. A single missing byte in a signature breaks cryptographic validation, and testing with actual receivers catches issues that internal tools miss.

Test Real Delivery Scenarios Before You Send at Scale

Many DKIM issues emerge only after messages hit Gmail, Outlook, or Yahoo—providers that enforce strict header length rules. MailTester’s inbox-placement testing simulates this reality. You send test emails through your own infrastructure, and MailTester checks the received message for a valid DKIM signature. If the signature is missing or malformed, it’s a sign your SMTP server or MTA is trimming headers during delivery. This isn't something you’ll catch in an email preview or with a basic syntax checker.

Even if your DNS records are correct, some MTAs truncate headers when they get too long—especially with nested DKIM and multiple SPF/DMARC records. According to RFC 6376, DKIM signatures must be preserved in full to be valid. A partial signature leads to rejection or spam filtering. Test at scale to catch this before your marketing or transactional emails start being rejected or flagged.

Stop Issues Before They Reach Your Inbox

The real-time verification API acts early in your sending pipeline. It checks the full email structure—including headers—to flag malformed or suspicious fields that could trigger truncation at the receiving end. This gives you visibility before the first message is sent, helping you clean up your templates or header logic.

Use bulk verification to scan entire lists for domains where DKIM issues are common. If multiple addresses from a domain fail verification with a “DKIM signature missing” or “truncated” result, the problem is likely at the MTA or infrastructure layer, not with individual addresses. You can then work with the domain’s administrator or your email service provider to fix the root cause.

You don’t need to rely on post-delivery reports or guess what’s broken. MailTester helps you isolate and fix delivery failures at the source:

Test inbox placement across Gmail, Outlook, Yahoo to verify DKIM integrity in real-world conditions.
Integrate the real-time API into your sending workflow to catch header issues early.
Run bulk verification to spot systemic DKIM flaws across domains.

It’s not enough to generate a DKIM signature. It must survive transmission. Use tools that test what matters: actual delivery, real receivers, and complete header preservation. That’s the only way to ensure deliverability isn’t compromised by invisible truncation.

DKIM & SMTP: A Technical Overview of What’s in the Signed Header

You must configure SMTP server settings to preserve DKIM signature integrity by avoiding incorrect line folding—especially when the DKIM-Signature header exceeds 1000 characters due to multiple domains, long canonicalization paths, or multiple tags. If the server breaks the line mid-signature, even at a single character offset, the verifier rejects the signature. This isn’t a theoretical risk; the RFC 6376 standard explicitly defines header line length limits and folding rules, and misbehavior here is a common cause of DKIM failure.

The Signed Header Structure

DKIM signs a specific set of headers—like From, To, Subject, and Date—plus a hash of the message body. The resulting signature is stored in the DKIM-Signature header, which can grow long quickly, especially when multiple domains sign the same email or canonicalization paths are complex.

Because this header can exceed 1000 characters, proper line folding is essential. Each line must be limited to 78 characters, with continuation lines starting with a space or tab. Incorrect line breaks—especially in the middle of a base64 signature—render the signature invalid, even if the cryptographic hash is correct.

SMTP’s Role in Signature Integrity

SMTP servers are responsible for transmitting the full message, including properly folded headers. If a server breaks a line in the middle of a signature value, the verifier sees a malformed signature and fails verification. This often happens with poorly configured MTAs or older email relay software that doesn’t follow RFC 6376 strictness.

Common tools like MxToolbox or Spamhaus can help detect signature issues, but prevention starts at the sending infrastructure level. The RFC 6376 defines the canonicalization process, header selection, and folding rules in detail—deviating from them is a recipe for deliverability issues.

If you're troubleshooting DKIM failures, check the raw message headers in your post-send logs. Look for a DKIM-Signature line split mid-value. Tools like MailTester’s inbox placement testing can reveal such issues in real-world conditions by simulating inbound email checks across major providers.

Industry-Standard Practices for Preventing DKIM Signature Truncation

DKIM signature truncation happens when headers are modified during transit—especially during TLS encryption, transport layer transitions, or line folding. To prevent it, you must preserve raw header content exactly as signed, avoid folding cryptographic headers like DKIM-Signature, SPF, or DMARC, and apply canonicalization only after the full signature is generated. This ensures verification succeeds and your messages aren’t rejected or marked as forged.

Header Preservation in MTA Transitions

Ensure your MTA (Mail Transfer Agent) doesn’t alter or reformat headers during TLS encryption or relaying between servers.
Let encrypted transport layers pass headers unaltered—no rewriting, no re-encoding—especially for DKIM-Signature, Received, or Resent-* headers.
Test with tools like MxToolbox to inspect header integrity in real messages, especially across different mail routes.

Canonicalization and Line Folding

Never fold lines in headers that contain cryptographic values—DKIM-Signature, SPF, DMARC, or any header directly involved in authentication.
Use RFC 6376 as a guide: canonicalization (relaxed or simple) must be applied only after the signature is fully formed.
Some systems fold long DKIM headers during delivery; avoid this by ensuring your MTA or email provider disables automatic line folding for authentication headers.
Validate signatures in test environments using real-world email routing—some platforms auto-adjust headers during delivery that break DKIM verification.

Let’s be clear: DKIM’s integrity depends on perfect header fidelity. Even a single line break in a DKIM-Signature header can render it invalid. If you’re sending transactional or bulk email, catching invalid signatures early saves you from deliverability issues.

Use a service like MailTester’s email checker to validate individual addresses and ensure they’re not flagged as invalid, catch-all, or risky—conditions that often correlate with authentication failures.

Common Misconfigurations That Trigger Truncation (and How to Fix Them)

DKIM signatures can be truncated when SMTP servers or relay services modify message headers before signing, fold long lines improperly, or inject content filters that alter formatting. These changes break the cryptographic hash used in DKIM. The fix is simple: ensure your email flow preserves the original header structure through every step, especially before signing. Use tools like MailTester’s real-time verification to catch formatting issues early.

Third-Party Relays That Rewriting Headers

Using a third-party SMTP relay that rewrites or normalizes headers without preserving DKIM integrity can break signatures. These services often strip or reorder headers, invalidating the DKIM checksum.
Always verify that your email provider (e.g., SendGrid, Amazon SES, or a custom relay) respects signed headers and does not modify them post-signing.
Check your service's documentation for options like “preserve header order” or “skip header sanitization” — these are critical when DKIM is in use.
Use MailTester's email checker to validate if a recipient's domain has correctly configured DKIM before sending, and verify if your own setup is preserved through the relay.

Header Folding and Legacy MTAs

Older MTAs or poorly configured systems may apply automatic line folding (wrapping lines after 78 characters), which alters the header text and invalidates DKIM.
DKIM signs the exact text of the headers, so even a single added newline or space changes the hash. This often happens when headers are folded after DKIM signing.
Ensure your MTA does not perform line folding on headers that include DKIM-Signature or other sensitive fields. Line folding should be disabled or deferred until after signing.
Refer to RFC 5322, Section 2.1.1 for the correct handling of header length and folding; never assume the MTA knows better.
Test your full delivery path using MailTester’s inbox placement tool to see if DKIM fails in real inboxes.
Disable auto-folding in legacy MTAs unless you’re certain it doesn’t interfere with DKIM-protected headers.

Content Filters That Alter Headers Before Signing

Some content filters, spam scanners, or gateway appliances modify headers (e.g., adding X-headers, inserting tracking tags) before DKIM signing occurs — this breaks the signature.
These filters must run after DKIM signing if your message relies on authenticated headers.
Use MailTester’s API to validate that domains accept your messages without rejecting them due to malformed or signed headers.
Ensure filters are configured to avoid touching DKIM-Signature, From, To, Subject, or other critical headers until after signing is complete.

Verify Your Email Infrastructure Today with MailTester

Test your SMTP server settings against real-world inbox behavior using MailTester’s inbox-placement feature. It checks for DKIM signature truncation and other deliverability risks before you send to large lists. With 98.9% accuracy, it mirrors how providers like Gmail, Outlook, and Apple Mail actually process your emails — no guesswork.

Check for DKIM Truncation and Delivery Failures Before They Happen

You don’t need to wait for bounces or spam complaints to find out your SMTP settings are breaking DKIM. MailTester simulates real inbox delivery across major providers, catching signature truncation early. This happens when your server chops off large DKIM signatures due to overly strict limits, often triggered by misconfigured MTAs or oversized header data.

For example, RFC 6376 (the DKIM standard) allows for long signatures, but some servers truncate them at 4,096 characters or less. If your setup hits this limit, your email fails authentication — even if everything else is correct. MailTester flags these cases during inbox-placement tests, so you can adjust your MTA or header size before scaling sends.

Get Clear Guidance with the In-App AI Assistant

Seeing a "risky" or "catch-all" result? Let the in-app AI assistant explain what it means and suggest fixes. It parses technical responses from mail servers and translates them into actionable steps — like adjusting your SPF record, reducing header length, or checking your DKIM key size.

Whether you’re troubleshooting a sudden spike in bounces or optimizing for a newsletter rollout, the AI helps you act on the findings without needing an email infrastructure expert on staff. It’s like having a deliverability consultant in your toolset.

Start testing your SMTP server settings today. Bulk verify your list at MailTester’s bulk verification page. Or use the inbox-placement tester to see how your messages land in Gmail, Outlook, and Apple Mail. For developers, the real-time API integrates directly into your workflow. With 100 free verifications to begin and credits that never expire, there’s no risk in testing.

Final Take: Protect Your Domain’s Trust with Proper SMTP Setup

Digital trust starts with technical correctness. DKIM is not a compliance checkbox—it’s a foundational signal that your domain is trusted by receiving servers.

Truncation is a silent failure. No bounce, no alert. The message appears to send cleanly, but authentication fails—damaging sender reputation and lowering inbox placement.

Proper SMTP server settings prevent these failures. Validate them before sending. Use real-time testing to catch issues early, not after damage is done.

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)
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)

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 signature truncation?

DKIM signature truncation occurs when the cryptographic signature exceeds line-length limits during SMTP transmission, causing it to be cut off or corrupted, which breaks email authentication.

Can DKIM signatures be too long for SMTP?

Yes. DKIM signatures can exceed the standard 998-character line limit in SMTP, especially with multiple signing domains or complex header canonicalization.

What SMTP setting causes DKIM truncation?

The maximum line length setting in the MTA—even if set to 998—can truncate long DKIM headers if not adjusted to allow longer lines before folding.

How do I fix DKIM signature truncation in Postfix?

Adjust the 'max_line_length' parameter in Postfix configuration to at least 1000, and ensure DKIM-signed headers are not subject to automatic folding.

Does MIME encoding affect DKIM signature length?

Yes. Base64 encoding increases header length; long signatures with multiple tags can easily exceed line limits without proper server handling.

Can email verification tools detect DKIM truncation?

Yes—tools like MailTester can test inbox placement and verify whether signatures remain intact by comparing raw email content across providers.

How often should I test for DKIM issues?

Test every time you change your MTA configuration, adopt a new email service, or encounter sudden delivery drop-offs.

Is DKIM truncation a sender reputation issue?

Not directly—but repeated truncation leads to failed authentication, which damages sender reputation and triggers spam filtering.

Do all email providers check DKIM signatures?

Most major providers—including Gmail, Yahoo, Outlook—validate DKIM signatures to confirm sender legitimacy and message integrity.

Can I use MailTester to test DKIM signatures?

Yes. MailTester’s inbox-placement testing evaluates whether DKIM signatures remain intact across major email providers, identifying issues like truncation.

Does DKIM work without SPF and DMARC?

Yes—DKIM works independently, but combining it with SPF and DMARC improves overall authentication strength and inbox placement.

What happens if a DKIM signature is truncated?

The signature becomes invalid. Receiving servers reject the email or mark it as suspicious, especially if the sender has weak or no DMARC policy.