Resolve DMARC 554 5.7.13 | Email List Validation

Why is your Salesforce email getting blocked with code 554 5.7.13?

You send an automated campaign from Salesforce, and it’s rejected with a 554 5.7.13 error. Not a typo. Not a missing field. The server says your message violates policy—specifically, DMARC.

This isn’t a syntax issue. It’s a trust signal. Your domain passes SPF and DKIM checks, but fails alignment. The receiving mail server sees a mismatch between the sending domain, the From address, and the authentication results. That’s why your email gets blocked even though everything else looks correct.

Especially in Salesforce, where outbound emails may route through third-party services like SendGrid, this misalignment crops up often. You’re not doing anything wrong—just sending from a domain that doesn’t align in the eyes of strict email receivers.

Key takeaways

554 5.7.13 is a DMARC policy rejection, not a coding or syntax error.
SPF and DKIM can pass while DMARC alignment still fails—this is common in Salesforce workflows using external email services.
Fixing the issue requires ensuring the From domain, SPF domain, and DKIM selector domain are all aligned, especially when integrating with SendGrid or similar platforms.

What does DMARC 554 5.7.13 actually mean in real email delivery terms?

When you see a DMARC policy violation 554 5.7.13 in Salesforce, it means the receiving server (like Microsoft 365 or Google Workspace) rejected your email because your sender identity doesn’t pass authentication checks. Specifically, the domain in your email’s From header doesn’t align with either the SPF or DKIM signature. Even if your email technically reached the server, it was blocked to prevent spoofing — no matter how well your sending infrastructure is set up.

Why alignment matters — even if SPF/DKIM pass

SPF and DKIM are useful, but they only tell part of the story. A DMARC policy violation occurs when the domain in the From header doesn’t match the domain used in SPF’s sender domain or DKIM’s selector domain. For example, sending from [email protected] but using SPF from acme.com (if the SPF record is set at the root level) might fail alignment if the email is sent via a subdomain like send.acme.com. This mismatch triggers the 554 5.7.13 error.

Modern email systems like Microsoft 365 enforce strict alignment to prevent spoofing and phishing. Even if you’re using a trusted sender domain with valid SPF and DKIM, inconsistent alignment will result in rejection. It’s not enough to send from an approved domain — the domain must appear in both the From header and the authentication records with matching scope.

How this affects Salesforce email workflows

In Salesforce, your outbound emails often use a corporate From domain, but Salesforce uses a different sending infrastructure (like SendGrid or Amazon SES) behind the scenes. If that infrastructure doesn’t include your From domain in either SPF or DKIM, or if the alignment fails due to subdomain mismatches, DMARC will block your messages.

You might not see this until users report missing emails or bounce reports accumulate. It’s especially common in automated workflows (e.g., alerts, notifications, onboarding) where sender identity is set at the org level but not properly aligned with the actual sending server.

The fix starts with verifying your authentication setup across your sending environment and your domain policy. Use tools like MXToolbox or DMARC.org to test your records and validate how they align in real-world scenarios.

If you're still unsure whether your setup matches standards, you can validate your email list quality and test send paths with a service like inbox placement testing — it checks how your emails land across real inboxes and identifies delivery issues tied to authentication failure.

How does Salesforce trigger DMARC failures during email campaigns?

When Salesforce sends emails through an external service like SendGrid or your organization’s shared IP pool, the sending source must properly authenticate the email’s From domain. If the SPF or DKIM records for that domain don’t align with how Salesforce is sending — for example, if the From domain uses a subdomain not listed in the SPF record — DMARC sees it as a mismatch and blocks the email with a 554 5.7.13 error. Even a small misalignment can trigger rejection, especially in strict DMARC policies.

Why external sending sources cause alignment issues

Many organizations use Salesforce with third-party email services to offload sending infrastructure. But those services often send from a different domain or IP pool than your official business domain. If your From address points to your company’s domain (e.g., [email protected]), but the send originates from a non-aligned domain (e.g., [email protected]), DMARC validation fails — even if SPF and DKIM are technically valid for the sending domain.

Let’s say your email uses your company’s domain in the From header, but your SPF record only includes IPs from a legacy system. If Salesforce routes that message through SendGrid’s IP pool, which your SPF doesn’t list, the email fails SPF. DMARC checks both SPF and DKIM alignment; if either fails, the message is rejected. This is common when SPF records are too narrow, outdated, or fail to include all legitimate sending sources.

Common misconfigurations that trigger 554 5.7.13 errors

