SPF Record Setup for 564 Error | Email List Validation

Why does the 564 error appear when sending email?

You sent an email. It went out. Then, a bounce message lands in your inbox: "564 Sender not authorized." You check your inbox, but nothing’s wrong — or is it?

The 564 error isn’t a glitch. It’s a server-level warning: your domain’s SPF record doesn’t list the sending server as authorized. This means the receiving mail server assumes you’re impersonating someone — likely a spoofing attempt. It’s not your fault. It’s just that your domain hasn’t told the internet, "Yes, this server can send emails on my behalf."

You’re not alone. This happens when you use Mailchimp, SendGrid, or your own SMTP client without properly configuring DNS SPF record setup. Without it, even valid emails get blocked — not because of content, but because of trust.

Key takeaways

564 errors occur when the receiving mail server finds no SPF record authorizing your sending IP or domain.
Even if your message is valid, unapproved senders are treated as suspicious — commonly blocked or marked as spam.
Setting up a DNS SPF record is mandatory when using third-party email services to prevent sender not authorized errors.

What is a DNS SPF record and why does it matter?

You're seeing a "564 sender not authorized" error because your domain’s DNS SPF record isn’t properly set up. SPF (Sender Policy Framework) is a DNS record that explicitly lists which mail servers are authorized to send email on behalf of your domain. If an email comes from an IP not on that list, receiving servers reject it, often with a hard bounce. This isn’t just about delivery—it’s about trust, security, and reputation.

How SPF works as a gatekeeper for your email

When you send an email, the receiving server checks your domain’s SPF record. It sees if the IP address used to send the message is in the approved list. If not, the email fails authentication. This gatekeeping prevents spoofing—where attackers pretend to be you—and stops your messages from being flagged as spam or blocked outright.

Let’s say you use your own server, then also send through SendGrid and HubSpot. All three IPs need to be in your SPF record. If any are missing, the email from that source fails SPF. You might not know which one—it’s not always obvious. That’s why it’s better to verify your email infrastructure regularly using tools that check real-time deliverability and authentication.

Clean your sender list with bulk verification to catch invalid or outdated domains before they cause deliverability issues. Many bounces and 564 errors come from old or poorly maintained lists—fixing the source is more effective than blaming the mail server.

Why SPF matters beyond just fixing errors

Correct SPF setup isn’t just about avoiding one error code. It improves your sender reputation. Email providers like Gmail and Outlook track whether you follow authentication standards. Consistent, proper SPF (and DKIM, DMARC) usage signals reliability—your messages are less likely to end up in spam folders.

A misconfigured SPF can hurt more than it helps. Overloading the record with too many mechanisms can break it. You can also get a “soft fail” if a server doesn’t fully trust your record. This is why the industry standard (per RFC 7208) recommends keeping it simple and using mechanisms like include: only when necessary.

The takeaway? SPF is a foundational layer of email security and deliverability. It doesn’t replace good content or list hygiene, but it ensures your legitimate emails aren’t blocked by automation. Double-check your DNS records, test your sending setup, and use verified tools to validate your entire email stack.

How to set up a DNS SPF record to resolve the 564 error

You fix the 564 "sender not authorized" error by adding a single, correctly formatted SPF record to your domain’s DNS settings. This record authorizes your mail server or service to send emails on behalf of your domain. Without it, recipients’ servers reject your messages. Use RFC 7208 as the definitive source for SPF syntax and behavior.

Log in to your domain’s DNS management provider—such as Cloudflare, Amazon Route 53, or GoDaddy. Access the DNS zone file for your domain.
Look for a TXT record type. Create a new TXT record where the name field is set to @ (or your full domain name, like example.com).
Set the value to v=spf1 include:_spf.your-mail-service.com ~all. Replace your-mail-service.com with your actual email provider’s SPF include (e.g., include:_spf.google.com for Gmail, include:servers.mcsv.net for Mailchimp).
Ensure you have only one SPF record per domain. Multiple SPF records cause parsing failures and break authentication. If you have existing SPF entries, merge them into a single record using include: or ip4: mechanisms.
Save the record. DNS changes typically propagate within 10–30 minutes. Do not send test messages immediately—wait for full propagation.
Verify your SPF record using free tools like MxToolbox or DNSCheck.org. These test whether your record resolves correctly across global DNS.

Why this process matters

