How to Configure SPF/DKIM to Fix 550 5.7.1 Sender Not Authorized

Why does Salesforce-ESP sync fail with 550 5.7.1 sender not authorized?

You send a campaign from Salesforce through your ESP, and it fails. Not a soft bounce. Not a delivery delay. A hard 550 5.7.1: "sender not authorized."

It’s not your list. Not your sender reputation. Not even a typo in the subject line. The server says no—because the domain claiming to send the email doesn’t have the right authentication records in place.

This error happens when an ESP like SendGrid, Mailchimp, or Amazon SES checks your sending domain and finds no valid SPF or DKIM records. Salesforce isn’t the problem. The ESP isn’t rejecting the message due to content or spam score. It’s rejecting it because it can’t verify the sender’s identity.

Even with a clean list and strong sending reputation, this error blocks delivery. It's a technical gate, not a content or permission issue. The fix lies in configuring SPF and DKIM correctly on your domain, not in Salesforce alone—though Salesforce needs to sync properly with your ESP.

Key takeaways

• 550 5.7.1 errors occur when domain authentication (SPF/DKIM) is missing or invalid during Salesforce-ESP sync.
• Valid SPF and DKIM records are required for any ESP to accept messages on behalf of your domain, regardless of list quality.
• Fixing the error requires proper DNS configuration on your domain, not just adjustments in Salesforce or your ESP dashboard.

What SPF and DKIM actually do in a Salesforce-ESP sync

SPF and DKIM are authentication protocols that tell email providers like Gmail or Microsoft your Salesforce outbound emails are legitimate. SPF checks if the sending server’s IP is authorized in your domain’s DNS records. DKIM adds a cryptographic signature to each email, proving it wasn’t altered in transit. Without both, modern ESPs reject your messages with errors like 550 5.7.1 “sender not authorized,” even if your list is clean and your content is compliant.

SPF: Your domain’s authorized sender list

SPF is like a permission slip stored in your domain’s DNS. It specifies which IP addresses or servers are allowed to send emails on behalf of your domain. When Salesforce sends an email through an ESP, the receiving server checks your SPF record to see if that server’s IP is listed. If it isn’t, the message is rejected.

For example, if your Salesforce org uses a third-party ESP (like SendGrid or Amazon SES), you must include that ESP’s outgoing mail servers in your SPF record. You can’t rely on Salesforce’s internal IP alone — the ESP’s IP is the one that matters. Without this, your messages trigger an SPF fail and land in spam or get blocked.

DKIM: Proof the message hasn’t been tampered with

DKIM acts like a digital seal. It adds a unique cryptographic signature to every outgoing email, tied to your domain’s private key. The receiving server verifies this signature using your domain’s public key published in DNS.

If the signature doesn’t match — or if the email was altered in transit — the recipient server rejects it, often with a 550 5.7.1 error. DKIM doesn’t replace SPF, but it complements it by confirming message integrity. Many ESPs, including those used in Salesforce integrations, require DKIM for deliverability.

Without either SPF or DKIM, your email gets flagged as potentially spoofed. Even if your content is perfectly valid, major providers like Google and Outlook apply strict policies. The result: hard bounces, poor inbox placement, or outright rejections.

Both protocols are standard best practice. The Internet Engineering Task Force (IETF) outlines them in RFC 7208 (SPF) and RFC 6376 (DKIM) — foundational documents you can review at IETF RFC 7208 and IETF RFC 6376. Proper setup isn’t optional — it’s required for modern email delivery.

How SPF and DKIM interact with email deliverability in 2026

You can’t fix a 550 5.7.1 sender not authorized error in Salesforce-ESP syncs by ignoring SPF and DKIM. These two authentication protocols work together to prove your identity to email service providers (ESPs). If either fails, your messages risk bounce, quarantine, or spam placement—even with a clean list. Proper alignment is non-negotiable for inbox delivery in 2026.

Why both SPF and DKIM matter for ESP trust

SPF validates the sending server’s IP address against your domain’s authorized list. DKIM signs the email content cryptographically to prove it hasn’t been altered. ESPs like Gmail, Outlook, and SendGrid check both. A failure in either triggers a trust loss.

Even if SPF passes, a DKIM failure means no content authenticity signal. Most ESPs interpret this as a red flag. Your message may be silently quarantined or rejected with a 550 5.7.1 error—especially during automated Salesforce-ESP syncs, where timing and consistency matter.

Alignment is the real key—SPF and DKIM don’t work like checklists

