SPF TXT Record Malformed Due to Encoding

Why is your SPF TXT record failing due to %20 or &?

You just fixed your email deliverability issue—then it broke again, and you’re staring at a DNS record with no idea what went wrong. If your SPF TXT record uses %20 or & where spaces or ampersands should be, that’s likely the culprit.

SPF records aren’t just technical checkboxes—they’re the gatekeepers of your domain’s email authenticity. A single malformed character breaks the entire rule, and email servers reject your messages before they even land in the inbox.

Even a small encoding glitch—like a URL-encoded space (%20) instead of a literal space—can invalidate the entire TXT record. Receiving servers don’t guess; they parse strictly. And they don’t trust a record that isn’t exactly valid.

Key takeaways

SPF TXT records must use plain text spaces and & symbols; encoded versions like %20 or & break parsing.
Email servers reject SPF records with invalid syntax—no matter how small the error—because authentication is binary.
Always verify SPF syntax using tools that test the exact DNS-level string, not just a visual check.

What does 'SPF TXT record malformed' actually mean?

When your SPF TXT record is marked as "malformed," it means the DNS record contains syntax errors that prevent receiving servers from reading it correctly. Even small mistakes—like encoding a space as %20 instead of a literal space, or using & instead of &—break the entire record. Since SPF relies on machine-readable parsing, invalid syntax means the server can’t verify your domain’s legitimacy, leading to delivery failures or spam filtering.

Why syntax matters in SPF records

SPF records are parsed as plain text by mail servers using strict rules defined in RFC 7208. The format is precise: tags, values, and mechanisms must follow exact structure, with spaces separating elements and special characters like & needing proper escaping. If a tool or form replaces a literal space with %20—common in URL-encoded data—the record becomes invalid. Similarly, & is the HTML entity for &, but SPF expects the actual & character. A single misencoded character renders the whole record unusable.

The consequence isn’t just a warning—it’s real deliverability impact. Mail servers don’t trust senders with malformed SPF records. They may reject emails outright, mark them as spam, or delay delivery. This happens regardless of whether your email content is clean or your sending reputation is strong.

Common mistakes that break SPF

Even with correct structure, syntax slips happen. The most frequent error is using %20 instead of a literal space between SPF mechanisms. For example, v=spf1 include:_spf.google.com %20all fails because %20 isn’t valid in the record. The same applies to unescaped special characters: & in place of & breaks parsing.

These issues often arise when editing records via web UIs that default to URL encoding, or when copying TXT records from HTML sources. You might not realize the problem until you start seeing bounces or low inbox placement. Tools like MailTester’s bulk email verification can catch invalid sender domains before you send, including those with malformed SPF records, helping you avoid mass delivery failures.

Proper validation is a must. Use tools that check DNS-level syntax, not just email addresses. The SPF specification itself is a clear reference point: RFC 7208 defines the expected format. If your record doesn’t follow it exactly, it won’t work—even if you're only off by one character.

How encoding like %20 or & breaks SPF records

SPF records rely on literal spaces to separate directives—using %20 (URL-encoded space) or & (HTML entity) breaks syntax, turning valid rules into misparsed strings. Your SPF record is now invalid, and receivers may reject your emails or mark them as spam. It’s not a bug—it’s a parsing fail.

Spaces must be literal, not encoded

SPF syntax requires actual space characters between mechanisms. So v=spf1 include:example.com -all works. But if a tool or CMS encodes that space as %20—like v=spf1 include:example.com%20-all—SPF reads it as a single, malformed string. The server sees example.com%20-all as a domain, which doesn't exist, and the record fails.

When you use APIs, spreadsheets, or CMS tools to manage DNS, ensure raw text output preserves literal spaces. Tools that auto-escape or URL-encode values can break DNS records silently.

HTML entities like & are not valid in TXT records

HTML entities like & are not allowed in SPF TXT values. If a script or form incorrectly passes & instead of a literal &, the DNS record becomes corrupted. For example, v=spf1 include:example.com & all gets parsed as include:example.com & all, where & is interpreted as “and,” but SPF doesn’t understand it as a directive.

