Fix Salesforce 554 5.7.13 Error | Email List Validation

Why does Salesforce throw a 554 5.7.13 error when sending emails?

You sent a message through Salesforce. It went out. Then came the bounce: “554 5.7.13 Sender not verified.” Not a Salesforce bug. Not a network glitch. Just your email, blocked.

This error happens because big providers like Gmail, Outlook, and Yahoo now enforce sender identity. If your domain doesn’t have SPF, DKIM, or DMARC properly configured, even a correct email address gets rejected. It’s not about validity—it’s about trust.

Authentication isn’t a Salesforce feature. It’s a core requirement for delivery. Without it, your messages don’t just land in spam—they vanish. We’ll show you exactly how to avoid the 554 5.7.13 error by setting up Salesforce email authentication properly in 2025.

Key takeaways

554 5.7.13 errors are caused by missing or misconfigured SPF, DKIM, or DMARC records—never by Salesforce itself.
Email providers enforce authentication to prevent spoofing; valid addresses are still rejected without it.
Setting up proper email authentication in Salesforce is required to maintain deliverability and avoid inbox placement failures.

What is the 554 5.7.13 error, and how does it affect Salesforce senders?

The 554 5.7.13 error means your email was rejected during the SMTP handshake because the receiving server couldn’t verify your sender identity. In Salesforce, this typically happens when you're sending from a custom domain or via Marketing Cloud without properly configured email authentication, like SPF, DKIM, or DMARC. The result? Messages bounce silently, delivery fails, and repeated attempts hurt your sender reputation over time.

Why SMTP negotiation fails with Salesforce

When a mail server receives an email, it runs a series of checks before accepting it. The 554 5.7.13 error appears during the SMTP EHLO or HELO phase — before content is even sent — because the server can't confirm your domain's legitimacy. If your Salesforce instance is sending from a branded domain (like [email protected]) without valid SPF records or a properly signed DKIM signature, the remote server flags it as suspicious and blocks it outright.

This isn’t unique to Salesforce. Any email sender using custom domains must prove they’re authorized to send on that domain’s behalf. The issue isn’t with Salesforce itself, but with missing or incorrect authentication setup at the DNS level. Without it, even legitimate messages get rejected by major providers like Gmail, Outlook, or Apple Mail.

How this hurts your sender reputation over time

Every failed send counts. When you repeatedly try to send to domains that reject your messages due to missing authentication, it signals poor list hygiene and weak security practices. Over time, ISPs notice patterns: repeated rejections from your IP or domain can lead to IP reputation downgrade or even blocklisting. According to RFC 7208 (SPF), one of the core email authentication standards, SPF is designed to prevent spoofing by verifying the sending server’s authorization.

Even if your content is valid, the server sees only that your domain didn't pass identity checks. The outcome? High bounce rates, low inbox placement, and wasted campaigns. If you’re using Salesforce Marketing Cloud or Salesforce Sales Cloud with custom sends, this error can become a recurring bottleneck — especially with seasonal or large-scale campaigns.

Prevention starts with verifying your domain’s email authentication. Tools like bulk email list cleaning help you identify invalid or poorly configured addresses before sending, reducing the risk of rejection. But the real fix lies in correct DNS configuration — SPF, DKIM, and DMARC — for your sending domain. Without it, no number of email cleanups can override the SMTP-level rejection.

How do SPF, DKIM, and DMARC work together to prevent 554 5.7.13 errors?

SPF, DKIM, and DMARC form a layered defense that stops email spoofing and misdelivery. SPF checks if the sending IP is authorized, DKIM verifies the email wasn’t altered in transit, and DMARC enforces policies when those checks fail—collectively reducing the risk of a 554 5.7.13 error, which marks emails as suspicious or unauthenticated. Without all three, even legitimate messages from your domain can be rejected by modern mail servers.

SPF: Confirming the Sender’s Authorization

SPF authorizes specific IP addresses or mail servers to send emails on your domain’s behalf. If your email comes from an unauthorized server—like an improperly configured marketing tool or API—it will fail SPF. This is a common trigger for the 554 5.7.13 error, especially in enterprise systems like Salesforce. Think of SPF as a guest list: only approved senders get in.

DKIM: Ensuring Message Integrity

DKIM adds a digital signature to your email’s header and body. When the receiving server checks it, it verifies the message hasn’t been altered since it left your server. A tampered email—whether by malware or a compromised server—will fail DKIM. This is why even if SPF passes, DKIM failure can still trigger rejection, particularly with large providers like Google and Microsoft.

For example, a Salesforce outbound email might pass SPF if it’s sent from an approved IP, but if the DKIM signature is missing or invalid, the message may still get blocked. That’s why both are required.