SPF is one of the core email authentication methods. Misconfigured records lead to delivery failures, even when your content is valid. The 564 error is a signal that your domain’s SPF policy did not recognize your sending server as authorized. This isn’t a problem with your email content—it’s a policy mismatch at the infrastructure level.

Using ~all (soft fail) instead of -all (hard fail) is a common mitigation step when you're testing, because it prevents legitimate messages from being blocked due to incomplete SPF configurations. But once your record is confirmed correct, switch to -all for stronger enforcement.

Common pitfalls to avoid

Do not use multiple SPF records. You can't have two TXT records with spf in the value.
Don’t forget your mail provider’s specific include tag. Google, SendGrid, and HubSpot each require different domains.
Do not rely on web forms or UIs that don't show the raw TXT value. Copy-paste the full value exactly.

If you're validating sender domains at scale, tools like bulk email list cleaning can help identify domains with broken SPF, DKIM, or other deliverability issues before you send.

Common SPF record mistakes that trigger the 564 error

If your email service returns a "564 sender not authorized" error, it’s likely due to a malformed or conflicting SPF record. You’re probably using multiple SPF records, misconfiguring includes for third-party services, or applying a hard fail policy without testing. The fix starts with a single, correctly formatted TXT record that explicitly lists all authorized sending sources. Let’s walk through the most common missteps that break SPF and trigger delivery failures.

One Record, One TXT — No Exceptions

You can only have one SPF record per domain. If you’ve added multiple TXT records containing SPF or v=spf1, they conflict — and the receiving server will reject all of them.
SPF checks are strict by design. Even one duplicate record breaks the validation. Use a DNS manager or tool like MXToolbox to scan for duplicates before deploying a new setup.

Policy Missteps: Using `all` Instead of `~all`

Setting your policy to v=spf1 ... all forces a hard fail on any unlisted sender — which can break legitimate outbound emails if a service isn’t properly added.
During testing or transition, use ~all (soft fail) instead. This reduces risk of blocking valid traffic while still signaling that unauthorized senders shouldn’t be trusted.
Once you’ve verified all sending sources, gradually move to all only after confirming full alignment across your infrastructure.

Missing or Incorrect Includes for External Senders

If you use SendGrid, HubSpot, or any third-party email sender, their IP addresses must be formally included in your SPF record via include:.
Omitting include:sendgrid.net or include:hubspotemail.com means those services will fail SPF checks — a leading cause of the 564 error.
Check each service’s documentation for the correct SPF include syntax. Many providers update their IP ranges, so include statements should be updated regularly.

Overly Restrictive SPF Policies Without Audit

Setting a policy like ip4:192.0.2.0/32 -all blocks all other sources — including your internal tools, marketing platforms, or legacy apps.
Too many strict rules without visibility into all your sending sources can result in legitimate mail being rejected. Audit your domains across all platforms to ensure you’re not accidentally blocking yourself.
Use tools like RFC 7208 to validate your SPF syntax and scope — a single misformatting error can break the entire record.

Not Updating SPF When Infrastructure Changes

Adding a new email service, switching hosting providers, or using a new transactional email platform means you must update your SPF record.
Failing to do so leads to the 564 error, even if the sending address is correct. SPF records don’t auto-scale with your tech stack — they require manual maintenance.
Use a service like bulk email list validation to audit your outbound sending sources and identify gaps in SPF coverage — especially before campaign launches.

SPF, DKIM, and DMARC: how they work together

You can fix the 564 sender not authorized error by setting up SPF, DKIM, and DMARC correctly. SPF checks if the sending server’s IP is authorized. DKIM cryptographically signs the email to prove it wasn’t altered. DMARC ties both together, enforcing policies, collecting reports, and guiding how receivers handle failed checks. All three are required to maintain strong deliverability and avoid high bounce rates or inbox rejection. Without them, your messages risk being flagged or blocked.

SPF: Authorizing the sending IP

SPF (Sender Policy Framework) is your first line of defense. It lets you list which IP addresses are allowed to send emails on your domain’s behalf. When an email arrives, the receiving server checks your domain’s DNS record to confirm the sending IP is in the approved list. If not, it fails SPF—commonly returning a 564 error. That’s why setting up a proper SPF record matters: it stops impersonators and builds trust.

But SPF has a catch: it only checks the envelope sender (often the Return-Path), not the visible From address. That’s where DKIM comes in.

DKIM: Authenticating the message content

DKIM signs each email with a cryptographic key. The sending server adds a digital signature to the message headers using a private key. The receiving server then verifies that signature using your public key, which lives in your DNS. This tells the receiver the message is unaltered and truly came from your domain.

