Fix Auth-Results Header Misalignment

What causes the Authentication-Results header field misaligned error in Postfix or Exim?

You’re troubleshooting a delivery failure, and the bounce message says: “Authentication-Results header field misaligned.” You’ve checked SPF, DKIM, and DMARC—but everything looks correct. What’s really wrong?

The issue isn’t with your DNS records. It’s with how the header is formatted. The Authentication-Results field must be a single logical line, even when wrapped visually after 78 characters. If the line break is applied incorrectly—without a proper soft break (CRLF + space)—the receiving mail server rejects it as malformed.

This error is common in Postfix and Exim when the mailer software applies folding inconsistently, or when an external MTA injects a header with poor formatting. The result? A failed authentication check, even if your digital signatures are solid.

Key takeaways

Authentication-Results must be a single logical line; splitting it with improper line breaks triggers a misalignment error.
Visually wrapped headers must use a soft line break (CRLF followed by a single space), not a hard break at any column.
Postfix and Exim are susceptible to this when header folding logic is inconsistent or when non-conformant MTAs inject malformed messages.

Why does this error harm email deliverability?

When the Authentication-Results header field is misaligned in Postfix or Exim, even correctly authenticated emails can be flagged or blocked by Gmail, Outlook, and Yahoo. These servers rely on precise formatting in the header to validate SPF, DKIM, and DMARC outcomes. If the parser finds inconsistent or malformed data, it treats the message as suspicious—regardless of whether the underlying authentication technically passed. A single error in the header structure can trigger automated filtering, especially when multiple checks are aggregated across multiple recipients.

How misaligned headers break validation pipelines

Modern inbound mail servers don’t just check if SPF or DKIM succeeded—they verify that the results are communicated consistently in the Authentication-Results header. If fields are out of order, missing, or improperly formatted, the server may reject the email outright or place it in the junk folder. This is especially true when multiple domains or authentication mechanisms are involved. The system sees inconsistencies as signs of spoofing or configuration errors, not just a typo.

Let’s say you’ve set up SPF and DKIM correctly, but your Postfix configuration adds the Auth-Results header in a non-standard way—say, with incorrect field ordering or missing tags. Even if the signature and IP check out, the receiving server may log a failure because it can’t parse the outcome. This is not a problem with your core authentication—it’s a problem with how the results are reported. And that’s enough to trigger a rejection.

As RFC 7675 (which defines the Authentication-Results header) notes, consistent and correct formatting is essential for interoperability. While the RFC doesn’t prescribe a single syntax, it does require that results be structured so they can be reliably parsed. Misaligned headers violate this principle, leading to unpredictable filtering behavior.

Some providers, like Spamhaus and MXToolbox, monitor header anomalies during email processing and can flag systems that deviate from expected patterns. Even without direct blocklisting, consistent header issues can hurt sender reputation over time.

What you can do—before it hits the inbox

Before sending bulk emails, test your authentication headers using a tool that simulates real-world delivery. You can verify how your server’s output is interpreted by major providers like Gmail or Outlook. Tools that check both the underlying authentication and the reported results help catch issues early. For example, try MailTester’s inbox placement test to see how your message behaves in a live environment—even as a single sender.

How do Postfix and Exim handle header folding by default?

Postfix strictly enforces 78-character line limits for headers, requiring soft line breaks (CRLF + space) when exceeded. Exim can auto-fold headers but may insert breaks mid-value if not configured to preserve header integrity, leading to misaligned Authentication-Results fields. Both servers follow RFC 5322, but only if your message construction layer respects the rules from the start.

Postfix: rigid but predictable folding

Postfix applies strict 78-character limits to header lines, as defined in RFC 5322. Any header exceeding this must be folded using a CRLF followed by a single space (a soft break), which is non-negotiable. This behavior is consistent and predictable — if you build your headers correctly, Postfix won’t deviate.

When you use tools like MailTester’s email checker to validate recipient addresses before sending, you’re already reducing the risk of formatting issues. Properly structured headers at the sending stage prevent Postfix from misprocessing them during delivery.

Exim: flexible but fragile by default

