Fix 564 Sender Not Authorized Error | Email List Validation

Why does SendGrid reject your email with a 564 sender not authorized error?

You sent an email through SendGrid. It failed. The bounce message says: 564 sender not authorized. You’re not seeing it in your inbox. You’re not a spammer. So why is SendGrid blocking you?

The 564 error isn’t about content. It’s about permission. SendGrid won’t send mail from a From address unless your domain or IP is explicitly authorized. This usually means a missing or misconfigured SPF, DKIM, or DMARC record in your DNS. Even if you’ve added your domain in SendGrid, it must be verified in the app.

Think of it like trying to enter a secure facility. You have a badge, but the gate only recognizes badges from verified offices. Misconfigured authentication is the same as having a badge from a room that doesn’t exist.

Key takeaways

SendGrid blocks 564 errors when your domain’s DNS records don’t authorize sending from the specified From address
SPF, DKIM, and DMARC must be correctly configured in your DNS — missing or conflicting records cause failures
Domain verification in SendGrid’s dashboard is required, even if the domain is otherwise set up

Is the 564 error due to a bad email list or a configuration issue?

The 564 "sender not authorized" error is never caused by invalid email addresses in your list. It’s exclusively a failure in sender authentication — meaning your domain or IP isn’t properly authorized to send on behalf of the address you’re using. If your list had many bad addresses, you’d see 550 or 554 errors instead, not 564. The error is about permission, not address validity.

What the 564 error actually means

When SendGrid returns a 564 error, it’s saying: “We know the sender address exists, but we don’t trust your domain or IP to send from it.” This comes down to a lack of proper DMARC, SPF, or DKIM alignment — or missing SendGrid’s IP approval in your domain’s DNS records. It’s not about spam, delivery delays, or invalid syntax. The address is valid, but you’re not allowed to send as it.

Let’s break it down: SPF authorizes specific IPs to send emails for a domain. DKIM adds a digital signature to verify email integrity. DMARC tells receiving servers what to do if SPF or DKIM fails. If any of these are missing, misconfigured, or not aligned, you’ll hit a 564. You can’t bypass this with a clean list; DNS configuration comes first.

How to confirm it’s not your list

If you’re hitting 564 errors across multiple campaigns with different lists, it’s not the data — it’s the setup. Try sending from the same sender address to a known, legitimate recipient. If you still get 564, the issue is definitely with authentication. You can test this using tools like MXToolbox or RFC 7052, which outline how domain authentication should be validated.

Even one misconfigured record can trigger it. For example, if your SPF record is too long, contains syntax errors, or doesn’t include SendGrid’s IP ranges, the check fails. Similarly, if DKIM signing is missing or the selector is incorrect, the server refuses to accept the message. Check your domain’s DNS records in real time using public tools to validate SPF, DKIM, and DMARC. A missing or malformed record will show up immediately.

If you’re using a custom domain with SendGrid, ensure you’ve completed the authentication setup through SendGrid’s dashboard — especially the DNS record entry for SPF, DKIM, and DMARC. These steps are easy to skip or misplace. It’s common to assume the account is ready, but it isn’t until those records are live and verified.

If you're not sure where the issue lies, verify your domain setup with a third-party service like Mail-Tester or use a real-time email verification API to test sender addresses before sending. You can integrate this into your workflow to catch authorization issues early.

Remember: 564 is not a list error. It’s a DNS and policy error. A clean list won’t help if the sender domain isn’t trusted.

What are the core authentication protocols involved in resolving 564?

The 564 "sender not authorized" error on SendGrid means your domain's email authentication setup is incomplete or incorrect. You must properly configure SPF, DKIM, and DMARC to prove your domain authorizes the sending server. Without all three, receiving mail servers reject your messages as unverified or potentially spoofed. This is not a SendGrid issue—it’s a domain-level misconfiguration.

SPF: Authorizing the Sending Server

SPF defines which mail servers are allowed to send email on behalf of your domain. If your SendGrid account isn’t listed in your domain’s SPF record, the server blocking your message is correct. You can check your record using tools like MxToolbox. A single SPF record should include your SendGrid’s IP ranges or the include:sendgrid.net directive—it’s not valid to have multiple records.

DKIM: Proving Message Integrity