DMARC: The Enforcement Layer

DMARC is the policy engine. It tells receiving servers what to do if an email fails SPF or DKIM—either quarantine it, reject it, or allow it with a warning. It also collects reports so you can monitor authentication status across all providers. A well-configured DMARC policy prevents attackers from impersonating your domain and helps you identify misconfigurations before they cause outages.

When SPF and DKIM are set up correctly, DMARC can be enforced. But without them, DMARC has nothing to enforce. The 554 5.7.13 error often appears when DMARC policies are in place but SPF and DKIM are missing or misaligned.

These protocols aren’t optional. Standards like RFC 7052 and industry practices from sources like Spamhaus and RFC 7208 emphasize their importance in modern email security. You don’t need to be perfect—just consistent.

Let’s say you’re sending from Salesforce and seeing 554 5.7.13. Start here: validate your domain’s DNS records using tools that check SPF, DKIM, and DMARC. If you need real-time verification during setup, test with email verification API to ensure senders are legitimate before deployment.

Step-by-step: Set up SPF, DKIM, and DMARC in Salesforce for 554 5.7.13 protection

You can prevent the 554 5.7.13 error in Salesforce by configuring SPF, DKIM, and DMARC correctly in your domain's DNS. This stops emails from being blocked due to failed authentication, especially when sending through Marketing Cloud or Email Studio. The process takes 15 minutes and reduces inbox placement issues caused by reputation misalignment with major providers like Microsoft and Google.

Authenticate Salesforce sending with DNS records

Log into your domain’s DNS provider—Cloudflare, GoDaddy, or AWS Route 53—and navigate to the DNS management section.
Create an SPF TXT record using the format v=spf1 include:sendgrid.net ~all. This allows Salesforce Marketing Cloud to send on your behalf while signaling to receivers that only authorized IPs can send from your domain.
Generate a DKIM selector and public key in Salesforce Marketing Cloud or Email Studio. Select "DKIM" under "Email Studio" settings, then create a new key. The system will provide a selector (like sf1) and a public key.
Go back to your DNS provider and add a new TXT record. Use the selector as the record name and the public key as the value. This enables receivers to verify the email's authenticity using cryptographic signing.
Set up a DMARC DNS record with p=none or p=quarantine. Start with p=none to monitor reports without affecting delivery, and gradually move to p=quarantine once alignment and authentication are stable. Include rua=mailto:[email protected] to receive aggregate reports.

Verify your setup with real tools

After adding the records, wait 5–10 minutes for DNS propagation. Then test with tools like MxToolbox or SendGrid’s DNS checker. These validate SPF, DKIM, and DMARC alignment in real time. If one fails, double-check your DNS settings—especially the exact formatting of the TXT values.

The 5 steps described in “Authenticate Salesforce sending with DNS records”, in order.

Remember: SPF has a 10-include limit. If you use multiple senders, consider merging records or using SPF 2.0 if supported. Also, DMARC reports help detect spoofing attempts but don’t block messages automatically. Use the data they provide to fine-tune your authentication strategy.

For ongoing list hygiene—keeping sender reputation healthy—use real-time tools like our real-time email verification API. It checks addresses for validity and risk before you send, reducing bounces and blacklisting chances.

Properly configured SPF, DKIM, and DMARC don’t guarantee inbox delivery—but they remove a major blocker. Combine this with clean data and good sender practices, and you’re set to maintain consistent delivery across major email providers.

What are common SPF and DKIM misconfigurations that trigger 554 5.7.13 errors?

554 5.7.13 errors often stem from DNS-level email authentication flaws—specifically, SPF records with too many includes, mismatched DKIM selectors, or missing DKIM/DMARC alignment. These issues signal to modern providers like Gmail and Microsoft that your domain isn’t properly authorized, triggering rejection. Fixing them directly improves inbox placement and avoids sender reputation damage.

SPF misconfigurations

Using more than 10 include mechanisms in your SPF record exceeds the 10 DNS lookup limit. This causes SPF validation to fail, triggering 554 errors—especially when you include third-party services like marketing platforms, CRMs, or CDNs.
SPF records that aren’t properly ordered (e.g., placing all before include directives) can result in unintended rejection. Always end with a ~all (soft fail) or -all (hard fail) and place allows before them.
Having multiple SPF records for the same domain is a hard violation. DNS allows only one SPF TXT record per domain. If you have duplicates, combine them into one, or merge the mechanisms using include.

DKIM and alignment issues