Unlike SPF, DKIM doesn’t care about the sending server’s IP. It cares about content integrity. So even if the message came from a different IP than your SPF record allows, DKIM can still confirm authenticity—provided your signature is valid. This makes DKIM essential for long-term trust, especially with email service providers (ESPs).

DMARC: Enforcing and reporting

DMARC is the enforcement layer. It tells receivers what to do when SPF or DKIM fails—reject, quarantine, or allow the message. You can also set up email reporting, so you get alerts when your domain is abused or misconfigured. Most major inboxes (Gmail, Yahoo, Outlook) use DMARC to decide whether to deliver your email. Without it, there’s no clear policy, and your email is treated as high risk.

To be effective, DMARC relies on valid SPF and DKIM results. If either fails, DMARC applies your policy based on the failure rate. This is why running bulk list validation is essential—it reveals invalid or risky addresses that could trigger DMARC failures. You can clean your list and reduce risk before sending: use our bulk verification to check domains and detect issues before they affect deliverability.

For a full guide, see the official DMARC specification. It’s an industry-standard framework. No single tool can replace it—but a solid setup with SPF, DKIM, and DMARC, combined with clean data, gives you the best shot at inbox placement.

A real-world example: fixing SPF on a SendGrid integration

If your domain uses SendGrid to send marketing emails and you're seeing a 564 sender not authorized error in your logs, the fix is almost certainly an incomplete or missing SPF record. You need to add include:sendgrid.net to your DNS TXT record for your domain. Once updated and propagated, the error should disappear. Test with a verified address from your domain to confirm it’s resolved.

Step-by-step fix: align your SPF with SendGrid’s requirements

Review your current SPF record using a public DNS lookup tool like MxToolbox or RFC 7208. Check if it includes include:sendgrid.net. Many organizations miss this because they assume a single SPF entry covers all senders.
Check SendGrid’s documentation to confirm the correct inclusion. SendGrid requires that you explicitly authorize its mail servers by including include:sendgrid.net in your SPF record. This tells receiving servers: “Yes, SendGrid is allowed to send on my behalf.”
Update your domain’s DNS TXT record with the full value: v=spf1 include:sendgrid.net ~all. The ~all mechanism allows a soft fail (not a hard block), which is standard for new setups. Avoid mixing multiple SPF records—it violates RFC 7208 and causes failures.
Wait for DNS propagation. Changes can take up to 48 hours to fully propagate across the internet. Use tools like DNSChecker.org to verify the new record is live globally before testing.
Send a test email from your domain using SendGrid. Use a real user address from your domain (e.g. [email protected]), not a generic one like admin@ or support@. These often trigger additional filtering. Check your email logs again—no 564 error should appear.

Why testing with a verified domain address matters

Many admins test with public email addresses or throwaway domains. These don’t reflect real-world delivery conditions. A [email protected] from a verified mailbox will actually trigger the full sender authentication process—exactly what you want to validate. This avoids false negatives where the error seems fixed but only because the test is too weak.

When a sender isn’t authorized, the receiving server doesn’t reject the message outright—it logs a 564 error and may defer delivery. That’s what you’re trying to prevent.

Once the SPF record is correctly set, your campaigns should deliver reliably. If issues persist, double-check DNS propagation and ensure no duplicate SPF records exist. Tools like bulk email list cleaning can help validate your sender infrastructure by uncovering other hidden issues like outdated or invalid domains.

Running a bulk email list through Email List Validation before sending catches invalid, role-based, and disposable addresses that can trigger authentication failures—even if they’re not the root cause. You’re not just cleaning your list; you’re reducing risks like spoofed addresses and blocklist exposure that indirectly cause 564 errors. The tool’s 98.9% accuracy includes detecting catch-alls and role accounts, while inbox-placement tests confirm your setup works in real inboxes.

Stop sending to addresses that cause authentication chain breaks

SPF errors like “sender not authorized” often stem not from misconfigured SPF records, but from sending to addresses that shouldn’t be contacted at all. Role-based emails (like admin@ or sales@) are commonly used in bulk campaigns but often bounce or fail deliverability checks. Some are even set up as catch-alls, which allow delivery but can’t be validated without deeper checks. Email List Validation identifies these automatically, so you don’t waste sends on them.

