SMTP 558 Error Code Meaning: Sender Policy Rejection Guide

What does SMTP 558 mean when your email bounces?

You send a campaign. All your metrics look good. Then you check the delivery report — and see a string of 558 errors. Your emails aren’t just delayed. They’re blocked. And no one’s telling you why.

SMTP 558 is a hard bounce code. It means the recipient server rejected your email based on sender policy. Not because the address is invalid. Not because it’s spam. But because your domain’s email authentication doesn’t match what the server expects. Specifically, your SPF record doesn’t permit the sending IP. This is a common reason bulk sends fail — especially when using third-party tools, shared servers, or misconfigured mail systems.

Key takeaways

• SMTP 558 means your sending domain’s SPF policy blocks the IP address attempting to deliver the email.
• It’s a hard bounce: the message will not be delivered unless the SPF record is corrected.
• SPF misconfigurations are a frequent cause of bulk email delivery failure, especially with automated or outsourced sending systems.

How sender policy rejection breaks email deliverability

If your email gets a 558 error due to sender policy rejection, it means the receiving server checked your SPF record and found no authorization for your sending domain. Even if your message is clean, your reputation is strong, and you’re sending through a trusted service, a single misconfiguration in your SPF record can result in immediate rejection—before the message ever reaches an inbox. This isn't a delay; it’s a hard block based on policy failure.

SPF is the gatekeeper of sender authorization

Every time you send an email, the receiving server checks your domain’s SPF record—a DNS entry that lists which servers are allowed to send on your behalf. If your sending IP isn’t listed there, the server rejects the message with a 558 error. This is not a soft bounce or a spam filter. It’s a fundamental policy violation.

Let’s say you’re using a third-party email service. If you didn’t include their servers in your SPF, or if your SPF record exceeds the 10 DNS lookup limit (as defined in RFC 7208), the check fails. The result? A 558 error, and no delivery.

Even strong reputations can’t override SPF mismatches

You can have a stellar sender reputation, a clean content history, and perfect engagement metrics—yet still face a 558 error if your SPF is off. That’s because SPF policies are enforced at the network level. A single misconfigured record breaks trust at the very first checkpoint.

This is especially common with email list verification. If you’re using outdated or improperly formatted lists, you may accidentally send from IPs that aren’t authorized. That’s where tools like bulk email verification help—by filtering out invalid, misconfigured, or unauthorized senders before they hit your mail server.

SPF failures are also common with domain transfers or when switching providers. Even small changes—like adding a new sending service—require updates to your SPF record. A missed update can cause a 558 error across hundreds or thousands of messages.

Understanding how SPF works is critical. The IETF’s SPF specification defines the standard, but real-world implementation is often flawed. Tools that test SPF records in real-time, like those included in our inbox placement testing, can prevent these issues before they impact your deliverability.

What causes an SMTP 558 error in real-world email sending?

The SMTP 558 error—“Sender Policy Rejected”—means your email was blocked because the receiving server checked your domain’s SPF record and found no authorization for your sending IP. This commonly happens when SPF is missing, misconfigured, or fails to include third-party services used to send email. It’s a technical gatekeeper preventing spoofing, and it’s enforced by default across major providers.

Common misconfigurations that trigger SMTP 558

• SPF records that omit authorized sending IPs, especially those tied to your email platform or infrastructure.
• Using multiple email services—like Mailchimp, SendGrid, or AWS SES—without updating SPF to include all their IP ranges, causing gaps in authorization.
• Switching email platforms without revising SPF, leaving the old record outdated and blocking all new messages.
• Overloading the SPF record with too many mechanisms (like too many include directives), which can trigger a DNS lookup limit and cause SPF to fail silently.
• Having conflicting or duplicate SPF records in DNS, which results in a policy conflict that most servers resolve in favor of rejection.

How to avoid SPF breakdowns before they happen

Let’s be clear: SPF is not optional for domain-level deliverability. A single misstep can mean your emails land in spam or vanish without trace. The best practice is to audit your SPF record regularly—especially after any infrastructure or platform change.

Use tools that validate SPF alignment at scale. You can test your current SPF setup with public DNS tools like MxToolbox or check RFC 7208, the standard governing SPF (RFC 7208), for exact mechanics. When sending with multiple services, ensure each one is explicitly authorized in your SPF record using include directives.

For example, if you use both HubSpot and SendGrid, your SPF record must list both domains. Omit either, and the receiving server sees it as unapproved.

If you’re doing bulk email sending, a clean list matters—invalid or poorly formatted addresses increase risk. You can verify entire lists before sending with bulk verification to catch issues early, including domains with weak or broken SPF records.