Even minor oversights cause delivery issues. For example, if you use a subdomain in the From address like [email protected], but your SPF record only includes the root domain acme.com, the subdomain isn’t trusted. Some services handle this well, but many DMARC policies reject messages where the sending domain doesn’t match the From domain exactly, or where the sending source is not explicitly authorized.

DMARC failure is also more likely when your domain’s policy is set to “reject” rather than “quarantine.” This is standard for high-security domains. You can check a domain’s DMARC record using tools like MXToolbox’s DMARC lookup, which shows how policies are enforced across receiving providers.

Preventing these errors means auditing your current sending infrastructure against your domain’s SPF, DKIM, and DMARC records. Make sure every service that sends on your behalf is explicitly authorized. Use a tool like bulk email list validation to test your domain reputation and sender alignment before launching campaigns.

What are the most common causes of DMARC violations in Salesforce workflows?

DMARC policy violations (like 554 5.7.13) in Salesforce usually stem from mismatched sender authentication—either the sending domain doesn’t align with SPF or DKIM, or a third-party service sends email without proper authorization. These issues trigger rejection by receiving mail servers, especially when SPF fails or DKIM signatures are missing or invalid. You’ll often see this when Salesforce relays emails through an external service, or when role-based or catch-all addresses are used without proper configuration.

Authentication Mismatches and Misaligned Records

The From domain in the email does not match the domain used in SPF or DKIM validation—common when emails are sent from a Salesforce org's subdomain but SPF is set for the main domain.
SPF records include mechanisms like include:third-party.com that list services not authorized to send on your behalf. Even if the service is legitimate, it must be explicitly approved in the SPF record; otherwise, it causes a fail.
DKIM keys are missing, expired, or not published correctly in DNS records. If your domain’s DKIM key is outdated or misconfigured, receiving servers drop the message despite valid content.

Salesforce Relay and Address Type Issues

Salesforce’s email relay system relies on sender authentication configured at the domain level. If the domain used in Salesforce sends messages but lacks an SPF record or includes unauthorized mechanisms, the relay fails SPF checks, triggering DMARC rejection.
Using catch-all addresses (e.g., [email protected]) or role-based emails (e.g., [email protected]) without proper authentication can cause DMARC failures. These addresses often bypass authentication checks or are flagged by spam filters due to their generic nature.
Some organizations use shared or unverified aliases in Salesforce campaigns. These can be interpreted as suspicious, especially if they don’t align with SPF/DKIM scope or if the sending IP isn’t in a trusted range.

DMARC enforcement is strict—receiving servers follow RFC 7052 (a standard for DMARC implementation), and failing any alignment check means a message gets quarantined or rejected. A single misconfiguration can result in a 554 5.7.13 error, even if the message content is clean.

Regularly validate your email sending setup using tools that test SPF, DKIM, and DMARC alignment. You can also use bulk email list validation to clean outdated or incorrectly formatted list entries before sending, reducing the risk of authentication mismatches.

How to diagnose your DMARC issue using real tools and logs

When Salesforce rejects an email with a 554 5.7.13 error due to a DMARC policy violation, start by checking the full email header for Authentication-Results and DKIM-Signature lines—these show the receiving server’s verification outcome. Use tools like MxToolbox or the RFC 7672-compliant DMARC record checker to confirm your DNS setup. Review Salesforce’s Email Log for the exact rejection reason, then validate your DMARC policy is set to p=none during testing to avoid blocking legitimate messages.

Step-by-step diagnosis process

Retrieve the full email header from a failed delivery. Look for the Authentication-Results field—this shows whether SPF, DKIM, or DMARC passed or failed. If DKIM is missing or invalid, the message won’t align with the domain, triggering rejection. The DKIM-Signature line should be present and cryptographically valid.
Validate your domain’s DNS records using a public tool like MxToolbox or the DMARC.org diagnostic page. Verify that your SPF, DKIM, and DMARC records are correctly published and not conflicting. Misconfigured or missing records are common causes of 554 5.7.13.
Check Salesforce’s Email Log (under Setup > Email Logs) for the failed message. Look for the exact error code and rejection reason—this tells you whether the issue is SPF failure, DKIM mismatch, or DMARC policy enforcement. Many admins miss this directly in Salesforce; ensure you’re not relying on guesswork.
Review your domain’s DMARC policy. If it’s set to p=reject or p=quarantine, even minor alignment issues can lead to rejection. Switch to p=none while testing. This allows messages to pass while you debug alignment and signature issues without disrupting deliverability.
Test your sender IP and domain alignment using a real inbox placement test with providers like Mail-Tester or GlockApps. These tools simulate real email routes and show authentication results across multiple receivers, helping isolate whether the issue is with your setup or a specific recipient’s filter.