Let’s say you send to a list with 10% role-based or disposable emails. Even if your SPF is technically correct, many of those messages will fail during envelope checks or land in spam folders—sometimes triggering blacklists. These bounce patterns can signal poor sender reputation, which negatively affects your ability to deliver even to valid addresses. Clean lists avoid this cascade.

Verify your setup with real-world inbox placement

Even with a correct SPF record, deliverability depends on real recipient behavior. A single test in a lab environment won’t catch everything. That’s why Email List Validation’s inbox-placement test runs your email through real inboxes across major providers like Gmail, Outlook, and Apple Mail. It checks how your message lands—whether it lands at all and if it ends up in spam.

Think of this as a dry run. You send a test message to a sample of verified addresses across different domains, and the system reports whether it arrived in the inbox, spam, or was blocked. If it ends up in spam, you can adjust your content or sender reputation markers before launching the full campaign. It’s a practical, measurable check that goes beyond SPF compliance.

For full visibility into your list health, start with a bulk email list cleaning or run a real-time verification API check. You can also test your campaign’s inbox placement before sending. These steps don’t fix SPF records—but they prevent the kinds of failures that get mistaken for authentication issues.

Ultimately, SPF setup is a technical layer. Your sender reputation, list hygiene, and domain authentication practices matter more than any single configuration. Email List Validation helps you keep all those layers in check. For context, the SPF specification (RFC 7208) defines how receivers validate senders, but it doesn’t define deliverability. That’s a broader ecosystem—one that starts with a clean, trusted list.

Best practices to maintain SPF validity over time

You should audit your SPF record quarterly—especially after adding email tools—to catch misconfigurations before they cause 564 sender not authorized errors. Use monitoring tools to detect broken records, avoid overly permissive mechanisms like 'all', and consolidate senders via include: directives instead of listing raw IPs. This keeps your SPFs lean, maintainable, and aligned with industry standards.

Quarterly audits and proactive monitoring

Inspect your SPF record every 90 days—automated monitoring services can flag issues like exceeding the 10 lookup limit.
Test your SPF configuration using tools like MXToolbox or RFC 7208’s validation guidelines to catch syntax errors early.
Set up alerts for DNS changes via a service such as DMARC Analyzer to detect unintended modifications to your SPF record.

Constructing robust and scalable SPF records

Never use include:all or all unless you control every sending IP—this commonly triggers SPF failures.
Delegate authority using include: statements (e.g., include:_spf.amazonses.com) instead of listing individual IPs.
If you use multiple senders (like SendGrid, Mailchimp, or AWS SES), combine them under a single, valid SPF with include: directives.
Use the spf2.0/mode=strict or relaxed mechanism only when necessary—most use cases work fine with basic include: chaining.
Limit your record to one SPF TXT record per domain—multiple records can cause validation errors.

When you’re testing or maintaining email deliverability, start with accurate sender data. You can clean large lists quickly with bulk email list cleaning to reduce invalid senders and ensure your SPF setup reflects real-world sending behavior.

When SPF isn’t enough: why DKIM and DMARC are non-negotiable

SPF stops unauthorized senders from using your domain, but attackers can still spoof your From address by bypassing SPF checks. You need DKIM to verify the message wasn’t altered in transit, and DMARC to enforce policies and report how your emails are treated—without all three, you’re missing critical layers of protection and visibility.

SPF only checks the envelope sender, not the user-facing From address

SPF validates the sending server based on the envelope from address, not the one users see in their inbox. That means a malicious actor can set a trusted From address—like [email protected]—while using an untrusted mail server behind the scenes. SPF won’t catch that. It’s like having a guard at the front gate who checks IDs but ignores what’s written on the letter inside.

DKIM and DMARC close the gaps

DKIM adds a digital signature to each email body and headers. When the receiving server checks it, the match proves the message hasn’t been tampered with since it left your server. Even if an attacker gets past SPF, they can't forge a valid DKIM signature—this stops content tampering and spoofing attempts.

DMARC sits on top, telling receivers what to do when SPF or DKIM fails. You can set a policy like “reject” (block bad emails) or “quarantine” (send to spam). It also provides reports, so you can see how your domain is being used, including unauthorized use. Without DMARC, you’re flying blind—emails may be flagged as spam, and you won’t know why.

Studies show that domains with DMARC policies in place see fewer phishing attempts and better inbox placement. According to the Anti-Phishing Working Group, domains using DMARC reduced the likelihood of being targeted by attackers significantly. That’s because DMARC gives email providers the tools to act decisively when abuse is detected.