Finally, don’t assume SPF is static. Changes in your email workflow—new tools, new servers—require updates. A single outdated record can block all outbound mail from your domain.

Why SPF, DKIM, and DMARC are not optional for deliverability

When your email gets an SMTP 558 error, it’s often because a receiver rejected your message due to failed authentication—specifically, SPF, DKIM, or DMARC checks. These three protocols aren’t just technical checkboxes; they’re the foundation of sender reputation. Without them, even legitimate emails land in spam or get outright blocked, especially by large providers like Gmail and Outlook. You can’t rely on deliverability without them.

How each protocol stops abuse and builds trust

SPF validates the sending IP address against your domain’s published policy. If an email comes from an IP not on that list, the receiver flags it as suspicious. DKIM signs the actual message content—so if the body or headers are tampered with, the signature fails and the email is rejected. DMARC ties the two together: it tells receiving servers what to do when SPF or DKIM fails, and often that action is rejection.

Think of SPF as a gatekeeper checking IDs at the front door, DKIM as a tamper-evident seal on the envelope, and DMARC as the enforcement rule that says: “If either fails, block the message.” Without them, your domain is open to spoofing. Reputable email providers—like those listed by the Messaging, Malware, and Mobile Anti-Abuse Working Group (M3AAWG)—treat unauthenticated senders as high risk, especially if they’re sending at scale.

Why 558 often means your authentication failed

When you see a 558 error, it’s usually a DMARC policy enforcement action. Even if one of SPF or DKIM fails, DMARC policies—especially p=reject—can instantly block the message. That means a single misconfigured record, a forgotten DNS entry, or a change in your sending infrastructure can trigger rejection.

This isn’t hypothetical. The DMARC specification explicitly allows receivers to reject messages when policies aren’t met. And according to feedback from major ISPs, rejection rates spike sharply on domains that don’t enforce DMARC policies, particularly during bulk sends. It’s not a bug—it’s the intended behavior.

Let’s be clear: you don’t get to opt out of this. Every bulk email campaign, every transactional send, every list import risks deliverability failure without proper alignment between your sending setup and your DNS records. Even a single invalid email address in a large list can expose your sender reputation if it’s tied to weak or missing authentication.

Real-time verification tools like bulk verification can catch malformed or invalid domains before they cause issues. They confirm not just deliverability, but also whether a domain’s authentication setup supports valid email transmission. That’s one reason we don’t just check if an email exists—we check if it can be delivered safely.

How to diagnose an SMTP 558 error in your email workflow

SMTP 558 means your email was rejected because the recipient’s server did not recognize your domain’s SPF record. This happens when your sending domain isn’t properly listed in the SPF record of the domain you’re sending from. It’s one of the most common reasons for hard bounces and blocked deliverability, especially with large outbound campaigns. Let’s walk through how to pinpoint and fix it.

Step-by-step diagnosis process

1. Check your bounce reports for the 558 code and recipient domain. Look for the exact error message in your email service provider’s bounce or delivery logs. The 558 code indicates a policy rejection — specifically, that the recipient’s mail server rejected your message based on SPF validation. Note the domain that rejected you. This helps isolate whether the issue is global or specific to certain domains.
2. Verify your domain’s SPF record using a DNS lookup tool. Use a real-time DNS tool like MXToolbox or run dig txt yourdomain.com in your terminal. Look specifically for the SPF record. Make sure it’s properly formatted and includes all the servers or services you use to send email from your domain.
3. Ensure every sender is authorized in your SPF record. If you send email via third-party services (like SendGrid, Mailchimp, or your own mail servers), each must be explicitly listed in the SPF record using mechanisms like include: or ip4:. Missing entries here trigger 558 errors, even if the message is legitimate.
4. Test your SPF setup against industry standards. SPF records must not exceed 10 DNS lookup limits. Overly complex or poorly nested includes can cause misinterpretations. Tools like RFC 7208 define SPF syntax and validation rules — these are the foundation of how recipient servers process your domain’s policy.
5. Monitor long-term SPF health after changes. After updating your SPF record, allow 24–48 hours for DNS propagation. Continue checking bounce reports and use inbox placement testing to verify your fixes improved deliverability. A single missing entry can still block deliveries.

Avoiding common pitfalls

Don’t assume SPF is “set and forgotten.” As your sending stack evolves — adding new tools, migrating servers — you need to update your SPF record. Over time, these changes can create gaps. For example, if you start using a new email service provider, but forget to include it in SPF, you’ll see 558 errors in your logs.