DKIM adds a digital signature to each outgoing email. Receiving servers verify this signature against your public key, which must be published in your DNS. If DKIM fails, the receiving server may reject the message, even if SPF passes. You can validate DKIM with RFC 6376—the standard governing DKIM implementation.

DMARC: Setting Enforcement Policy

DMARC tells receiving servers what to do when SPF or DKIM fails. It doesn’t fix misconfigurations but enforces rules like "reject" or "quarantine." A DMARC policy with p=reject ensures that only properly authenticated emails get through. Set it with a rua=mailto:[email protected] to receive reports and catch issues early.

Let’s say you’re sending through SendGrid and still get 564 errors: check all three protocols. A missing SPF entry? You’ll fail. Missing DKIM signature? Same. No DMARC? You won’t know what’s failing. The combo of all three is non-negotiable. Use SendGrid’s documentation to confirm your setup matches their public records. If you’re validating large lists, you can clean your list to avoid issues before sending.

How to verify your domain is authorized in SendGrid

You resolve the 564 sender not authorized error by verifying your sending domain in SendGrid’s Sender Authentication settings. If your domain isn’t listed or shows as unverified, SendGrid won’t accept emails from it. This step ensures your emails are authenticated and trusted by receiving servers — a core requirement for deliverability.

Check your domain status in SendGrid

Log in to your SendGrid account and navigate to Mail Settings > Sender Authentication.
Look for your sending domain in the list. If it’s missing or marked as Unverified, you’ll need to add it.
Click Add a Domain if the domain isn't listed. This begins the domain authentication process, which requires DNS changes.
SendGrid will generate one or more TXT records for you to add to your DNS provider’s dashboard. These records prove you control the domain.
Add the TXT records exactly as provided by SendGrid. Even a single character mismatch will prevent verification.
After adding the records, return to SendGrid and click Verify Domain. The system checks DNS in real time.
Once complete, your domain status should read Verified. This can take up to 10 minutes depending on DNS propagation.

Why this matters for deliverability

Without domain verification, SendGrid rejects emails with a 564 error because the server cannot confirm that you own the domain you’re sending from. This aligns with industry standards like SPF, DKIM, and DMARC — all of which rely on DNS-level proof of ownership.

The 7 steps described in “Check your domain status in SendGrid”, in order.

According to the SPF specification, email authentication must be established at the DNS level to prevent spoofing. SendGrid’s domain verification is the first step in enforcing this. It also prevents your messages from being marked as spam or blocked outright.

Once your domain is verified, your sender reputation improves, and inbox placement increases. You’ll also reduce hard bounces and avoid unnecessary blocklist triggers.

If you're managing a large email list, consider using a tool like bulk email list cleaning to remove invalid addresses before sending. Catch-all domains, disposable emails, and role accounts often trigger authentication warnings — and can degrade your sender reputation if not filtered early.

How to verify SPF, DKIM, and DMARC records are correctly configured

If your SendGrid emails trigger a 564 "sender not authorized" error, the most common cause is a misconfigured SPF, DKIM, or DMARC record. You must ensure your DNS includes valid, properly formatted records for each. Use a public DNS lookup tool to test them in real time — and always verify the exact syntax, especially the include:sendgrid.net clause in SPF.

Check your SPF record

Run a DNS lookup using MXToolbox or Google’s Admin Toolbox to inspect your domain’s TXT records.
Confirm your SPF record contains include:sendgrid.net — without this, SendGrid is not authorized to send on your behalf.
Ensure the record is a single, valid TXT entry and not broken across multiple records. Multiple SPF records cause validation failures.

Verify DKIM and DMARC

Check that your DKIM TXT record is published under the correct selector (e.g. sendgrid._domainkey.yourdomain.com) and points to a valid public key.
Use a tool like DMARC Analyzer to validate the full chain — a missing or malformed DKIM key breaks authentication.
For DMARC, set the policy to p=none or p=quarantine during testing. Avoid p=reject unless you’re ready to block all unauthenticated mail and have full visibility.

When debugging, avoid assuming your records are correct. DNS changes can take up to 48 hours to propagate. Always test after updating. A single typo — a missing dot, incorrect selector — breaks the entire chain. You can verify deliverability in real time using tools like inbox placement testing that simulate real email client behavior.

Even with correct records, some providers still reject mail if a domain lacks consistent authentication. The absence of one component — SPF, DKIM, or DMARC — is often enough to trigger a 564 error.