This isn’t just a formatting issue—it causes SPF validation to fail. Some systems may even interpret & as a malformed entity, leading to outright rejection. This is especially common when generating records via web forms, content builders, or automated scripts that assume HTML-safe output.

Always test your SPF record using a real DNS lookup tool. For example, you can use MXToolbox or RFC 7208, Section 4.1 to confirm syntax rules are followed. A single misparsed character can break authentication for all outgoing email.

If you’re deploying a list of email addresses for sending—especially in bulk—check both the SPF record and each address’s validity before transmission. Use a tool like MailTester’s bulk verification to detect invalid or malformed inboxes and SPF failures early, so you don’t waste sends on addresses that won’t reach the inbox.

Real-world impact: what happens when SPF is malformed?

You’ll likely see bounces, delivery failures, or your emails flagged as suspicious—because malformed SPF records, especially those with improper encoding like %20 or &, break the DNS parsing process. Mail servers can’t validate your domain’s authenticity, so they either reject your messages outright or treat them as unreliable. This doesn’t just disrupt delivery; it damages sender reputation over time.

Immediate delivery failures and sender reputation risk

When an SPF record contains invalid characters like & or %20 instead of plain whitespace, DNS resolvers can’t parse it correctly. The result? The receiving mail server treats the record as invalid or missing. Many servers will then reject your email during the SMTP handshake, leading to hard bounces. If you’re sending at scale, even a few malformed records can trigger a high bounce rate—often seen above 5% as a red flag to ESPs.

Even if your email gets through, mail providers like Gmail or Outlook use SPF validation as part of their inbox placement decision. A failed or malformed SPF check is seen as poor technical hygiene. That signal can reduce your chances of landing in the primary inbox and may increase the likelihood of throttling or quarantine. This isn’t just about one bad message—it compounds over time, especially if you don’t fix it.

Spam filters and blacklisting: the long-term consequences

Spam filters aren’t reading your email content first; they’re checking your infrastructure. A malformed SPF record suggests a lack of attention to basic email security standards. That’s a well-documented red flag. According to data from the Messaging, Malware, and Mobile Anti-Abuse Working Group (M3AAWG), misconfigured authentication protocols are among the top indicators of poor sender hygiene, which correlates to higher spam likelihood.

If your domain keeps sending to servers that see SPF as broken, your IP or domain can be flagged as suspicious. Over time, repeated failures can lead to inclusion on blocklists, even if your content is clean. While you won’t get blacklisted immediately, ongoing authentication flaws erode trust. Recovery becomes harder as time passes.

Let’s be clear: encoding errors like %20 in SPF aren’t just technical nitpicks. They’re delivery killers. Use a reliable tool to scan your domain’s DNS configuration—including SPF, DKIM, and DMARC—before sending. You can test your SPF in real time with MailTester’s email checker, or verify your full list with bulk verification to find issues before they impact deliverability.

How to check if your SPF record is malformed

You can verify if your SPF record is malformed by retrieving the actual TXT record via a real-time DNS lookup tool. Look for non-standard encodings like %20 (for spaces) or & (for ampersands), which are not valid in SPF records. Proper SPF syntax requires literal spaces and unencoded characters—HTML or URL encoding breaks SPF validation.

Run a real-time DNS lookup

Use a reliable DNS lookup tool like MxToolbox or Google’s dig command to retrieve your domain’s TXT records.
Focus on the record that starts with v=spf1—this is your SPF policy.
Check the full raw content for any signs of improper encoding.

Review for invalid encodings

Look for %20—this is a URL-encoded space. Replace it with an actual space character.
Check for & or &—these are HTML encodings. SPF records only accept plain & when used as part of a mechanism (e.g., include:), not as a literal ampersand.
Ensure all spaces in your SPF record are literal—no encoding, no spaces between mechanisms and qualifiers.
Validate that the record ends with a ~all or -all mechanism. Missing or malformed mechanisms cause SPF failures.
Refer to RFC 7208 for canonical syntax rules—this is the definitive guide for SPF record structure.