Using real-time verification before sending helps avoid this. For example, bulk email verification checks for invalid or misconfigured addresses early, filtering out domains that are likely to reject your emails based on policy issues.

SPF vs DKIM vs DMARC: Roles and real-world conflicts

You're seeing an SMTP 558 error because your sending domain's DMARC policy rejects emails where SPF fails, even if DKIM passes. SPF authorizes specific IPs to send on your domain's behalf; DKIM adds a digital signature to ensure message content hasn’t changed; DMARC ties both together and tells receivers what to do when a check fails—like quarantining or rejecting the email. A mismatch in any of these can trigger rejection. Let's break down how they interact and why misconfigurations are a top cause of deliverability failure.

How the three work together in practice

When an email arrives, receivers check all three protocols. SPF verifies the sending server IP is in your allowed list. DKIM checks that the email body and headers haven't been altered since signing. DMARC interprets both results and enforces your policy—reject, quarantine, or allow. Even if DKIM passes, a failed SPF can still lead to a 558 rejection if your DMARC policy is set to reject.

Real-world example: You use a newsletter platform that sends via its own IP, but you’ve only added your own company IP to SPF. DKIM may pass because the platform signs the email, but SPF fails — and if your DMARC policy is set to reject, the message gets blocked with an SMTP 558.

How to avoid deliverability breaks

Check your SPF records for missing or outdated IPs. Ensure DKIM keys are consistent across all senders. Use DMARC reports to monitor failures — and avoid "reject" until you’ve verified your setup across all sending sources. The DMARC specification (RFC 7483) makes this standard, but implementation nuances cause 558 errors daily.

Before sending to a new list, validate it with real-time checks to catch SPF/DKIM/DMARC mismatches early. Use a tool like bulk verification to test a list’s deliverability health — it checks DNS records, catches invalid or risky addresses, and flags possible policy conflicts before you send.

How to fix SPF policy rejection before sending to a new list

If you're hitting an SMTP 558 error due to sender policy rejection, it means your SPF record is misconfigured or missing authorized sending sources. Fix it by auditing your current SPF, adding all active email services using include: mechanisms, and keeping the total number of mechanisms under 10 to avoid fallback failures. This prevents bounces and protects sender reputation.

Step 1: Audit your current SPF record

Start by checking your domain’s current SPF configuration. Use tools like MXToolbox or run dig TXT yourdomain.com in your terminal. Look for lines starting with v=spf1. The record should list all authorized sending services. If you don’t see your ESPs listed, that’s likely why the 558 error appears.

Step 2: Add all sending services with include mechanisms

For every service you use—Mailchimp, Klaviyo, SendGrid, or others—add an include: mechanism to your SPF record. For example: include:_spf.mailchimp.com. These mechanisms allow the receiving server to verify that your sending service is authorized. Skipping even one means emails from that service risk rejection.

Step 3: Stay under 10 mechanisms to avoid policy failure

SPF has a limit of 10 DNS lookups per evaluation. Each include:, ip4:, ip6:, or redirect: counts toward that total. If you exceed 10 lookups, the SPF check fails and sends may be rejected, even if you're authorized. Monitor your record’s mechanism count—tools like RFC 7208 define the standard.

1. Access your DNS provider’s console (e.g., Namecheap, Cloudflare, AWS Route 53).
2. Locate the TXT record for your domain’s SPF.
3. Review all existing mechanisms and note services not yet included.
4. Add missing services using include: (e.g., include:_spf.sendgrid.net).
5. Count all mechanisms—ensure you stay under 10. Remove outdated or unused services if needed.
6. Save changes and wait up to 48 hours for propagation.
7. Verify the new record using MXToolbox or similar tools.

Once the SPF record is correct, test it with a real email send from each service. Monitor inbox placement with tools that simulate real recipient inboxes. You can validate a list before sending to catch invalid addresses and reduce the risk of deliverability issues, including 558 errors. For bulk list validation that includes SPF health checks, try bulk verification with EmailListChecker.

Why checking your list before sending prevents SMTP 558 issues

You prevent SMTP 558 errors by verifying every email address before sending. Invalid or non-existent addresses trigger rejection logs at the recipient’s mail server, which can degrade your sender reputation and lead to domain-level detection signals that increase the risk of being blocked. Cleaning your list beforehand stops these issues before they start.

How invalid addresses trigger policy-level rejections

When you send to an address that doesn’t exist or is actively rejecting messages, the receiving server logs the event. Over time, repeated failures from your domain can signal poor list hygiene, which can trigger policy rules—even those that aren’t explicitly about spam. Some providers use these signals to apply stricter policies like the SMTP 558 error, which blocks messages citing "sender policy rejection."

