DKIM Non-RFC Compliant Header Fix

What Does 550 5.7.1 Mean When Your Email Gets Rejected?

You sent an email. It wasn’t spam. It wasn’t blocked by a filter. Yet it got rejected with a 550 5.7.1 error — specifically, “DKIM non-RFC compliant header.” And now your deliverability is broken. You’re not alone. This is a silent killer of outbound email, especially for automated systems.

This error means the receiving server didn’t just doubt your message — it rejected it outright because your DKIM signature header violates RFC 6376, the official standard for how DKIM signatures must be structured. It’s not about content, sender reputation, or spam filters. It’s a technical misalignment at the protocol level. If your DKIM header is malformed, the email is treated as forged — even if it isn’t.

The fix isn’t about tweaking your subject line or warm-up strategy. It’s about ensuring your email infrastructure strictly follows RFC 6376. The most common issue? Headers that aren’t formatted correctly — missing or misordered fields, improper encoding, duplicate headers, or whitespace violations.

Key takeaways

550 5.7.1 rejection means your DKIM header violates RFC 6376, not spam rules.
The most common cause is a DKIM signature header with improper formatting, such as incorrect field order or encoding.
Even valid DKIM signatures fail if they don’t adhere to the exact structure defined in RFC 6376.

Why Is My DKIM Header Non-RFC Compliant?

DKIM signatures must follow precise formatting rules from RFC 6376: header fields must appear in a strict order (h=, b=, d=, etc.), field names must be exact, and line folding must use a single CRLF followed by a space or tab. Even minor deviations—like placing 'b=' before 'h=' or using inconsistent line breaks—trigger rejection by strict validators, leading to 550 5.7.1 errors. Many tools generate signatures that pass basic checks but fail strict RFC validation due to these subtle issues.

What Makes a DKIM Header Non-RFC Compliant?

Let’s break down the key requirements. The DKIM-Signature header must list fields in this order: 'v=', 'a=', 'c=', 'd=', 'h=', 's=', 'bh=', 'b='. Any deviation—like inserting 'b=' early or reordering 'h=' after 'b='—invalidates the signature. The specification is strict: even if the algorithm and cryptographic data are correct, wrong field order breaks the signature.

Line folding also matters. Each line must end with CRLF (not just LF), and continuation lines must start with exactly one space or tab after the newline. Some email SDKs or SMTP libraries fold lines incorrectly, inserting multiple spaces or failing to insert any, which triggers non-compliance.

Missing or malformed required fields are another common cause. If 'h=' doesn’t list all headers used in the signature, or if 'b=' contains invalid base64, the verifier will reject the email regardless of the signing key’s validity.

Why Do Some Systems Pass Basic Checks but Fail Strict Validation?

Many email systems, especially older or third-party libraries, perform only minimal DKIM validation—checking the signature length, base64 format, and basic field presence. They may not verify field order or line folding rules. This creates a false sense of compliance, but modern systems like Microsoft’s Exchange or Gmail’s mail servers enforce full RFC 6376 compliance.

This is why you might see your email reject with "550 5.7.1" even if it sent successfully through other platforms. The error isn't about the domain or keys—it’s about the structure. Tools built for simplicity often prioritize speed over strict adherence to specs.

If you're debugging this, check your mail server’s DKIM signing logs or use a tool like MXToolbox DKIM Validator to test your signature. For real-time checks, use MailTester’s email checker to validate the underlying headers and structure before sending.

How Do I Check If My DKIM Header Is RFC-Compliant?

You can verify if your DKIM header is RFC-compliant by analyzing the full headers of a signed email using a tool that validates against RFC 6376. Look for syntax issues like misplaced fields, extra whitespace, incorrect delimiters, or malformed base64 encoding. Tools like MxToolbox’s DKIM Record Checker or raw email analyzers help catch these errors before they trigger a 550 5.7.1 rejection.

Step-by-step validation process

Extract the full email headers from a message sent from your domain. You can do this via your email client’s “Original Message” or “View Raw” option. These headers contain the DKIM-Signature field you need to inspect.
Paste the raw headers into a validator that checks RFC 6376 compliance. Tools like MxToolbox’s DKIM Record Checker or specialized email header analyzers will parse the DKIM-Signature field and report syntax issues such as unescaped characters, incorrect field ordering, or invalid base64 padding.
Check field order and delimiters. DKIM requires fields to be in a specific order: h=, d=, s=, and b=—in that sequence. Any deviation breaks RFC compliance. Fields must be separated with ; and must not include trailing spaces.
Validate base64 encoding. The signature value (b=) must be properly base64-encoded. Extra padding or embedded line breaks will cause the validation to fail. Tools can flag non-standard encoding or incorrect padding (e.g., missing one or two = signs).
Review header field names. Field names like dkim-signature must be lowercase. Uppercase letters or mixed case can lead to validation errors, even if the rest of the signature is correct.