Pro tip: Don’t ignore alignment

Even if DKIM and SPF pass, DMARC fails if the “from” domain doesn’t align. Salesforce often sends from a subdomain (like salesforce.com) but uses your sending domain in the “From” header. This misalignment trips DMARC. Use a tool that checks header alignment or verify this in the email header before sending.

How to use Email List Validation to catch flawed email addresses before sending

You can prevent DMARC policy violations in Salesforce by verifying every email in your list before sending—using Email List Validation’s real-time API or bulk verification to detect invalid, role-based, disposable, or catch-all addresses that trigger authentication failures. This upfront cleanup reduces the risk of your messages being rejected with a 554 5.7.13 error, especially when sending from a domain with strict DMARC policies.

Verify and clean your Salesforce email list early

Before launching any campaign in Salesforce, process your entire list through Email List Validation. Whether you're sending via Marketing Cloud or a native email workflow, catching bad addresses at the source stops bounces and protects your sender reputation. Use the real-time API to verify emails as they’re added, or run a full bulk verification on your list using bulk email list cleaning tools to flag issues before they cause delivery failures.

DMARC failures often stem from spoofing attempts—when a message claims to come from your domain but arrives from an unauthenticated source. Invalid or non-existent addresses can look like spoofing if the receiving server can't verify them, especially if they’re role addresses, temporary disposable domains, or catch-all inboxes. These are red flags that can trigger rejection even with SPF and DKIM correctly configured.

Filter high-risk addresses and leverage precision

Role addresses like sales@, info@, or support@ often lack proper authentication and can be rejected by modern email systems. Disposable domains (like tempmail.com) rarely have valid MX records and frequently get flagged. Catch-all domains accept almost any email, making them unreliable for deliverability and a common source of spoofing attempts.

Email List Validation identifies these with 98.9% accuracy—so you’re not blocking valid emails due to overzealous filters. This helps avoid false positives that might otherwise be flagged as spoofing, which is especially important when your domain has strict DMARC policies set to reject or quarantine. The system uses real-time checks against DNS, SMTP, and domain reputation signals to determine validity.

For deeper insights, use the in-app AI assistant to analyze problematic domains and suggest fixes. It can detect patterns like repeated role addresses or suspicious TLDs and recommend targeted list pruning. This is critical when you’re managing high-volume Salesforce campaigns, as even a few bad records can trigger automated delivery blocks.

For more context on how DMARC works, see the IETF’s official specification on DMARC. For guidance on email validation best practices, industry standards from Spamhaus and MxToolbox reinforce the need for clean, authenticated sender lists.

How to fix SPF alignment when sending from Salesforce or SendGrid

If your Salesforce emails are being rejected with a 554 5.7.13 error due to DMARC policy violations, the most likely cause is SPF alignment failure. You must ensure your SPF record explicitly includes both sendgrid.net and sfmail.salesforce.com using the include mechanism. Avoid listing IPs directly—this increases complexity and risk. Keep your SPF record under 10 mechanisms to stay within DNS limits, and always validate the syntax and reachability of the record using a trusted DNS tool.

Step-by-step alignment fix

Identify all sending sources in your email workflow. Salesforce uses sfmail.salesforce.com, and SendGrid uses sendgrid.net. Any additional services (like Mailchimp or HubSpot) must also be included.
Add include mechanisms for each service. For example: include:sendgrid.net and include:sfmail.salesforce.com. This keeps the record clean and maintainable.
Limit your mechanisms. SPF records have a maximum of 10 mechanisms. Don’t manually add every IP address—spammers and bulk senders do this, which damages reputation. The include directive is more scalable and less error-prone.
Test the record using a DNS SPF validator. Tools like MXToolbox or Kitterman’s SPF Validator check syntax, reachability, and alignment across all mechanisms.
Check alignment in practice. Use a tool like DMARC Analyzer to monitor how your messages align during delivery. Misalignment here will still trigger rejection—even if SPF passes.

Common pitfalls to avoid

Don’t use all:fail in a test or production record unless you're certain all sending sources are accounted for.
Don’t mix ip4 and ip6 entries without proper delegation. Each adds to the mechanism count.
Don’t rely on old or cached records—DNS changes can take up to 48 hours to propagate. Use a real-time checker before concluding a fix has failed.