Even a few invalid addresses can be red flags. If your domain shows patterns of sending to non-existent or inactive accounts, ISPs may assume you’re sending unsolicited mail or using outdated data. This triggers automated systems that can block future messages, not just from that domain but potentially from your entire IP range.

What happens when your list contains catch-alls or role accounts

Catch-all addresses accept almost any email, even if the specific user doesn’t exist. Sending to them isn’t a failure—but it’s a waste of resources and can still be logged as a bounce. The difference in logging behavior between real bounces and catch-all acceptances is often subtle but detectable. Over time, these mismatches can contribute to reputation scoring models that penalize your domain.

Role accounts like admin@, support@, or info@ are another issue. While they may technically accept mail, they’re often used for filtering or are monitored closely by security systems. Sending to them at scale can trigger suspicion, especially if those addresses are not engaged. A verified list lets you identify and filter these early.

Let’s say you’re targeting 10,000 contacts. If 1,000 are invalid or risky, you’re not just wasting sends—you’re feeding data into systems that can flag your domain. That’s why using a tool like bulk email verification before sending is essential. It checks each address against real-time protocols, including MX records, SMTP responses, and known disposable domains.

Tools like our real-time verification API integrate seamlessly with your workflow, so you don’t need to pause campaigns. You’re sending only to addresses that are both valid and actively receiving. This reduces bounce rates, supports sender reputation, and keeps you out of the range of policy-level rejections like SMTP 558.

For more context on how email policies work, the SMTP RFC 5321 defines how servers handle rejection codes like 558, and Spamhaus provides insight into how sender reputation systems monitor patterns of abuse.

How Emaillistchecker.io prevents SMTP 558 errors via list hygiene

SMTP 558 errors mean your email was rejected due to a failed Sender Policy Framework (SPF) check. This happens when the sending server doesn’t match the domain’s authorized IPs—common with misconfigured or spoofed addresses. Emaillistchecker.io stops these errors before they happen by cleaning your list: removing invalid, disposable, and role-based addresses that often trigger SPF failures or get flagged by filters. Real-time checks and inbox-testing verify deliverability under actual conditions, not just theory.

Bulk verification catches the weak links

• You avoid SMTP 558 errors by running your entire list through bulk verification before sending. This process filters out invalid domains, typos, and non-existent addresses before they hit the mail server.
• Disposable email addresses (like mailinator or temp-mail.org) are removed because they're not trusted for deliverability and often don’t support SPF checks.
• Role addresses (e.g. sales@, info@) are flagged as risky—they rarely pass SPF validation and often have low engagement, increasing spam risk.
• By using bulk verification, you reduce the number of failed deliveries and protect sender reputation.

Real-time checks and inbox testing catch hidden risks

• Our real-time API checks each email against SMTP servers in real time, identifying SPF or DMARC failures before you send.
• This is especially useful when you're sending from third-party platforms or using shared IPs—common causes of SPF mismatches and 558 errors.
• You can simulate your email delivery across real inboxes using inbox-placement testing. This shows whether your message lands in the primary inbox, spam, or gets rejected due to policy issues.
• Testing via inbox placement reveals whether your sender identity is trusted—if SPF is misconfigured, you’ll see a drop in inbox delivery rates.

SPF failures aren’t just technical—they harm reputation. And reputation drives deliverability. Emaillistchecker.io gives you control: clean your list, test your setup, and verify results under real-world conditions. You don’t have to guess if your email reaches inboxes—you can measure it. This is how you prevent 558 errors at scale, not just once.

Can you trust your sender reputation if you still get 558 errors?

You can’t fully trust your sender reputation if you’re still getting SMTP 558 error codes, even if other metrics like open rates look good. The 558 error means the recipient’s server rejected your message due to a failed SPF check, which is a technical signal that your sending domain isn't properly authorized. While reputation is built over time through engagement and deliverability, repeated 558 bounces signal instability to ISPs and can eventually trigger filtering or blocklists, especially if they accumulate.

Reputation vs. SPF: They’re Not the Same, But They Interact

Sender reputation is separate from SPF alignment, but it’s not immune to SPF failures. Internet service providers (ISPs) and blocklist operators use technical signals like SPF, DKIM, and DMARC to assess sender reliability. A single 558 error is likely one false alarm, but if you see it regularly—especially with high-volume sends—it raises red flags about your technical setup. The more 558 errors you generate, the more likely it is that your domain will be flagged as unreliable.

Why Repeated 558 Bounces Hurt Your Reputation