Using an incorrect or missing DKIM selector in your DNS TXT record breaks signature validation. The selector (like default or mail) must match the one used by your sending system. You can verify this via headers or DNS lookups.
DKIM signatures that are not aligned with the From domain fail at validation. For example, if your DKIM signs with example.com but the From header uses [email protected], the alignment fails unless proper subdomain policies are in place.
Using SPF alone without DKIM or DMARC provides insufficient protection. Modern email providers like Gmail rely on multiple authentication layers. A missing DKIM or DMARC record may cause 554 5.7.13 errors due to perceived lack of sender legitimacy.

For a deeper check, run your domain through a DKIM and SPF checker or examine the full email headers sent by your system. Use tools that validate the full authentication chain, including SPF, DKIM, and DMARC, to avoid hidden fails.

You can audit your list’s sender addresses before sending to catch invalid or misconfigured domains early. Try our bulk email list cleaning to validate and de-duplicate your addresses in real time.

Bad email addresses—invalid, non-existent, or disposable—trigger 554 5.7.13 errors in Salesforce not because of authentication flaws, but because they fail at the most basic level: the recipient’s mailbox doesn’t exist. When your list contains these, the email server rejects the message early, often mislabeled as a policy or authentication failure. Cleaning your list beforehand removes this friction, so authentication layers aren’t overwhelmed by noise. You’re not fixing the auth setup—you’re making sure it’s tested against real, valid addresses.

Why invalid addresses look like authentication issues

When Salesforce sends to a fake or non-existent email, the receiving server responds with a 554 5.7.13 error—often cited as a sign of failed SPF, DKIM, or DMARC. This isn’t true. The rejection happens at the envelope level, before authentication is even checked. A misconfigured domain or weak DMARC policy won’t reject a valid address, but a non-existent one will. This is why your logs might show a clean auth record with a 554 error: the server never got to authentication because the recipient wasn’t valid.

According to the SMTP RFC 5321, a server can reject a message at any point, and rejecting non-existent recipients is a standard practice. This means your authentication is technically sound—but your list hygiene isn’t. The error isn’t in your setup. It’s in your audience.

High-risk addresses strain delivery systems

Emails to role-based addresses like info@, sales@, or support@ often land in spam traps or trigger automated filters. These domains are frequently used for bulk mail, so they’re monitored closely. Similarly, disposable domains (like tempmail.org) are created only to receive emails and are commonly blacklisted. Sending to them doesn’t just lose engagement—it harms your sender reputation.

Sending to a large number of such addresses increases bounce rates, which directly impacts your sender reputation. ISPs and email providers track bounce patterns. High bounce volumes—even from invalid addresses—signal that you're not filtering your list properly. Over time, this can trigger more aggressive filtering, eventually leading to 554 5.7.13 errors even for valid emails. You’re not avoiding the error—you’re making it more likely.

By using a bulk verification tool to clean your list before sending, you remove all non-existent and high-risk addresses. This reduces the load on your authentication layer and keeps your sender reputation healthy. Tools like email list validation software check each address against real-time SMTP checks, domain policies, and known disposable patterns before you send.

How to verify your Salesforce email list before sending to avoid authentication issues

You can avoid the 554 5.7.13 error in 2025 by cleaning your Salesforce email list before sending. Use bulk verification to remove invalid, catch-all, and disposable addresses. Test inbox placement with your actual SPF/DKIM setup. Check your sender reputation with tools like Spamhaus or MxToolbox. Only send to addresses proven to deliver.

Pre-send validation: what to check and why

Run your Salesforce list through bulk email list cleaning to flag invalid, catch-all, or disposable email addresses before sending.
Use inbox placement testing to simulate delivery from your domain while preserving SPF and DKIM alignment — this shows whether your messages land in inboxes or spam folders.
Check if your sending domain or IP is listed on any blocklists like Spamhaus (spamhaus.org) or MxToolbox’s global blocklist checker.
Focus on sending only to validated addresses that have strong deliverability signals: active accounts, proper domain alignment, and no history of spam complaints.
Verify your SPF, DKIM, and DMARC records are correctly configured in Salesforce’s outbound email settings. Misconfiguration leads directly to 554 5.7.13 errors.

What happens when you skip verification

Without pre-send validation, you risk triggering SMTP rejection codes like 554 5.7.13 — a clear signal that your message was blocked by the recipient’s mail server. This often happens because the sending IP or domain is flagged, or because the message comes from a high-fraud-domain address (e.g., @tempmail.com).

Even if you’ve set up SPF/DKIM properly, sending to a catch-all or disposable address can still result in a bounce, degrade sender reputation, and harm future inbox placement. Let’s be clear: authentication isn’t just about headers — it’s also about whom you’re sending to.