When you're sending at scale, even a single misaligned domain can break delivery. If you're unsure about which domains are active, or if your list contains outdated or malformed addresses, you can verify your sender list with real-time tools. Clean your email lists with bulk verification to reduce bounce risks and improve sender reputation. A validated list is harder to exploit and more likely to pass DMARC checks.

How to set up DKIM correctly for Salesforce outbound emails

You must enable DKIM signing at the domain level in your email service (like SendGrid), publish the public key as a DNS TXT record with the correct selector, and ensure Salesforce doesn’t bypass the signing process. For Salesforce to send DKIM-signed emails, the sending service must apply the signature before relaying the message—never rely on Salesforce to generate DKIM manually.

DNS and provider setup

If you're using SendGrid as your SMTP relay for Salesforce, log into your SendGrid account and navigate to the Domain Authentication section. Enable DKIM signing for your domain, and copy the public key provided. This key must be added to your DNS as a TXT record with the correct selector (e.g., sendgrid._domainkey.yourdomain.com). The selector must exactly match the one used by SendGrid when sending emails.

Many DKIM issues stem from mismatched selectors or incomplete DNS configuration. Double-check that the entire public key—especially the DKIM-Signature: header—is included in the DNS TXT record. A single missing character breaks validation. According to RFC 6376, DKIM signing must cover both the message headers and body to ensure integrity and prevent tampering.

How Salesforce interacts with signing

When Salesforce uses a third-party SMTP server, like SendGrid, it relays the email without applying DKIM itself. This means you must ensure the sending service (like SendGrid) applies the signature before delivery. If Salesforce's "Send Email" feature is configured to bypass the service’s DKIM, your emails will fail DMARC checks—even if the public key is correct.

Let’s be clear: never try to manually craft a DKIM signature. The private key is never exposed to the sender, and the signing algorithm is complex. Use your provider’s tools—SendGrid, Amazon SES, or others—to generate and apply the signature automatically. If you're managing multiple domains or routes, verify that each subdomain has its own selector and public key published in DNS.

For teams running large-scale workflows, consider validating your sender address setup upfront. Tools like Email List Validation’s bulk verification help ensure your outbound email list is clean, reducing the risk of DMARC issues caused by spam-like behavior. That way, when DKIM is set up properly, your domain reputation stays strong.

How to verify DMARC alignment with real inbox tests

You can verify DMARC alignment in your Salesforce email workflow by testing your actual message in real inboxes—Gmail, Outlook, and Yahoo—using inbox-placement tools. This reveals whether your From header aligns with SPF and DKIM, or if your message is being blocked due to policy violations, even if your DNS records look correct. Email List Validation’s inbox-placement feature simulates delivery with real mail servers, showing how your domain performs in actual filtering environments.

Test from multiple domains to expose alignment gaps

Let’s say you’re sending from a shared domain like [email protected], but your marketing emails come from [email protected]. Even if SPF and DKIM are set up for one, DMARC alignment fails when the From header doesn’t match. Testing across domains catches these mismatches. Role addresses (like support@ or info@) often lack proper authentication, so sending from them can trigger DMARC failures—even if your main domain is clean.

Use inbox-placement testing to send your Salesforce message to actual inboxes. This isn’t theoretical—it shows whether your message hits the inbox, spam folder, or gets rejected outright. If your message fails in Gmail but passes in Outlook, it’s likely due to DMARC alignment issues rather than general deliverability problems. Real inbox tests uncover what SPF, DKIM, and DMARC validation tools miss: how the entire email stack behaves in practice.

DMARC alignment isn’t just about DNS checks. It’s about whether the domain in your From header matches the domain used in SPF and DKIM. Misalignment—common when using third-party services or role addresses—can trigger a 554 5.7.13 error even if all technical checks pass. You’re not just verifying syntax; you're testing real-world delivery. As outlined in RFC 7052, a message must pass alignment checks for all three components to pass DMARC.

For deeper insight, test your message from multiple sender domains. This helps spot patterns like: one domain passes, others fail. That inconsistency can point to role-based senders, incorrect SPF records, or missing DKIM signatures. You can run these tests at scale through Email List Validation’s inbox-placement tool, which simulates delivery to major providers with your actual content and headers. It’s the only way to be sure your Salesforce workflow complies with real-world filtering policies.

Once you identify misaligned sends, adjust your SPF, DKIM, or From header settings accordingly. Keep testing until delivery is consistent across Gmail, Outlook, and Yahoo.

How to implement a safe DMARC policy rollout in Salesforce