Common issues and how to fix them

Even small deviations break the signature. A common mistake is including extra spaces before or after field values. Another frequent error is misencoding the h= field, where header names are not properly lowercase or include a missing :. These are syntactic flaws, not cryptographic issues—fixing syntax resolves 90% of 550 5.7.1 errors.

The 5 steps described in “Step-by-step validation process”, in order.

You can test the full email flow by simulating delivery using a tool like MailTester’s inbox placement test, which checks both DKIM and SPF alignment in real-world email environments. The test reveals if your signature is being rejected based on RFC compliance.

The RFC 6376 standard defines exact syntax requirements for DKIM. While many systems tolerate minor misformatting, major mail providers like Gmail and Microsoft enforce strict compliance, especially for new or poorly authenticated domains.

Common DKIM Formatting Mistakes That Trigger 550 5.7.1

When your email gets rejected with 550 5.7.1 DKIM non-RFC compliant header, it’s usually not the DKIM key that’s broken—it’s how the DKIM-Signature header was formatted. The most common culprits are extra whitespace, incorrect field ordering, typos in field names, or improper line folding. These tiny errors break RFC 6376 compliance, and most modern mail servers will reject the message outright.

Checklist: Fix These DKIM Header Errors

Don’t add extra whitespace between header fields or inside the signature value. Even a single space between h= and d= can invalidate the signature. Stick to RFC 6376’s strict syntax.
Order matters: h= must come before b= and other fields should appear in the exact sequence specified by the DKIM standard. Reordering fields—even in a different sequence—is a violation.
Use correct header field names—don’t spell d= as domain=, s= as selector=, or a= as algorithm=. Each field name is defined in the DMARC specification and must be used exactly as written.
Always fold long lines properly: use CRLF + space (a newline followed by a single space) to wrap header values, not just CRLF. Improper line folding breaks the signature’s integrity and is flagged by strict filters.

How to Verify Your DKIM Setup

Even if your signing tool claims to be valid, the final header must comply with the exact standard. The only way to know for sure is to inspect the raw message.

RFC 6376 outlines the precise syntax for DKIM-Signature headers—no room for interpretation. When your mail server rejects the message with "non-RFC compliant," it’s doing exactly what it should: enforcing standards. You can’t rely on email tools that don’t validate against this.

If you’re sending bulk or transactional emails, it’s worth verifying your entire envelope and header structure ahead of time. You can test actual delivery scenarios with inbox placement tools that simulate real-world filtering. MailTester’s inbox placement test checks your full message against real mail servers and flags non-compliant headers like malformed DKIM-Signature fields.

For developers and system admins, automated verification helps catch these issues before they hit production. The MailTester API can validate individual addresses and their headers as part of a pre-send workflow, ensuring your mail stack stays intact.

How Does Email Verification Help Prevent DKIM Rejection Errors?

Verifying email addresses won’t fix DKIM misconfigurations, but it confirms whether a recipient’s address is technically valid and exists at their domain. This helps you rule out sender-side issues when you receive a 550 5.7.1 rejection—knowing the address is real means the problem likely lies with the recipient’s DKIM setup, not your list. You can then focus on your own sending practices instead of guessing.

Why DKIM Errors Don’t Always Mean an Invalid Email

DKIM validation failure—like the 550 5.7.1 error—means the receiving server expected a digital signature matching your domain, but it either didn’t arrive or didn’t verify. But that doesn’t mean the email address doesn’t exist. A user with a properly formatted address might still get rejected if their domain has misconfigured DKIM, or if the signature is malformed in ways that don’t follow the expected protocol. In such cases, the error is on the recipient’s side, not yours.

This is where email verification becomes a diagnostic tool. When you verify an address and it comes back as valid, you know the issue isn’t a typo, non-existent mailbox, or malformed syntax. Instead, the rejection is likely due to policies on the receiving end—not because the address was wrong, but because the sender’s signature didn’t meet a strict standard. The RFC 6376 specifies how DKIM signatures must be formatted, and servers reject messages that deviate—especially if the headers are non-RFC compliant.