Real-world delivery performance depends on both technical setup and list hygiene. You can’t fix poor deliverability with better authentication if your list includes addresses that never receive mail. Clean the list first. Test delivery next. Protect your reputation after.

How Email List Validation can help prevent 554 5.7.13 errors in Salesforce

Running into a 554 5.7.13 error in Salesforce? It's usually a sign that your emails are hitting spam filters or invalid addresses. Fix it by validating your list before sending: clean out fake, disposable, catch-all, or risky addresses using a tool with 98.9% accuracy. This stops bounces, protects your sender reputation, and keeps your emails out of quarantine — especially when syncing with Salesforce via integrations or real-time APIs.

Prevent errors at the source with verification

Use built-in email validation to scrub invalid addresses before they enter your Salesforce CRM — a single bad email can trigger the 554 5.7.13 error and hurt deliverability for the entire campaign.
Verify every email at point of entry using a real-time API integrated via Zapier, custom script, or middleware — ensure only valid, active addresses are accepted.
Run bulk list validation before launching campaigns to remove catch-all, disposable, or risky domains — these are common triggers for SMTP rejections, especially from Gmail and Microsoft’s mail systems.
Check inbox placement in real environments with simulated sends to Gmail, Yahoo, and Outlook — this reveals whether your messaging lands in the inbox or gets blocked before reaching the user.
Reduce bounce rates by up to 80% when your list is cleaned — fewer bounces mean fewer spam complaints and a healthier sender reputation with providers like Microsoft and Google.

Integrate smoothly with your workflow

Most 554 5.7.13 errors stem from sending to undeliverable or risky addresses during mass outreach. You can avoid that by validating at scale, before the send. Tools like bulk email list cleaning help you process thousands of addresses in minutes, identifying and removing problematic ones in bulk — including high-risk domains and disposable email providers.

With real-time API verification, you can embed validation directly into your Salesforce form or lead capture workflow. This stops invalid emails before they even reach your send queue — no more wasted credits or reputation damage.

According to industry data, 30–40% of email lists contain invalid or undeliverable addresses over time. RFC 5321 outlines SMTP rejection procedures, and while it doesn’t specify a 554 error code, it explains how receivers handle malformed or suspicious mail — a direct cause of 554 5.7.13. Proper list hygiene helps you stay compliant with accepted standards.

Email List Validation vs. other tools: What truly matters for 554 5.7.13 prevention?

You don’t prevent 554 5.7.13 errors by just checking if an email address exists. The real fix is ensuring your entire list is technically ready for delivery—validating authentication setup, simulating inbox placement, and cleaning lists at scale. Tools that only check syntax or spam traps won’t stop a 554 error from Salesforce when your sender reputation or DKIM alignment fails. Email List Validation goes beyond basic validation to test deliverability conditions that actual mail servers check.

Why basic validation tools fall short

Many tools—ZeroBounce, NeverBounce, Kickbox, Bouncer—focus on spotting invalid addresses or detecting disposable domains. These are useful for basic list hygiene but don’t test whether your authentication setup (SPF, DKIM, DMARC) is correctly aligned with your sending domain. A valid address with misconfigured authentication will still trigger a 554 5.7.13 error from Salesforce or other modern filters. You can’t catch this with address-level checks alone.

Emailable and MillionVerifier offer real-time verification, handy for single addresses or small batches. But they also don’t simulate how your emails land in real inboxes. No deliverability testing means you won’t know if your messages are being filtered by reputation systems, even if they’re technically valid.

What Email List Validation does differently

Unlike most tools, Email List Validation includes inbox placement testing. You can send a test message from your Salesforce-sent domain and see how it lands across Gmail, Outlook, and other major providers. This shows whether your infrastructure—authentication, sender reputation, content—can pass real-world filters. It’s a direct test of what causes a 554 5.7.13 error, not just if the address parses.

It also verifies authentication readiness across your full list. You can run a bulk check to find addresses linked to domains with broken SPF, missing DKIM, or conflicting DMARC policies. Fixing these issues before sending is the most effective way to prevent rejection by Salesforce, which enforces strict authentication policies.

And yes, it handles integration with Salesforce and other marketing platforms (like HubSpot and Klaviyo) through direct connectors. You can validate and clean a list before sending, then sync the updated list back to Salesforce—automating the hygiene cycle.

With an in-app AI assistant, you get plain-language explanations of results and recommendations. If you see a spike in catch-all addresses, or a cluster of domains failing DMARC, the tool helps you understand why and what to do, without needing a deliverability expert on staff.