Even if your content is relevant and users engage, ISPs like Gmail and Outlook consider delivery failures a sign of poor sender hygiene. The same systems that track spam complaints and engagement rates also monitor bounce patterns. Consistent 558 bounces indicate unauthorized sending attempts, which ISPs use to adjust their filters and reputation models.

For example, an authenticated sender with high bounce rates (including policy rejections) sees a higher chance of being throttled or sent to spam. According to dmarc.org, incorrect SPF configurations are among the top misconfigurations affecting sender deliverability, often leading to outright rejection. This isn’t just theory—many large email services apply strict enforcement policies based on SPF and DMARC results.

Fixing the root cause—SPF misconfiguration—is the only sustainable path to rebuilding trust. Use tools to audit your SPF records, ensure they’re not over-qualified, and avoid duplicate records. Once configured correctly, use a service like bulk email verification to clean your list and prevent new invalid sends before they trigger 558 errors.

Sender reputation isn’t just about content or engagement—it’s about technical compliance. Ignoring 558 errors means ignoring the foundation of inbox placement. Fixing SPF isn’t a one-time step. It’s part of ongoing sender diligence that keeps your reputation strong.

The bottom line on SMTP 558: it’s about policy, not spam

SMTP 558 errors signal a flaw in sender authentication, not content quality. They occur when a receiving server checks your domain’s SPF record and finds it invalid, missing, or mismatched—regardless of your message’s relevance or tone.

Why SPF matters at scale

Even permission-based campaigns fail if SPF isn’t properly configured. A single misconfigured domain or outdated DNS record can trigger 558 errors across thousands of legitimate messages.

Prevention is proactive, not reactive

There are no workarounds for 558. The only reliable fix is maintaining clean, verified lists and validating sender policies in advance. Automated verification tools catch issues before they harm deliverability.

Sources

• A 2025 list quality analysis found 11.7% of emails are invalid and another 7.9% are risky (spam traps, disposable addresses), meaning 19.6% of a typical list can damage sender reputation. — Apollo.io sender reputation guide (2025)
• Spam accounted for 46.8% of global email traffic as of December 2024 — nearly half of all email sent worldwide. — Mailmodo (citing Statista) (2024)

Keep reading

• Email compliance: CAN-SPAM, GDPR, HIPAA and consent (complete guide)
• How to Use Domain Reputation Data to Block Dangerous Shorteners in Emails
• Email Relay Chain Security: Preventing Envelope Mismatch Attacks
• Why Modern Email Providers Don’t Respond to VRFY/EXPN Queries
• Email Verification API Rate Limits Due to DNS TXT Record Query Throttling

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

Frequently asked questions

What is the SMTP 558 error code?

SMTP 558 means the recipient server rejected your email due to a sender policy violation, usually because SPF does not authorize the sending IP.

Does SMTP 558 mean my email was marked as spam?

No. 558 is a policy rejection, not a spam filter response. It’s a hard bounce based on sender authentication failure.

Can I fix SMTP 558 without reconfiguring SPF?

Only if the issue is on the recipient’s side. For your own sends, SPF must be corrected—it’s not optional for deliverability.

How does Emaillistchecker.io help with SPF-related issues?

It identifies invalid and risky addresses before sending, reducing bounce rates and protecting sender reputation, which includes mitigating 558 risks from list quality issues.

Is using DKIM enough to avoid SMTP 558?

No. While DKIM helps with message integrity, SPF remains a required check. 558 is triggered during SPF validation, not DKIM.

Are disposable emails a common cause of SMTP 558?

No. Disposable emails cause invalid address bounces, not 558 errors. 558 is tied to sender policy at the domain level, not individual mailboxes.

How often should I check my SPF record?

At least monthly, and after any change in email service or sending infrastructure. SPF is static—updates don’t auto-propagate.

Can a mailing list tool like Mailchimp cause SMTP 558?

Yes—if your domain’s SPF record doesn’t include Mailchimp’s sending servers, and you send via them, the receiver will reject the email with 558.

What happens if I ignore an SMTP 558 error?

Your emails will fail to deliver, your sender reputation may degrade, and you risk being flagged by blocklists if bounces persist.

Can Emaillistchecker.io detect SPF misconfigurations?

No—SPF is a DNS-level check. But it can help you avoid sending to invalid addresses that might trigger sender policy logs when bounced.

How many free verifications does Emaillistchecker.io offer?

100 free verifications are available to start, with no expiration on purchased credits.

Does Emaillistchecker.io test inbox placement?

Yes—its inbox-placement testing simulates real delivery conditions to confirm your emails land in the inbox, not spam or blocked.