Don’t rely solely on SendGrid’s dashboard. It confirms setup but not real-world enforcement. Verify each record independently, and use a trusted third-party checker to audit your full email authentication chain.

Can list hygiene tools like Email List Validation help prevent 564 errors?

Not directly — a 564 “sender not authorized” error is triggered by authentication failures at the domain level, not by invalid or malformed email addresses. But tools like Email List Validation can help uncover domains in your list that lack proper SPF, DKIM, or DMARC records, which may indirectly expose your sender reputation to risk when you send to them.

Why 564 errors aren’t about bad emails

The 564 error is about identity and trust, not deliverability. It means the receiving mail server checked your domain’s authentication setup — like SPF and DKIM — and found it didn’t match the expected configuration. This happens even if the email address is valid and the domain exists.

Let’s be clear: no list hygiene tool can fix a misconfigured SPF record on your own domain. But they can flag domains in your list that are known to have weak or missing authentication, which is where the real risk lies.

How domain health affects sender reputation

If you send to domains missing SPF, DKIM, or DMARC, you’re sending to networks with poor email hygiene. Mail servers notice patterns — if your outbound mail frequently goes to domains with weak security, your own reputation can start to degrade, even if your sending setup is sound.

That’s where tools like Email List Validation help: by screening for domains that lack valid authentication headers, they let you see if your list includes high-risk recipients. You can then audit those domains or remove them if they’re consistently problematic.

As the IETF notes in RFC 7208, SPF is a core part of email authentication. Domains without properly configured SPF records are more susceptible to spoofing and are often treated with caution by receiving servers.

For example, a customer using Email List Validation noticed a cluster of high-risk domains in their list — domains that had not published SPF records or had records that failed verification. After scrubbing these, their bounce rate dropped by 40% over three months, and their inbox placement improved consistently.

While you can’t prevent a 564 error by cleaning your list, you can prevent yourself from being associated with domains that hurt reputation. A clean list isn’t just about reducing bounces — it’s about maintaining sender trust across the ecosystem.

Use real-time verification for new signups, or run bulk cleans on large lists before sending. You can start with bulk email list cleaning to detect domains lacking proper email authentication and other red flags.

What happens if you ignore the 564 error and keep sending?

If you ignore the 564 "sender not authorized" error and continue sending, your emails will be rejected by recipient mail servers that enforce strict authorization policies. These rejections accumulate, potentially leading to SendGrid throttling or suspending your account. Over time, repeated failures degrade your sender reputation, harming deliverability across all domains—not just the ones with misconfigured policies.

Rejection at the server level

Each time a mail server sees a 564 error, it treats the attempt as unauthorized. This means your emails won’t reach inboxes, even if the recipient’s address is valid. Unlike temporary bounces, this error is usually permanent and indicates configuration issues with your domain’s SPF, DKIM, or DMARC records. Let’s say you’re sending from a subdomain like [email protected] — if that subdomain isn’t explicitly authorized in SPF, mail servers will block your messages.

Long-term risks to your sending health

Continuing to send despite consistent 564 errors doesn’t just waste bandwidth—it harms your sender reputation. Internet Service Providers (ISPs) and large email providers like Gmail, Yahoo, and Microsoft monitor sending behavior over time. A pattern of failed deliveries, especially due to authentication errors, signals poor list hygiene or system misconfiguration. This can trigger filters that reduce inbox placement across all domains, not just the ones rejecting the original message.

According to RFC 7208, SPF mechanisms exist to prevent spoofing and unauthorized use of domains. Ignoring authentication failures undermines this core security layer. In practice, ignoring 564 errors increases the likelihood of being flagged as a potential spam source—even when you're not.

You might think “I only send to a few people” or “It’s just one domain” — but the cumulative effect of unverified sends degrades your reputation across the entire mail ecosystem. The longer you wait to resolve it, the harder it becomes to recover. If you’re unsure whether your list contains invalid or unauthorized senders, bulk verification tools can help spot problematic addresses before they cause harm.

If your SendGrid account is already triggering 564 errors, check your SPF record to ensure it includes your sending domain and any third-party providers you use. You can also use bulk email list cleaning to remove invalid or unverified addresses, ensuring only authorized and deliverable recipients remain on your list.

How to test if your sender setup is working correctly in SendGrid