It’s not enough to have SPF and DKIM configured. They must align. That means the domain in the "From" header must match the domain used to authorize the sending IP (SPF) and the domain that signed the message (DKIM).

When Salesforce sends emails via an ESP, it uses its own infrastructure. If you haven’t configured SPF and DKIM to cover the sending domain (e.g., your customer domain), you’ll trigger authentication failures. Even with a perfect list, flawed authentication breaks deliverability.

One misconfiguration here can ruin engagement scores. According to industry data from the Messaging, Malware, and Mobile Anti-Abuse Working Group (M3AAWG), misaligned authentication is a leading cause of delivery failure in enterprise email flows. M3AAWG reports that aligned SPF and DKIM correlate directly with higher inbox placement rates.

Let’s be clear: no workaround fixes 550 5.7.1 errors caused by weak authentication. That means checking your DNS records, verifying domain alignment, and testing your setup with a trusted tool. You can’t rely on list hygiene alone.

Before syncing Salesforce with an ESP, validate your email addresses and infrastructure. Use a bulk verification tool to catch invalid recipients, but also use a real-time API to test your deliverability before sending. Test your sender identity with real-time email verification to catch issues early—before they break syncs or damage sender reputation.

SPF vs DKIM vs DMARC: the roles each plays in email authentication

You need all three—SPF, DKIM, and DMARC—to authenticate your emails properly. SPF authorizes specific IP addresses to send on your domain’s behalf. DKIM cryptographically signs messages to prove they weren’t altered in transit. DMARC tells receivers what to do if an email fails SPF or DKIM—usually reject or quarantine. In Salesforce-ESP syncs, DMARC policy enforcement is often enabled. If either SPF or DKIM fails, the email is rejected with a 550 5.7.1 error. You can’t skip any one.

How each layer works in practice

Let’s break down each mechanism and why they matter when syncing with Salesforce-ESP.

SPF alone isn’t enough. DKIM ensures content integrity. Together, they build trust. DMARC adds enforcement—without it, failing checks may go unnoticed. This is why 550 5.7.1 errors appear in Salesforce-ESP syncs: the receiving server sees a mismatch in authentication layers and blocks the message.

For organizations using Salesforce with SendGrid, Mailchimp, or other ESPs, misconfigured SPF or DKIM can lead to hard bounces, deliverability drops, and missed communication. It’s not just technical—it blocks real business outcomes.

Want to test your domain’s authentication setup? Run a deliverability test with Email List Validation to catch SPF/DKIM flaws before your campaign launches.

For deeper insight, see the DMARC specification and SPF standard in the IETF’s official documentation. These aren’t recommendations—they’re the technical foundation of email security.

Step-by-step: Configure SPF and DKIM for Salesforce-ESP integration

You fix the 550 5.7.1 sender not authorized error by ensuring your domain’s SPF and DKIM records are correctly published in DNS and verified by your ESP. This tells receiving servers you’re authorized to send from that domain. SPF authorizes specific IPs or services; DKIM adds cryptographic proof each email hasn’t been altered. Without both, emails fail authentication and are blocked.

Set up SPF: Authorize Your ESP’s Sending Sources

1. Log in to your ESP’s dashboard—SendGrid, Amazon SES, or Mailchimp—and navigate to domain authentication settings.
2. Copy the SPF record format provided, which typically includes include:spf.protection.outlook.com or a specific IP range for the service.
3. Update your domain’s DNS zone file by adding a TXT record with the copied SPF content. Do not create multiple SPF records—merge all values into a single record using the SPF mechanism to avoid validation failures.

Set up DKIM: Add Cryptographic Signing Keys

4. In your ESP’s interface, generate a DKIM key pair. This creates a public key you’ll publish in DNS and a private key the ESP uses to sign outgoing emails.
5. Copy the public key and add it as a TXT record in your DNS zone, using a subdomain like selector1._domainkey.yourcompany.com.
6. Wait 10–30 minutes for DNS propagation. Use a tool like MxToolbox to verify both SPF and DKIM records are live and correctly formatted.
7. Return to your ESP dashboard and complete the domain authentication check. This confirms the infrastructure is set up and working.

Once verified, Salesforce’s ESP sync should resolve the 550 5.7.1 error. If issues persist, check for malformed records, incorrect selectors, or delays in DNS propagation. You can validate your email list for deliverability ahead of sync using automated tools—bulk email list cleaning ensures only valid, deliverable addresses are sent.

Common SPF and DKIM misconfigurations in Salesforce setups