Exim includes automatic header folding logic, but it lacks consistent control over where breaks occur. Unlike Postfix, Exim can split a header mid-value — such as breaking within a quoted string or a domain name — unless explicitly configured to preserve content boundaries.

This can cause the Authentication-Results header to appear misaligned in logs or DMARC reports. For example, a break after spf=pass might render as spf=pass on one line and result=pass on the next, violating protocol expectations. You can enforce alignment using smtp_envelope_from_fold and other options in Exim’s configuration, but it requires deliberate setup.

As noted in RFC 5322, Section 2.1.1, line folding must preserve semantic meaning — you can’t split a field value where it breaks syntax. Misaligned authentication headers often stem from this break in logic, not the server itself. The root cause is usually flawed message construction, not server behavior.

Both Postfix and Exim are compliant with standards. But if your header folding isn’t intentional, you’ll see misalignment in post-delivery analysis. Always test headers using tools like MailTester’s inbox placement tester to simulate real-world delivery conditions and catch formatting flaws before they hit the inbox.

What’s the correct way to format the Authentication-Results header?

The Authentication-Results header must be a single logical line, even if split across physical lines. When breaking it, do so only after a space, using CRLF (Carriage Return Line Feed) to separate the segments. The entire header must remain contiguous in its logical form to ensure recipient systems like Postfix or Exim interpret it correctly. This is required by RFC 7601, which standardizes how authentication results are reported.

Why the line break location matters

Splitting the header at any other point breaks its structure. Some mail servers, like Postfix or Exim, reject or misparse headers if they aren’t split after a whitespace character. If you insert a break mid-word or directly after a semicolon without a space, you trigger a misalignment error — the receiving server sees it as invalid or malformed, even if the content is correct.

How to get it right in practice

Let’s say you’re generating the header manually or via a script. Always ensure the line continuation is preceded by a space and follows a full CRLF. For example: Authentication-Results: mx.example.com; spf=pass (sender=pass) smtp.mailfrom=example.com; dkim=pass header.d=example.com; dmarc=pass action=none Don’t break it like this: Authentication-Results: mx.example.com; spf=pass (sender=pass) smtp.mailfrom=example.com; dkim=pass header.d=example.com; dmarc=pass action=none This split fails because it doesn’t follow a space before the newline. A space before the line break is mandatory.

For systems that automatically generate these headers — especially in email infrastructure — double-check that your MTA (Mail Transfer Agent) or filtering layer handles line folding properly. Tools like MailTester’s email checker can help verify if an address is deliverable and whether authentication headers are likely to be accepted by major inboxes.

Ultimately, compliance with the line formatting rules in RFC 7601 is not optional. Misalignment can lead to SPF/DKIM/DMARC results being ignored or misinterpreted, directly impacting deliverability. It’s a small detail, but it matters — especially when you're debugging deliverability issues in Postfix or Exim environments.

For a deeper look at how real-world email validation impacts sender reputation, see the official specification and explore how authentication headers are used across the email ecosystem.

How to diagnose the issue in your logs?

You can diagnose an Authentication-Results header field misaligned error by inspecting raw email headers in your Postfix or Exim logs. Look for the Authentication-Results line splitting across non-contiguous lines without a proper soft break. A violation occurs when a line continuation follows directly after a line break (CRLF) without a space, breaking RFC 5322 syntax. Use tools like MxToolbox or raw server logs to catch this in real time.

Check your raw headers for misalignment

Access your mail server’s raw message logs, either via dmesg, maillog, or a dedicated log viewer like Rspamd or Exim’s debug logs.
Extract the full header section from a failing message and examine it line-by-line, focusing on the Authentication-Results field.
Look for situations where the header line splits across separate lines without a space immediately after the CRLF — e.g., CRLF followed directly by a letter like ...p=rsa-sha256; p=rsa-sha256 instead of CRLF space.
Verify that line breaks in multi-line header fields use a proper soft break: a CRLF followed by a single space. This is specified in RFC 5322, Section 2.2 — the standard for MIME and email formatting.

Confirm the root cause with real-world tools