Malformed records due to improper encoding commonly result in SPF failures during email delivery. Even a single encoded space can disrupt authentication.

Once you’ve verified the syntax, test your full email flow using a deliverability tool like MailTester’s Inbox Placement Test to confirm your SPF alignment, DKIM, and DMARC are working in concert.

How to fix a malformed SPF record

Fix a malformed SPF record by editing it in your DNS provider’s console to use literal spaces, not encoded ones like %20 or &, and replace & with a plain &. Ensure it starts with v=spf1 and ends with -all or ~all. Save the change and verify it propagates using a public DNS lookup tool.

Step-by-step fix

Log in to your DNS provider’s dashboard—Cloudflare, AWS Route 53, GoDaddy, or another platform. This is where you manage domain records like SPF, DKIM, and DMARC.
Find the SPF TXT record for your domain. It’s usually listed as @ or @.example.com in the record name field. Look for a value beginning with v=spf1.
Edit the value. Replace any encoded spaces (%20, ) with actual spaces. Likewise, replace & with a plain & character. Malformed encoding breaks SPF validation in practice, even if it seems correct in theory.
Ensure the record starts with v=spf1 and ends with -all (hard fail) or ~all (soft fail). A missing or incorrect mechanism breaks alignment with sender policy standards.
Save the change. DNS changes can take up to 48 hours to propagate globally, but many providers update faster—usually within minutes.

Verify it works

After saving, test propagation using a public tool like MXToolbox DNS Lookup or DNSChecker.org. Enter your domain and confirm the SPF record appears correctly as a single, unencoded TXT record.

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

Want to catch issues like this before sending? Use MailTester’s email checker to validate individual addresses or bulk verification to clean your list and catch invalid or malformed records early.

Why SPF should not be the sole authentication method

SPF alone isn’t enough to guarantee inbox delivery. Even with a correct SPF record, emails can still be flagged as spam or rejected if DKIM and DMARC aren’t properly configured. Malformed SPF records—like those with incorrect encoding such as %20 or &—can break the entire authentication stack, causing deliverability issues even when other checks pass.

SPF is just one piece of the authentication puzzle

Think of email authentication like a multi-layered security system. SPF checks the sending server’s IP address, but it doesn’t verify the message content or sender identity. DKIM signs the email body and headers, ensuring the content hasn’t been altered in transit. DMARC ties them together, telling receiving servers what to do when SPF or DKIM fails.

Without DKIM, there’s no proof the message comes from a legitimate source. Without DMARC, there’s no policy to enforce what happens when either SPF or DKIM fails. Relying solely on SPF leaves gaps that attackers can exploit. Even a single misconfigured or malformed record—like one with incorrect encoding such as %20 instead of a space—can cause an entire domain’s emails to fail validation.

Malformed records break the whole chain

A single error in SPF, such as a line break improperly encoded as %20 or &, can make the record unreadable to mail servers. This isn’t just a technical nitpick—malformed records cause SPF to fail silently, which triggers spam filters and blocks emails based on the absence of a valid authentication chain.

For example, if SPF fails due to a malformed TXT record, DMARC may still pass if DKIM is valid, but many receivers still reject the email. According to reports from Return Path and the Messaging, Malware, and Mobile Anti-Abuse Working Group (M3AAWG), delivery failures commonly stem from incomplete or misconfigured authentication sets, not just one failed check.

Even if DKIM and DMARC are set up correctly, a failed SPF can still result in low inbox placement or being marked as spam. This is why modern email services require all three: SPF, DKIM, and DMARC. A single weak link—like a malformed SPF record—can ruin the whole delivery process.

Before sending, verify your email authentication setup with tools that test the full stack. Use MailTester’s email checker to validate individual addresses and ensure your SPF, DKIM, and DMARC records are properly structured and free of encoding issues.