Deploying all three—SPF, DKIM, and DMARC—closes the loop. It reduces hard bounces from rejected messages, lowers phishing reports, and improves sender reputation. These aren't optional features; they're the foundation of deliverability. For teams managing large lists, validating email addresses before sending can catch invalid or risky domains early—helping keep your outbound list clean and trusted. You can test your full setup using inbox placement tools, or validate your list in bulk to ensure only active, authentic inboxes receive your messages. Use the bulk verification tool to catch weak or spoofed addresses before they hurt your reputation.

The bottom line: stop sending until SPF is correct

You can’t fix a 564 error by sending more emails. Doing so risks damaging your sender reputation, triggering rate limits, or getting blocked entirely. The fix requires validating your DNS SPF record, testing the result, and only resuming sends after confirmation. A single misconfigured SPF record can harm all future delivery.

Why the 564 error hurts your deliverability

When a receiving server returns a 564 "sender not authorized" error, it’s rejecting your message because your domain’s SPF record doesn’t list your sending server as valid. This isn’t a minor flag—it’s a hard rejection. Repeated instances degrade your sender reputation with major email providers like Gmail and Microsoft.

Receiving servers track these errors across senders. If they see repeated 564 responses from your domain, they may rate-limit future messages or block your domain entirely. This isn’t a theoretical risk—it’s a common cause of long-term inbox placement failure. According to the RFC 7208, SPF is designed to prevent domain spoofing, and strict enforcement is standard across major providers.

Fix it right the first time

Fix your SPF record by checking that your sending IP or service (like Mailchimp or SendGrid) is listed in the include or ip4 mechanisms. Avoid common missteps: too many mechanisms, overlapping records, or failing to update when changing sending platforms. Use tools like MxToolbox to verify your published record matches your intended configuration.

Once updated, test it. Don’t just assume it works. Use a real-time email validation service to confirm your domain can send without error. You can also run inbox placement tests to see how your emails land in inboxes. Tools like Email List Validation’s inbox placement testing show you exactly how your messages perform across Gmail, Outlook, and others.

After confirming SPF is correct and deliverability is stable, only then should you resume sending. Sending before validation risks repeating the error, resetting progress, and making it harder to recover your reputation.

Final check: is your SPF setup working?

After updating your DNS SPF record, use a public validator like MxToolbox or DMARC Analyzer to confirm it resolves correctly and contains no syntax errors.

Test the full chain

Send a test message to a personal inbox and inspect the full email headers for SPF: pass. A missing or failing SPF check confirms the record isn’t being interpreted as intended.

Avoid pitfalls

Ensure only one SPF record exists per domain. Duplicate records—especially across subdomains or DNS zones—trigger validation failures. Use a DNS lookup tool to scan all zones for redundancy.

Simulate real-world delivery

Run a delivery test via Email List Validation’s inbox-placement feature. It checks how your message lands across major inboxes using real mailbox data, identifying issues before bulk sends.

Keep reading

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

Frequently asked questions

What does the 564 sender not authorized error mean?

It means the receiving mail server rejected your message because your domain’s SPF record does not authorize the sending IP or service.

Can I have multiple SPF records in DNS?

No. Only one TXT record per domain is allowed. Multiple records cause misconfigurations and delivery failures.

How often should I update my SPF record?

Review and update it whenever you add new email services or switch sending platforms.

What’s the difference between ~all and -all in SPF?

~all is a soft fail—messages are accepted but flagged. -all is a hard fail—messages are rejected. Use ~all during setup.

Does SPF protect against all email spoofing?

No. SPF only verifies the envelope sender. Use DKIM and DMARC for full protection.

Why do some emails still fail after fixing SPF?

Other issues like poor sender reputation, missing DKIM, or a low inbox placement score could still block delivery.

Can I use Email List Validation to check SPF settings?

Not directly. But it helps verify your list and test inbox placement, reducing delivery risks from other sources.

How long does SPF DNS propagation take?

Typically 10 to 30 minutes, though some DNS providers take longer.

Is it safe to use include:sendgrid.net in SPF?

Yes, as long as SendGrid is your authorized sender. Always verify it's a trusted, official service.

What happens if I delete my SPF record?

Emails will fail authentication unless DKIM and DMARC are properly configured. Most servers reject messages without SPF.

Should I include my own IP address in SPF?

Only if you send directly from a server not covered by another include statement. Otherwise, it’s redundant.

How do I verify that my SPF record works?

Check the full email headers after sending a test message, or use a public validator like MxToolbox.