Use MxToolbox’s Email Headers tool to paste raw headers and validate their structure. It highlights issues like improper continuation lines.
Check if your mail server’s content filters or milters inject the Authentication-Results header in a way that breaks the line format — a common issue when third-party services or scripts append data without respecting formatting rules.
If you're using a mail relay or sending through a third-party service, ensure they aren't injecting or modifying headers in a way that violates RFC 5322.
Test with a single verified email using MailTester’s email checker to validate whether the address itself is deliverable, reducing variables in your diagnosis.

Step-by-step: Fix the Authentication-Results misalignment in Exim

You’re seeing an Authentication-Results header misalignment in Exim when mail passes through multiple servers, usually because multiple agents are injecting or rewriting the header. This breaks SPF/DKIM/DMARC validation at the recipient side. The fix is simple: ensure only one agent sets the Authentication-Results header. Locate your outgoing transport, remove conflicting entries, and use header_remove Authentication-Results to prevent duplication during message transit. Confirm it’s not being reinjected downstream.

Step-by-step configuration fix

Access your Exim configuration file — typically /etc/exim4/exim.conf or exim.conf.template — with a text editor. You’ll need root access. This is the only place where you can control header injection behavior at the transport layer.
Find the transport section handling outbound mail — usually named smtp or smtp_smarthost. This section handles how messages are delivered to remote SMTP servers, and it’s where header manipulation occurs.
Add or verify the line: header_remove Authentication-Results in that transport block. This prevents Exim from adding a new header if one already exists. The RFC 7001 specification defines this header as a single authoritative result, not a chain of partial checks.
Double-check your configuration for any custom header injections, especially in ACLs or rewrite rules, which might re-add the header mid-transit. These conflicts are common in relay or filtering setups. A single source should define the final result.
Test the fix using exim -d -bh to simulate a message and inspect the full header construction. Watch how line folding and header presence behave — a misaligned or split header is a sign of improper handling. Use tools like MXToolbox Email Headers to validate parsing.

Verification and monitoring

After applying the fix, send a single test message to a verified inbox (like Gmail or Outlook). Check the received message’s full headers and confirm the Authentication-Results field appears only once and is correctly formatted.

If you’re managing high-volume outbound mail, use MailTester’s email checker to validate sender-side address hygiene and avoid sending to invalid or risky addresses that can trigger delivery anomalies.

Step-by-step: Fix the Authentication-Results misalignment in Postfix

Authentication-Results header misalignment in Postfix usually stems from header truncation or line folding errors during SMTP processing. Check your main.cf settings—especially header_size_limit (must be ≥1024, which is default but worth verifying). If using milters like rspamd or opendkim, ensure they don’t modify or split the Authentication-Results header. You can debug this by enabling smtpd_show_my_options = yes to see how the header is constructed step-by-step.

Review your Postfix configuration

Open your main.cf file and check for message_size_limit and header_size_limit. The default header_size_limit = 1024 is sufficient for most cases, but if your headers exceed this (e.g., with long DKIM signatures or multiple Auth-Results entries), misalignment occurs. If you’ve increased this value, ensure it’s consistent with your mail flow.
Look for any header modification rules—such as header_checks, smtpd_header_checks, or header_size_limit overrides. These can truncate or reformat headers unexpectedly. Remove or adjust any custom rules that might interfere with standard header alignment.
Ensure no content filter or milter alters the Authentication-Results field. Tools like Rspamd or OpenDKIM can split long headers if not configured properly. Check your filter logs for any signs of header manipulation.

Debug with tracing and real-world testing

Temporarily set smtpd_show_my_options = yes in main.cf. Restart Postfix and send a test message. Check the raw header output. The Authentication-Results line should appear as a continuous line, not folded mid-field. If it breaks unexpectedly, the problem is upstream in your pipeline.
If using opendkim, verify that signature insertion happens after all other header modifications and does not break line folding. Ensure Canonicalization = relaxed/simple and that you're not introducing line breaks where they aren't allowed.
Test the email with a tool like MailTester’s inbox placement tester to verify whether the header is delivered cleanly. It checks for header alignment and other deliverability red flags in real inboxes.