For high-volume senders, this isn’t just about filtering bad emails. It’s about building trust with receivers and ensuring your messages pass technical gatekeeping. You can start with 100 free verifications at our pricing page—no risk, no expiration, just real results.

The 554 5.7.13 error is not about your email content — it’s about sender trust

Getting a 554 5.7.13 error means your email was blocked before any content was read. Receiving servers check authentication—SPF, DKIM, and DMARC—not subject lines, CTAs, or send frequency. Even a perfectly written message fails if your domain isn’t trusted and properly configured.

Authentication is the gatekeeper, not content

You might spend hours perfecting your email copy, but a single misconfigured DNS record can stop it cold. The 554 5.7.13 error is a sender reputation issue. It’s not a spam filter judgment—it’s a technical validation that your domain is allowed to send from the IP address it claims.

Receiving servers rely on DNS records to verify identity. If SPF doesn’t list the sending IP, DKIM fails to sign the message, or DMARC policies don’t align, the server rejects the message outright. This is the same logic used by major providers like Microsoft and Google. For reference, RFC 7052 and Microsoft’s Sender Authentication documentation clarify how these mechanisms are enforced at scale.

Why even good senders get blocked

Even with clean content and low bounce rates, you’ll still hit 554 5.7.13 if your domain’s authentication setup has gaps. Common causes include missing or conflicting SPF records, expired DKIM keys, or DMARC policies set to "reject" but not properly aligned.

It's not about how many people you email or how frequently. It’s about whether your sending infrastructure can prove, beyond doubt, that it’s authorized by your domain. Misconfiguration anywhere in the chain—whether on your side or through your email service provider—can trigger rejection.

Let’s be honest: even a flawless campaign fails if the technical foundation is weak. That’s why you should validate both your list and your configuration. Tools like bulk email list cleaning can help identify issues early—including invalid or non-existent addresses that could otherwise trigger sender reputation flags—before you send a single message.

Authentication isn’t optional. It’s the first line of defense for deliverability. Fixing it isn’t about crafting better emails. It’s about proving you’re allowed to send them.

Keep 554 5.7.13 errors away: Maintain email authentication and list hygiene over time.

SPF and DKIM records can break silently after system changes. Quarterly audits ensure your Salesforce email authentication setup remains intact and trusted.

Bounce and complaint rates are early warning signs. Monitor them monthly to catch reputation issues before they trigger 554 5.7.13 errors.

Always test campaigns on a small, verified list first. This reduces risk and confirms deliverability before broader sends.

Sources

An estimated 376 billion emails are sent and received every day worldwide in 2025, projected to reach 424 billion daily emails by 2026. — Statista (2025)

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 554 5.7.13 error mean in Salesforce?

It means the receiving email server rejected your message due to missing or invalid email authentication, such as SPF, DKIM, or DMARC misconfigurations.

Can I fix 554 5.7.13 errors without changing my domain's DNS?

No — the error is caused by missing or incorrect SPF, DKIM, or DMARC records in DNS. You must update your domain’s DNS settings.

Does Salesforce automatically set up SPF and DKIM?

No — Salesforce does not manage DNS records. You must configure them in your domain’s DNS provider.

How often should I verify my Salesforce email list?

Verify lists before every major send, and recheck every 90 days to maintain hygiene and prevent outdated or invalid addresses.

Why does a valid email address still get rejected with 554 5.7.13?

Because authentication fails, not because of the address. A valid address can be rejected if SPF or DKIM is not correctly set up.

Can disposable email addresses cause 554 5.7.13 errors?

No — they don’t cause the error, but they increase bounce risk and harm sender reputation, which indirectly impacts deliverability.

Is DMARC required to prevent 554 5.7.13 errors?

No — DMARC is not required for delivery. But it enables stronger alignment and reporting, which improves long-term reputation.

How can I test if my SPF and DKIM are working?

Use tools like MxToolbox or SendGrid’s DNS check to verify TXT records. Also, run inbox-placement tests with Email List Validation.

Does Email List Validation integrate with Salesforce Marketing Cloud?

Yes — it integrates via API and common tools like Zapier, HubSpot, and SendGrid. You can verify addresses before syncing with Salesforce.

Are purchased verification credits in Email List Validation permanent?

Yes — once purchased, credits never expire, allowing you to verify lists at your own pace.

What type of email addresses should I remove to avoid 554 5.7.13 issues?

Remove invalid, catch-all, disposable, and role-based addresses (e.g. admin@, contact@) — these harm deliverability and reputation.

Can using a third-party email service change 554 5.7.13 errors?

Yes — if the third-party service does not properly authenticate emails, it increases risk. Ensure all services use correct SPF and DKIM.