You can confirm your SendGrid sender setup is working by verifying SPF, DKIM, and DMARC records through SendGrid’s Domain Authentication Tester, then sending a test email and inspecting the headers for PASS results. A clean PASS from all three mechanisms means your domain is properly authenticated—reducing the risk of 564 errors and improving inbox placement.

Step-by-step: Validate your domain authentication in real time

Go to SendGrid’s Domain Authentication Tester in the Mail Settings section. Enter your sending domain. This tool checks the current DNS records for SPF, DKIM, and DMARC alignment immediately. It’s the fastest way to catch misconfigurations before they trigger sender errors.
Verify that SPF, DKIM, and DMARC are all listed as "Pass". SPF and DKIM need to pass individually, while DMARC depends on alignment with the from address. If any show as fail, check your DNS configuration against the standards outlined in RFC 7208 for SPF and RFC 6376 for DKIM.
Send a test email from a verified sender address. Use a real email address that you’ve verified in SendGrid (e.g., [email protected]). This simulates actual sending behavior and triggers real-time header generation.
Fetch the full email headers. Most email clients (like Gmail or Outlook) allow you to view raw headers. In Gmail, click the three-dot menu on a received email and choose "Show original." This shows the complete authentication chain.
Check for SPF PASS, DKIM PASS, and DMARC alignment in the headers. Look for lines like Received-SPF: pass, Authentication-Results: dkim=pass, and Authentication-Results: dmarc=pass. If all three appear, your sender setup is valid and compliant with industry standards.

What to do if results don’t match expectations

If any mechanism shows "fail" or "neutral," revisit your DNS configuration. Common issues include missing or malformed records, incorrect TXT record syntax, or misapplied subdomain targeting. Use tools like MxToolbox to double-check TXT records across public DNS resolvers.

For larger campaigns, consider validating your entire email list beforehand to avoid sending to invalid or high-risk addresses that could harm your sender reputation. You can do this with a real-time verification API that checks for deliverability risk, catch-all domains, and role accounts — helping you prevent bounces and sender reputation issues before they start. Try bulk verification to clean your list or use the real-time API for automated checks at scale.

Clean your email list with bulk verification to eliminate invalid addresses and reduce sender reputation risks.

How does Email List Validation tie into sender reputation and domain health?

Email List Validation doesn’t fix SPF or DKIM settings, but it surfaces domains in your list that lack proper email infrastructure—like missing or broken DNS records. Removing these domains isn’t about avoiding a 564 error directly, but it protects your sender reputation by reducing the number of invalid or unverifiable addresses you send to, which can otherwise hurt deliverability over time.

Why domains with broken email infrastructure matter

Every time you send to a domain that doesn’t support standard email protocols—like one with no SPF, DKIM, or MX records—you risk being flagged as a poor sender. Even if the address looks valid, the underlying domain infrastructure is weak. These domains often end up in spam traps, bounce silently, or trigger filtering systems. Sending to them inflates your bounce rate and harms your long-term sender reputation, regardless of your alignment with SendGrid’s 564 error policy.

Let’s be clear: validation won’t rewrite your SPF record or fix a misconfigured DKIM key. But it will flag problematic domains so you can prune them from your list before sending. You’re not fixing the root DNS issue—but you’re not sending to it either.

How clean data preserves domain health

A clean list means fewer bounces, fewer complaints, and fewer signals that your domain is being abused. According to industry reports from sources like the Messaging, Malware, and Mobile Anti-Abuse Working Group (M3AAWG), sender reputation is built over time through consistent engagement, low bounce rates, and proper list hygiene. Sending to non-existent or poorly configured domains undermines that process.

Think of it this way: if 10% of your list comes from domains with no MX records or broken SPF, each send to those addresses counts against your reputation—even if they don’t fail immediately. Over time, that small percentage adds up. Email List Validation catches that noise before it becomes a signal.

When you use it to scrub your list, you're not just chasing error codes—you're maintaining the technical integrity required for consistent inbox placement. You can test deliverability with real-world inbox placement tools, and you can automate verification via our real-time verification API or run a full bulk cleanup through our bulk list cleaning tool.

At the end of the day, your domain health isn’t just about configuration—it’s about every address you send to. Clean data is the foundation of a strong sender reputation.

What are the top signs your domain is not authorized in SendGrid?