Let’s say you’re sending to a list and hit this rejection repeatedly. Without prior verification, you might assume the entire list is broken. But with MailTester’s bulk verification or real-time API, you catch invalid or non-existent addresses upfront. Verify your emails before sending at scale, and you’ll see which addresses are valid, which are catch-alls, and which return an error—helping you distinguish between sender-side list hygiene and recipient-side infrastructure issues.

If your verified list still gets 550 5.7.1 errors, you now know the problem is not your list—it’s the receiving mail server's DKIM validation policy. You can then investigate whether your DKIM setup needs fixing, or if the domain has strict filtering rules. The key is knowing what’s valid before sending, so you don’t waste resources on addresses that don’t exist—or waste time troubleshooting an error that isn’t your fault.

Most important: email verification doesn’t solve DKIM misconfigurations, but it gives you the clarity to know when the problem isn’t yours. With MailTester’s bulk verification, you reduce the chance of sending to invalid addresses, improve your sender reputation, and isolate delivery issues to their actual source.

What Tools Can Detect Non-RFC DKIM Headers in Real-Time?

Real-time detection of non-RFC DKIM header issues requires tools that analyze full email envelope and header structure during delivery simulation, not just syntax checks. Services like MailTester’s inbox-placement tests examine how your email is processed by receiving servers, including exact responses like 550 5.7.1, exposing non-compliant header formatting before you send.

Why Simulated Delivery Matters

Many basic validators only check syntax—whether a DKIM signature exists or if the domain is valid. But they miss how non-RFC formatting breaks parsing in real mail servers. Let’s say your header has a field with improper line folding or extra whitespace where RFC 5322 forbids it. The signature may be mathematically correct but still rejected because of structure violations. Tools that emulate actual SMTP routing catch this—because they parse the raw transport-layer data.

MailTester’s inbox-placement tests simulate delivery through real-world mail servers, including Gmail, Outlook, and Yahoo. These tests don’t just verify the address; they inspect the entire message envelope and raw headers during transport. If a header fails an RFC compliance check, even subtly, the receiving server returns a precise rejection code. This helps you see exactly why a message was blocked—before it ever hits your list.

How These Tools Work Under the Hood

They parse both the envelope (SMTP transaction) and header data at the byte level. This includes detecting issues like improperly folded lines in DKIM-Signature headers, missing or malformed header fields, or invalid base64 encoding in the signature body. These are common in automated systems that generate headers without validating RFC compliance.

Because DKIM header rules are strict—per RFC 5322—even minor deviations can cause rejection. A single misplaced space in a header field value can violate line length limits or break parsing. Only tools that inspect the raw message flow during simulated delivery can detect this.

MailTester’s real-time API enables you to test individual or bulk messages with delivery simulation. Each verification runs through a live SMTP handshake and checks for responses like 550 5.7.1, helping you identify non-compliant headers before sending to real recipients. This level of inspection is far beyond simple syntax validators and is essential for ensuring deliverability.

To test your emails with these capabilities, use MailTester’s inbox-placement tester—it validates the full message structure, simulates real delivery, and reports exact server responses, so you can catch RFC-compliance issues before they cost you deliverability.

Can DKIM Issues Be Caused by the Sending Platform or ESP?

Yes — your ESP or email service provider can generate non-RFC-compliant DKIM headers, especially if they auto-sign messages without strict adherence to RFC 6376. Even small formatting deviations in the DKIM-Signature header (like incorrect field ordering, improper line folding, or using non-standard headers) can trigger a 550 5.7.1 rejection. If your platform handles signing automatically, the issue might not be your setup — it’s likely theirs.

Check Your ESP’s Documentation for Known DKIM Issues

Some platforms like SendGrid, Mailgun, or Amazon SES have been reported to generate DKIM headers that deviate from RFC 6376 in subtle ways. These aren’t always flagged in logs, but they consistently show up as non-compliant in strict filtering environments. Always consult your ESP’s support center or knowledge base for known issues. For example, Mailgun’s documentation notes specific behavior around header ordering and canonicalization that, if altered by custom scripts, can break compliance.

Let’s say you’re using an ESP that auto-generates DKIM signatures. You may not see the raw header until you examine the full message source. Tools like MailTester’s email checker can verify whether a message’s DKIM signature format is valid before sending, helping you catch issues early.

Take Control with Manual DKIM Signing

If your ESP supports it, generating your own DKIM keys and managing the signing process manually is the most reliable path to compliance. This way, you control header field ordering, line folding, and canonicalization (both header and body). Many enterprise-grade platforms allow this via API or SMTP configuration. You can use tools like the MailTester API to validate the final signature during testing.