A single header line fold in the Authentication-Results field can cause DMARC failures. The RFC 5322 standard requires line continuation with a space as the first character in a new line—malformed folding breaks authentication.

How to prevent this issue in your email sending stack?

Keep your MTA (Postfix, Exim, or OpenMailSys) updated and standards-compliant, avoid injecting custom headers unless essential, validate all outbound headers using real-world testing tools like MailTester’s inbox placement test, and automate header scanning in your CI/CD pipeline for transactional or campaign emails. These steps directly address header field misalignment by ensuring compliance with RFC standards and consistency across delivery paths.

Use up-to-date, standards-compliant MTAs

Stick with widely-supported MTAs like Postfix or Exim and ensure you're running a version released in the last two years. Older versions may omit or mishandle required header fields, especially in response to newer authentication requirements.
Regularly audit your MTA configuration against RFC 5322 (Internet Message Format) and RFC 5321 (SMTP), which define the correct structure and handling of message headers, including authentication results.
Disable any experimental or non-standard header manipulation modules unless absolutely required for legacy systems.

Automate header validation and testing

Never assume your headers are correct based on internal logic alone. Use tools like MailTester’s inbox placement test to send a real message to known inbox providers and inspect how the Authentication-Results header is built and aligned across SPF, DKIM, and DMARC outcomes.
Integrate header validation into your CI/CD pipeline. Run automated checks on every email template or transactional send script to flag misaligned or missing authentication headers before deployment.
If you use custom header injection (e.g., via a middleware or app-layer script), test the full header chain with each sending instance. Even one malformed or improperly ordered Authentication-Results field can trigger rejection by receiving servers.
Avoid relying solely on local testing or sandbox tools that don’t simulate real-world delivery. Real email providers process headers differently, and discrepancies often appear only in production environments.

Even one incorrectly formatted authentication field can be enough to block deliverability, especially when DMARC policies are set to reject.

Can email-verification tools catch misaligned headers?

No — email-verification tools like MailTester do not inspect the structure or formatting of header fields like Authentication-Results for misalignment errors. They focus on whether an email address is valid, deliverable, and likely to reach the inbox. Misaligned headers are a server-side configuration issue, not a validity signal. However, when you test inbox placement, MailTester checks full headers as part of the diagnostic process.

What verification tools actually check

Tools like MailTester verify whether an address exists, whether it’s a role account or disposable, and if the domain’s SPF, DKIM, and DMARC records are properly set. These are direct signals of deliverability risk. They do not parse header syntax, such as whether the Authentication-Results header is misaligned or improperly formatted.

That said, you can’t fully diagnose inbox placement success without reviewing the full message structure. Misaligned headers can cause rejection by major providers—especially those enforcing RFC 5322 and RFC 7001 compliance—but this is beyond the scope of standard validation.

How inbox placement testing catches header issues

When you run a deliverability test using MailTester’s inbox placement feature, the system simulates sending a real message through major inbox providers. The full message, including headers, is received and analyzed. This includes checking for malformed or misaligned Authentication-Results headers, which are common when SPF/DKIM results are not properly aligned with the From domain.

If your message fails inbox placement, the report will call out header-level issues—including misaligned authentication results—alongside other red flags like poor content scoring or reputation signals. This is part of a holistic deliverability diagnosis, not a general address validation.

For example, a misaligned Authentication-Results header is often a sign of configuration error in Postfix or Exim. These servers must ensure that both SPF and DKIM results are aligned with the sender's domain. If not, the receiving server may treat the message as suspicious or spoofed. You can read more about these alignment requirements in RFC 7001.

While tools like MailTester won’t flag a misaligned header during a basic validation check, the inbox placement test does include that level of scrutiny. If you’re troubleshooting delivery problems, use this test to find the root cause—whether it’s a misconfigured server, a greylisted address, or a malformed header.

To test your full email’s inbox placement and receive real-time diagnostics, including header-level feedback, visit the inbox placement tester.

Best practices to avoid header misalignment across all mail servers

You can prevent Authentication-Results header errors in Postfix or Exim by using modern, RFC-compliant MTAs, avoiding manual line breaks in headers, validating raw message structure with trusted tools, and testing delivery with real receivers. Misalignment often stems from non-standard header formatting — not from authentication failures. The fix is consistent, documented adherence to email standards, not guesswork.