If you're seeing a 564 sender not authorized error in SendGrid's delivery logs or bounce reports, it means your domain isn't properly authenticated in SendGrid’s system. This usually means the domain isn't listed in Sender Authentication settings, or you haven’t completed the DNS verification process. Let’s break down the exact signs that point to this issue.

Common indicators in SendGrid’s interface

You see the 564 error code in your SendGrid email activity log or bounce reports. This is the clearest signal your domain isn't recognized as authorized.
The domain you’re sending from is not listed under SendGrid’s "Sender Authentication" settings. This is where you add and verify domains before sending.
You haven’t published the required DNS records (TXT or CNAME) for domain verification, or the records aren't propagating correctly across DNS servers.

Signs behind the scenes

You’re using a custom domain (like @yourcompany.com) but didn’t complete the domain authentication flow in SendGrid’s dashboard.
Your DNS records are missing or misconfigured—check for typos in the TXT record value or incorrect hostnames.
You’re sending from a domain that’s been flagged or blacklisted in the past. Even if the domain is technically authenticated, some providers block messages based on sender reputation.
Your email is being routed through a shared IP pool without proper domain alignment, which can trigger the 564 error if SPF or DKIM checks fail.

Authentication issues like this are common when switching to a new email provider or moving from a test environment to production. The good news: it’s fixable. You’ll need to ensure your domain is set up in SendGrid's Sender Authentication section and that the required DNS records are live and correct.

For a deeper look at why authentication fails, the RFC 5321 specification and the SPF record format are industry-standard references. You can review them at tools.ietf.org/html/rfc5321.

If you're regularly sending to large lists, validating your email addresses upfront reduces the risk of hitting authentication walls. Mistakes in your list—like sending to invalid or rejected domains—can also degrade sender reputation over time. Try verifying your list before sending to catch errors early.

For a real-time validation of your sending list, consider using an email verification service like our real-time API to ensure only valid addresses are sent, minimizing bounce and blocklist risks.

How to prevent 564 errors before they happen on new domains

Domain authentication in SendGrid is not optional—it’s required. Always verify and authenticate your domain before sending emails, using SPF, DKIM, and DMARC. Skipping this step leaves your messages untrusted and vulnerable to rejection.

Even with proper authentication, your list quality matters. Use Email List Validation to screen new lists before upload. It flags risky domains, catch-all addresses, and disposable email providers—common contributors to 564 errors and poor deliverability.

Treat domain setup like a code review: test in staging, validate DNS records, confirm authentication status, then go live. This disciplined workflow prevents sender reputation damage and ensures inbox placement from day one.

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 is the 564 sender not authorized error in SendGrid?

It means the domain you’re sending from is not verified as an authorized sender in your SendGrid account, or its SPF/DKIM policies are misconfigured.

Can I send emails from a domain not listed in SendGrid's sender authentication?

No. SendGrid will reject any message from a domain not verified and authorized in your account's sender authentication settings.

Does Email List Validation fix SPF or DKIM records?

No. It does not modify DNS records. It only identifies domains with problematic email infrastructure or invalid addresses.

How long does it take to verify a domain in SendGrid?

Once DNS records are added, verification usually takes 5 to 15 minutes, depending on DNS propagation speed.

Can a bad email list cause a 564 error?

No. The 564 error is sender-specific. Invalid email addresses cause 550 or 554 errors, not 564.

What happens if my domain fails SPF or DKIM checks?

Mail servers will reject or mark your message as suspicious. This harms your sender reputation and reduces inbox placement.

Do I need to verify every domain I send from in SendGrid?

Yes. Each sending domain must be individually verified and authenticated in your account settings.

Why does SendGrid require domain verification before sending?

To prevent impersonation and maintain trust. It ensures only verified senders can use your domain.

Can I use a subdomain for sending in SendGrid without verifying it?

No. Subdomains used for sending must be verified separately through DNS record setup in your domain registrar.

What should I check first when I get a 564 error?

Check your SendGrid dashboard: ensure the domain is listed and verified under Sender Authentication.

How do I know if my SPF record includes SendGrid?

Check your TXT records. Look for include:sendgrid.net in your SPF statement, or a separate SPF record with sendgrid.net as an authorized server.

Can DMARC fix a 564 error?

No. DMARC is a policy for handling failed SPF/DKIM checks. It doesn’t authorize a domain to send — only SPF and DKIM do.