You can catch SPF TXT record issues—like malformed entries due to incorrect encoding such as %20 or &—before they cause bounces or spam filtering. MailTester detects these problems during inbox-placement tests by validating DNS records in real time, ensuring your domain’s configuration aligns with industry standards. This prevents delivery failures you might otherwise only discover after sending.

Spotting encoding errors before they break delivery

Incorrectly encoded characters in SPF records—like URL-encoded spaces (%20) or unescaped ampersands (&)—can break DNS parsing. Many tools miss this because they only check syntax, not content validity. MailTester checks the raw DNS data as it’s served, flagging malformed entries that would otherwise slip through. This includes common pitfalls when manually editing DNS or using unreliable automation tools.

For example, a record like v=spf1 include:_spf.example.com %20 -all is invalid because %20 is treated as literal text, not a space. Similarly, & used instead of & in a string can break parsing. These subtle errors can result in hard bounces or rejection by receivers that enforce strict SPF validation—something our tests simulate. You can verify these cases using our inbox-placement tool to see how major providers like Gmail or Outlook process the record.

Proactively verify with API or bulk checks

Let’s say you’re setting up a new domain or updating email infrastructure. Use the MailTester verification API to automatically validate SPF records as part of your deployment workflow. Or, if you’re cleaning a large list, run a bulk verification to catch all DNS-level risks across multiple domains. Both methods scan for malformed records, including encoding issues, before you send messages at scale.

This helps avoid scenarios where an SPF failure results in emails being rejected at the SMTP level, even if the email itself is clean. You’re not just checking email addresses—you’re validating the full delivery chain. For teams integrating with Mailchimp, HubSpot, Klaviyo, or SendGrid, our integrations ensure SPF problems are caught at the point of list upload or API call.

Best practice: how to verify SPF before sending mail

Before publishing your SPF record, test its syntax with an online validator. Ensure all spaces are literal—no URL-encoded %20 or & characters. Validate through end-to-end inbox-placement tests to confirm deliverability. This prevents bounces and inbox filtering caused by malformed records.

Check SPF syntax before publishing

Use a trusted SPF validator like the one from RFC 7208 or tools from MxToolbox to ensure your syntax follows standard format.
Avoid any HTML or URL encoding—spaces must be real space characters, not %20 or &.
Double-check that mechanisms like include: or ip4: are spelled correctly and not wrapped in quotes or encoded.

Test the full deliverability chain

Run a full inbox-placement test using a tool that simulates real email clients, testing not just SPF but also DKIM, DMARC, and content reputation.
MailTester’s inbox-placement tester checks the complete delivery path, catching issues that syntax-only tools miss.
If you're managing a list of hundreds or thousands, use bulk verification to catch malformed records across your entire domain before sending.

Even a single space encoded as %20 in an SPF record breaks the standard and can trigger rejection by mail servers. You can’t rely on a sender domain being “trusted” if the SPF record is syntactically invalid.

What happens if you don’t fix malformed SPF records?

If your SPF TXT record contains malformed encoding like %20 or &, email receivers may reject your messages outright or mark them as spam. This breaks authentication, damages your sender reputation over time, and increases the risk of being blocked by services like Spamhaus or Barracuda after repeated failures. You’ll see higher bounce rates, lower inbox placement, and reduced deliverability—especially on platforms that enforce strict SPF checks.

Authentication failures lead to delivery loss

When an SPF record is incorrectly encoded, mail servers can’t parse it correctly. This means your domain fails SPF validation, even if your sending infrastructure is otherwise sound. The result? Messages are rejected or silently filtered into junk folders. Services like Gmail, Outlook, and corporate email systems rely heavily on SPF to determine sender legitimacy. A malformed record turns every email into a suspect.

Let’s say your SPF record reads v=spf1 include:_spf.example.com %20 reject instead of v=spf1 include:_spf.example.com reject. The %20 is a URL-encoded space, which isn’t valid in DNS TXT records. DNS expects plain text, not encoded sequences. The server sees this as a parsing error and skips the policy, leading to a soft fail or no authentication at all.