While this requires more technical effort, it removes ambiguity. DKIM’s purpose is to verify authenticity via cryptographic signature — but only if the header is structured correctly. The RFC 6376 standard defines the required syntax precisely; deviations, no matter how small, can break verification in modern mail servers.

If you’re not sure where the failure lies, test the message using an inbox placement tool like MailTester’s inbox tester. It simulates delivery through major providers and can highlight whether the issue is DKIM-related, SPF, or sender reputation — saving you time in troubleshooting.

How to Fix a Non-RFC DKIM Header Without Breaking Your Stack

You’re getting a 550 5.7.1 rejection because your DKIM signature header isn’t ordered correctly or violates RFC 6376. The fix is to validate your DKIM header structure before sending—ensure all fields are in the required order (d=, s=, c=, q=, t=, h=, b=, bh=, b=), use a proven library instead of rolling your own, and test the final output against an RFC-compliant validator.

Review your email generation pipeline—especially third-party libraries or SDKs handling DKIM signing. Some generate headers with incorrect field order or include non-RFC fields. Let’s say you’re using a custom wrapper or a legacy email service: dig into the output and check if the DKIM-Signature header follows the RFC-6376 standard.
Ensure field ordering is strictly correct. The sequence must be: d= (domain), s= (selector), c= (canonicalization), q= (query method), t= (timestamp), h= (headers), b= (signature), bh= (body hash), and b= again (signature). Even one misplaced field triggers rejection.
Replace homegrown DKIM code with a battle-tested library. Libraries like node-dkim or python-dkim implement the RFC correctly. Roll-your-own implementations often miss edge cases, like header folding or improper canonicalization.
Validate the final header using an RFC-compliant tool. Before sending, use a verifier that checks both syntax and standard compliance. Tools like RFC 6376 outline precise rules for formatting. You can test your output in a local debugger or with a tool like MailTester’s inbox placement tester to see how your email behaves in real inbox filters.

Why field order matters

Mail servers parse DKIM header fields sequentially. If any field is out of order—say, h= comes before t=—the server treats the entire signature as invalid. This isn’t a "soft fail" it’s a hard rejection. Even minor deviations can trigger the 550 5.7.1 error.

How to avoid future breaks

Regularly audit your DKIM setup, especially after updating your email SDK or switching to a new transactional email provider. If you’re on a platform like SendGrid, AWS SES, or Mailchimp, their documentation may include examples of compliant headers. When in doubt, use a tool that checks compliance—there’s no reason to guess.

How Does Sender Reputation Affect DKIM Validation?

You cannot bypass technical failures like a 550 5.7.1 DKIM non-RFC compliant header with a strong sender reputation. Even if your IP and domain have a clean history, receiving servers enforce protocol rules strictly. A single non-compliant DKIM header will trigger rejection — reputation doesn’t override RFC compliance.

Technical Compliance Comes Before Reputation

Receiving servers check DKIM signatures using specific rules defined in RFC 6376. If your header doesn’t follow these, the signature fails — regardless of your past sending behavior. A strong sender reputation means you’re less likely to be blocked by heuristics, but it won’t excuse a technical violation. The server doesn’t care how many emails you’ve sent well — it only cares if this one is correctly signed.

Let’s say your email client or mailer script adds unnecessary whitespace or uses an incorrect field order in the DKIM-Signature header. This is a non-RFC compliant format. The receiving server sees it as invalid and returns a 550 5.7.1 error. You might have a clean IP, low spam complaints, and solid engagement — but that doesn’t matter if the header is malformed. Compliance is absolute, not negotiable.

How Errors Like This Damage Deliverability Over Time

If left unchecked, repeated 550 5.7.1 rejections can signal poor sending hygiene. Even one failure can trigger throttling or temporary blocklists, especially if it happens across multiple domains. Once reputation starts to degrade, recovery is slow. It’s not just about one bounce — it’s about patterns. Consistent technical errors suggest a flawed infrastructure, which receivers use to assess risk.

Many senders ignore header-level issues because they don’t show up in basic bounce reports. That’s where tools like bulk email verification help. You can check your entire list for technical flaws before sending, including malformed DKIM headers in test messages. Catching issues early prevents long-term damage to your sending health.

RFC 6376 sets clear standards for DKIM header format. The RFC itself details the syntax and processing rules — and no server will relax these. Even a single invalid character in the signature can cause a drop in inbox placement. The best defense isn’t reputation — it’s correctness.