You're seeing a 550 5.7.1 error during Salesforce-ESP sync because your domain’s SPF or DKIM records are misconfigured. Common issues include multiple SPF records, incorrect DKIM selectors, or DNS propagation delays. These errors prevent authentication and block email delivery. Let’s walk through the most frequent root causes and how to fix them properly. You don’t need to guess — each issue has a clear, technical fix.

SPF record issues

• Only one SPF TXT record is allowed per domain. If you have more than one, mail servers reject your messages. Remove duplicates and consolidate your mechanisms into a single record.
• Using both include:spf.protection.outlook.com and a long list of IP addresses can exceed the 10 DNS lookup limit. This triggers SPF permerror. Use include only for trusted third parties and avoid listing many individual IPs.
• Ensure your SPF record uses the correct syntax: start with v=spf1, use mechanisms like include:, ip4:, or all, and end with a policy like -all for strict enforcement.

DKIM configuration errors

• The DKIM selector in your ESP (e.g., Salesforce) must exactly match the one in your DNS record. A mismatch — such as using selector1 in DNS but mail in Salesforce — breaks signing and triggers rejection.
• Copy the DKIM public key without extra spaces, line breaks, or encoding artifacts. Even a single space can invalidate the key. Use a plain text editor or the ESP’s export function to avoid mistakes.
• After updating DNS, wait for propagation. DNS changes can take up to 48 hours. Don’t assume it’s live immediately. Check with tools like MxToolbox or DNS Checker to confirm the record is visible globally.
• Always test your configuration with an email sent from Salesforce to a known address. Monitor delivery and check headers to validate SPF/DKIM alignment.

These misconfigurations are why many Salesforce-ESP syncs fail silently. Once you’ve fixed the underlying DNS issues, you’ll see consistent inbox placement. If you’re validating sender reputation and deliverability across multiple domains, consider using a bulk email verification tool to clean your list before deployment. Clean your list upfront to eliminate bounce risks and protect sender reputation.

How to verify SPF/DKIM configuration is working

Send a test email from Salesforce through your ESP integration, then inspect the full email headers using a tool like Mail-Tester or your ESP’s delivery logs. Look for SPF pass and DKIM pass in the results. If either fails, check your DNS records for accuracy and allow up to 72 hours for global propagation after changes.

Check headers for confirmation