Use trusted, compliant MTAs

Always run mail servers like Postfix or Exim with the latest stable release. Outdated versions may not fully follow RFC 5322’s header formatting rules.
Verify your MTA’s compliance by checking its source code or changelogs for documented adherence to standards — especially around header line folding.
For mission-critical mail, use MTAs with active maintainers and transparent bug-tracking systems, like the official Postfix project or Exim’s public repositories.

Validate headers before sending

Never insert arbitrary line breaks in headers. Use only soft breaks (CRLF + space) where line wrapping is necessary.
Test raw message structure with tools like RFC 5322 readers or online validators such as MxToolbox’s header analyzer to catch misalignments early.
Use the MailTester email checker to validate individual addresses and ensure your messages are built correctly from the ground up.
Monitor your server logs for malformed headers or authentication discrepancies — they often appear before bounces or delivery failures.
Test delivery with real receivers. Internal processing won’t catch errors that only manifest in production. Tools like MailTester inbox placement tester simulate real-world delivery conditions.

Header misalignment isn’t a delivery failure — it’s a structural flaw. Fix the source, not the symptom.

Summary: Fixing the Authentication-Results misaligned error

The Authentication-Results header field misaligned error occurs when line folding in the header violates standard SMTP formatting, typically by breaking lines at invalid points or using incorrect delimiters.

Incorrect folding can lead to receiving servers misinterpreting authentication results, triggering false negatives in DMARC, SPF, and DKIM checks — even when authentication is valid.

How to fix it

Ensure all header lines use standard line folding: CRLF followed by a single space.
Use Postfix or Exim’s default header formatting rules, which are designed to comply with RFC 5322.
Validate header structure during message construction to prevent misalignment before sending.

Verify and monitor

After applying fixes, test with tools like MailTester’s inbox placement test to confirm headers are correctly formatted and authentication results are processed as intended.

Prevent recurrence by embedding header validation in your mail generation pipeline and monitoring server logs for non-compliant headers or delivery anomalies.

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 the Authentication-Results header field misaligned error mean?

It means the header was split across lines without a proper soft break (CRLF + space), violating RFC 5322, which can cause email rejection or spam filtering.

Can misaligned headers cause an email to be blocked?

Yes — even if authentication passes, a misaligned header can prompt automatic filtering or rejection, especially by strict receivers like Gmail or Microsoft.

How do I test if my email headers are properly formatted?

Use tools like MxToolbox or MailTester’s inbox placement test, which analyze raw headers and flag formatting issues like misaligned Authentication-Results.

Does DKIM signing cause Authentication-Results misalignment?

Not directly, but if the DKIM milter misforms the header during signing — such as inserting a line break mid-field — it can break the format.

Is this a common issue in Postfix and Exim?

Yes — especially when using third-party filters, milters, or custom transport configurations that don’t follow RFC line-folding rules.

Can email verification services fix header formatting?

No — email-verification services like MailTester verify address validity and mailbox behavior, not header structure. However, they can detect delivery failures linked to header issues.

What’s the difference between hard and soft line breaks in email headers?

A soft break (CRLF + space) allows continuation; a hard break (CRLF + letter) breaks syntax. Only soft breaks are allowed in headers.

Why do some mail servers ignore this error?

Some receivers tolerate minor syntax violations, but strict ones (Gmail, Microsoft) reject or flag messages with malformed Authentication-Results.

How often should I audit my email headers for misalignment?

At least once per major configuration change, and during periodic deliverability health checks on high-volume mail streams.

Can a catch-all address cause Authentication-Results misalignment?

No — catch-all addresses affect deliverability but not header formatting. Misalignment stems from the MTA’s construction of the message, not the recipient.

Does MailTester test for header misalignment?

Yes — its inbox placement test includes analysis of header structure, including Authentication-Results formatting, as part of deliverability diagnostics.

What’s the minimum header_size_limit I need in Postfix?

The default of 1024 characters is sufficient for most cases. Increase it only if you have unusually long authentication fields or custom headers.