What If My Domain’s DKIM Is Working for Some Recipients But Not Others?

If your DKIM signature passes for some recipients but fails for others — especially with a 550 5.7.1 DKIM non-RFC compliant header error — it means the receiving server enforces strict DKIM validation rules, like Microsoft 365 or Google Workspace. These systems reject signatures that don’t follow the exact format specified in RFC 6376, even if the signature is technically valid. Others may accept slightly malformed headers, which is why your emails work unevenly across providers.

Why Some Servers Reject What Others Accept

Not all email providers validate DKIM the same way. Microsoft 365, for example, uses a stringent check that requires every header in the canonicalized list to be strictly formatted. A missing or improperly ordered DKIM-Signature header, even with correct content, can trigger rejection if it doesn’t follow the exact order defined in the RFC. Many smaller providers or older systems may skip or relax this check — they only validate the signature’s cryptographic integrity, not the header syntax.

It’s not just about whether the signature is correct. The order, spacing, and formatting of headers matter. A common mistake is placing extra spaces or newlines in the DKIM-Signature field, which violates the RFCs. This can cause failure on strict servers while passing permissive ones. It’s also why some recipients see delivery issues while others do not — even from the same sender domain.

How to Spot Which Providers Are Enforcing Strict Rules

Let’s say you’re sending to customers across multiple domains. To diagnose which servers are rejecting mail due to formatting, run an inbox-placement test across major providers. Services like MailTester’s inbox placement tester deliver test messages to real user inboxes at Gmail, Outlook, and others, then report back on delivery, spam filtering, and headers. This reveals whether the issue is specific to one provider, like Microsoft 365, or more widespread.

For instance, if your test shows failure only on Outlook but success on Gmail, the culprit is almost certainly the DKIM header structure being non-RFC compliant. You can then validate your DKIM signing setup using tools like RFC 6376 to ensure header ordering, line folding, and field names are correct. Fixing this often resolves 550 5.7.1 errors.

Once verified, run your list through a bulk verification tool like MailTester's email list verifier to check for any misformed or problematic addresses that could trigger stricter validation. Addressing both header format and list hygiene improves reliability across all recipients.

The Bottom Line: Fixing DKIM Non-RFC Issues Is a Technical Must

The 550 5.7.1 error is not a reputation issue. It is a strict, technical rejection caused by a non-compliant DKIM signature header.

Even minor deviations—like incorrect line breaks, improper header order, or invalid base64 encoding—can result in complete message rejection at the receiving server.

Prevent rejection before sending

Before sending at scale, verify both the validity of each email address and the technical compliance of your message headers.

Use MailTester’s deliverability testing to catch DKIM and other technical issues early, avoiding delivery failures and protecting your sender reputation.

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)
Roughly one in six legitimate commercial emails (16.5%) never reaches the inbox globally — 6.7% is filtered to spam and 9.8% disappears without a bounce. — Validity 2025 Email Deliverability Benchmark 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 does 550 5.7.1 mean in an email rejection?

It means the receiving server rejected your email due to a non-compliant DKIM signature header, violating RFC 6376 standards.

Can DKIM errors be caused by my email client?

No — the client doesn’t sign the email. The error is caused by the sending system or ESP that generates the DKIM header.

Does MailTester test for DKIM compliance?

Yes — MailTester’s inbox-placement tests simulate real delivery, including checking for RFC-compliant DKIM headers and rejecting messages that fail.

How often should I check my DKIM header formatting?

At least once per major change to your email sending flow. Use inbox-placement testing before large campaigns to catch issues early.

Do all email providers enforce RFC 6376 strictly?

No — some accept non-compliant headers, but major providers like Microsoft and Google enforce strict checks, so compliance is essential for inbox placement.

What happens if I ignore DKIM non-RFC errors?

Your emails will be rejected by strict hosts, and your sender reputation may degrade over time, even if your content is clean.

Can invalid email addresses cause 550 5.7.1 errors?

No — address validity doesn’t affect DKIM. The error is technical, not about whether the email exists.

Is DKIM validation part of SPF or DMARC?

No — DKIM is independent of SPF and DMARC. Each serves a different purpose: DKIM verifies message integrity, SPF checks sender IP, and DMARC enforces policies.

How do I know if my DKIM signing is RFC-compliant?

Use a header validator that checks against RFC 6376. Manual validation is error-prone — automated tools or inbox-testing services are more reliable.

Does MailTester help with DKIM configuration?

No — it doesn’t generate keys or configure DNS. But it tests whether your final message header passes validation on receiving servers.