You can avoid inbox delivery failures during DMARC policy rollout by first setting p=none to collect data without blocking emails. Clean your list with tools like Email List Validation to remove invalid or risky addresses. Then monitor aggregate reports from receiving servers and only gradually enforce p=quarantine or p=reject once you confirm proper alignment and consistent delivery performance.

Start with monitoring, not enforcement

Set DMARC policy to p=none in your DNS record. This collects reports from receiving domains without affecting email delivery. You’ll begin seeing aggregate data on sending domains, alignment status, and whether emails are being marked as failed.
Use DMARC reporting tools or feedback loops. Receiving servers send reports to [email protected] or via automated feeds. Services like dmarc.org and Spamhaus provide insights into how your domain's emails are handled in the wild, helping you identify unauthorized senders or technical misalignments.
Run a full list audit before policy changes. Invalid, disposable, or role-based email addresses can cause delivery spikes and increase risk. Use bulk email list cleaning to filter out non-deliverable or high-risk addresses before rolling out tighter DMARC policies.

Gradual enforcement with real-world verification

Verify email alignment in Salesforce. Ensure that the From address in your emails matches the domain used in SPF and DKIM. Misalignment is a common cause of DMARC failure. You can test this using tools like MXToolbox or by sending test emails via your Salesforce workflow and inspecting headers.
Test delivery with p=quarantine after baseline validation. Change the DMARC policy to p=quarantine only after you’ve confirmed your sending domains are aligned and bulk email volumes are stable. This allows receiving servers to treat non-aligned messages as spam but doesn’t block them entirely—useful for validating impact before full enforcement.
Go live with p=reject only after sustained monitoring. Once you’ve tracked reporting data for at least two weeks and confirmed no meaningful bounce or delivery drop, switch to p=reject. This blocks emails that fail DMARC checks, hardening your domain's reputation and reducing phishing risk.

DMARC is not a one-time setup. It's a continuous process of validation, adjustment, and monitoring—especially when sending at scale through Salesforce.

Always keep your list clean. Invalid entries undermine even perfect policies. Use the Email List Validation real-time email verification API to catch and flag problematic addresses before they enter your workflow.

The bottom line: avoid DMARC 554 5.7.13 by verifying your email list and aligning authentication

The 554 5.7.13 error in Salesforce emails isn't caused by Salesforce itself. It points to a misalignment in sender identity or email authentication, typically between SPF, DKIM, and DMARC configurations.

Even with a strong Salesforce setup, sending to invalid, catch-all, or poorly authenticated domains leads to rejection. These issues are not detected by Salesforce — they’re caught at the receiving end, often too late.

Use Email List Validation to verify your list before sending. Its 98.9% accuracy identifies invalid addresses, catch-all domains, and risky inboxes. Pair this with inbox placement testing to validate deliverability before enforcement.

Always test DMARC policies in a monitoring (p=none) phase first. Enforcing strict policies without validation increases bounce rates and damages sender reputation at scale.

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 DMARC violation 554 5.7.13 mean?

It means the email was rejected by the recipient server because the sending domain failed DMARC alignment — the From header doesn't match SPF or DKIM authentication domains.

Why do Salesforce emails fail DMARC when SendGrid is involved?

If SendGrid sends from your domain but SPF or DKIM aren't correctly aligned, DMARC fails. SendGrid must be included in SPF and use a valid DKIM key.

Can invalid email addresses cause DMARC issues?

Not directly, but role or disposable addresses often lack proper authentication and may trigger suspicion. Clean your list first.

How do I test DMARC alignment before sending?

Use inbox-placement testing tools like Email List Validation to send test emails and validate deliverability and alignment results.

What happens if I set DMARC to 'p=reject' too soon?

Legitimate emails may be blocked if SPF/DKIM aren’t fully aligned. Always start with 'p=none' and monitor reports.

Does using a subdomain in From cause DMARC failure?

Yes — if the subdomain isn’t listed in SPF or doesn’t have DKIM configured, it will fail alignment.

Do I need to configure DMARC for every Salesforce instance?

Yes — each From domain must have its own DMARC policy set in DNS, regardless of the sending service used.

How does Email List Validation help with DMARC?

It cleans your list by removing catch-all, disposable, and role addresses — reducing the risk of spoofing and alignment issues.

How often should I check my DMARC policy?

Monthly at minimum, especially after adding new sending services or changing sender domains.

Are there any tools to automate DMARC monitoring?

Yes — use Email List Validation’s inbox tests, third-party DNS checkers, or services like Postmark’s or SendGrid’s DMARC reporting dashboards.