Reputation damage accumulates silently

Each failed SPF check adds risk points to your domain’s reputation. Tools like Spamhaus and Barracuda maintain real-time blocklists based on sender behavior. Repeated failures—especially those caused by preventable issues like malformed records—can trigger automatic alerts or even blacklisting.

For example, Spamhaus evaluates sending behavior over time. If your domain consistently sends unauthenticated messages, it may appear in their RBL (Real-time Blocklist) without a clear warning. Unlike a single bounce, this kind of reputation decay is slow but hard to reverse.

While SPF isn’t the only factor in deliverability, it’s a foundational one. A single syntax error in your TXT record can undermine all your other email hygiene efforts. If you're sending to a large list, verifying your DNS records before each campaign is critical.

Use tools to test your SPF configuration before sending. Check individual addresses or verify entire lists for authentication issues. MailTester’s real-time verification includes SPF validation to help you catch these errors before they hurt your results.

Final step: monitor SPF health after fixing it

Fixing a malformed SPF TXT record is incomplete without verifying that your emails now land in inboxes. Use MailTester’s deliverability testing to simulate real-world sending and confirm your setup no longer blocks messages.

Proactive monitoring prevents regressions

Even after correction, SPF policies can break due to accidental edits, third-party tool changes, or DNS propagation delays. Schedule periodic checks—automated or manual—to catch these issues before they hurt deliverability.

Integrate verification into your workflow

Prevent issues at scale by integrating MailTester with your email platform. Mailchimp, SendGrid, Klaviyo, and others support real-time verification to block risky or invalid addresses before sending.

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)
52.1% of the world's top 1.8 million domains (937,931 domains) now publish a valid DMARC record, up from 29.1% in 2023. — EasyDMARC 2026 DMARC Adoption & Enforcement Report (2026)

Keep reading

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

Frequently asked questions

Can %20 in an SPF record make it invalid?

Yes. %20 is URL-encoded for a space. SPF requires literal spaces. Using %20 breaks syntax and invalidates the record.

Why does & cause SPF record errors?

It's interpreted as an HTML entity, not a literal character. Receiving mail servers see & as part of the value, not as a separator.

How do I check my SPF record for encoding issues?

Use a DNS lookup tool to retrieve the TXT record and inspect its value manually. Look for %20, &, or any non-literal character in place of spaces or special syntax.

Can SPF be broken without changing the DNS record?

Yes. Misconfigured email clients, forwarders, or header rewrite tools can insert malformed content. Always validate the entire message path.

Is there a tool that checks SPF for HTML or URL encoding?

Yes. MailTester’s real-time verification and inbox-placement testing flag records with malformed syntax, including encoding issues like %20 or &.

Do I need to fix SPF if I use SendGrid or Mailchimp?

Yes. Even with a third-party sender, your domain’s SPF must authorize the outbound server. Unverified or malformed SPF breaks authentication.

What’s the difference between a malformed SPF and a missing SPF?

Malformed SPF fails syntax checks; missing SPF means no record exists. Both cause delivery issues, but malformed records are more common due to incorrect edits.

How long does it take for SPF changes to take effect?

DNS propagation typically takes 1 to 72 hours. Use a DNS checker to confirm the change is live before sending email.

Should I use +all or -all in my SPF record?

-all is required for strong authentication. +all allows any server to send on your behalf, which weakens security and harms deliverability.

Can I have multiple SPF records?

No. Only one SPF TXT record is allowed per domain. Multiple records cause parsing failures and must be merged into a single entry.

How often should I audit my SPF record?

At least once every three months, or after any DNS change. Use MailTester’s bulk list verification or API to catch technical issues early.

Is there a difference between SPF syntax and format?

Syntax defines the order and valid mechanisms; format refers to how the record is stored in DNS—including encoding, spacing, and escaping. A format error can break syntax.