Once the test email lands in a mailbox, open it and view the raw headers—most email clients let you access them via "Show original" or similar. Tools like Mail-Tester (https://www.mail-tester.com/) or your ESP’s own logging interface will parse these headers and show validation outcomes. A clean SPF pass and DKIM pass indicate your configuration is functioning.

These checks are standard across email authentication. The RFC 7001 specification defines SPF, while RFC 6376 covers DKIM—both are industry-standard practices used by major providers and inbox filters. When either fails, the email may be flagged or rejected, often with a 550 5.7.1 error in Salesforce-ESP sync setups.

Fix and revalidate if needed

If you see a SPF fail or DKIM fail, double-check the DNS records in your domain’s zone file. Misconfigured or missing TXT records are common culprits. Use a tool like MxToolbox (https://mxtoolbox.com/) to verify record presence and syntax. SPF can be especially sensitive to syntax errors—excessive mechanisms or incorrect alignment can break the pass.

Remember: DNS changes take time. Even after updating records, propagation can take up to 72 hours globally. Waiting 24 hours before testing again is standard practice. If failure persists beyond 48 hours, verify your ESP is configured to use the correct sending domain and that it’s not applying sender filters that override authentication.

For teams managing high-volume lists, validating domain and mailbox authenticity upfront reduces delivery issues. You can use Email List Validation’s real-time API or bulk verification tools to screen for risky or invalid addresses before sending, reducing bounce rates and protecting sender reputation. Test configurations with confidence by ensuring your infrastructure passes standard authentication checks.

How Email List Validation can help catch deliverability issues early

You can prevent inbox placement failures and sender reputation damage—even with correct SPF/DKIM—by validating your list before sending. Email List Validation catches invalid, risky, or catch-all addresses that would otherwise trigger bounces or get flagged as spam, even if your authentication is fully set up. This reduces waste, keeps hard bounces low, and maintains sender reputation over time.

Authentication is necessary, but not sufficient

Even when SPF and DKIM are configured correctly in Salesforce or your ESP, a poor-quality list can still tank deliverability. Bounces from invalid or dormant addresses hurt your sender reputation, which can lead to increased filtering—even if your technical setup is flawless. You can’t rely on authentication alone to guarantee inbox placement.

Let’s say your domain passes SPF/DKIM checks but you’re sending to hundreds of outdated or role-based emails. Those bounces still get logged by receiving servers, and over time, your sending reputation erodes. Email List Validation finds those weak links before they cause problems, reducing bounce rates and keeping your domain trusted.

High accuracy, real-time insights

With 98.9% accuracy, Email List Validation identifies not just invalid emails, but also risky ones like disposable domains, role accounts (e.g., admin@ or sales@), or catch-all addresses that accept any input. These don’t just bounce—they can signal spam behavior to filters.

For example, a single catch-all domain accepting every address may trigger reputation alerts, even if individual recipients are valid. Catching these early prevents your outbound volume from being misclassified. Use the bulk verification tool to clean large lists before syncing with Salesforce or your ESP.

When you hit a 550 5.7.1 error, it’s not always about authentication. Sometimes, the root cause is list quality. The in-app AI assistant helps you parse header data, match bounce codes to list issues, and trace problems back to real-world sender behavior. You’ll see how list hygiene correlates with deliverability metrics, which makes troubleshooting faster and more precise.

Industry standards like RFC 5321 and the Sender Policy Framework documentation emphasize that both alignment and list quality matter. Just as SPF prevents spoofing, a clean list prevents reputation fatigue. RFC 5321 defines SMTP transaction rules, including how recipients handle malformed or high-bounce-volume sender behavior. The same principle applies: you’re not just sending emails—you’re sending a signal about your domain’s credibility.

Start with a free batch of 100 verifications to see how list quality impacts your delivery rates. The credits never expire, so take time to test. After your SPF/DKIM checks pass, validate your list. That’s where real deliverability improvement begins.

What to do if SPF/DKIM is correct but your Salesforce-ESP sync still fails

If SPF and DKIM are configured correctly but you’re still getting a 550 5.7.1 "sender not authorized" error during Salesforce-ESP sync, the issue is likely due to enforcing DMARC policies, mismatched header domains, or reputation-based filtering—none of which SPF/DKIM alone can resolve. Even if authentication passes, messages can be rejected if DMARC policy is set to reject, or if the return-path doesn't align with the authenticated domain.

Check for enforced DMARC policies

Even with valid SPF and DKIM, DMARC can still block your message if the policy is set to reject. Many senders assume passing SPF/DKIM is enough, but DMARC requires alignment of the domain in the From header with the domain authenticated in SPF or DKIM. If the sender domain doesn't match the alignment domain, DMARC fails—even if authentication passes.

Check the recipient’s DMARC record using tools like MxToolbox or dmarc.org. See if the policy includes reject or quarantine. A reject policy blocks emails that fail alignment, regardless of SPF/DKIM validity.

Verify domain alignment in header and return-path

Ensure the domain in the From header matches the one authenticated in SPF or DKIM. For example, if your ESP sends from [email protected] but SPF is set for send.yourcompany.com, alignment fails. This is a common pitfall in Salesforce-ESP syncs where the sending domain is not the same as the From domain.

Also confirm the Return-Path or Return-Path domain matches the sending domain. If your ESP uses an alias like [email protected] while your SPF is set to yourcompany.com, the email will fail strict checks. Use inbox-placement testing to simulate email delivery and verify alignment in real inboxes.

Finally, check if your sending domain or IP is on a blocklist. Even with correct authentication, poor sender reputation or IP blacklisting can cause 550 errors. Use tools like Spamhaus or MxToolbox to verify IP and domain reputation. High bounce rates or spam complaints degrade reputation and can block delivery, even with valid records.

Pro tip: Automate email authentication checks with Email List Validation

You can catch SPF/DKIM misconfigurations before they trigger 550 5.7.1 errors in Salesforce-ESP sync by verifying sender alignment at the recipient level. Integrate Email List Validation with SendGrid, HubSpot, or Klaviyo to automatically clean your list and test authentication right before send. This stops invalid or misaligned emails from harming your sender reputation — even one rejected message can impact deliverability.

Check alignment in real time, not in theory

SPF and DKIM are only effective if they match the sending domain. A recipient server checks both, and a mismatch — even if subtle — can cause rejection. Email List Validation’s real-time API doesn’t just check syntax; it validates actual email delivery conditions, including domain alignment at the recipient level. This is crucial when syncing from Salesforce to an ESP, where misconfigurations often go unnoticed until mail stops arriving.

With the real-time verification API, you can check individual addresses for SPF/DKIM alignment on demand. Let’s say you're syncing a lead list from Salesforce to HubSpot. Run each email through the API before sync — if the domain fails alignment, you’ll know before it reaches the ESP’s filters. This isn’t guesswork. It’s a proactive check against real, live infrastructure.

Prevent reputation damage before it starts

Even one message sent to a non-compliant or blocked domain can hurt your sender reputation. According to Spamhaus, inconsistent authentication is a red flag in modern email systems — especially when paired with high bounce rates or spam complaints. If an ESP like SendGrid sees repeat authentication mismatches, it may throttle or block future sends.

By integrating Email List Validation into your pre-send workflow, you’re not just cleaning lists — you’re auditing email infrastructure. This isn't about volume; it's about signal. Each verified email gives your domain a small win in the eyes of inbox providers. Over time, this reduces bounces, lowers the risk of blacklisting, and improves inbox placement.

Use the bulk verification tool to regularly scan your entire list, flagging domains with misaligned SPF/DKIM. Pair it with your ESP’s native list management, and you’ll catch configuration drift before it becomes a delivery failure. You don’t need to be perfect — just consistent. And that consistency starts with real-time validation.

Final note: Deliverability doesn’t depend on one fix — it’s a system

SPF and DKIM are foundational, but they don’t guarantee inbox placement. Even with correct authentication, a high bounce rate, poor engagement, or a weak sender reputation will still trigger filtering.

Deliverability is a holistic system

• Authentication (SPF/DKIM) prevents rejection at the envelope stage.
• List hygiene ensures you’re not sending to invalid or dormant addresses.
• Inbox testing confirms your email arrives in inboxes, not spam folders.
• Sender reputation evolves from consistent sending behavior over time.

Fixing 550 5.7.1 errors in Salesforce-ESP sync is a necessary step — but it’s only one part of a larger deliverability framework.

Keep reading

• Bounce management: hard bounces, soft bounces and bounce rate (complete guide)
• How to Sanitize Email Lists for Mailgun to Avoid 550 5.7.2 Error
• Email Verification SaaS with Automatic 550 5.7.1 Suppression List Refresh in 2024
• Automate Suppression List Based on 550 5.7.1 Error Codes in 2024
• Stop 554 5.7.9 Reputation Threshold in Pipedrive Sync with Email Verification API

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 550 5.7.1 sender not authorized mean in Salesforce?

It means the email server rejected the message due to missing or invalid SPF or DKIM authentication records. The domain is not authorized to send emails from the specified IP address.

Can I fix SPF/DKIM without changing DNS?

No — SPF and DKIM require DNS changes. The records must be published in your domain’s DNS zone to be effective.

How long does SPF/DKIM propagation take?

DNS changes typically take 10–30 minutes to propagate, but can take up to 72 hours in rare cases. Use tools like MxToolbox to verify propagation.

Why does my test email still fail after adding SPF and DKIM?

Check for multiple SPF records, incorrect DKIM selector names, missing DMARC policies, or mismatched return-path domains. Also verify DNS propagation.

Can I use Email List Validation to test SPF and DKIM?

No — the tool doesn’t validate DNS records directly. However, it tests deliverability and inbox placement, which helps identify if authentication issues are affecting delivery.

Do I need DKIM if I have SPF?

Yes. SPF alone is not enough. Modern ESPs require both SPF and DKIM to ensure message integrity and sender identity.

Is DMARC required for Salesforce-ESP sync?

Not required, but many ESPs enforce DMARC policies. Failing SPF or DKIM may lead to rejection if DMARC policy is set to reject.

How does list hygiene affect SPF/DKIM errors?

List hygiene doesn’t directly fix SPF/DKIM errors, but poor list quality (high bounces, spam traps) can damage sender reputation and trigger higher scrutiny from ESPs.

What are the consequences of ignoring 550 5.7.1 errors?

Messages will fail to send, reduce campaign performance, harm sender reputation, and increase the risk of being blacklisted.

Can Email List Validation prevent 550 5.7.1 errors?

It can’t prevent authentication failures, but it helps reduce spam trap exposure and invalid sends — which indirectly supports deliverability and reputation.

Why do some ESPs show SPF pass but DKIM fail?

This indicates the sender IP is authorized, but the message signature verification failed. Check DKIM key alignment, selector name, and header changes during routing.

How many SPF records can I have per domain?

Only one. Multiple SPF records cause a validation failure. Use the mechanisms listed in RFC 7208 to aggregate multiple authorizations under one record.