Configure DKIM & SPF for CRM Integrations

Why do 550 5.7.1 errors keep breaking your CRM email integration?

You’ve set up a clean integration in your CRM—Zapier, native sync, whatever it is—and then, suddenly, every email you send from a contact record fails with a 550 5.7.1 error. No warning. No explanation. Just a hard bounce.

This isn’t your CRM’s fault. It’s not even the recipient’s. The error means the receiving mail server rejected your message because it didn’t trust the sender’s domain—most likely due to a missing or misconfigured SPF or DKIM record at the sending domain level.

Even if your CRM platform itself sends well, integration-triggered emails often run through your company’s own domain. If that domain lacks proper email authentication, the message gets flagged or blocked before it ever hits the inbox. You’re not just losing a single email—you’re risking your sender reputation across every send.

Configuring DKIM and SPF correctly for CRM integrations isn’t a side chore. It’s the core technical foundation for reliable email delivery. We’ll walk you through exactly how to set it up so you stop hitting those 550 5.7.1 blockers—without needing to rebuild your workflow.

Key takeaways

550 5.7.1 errors indicate a failed email authentication check—usually due to missing or incorrect SPF or DKIM records at the sender domain.
CRM integration emails often inherit the authentication setup of the sending domain, not the CRM’s own sending domain, so configuration must match the actual sender.
Even if your CRM sends reliably, a misconfigured sender domain in integrations can break deliverability and hurt your overall sender reputation.

The role of SPF and DKIM in CRM email delivery

You need SPF and DKIM configured properly to prevent 550 5.7.1 errors when sending emails through CRM integrations. These protocols work together to verify your identity and ensure messages aren’t tampered with in transit—key factors that inbox providers like Gmail and Microsoft use to decide whether to accept or block your emails. Without them, even legitimate CRM sends may be flagged as suspicious. Let’s break down how each one contributes.

SPF: Authorizing the sending source

SPF (Sender Policy Framework) tells receiving servers which IP addresses or domains are allowed to send email on your behalf. If your CRM integration uses an external email service—like SendGrid, Mailchimp, or a cloud-based SMTP provider—SPF must include those sources. Otherwise, receiving servers see the message as spoofed and reject it with a 550 5.7.1 error. A single missing entry in your SPF record can trigger this.

For example, if your CRM sends via a third-party platform that uses a different IP range than your own, failing to update your SPF record to include that IP will result in delivery failure. This is common in large-scale automation flows where the sending IP isn’t your own. You can check your current SPF setup using tools like MXToolbox or RFC 7208, the official specification.

DKIM: Ensuring message integrity

DKIM (DomainKeys Identified Mail) adds a digital signature to each outgoing email, proving it was sent from your domain and hasn’t been altered in transit. Unlike SPF, which checks the source, DKIM validates the content’s authenticity. This is especially important when your CRM sends emails through an intermediary, since the message might be rewritten or modified during routing.

Mail providers treat DKIM-signed messages as higher trust. If DKIM validation fails—say, because the signature doesn’t match or the key isn’t published—receivers may flag the message as suspicious. This can cause inbox placement issues or outright rejections, especially for bulk or transactional emails from sales or marketing teams using CRM systems.

Both SPF and DKIM are industry-standard verification methods. According to RFC 7208, SPF is designed to help prevent sender address forgery, while DKIM, defined in RFC 6376, provides cryptographic assurance that the message content remains unchanged. Together, they’re essential for reliable CRM email delivery. If your integration sends from multiple sources, ensure both records are updated and tested.

How to verify your CRM integration domain is properly authenticated

You can confirm your CRM integration domain is properly authenticated by checking its SPF and DKIM records in DNS using a free tool like MxToolbox. Ensure the SPF record includes only authorized sending IPs or service providers (like SendGrid or your CRM’s outbound servers). Confirm DKIM is active with a valid public key for the selected selector (e.g. default or custom). These checks prevent 550 5.7.1 errors by validating your domain’s legitimacy during email delivery.

Step-by-step DNS verification checklist

Identify the exact sending domain used by your CRM integration — this could be your primary domain (example.com) or a subdomain like mail.example.com.
Use a reputable DNS lookup tool such as MxToolbox to query the SPF and DKIM records for that domain.
Check the SPF record for a list of allowed sending sources. It should include the IP addresses or service providers handling outbound email (e.g., SendGrid, Mailchimp, or your CRM’s dedicated outbound servers), not just generic entries like "include:spf.protection.outlook.com" without specificity.
Verify the DKIM record uses the correct selector (common ones include default, dmarc, or a custom name). The public key must be visible and match the signing key used by the sending system.
Ensure no conflicting or overly permissive records exist (e.g., multiple SPF records or unqualified mechanisms like “all” without exceptions).
Test a sample email sent via the CRM integration and check its headers for authentication results using a tool like RFC 6376, the standard defining DKIM.

Common issues and fixes

If SPF fails, the record may be malformed, too long (over 10 DNS lookups), or include unauthorized or wildcard mechanisms.
If DKIM fails, the private key may not match, the selector might be wrong, or the DNS record might be missing or typoed.
Some CRMs use shared IP pools. If your provider uses a shared infrastructure, ensure their SPF includes your domain or use a DKIM-only authentication path.
Never rely on a single service’s default configuration. Always validate the actual DNS records of the sending domain.
Changes to SPF or DKIM take 24–48 hours to propagate globally. Monitor new messages after updates.

Properly configured SPF and DKIM not only prevent 550 5.7.1 errors but also protect your sender reputation. If you're managing a high-volume CRM email stream, validate your full list before sending — clean and verify your list to avoid delivery failures on poorly authenticated domains.

Common causes of 550 5.7.1 errors in CRM-to-email flows

550 5.7.1 errors happen when your email gets rejected because the receiving server doesn't trust your sender identity. This usually stems from misconfigured SPF or DKIM, duplicate DNS records, using unverified sending domains, or sending from role-based addresses without reputation tracking. Let’s break down the most common culprits.

SPF and DKIM configuration failures

You’re using a CRM integration that sends from a different IP or cloud service than what’s listed in your SPF record. If the integration doesn’t appear in your SPF, the email will fail authentication.
DKIM signatures are missing, expired, or signed with the wrong domain. If your CRM uses a subdomain like send.company.com, the DKIM record must be published under that specific subdomain, not the root domain.
If your CRM sends from an API endpoint or shared IP (like SendGrid or Mailchimp), you must include that service’s IP ranges in your SPF record—either via their included include directive or by manually adding their IP ranges. Missing this is a key reason for 550 5.7.1 failures.
Multiple SPF records in DNS are invalid. Only one SPF record per domain is allowed. If you have more than one, the server rejects the email. Use DNS tools like MXToolbox to check for duplication.

Identity and reputation issues

You’re sending from a role-based address like [email protected] without a strong sender reputation. These addresses often lack historical authentication data and are more likely to be flagged as suspicious by receivers.
The DKIM DNS record is missing or incorrect. Even if you have a DKIM key, it won’t validate unless the public key is correctly published in DNS at the proper selector and subdomain. Use RFC 6376 as a reference for proper DKIM DNS record structure.
Using a domain for sending that isn’t aligned with the From address. For example, a CRM sending from [email protected] but using a non-aligned SPF or DKIM domain leads to rejection.
Recent spikes in sending volume from a new or underused domain can trigger rate-based filtering, especially if there’s no sender reputation history. Consistent, low-volume sending builds trust over time.

Detecting these issues early saves time and improves inbox placement. You can spot invalid or risky sender addresses before sending—use real-time email verification to validate addresses in your CRM list. Verify email addresses instantly and catch delivery risks before they affect your campaign results.

Step-by-step: Fix SPF for your CRM integration domain

You fix SPF for your CRM integration domain by editing your DNS TXT record to include the sending service’s domain (like include:sendgrid.net), ensure only one SPF record exists, and combine multiple sources using include: instead of duplicating entries. After updating, wait 15–30 minutes and validate the change with a tool like Mail-Tester or MXToolbox. This stops 550 5.7.1 errors from sender authentication failures.

Check your current SPF setup

Log into your domain registrar or DNS provider — Cloudflare, AWS Route 53, GoDaddy, or similar.
Locate the SPF TXT record for your sending domain (e.g., example.com). It often appears as v=spf1 include:sendgrid.net ~all.
Verify it lists the correct sending service or IP range. For example, if your CRM uses SendGrid, ensure include:sendgrid.net is present.

Correct and consolidate your SPF record

If you have multiple sending services (e.g., SendGrid, HubSpot, Mailchimp), combine them all into a single SPF record using include: — never create duplicate TXT records.
Example: v=spf1 include:sendgrid.net include:hubspot.net ~all. This ensures all allowed sources are recognized without conflicting with SPF limits.
Remove any extra SPF records. Having more than one breaks SPF validation and triggers rejections.
Limit the number of include: mechanisms to under 10 — exceeding this can cause SPF failure due to evaluation limits.
Save changes and wait 15–30 minutes for DNS propagation. Most providers update within that window.
Test the result using tools like MXToolbox or Mail-Tester to confirm SPF passes.

SPF failures are often mistaken as CRM issues, but they’re usually DNS-level. A misconfigured SPF record means your CRM emails get rejected with 550 5.7.1 errors — even if your list is clean and the content is on-brand. Fixing the record at the DNS level resolves this root cause.

The 3 steps described in “Check your current SPF setup”, in order.

For broader deliverability health, use a service like inbox placement testing to validate not just SPF, but also DMARC, spam content, and sender reputation. This helps you catch issues before they affect real campaigns.

Step-by-step: Set up DKIM for your CRM integration domain

You can prevent 550 5.7.1 errors in CRM integrations by enabling DKIM signing on your outbound email domain. This confirms your messages are from a verified source. Start by generating a DKIM key pair in your CRM or email service (like HubSpot or SendGrid), then add the public key as a DNS TXT record using a selector like default._domainkey. Wait 15–30 minutes, then verify with a tool like DKIMvalidator.com. This step is critical for inbox placement and sender reputation.

Generate and publish your DKIM key

Access your CRM’s email settings — log into your CRM (HubSpot, Salesforce, etc.) and find the email or messaging configuration section. Enable DKIM signing for outbound messages. This tells the system to sign every email sent on your domain.
Generate a key pair — your CRM or email service provider (e.g., SendGrid, Mailchimp) will generate a public-private key pair. The private key stays secure on your provider's servers; the public key is what you’ll publish in DNS.
Copy the full public key — locate the key starting with v=DKIM1; k=rsa; and the large base64-encoded p=... string. It will look like: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC.... This is the entire record you’ll add.
Choose a selector — use a standard one like default._domainkey or smtp._domainkey. The selector defines the key’s identity in the DNS lookup. Some systems require a specific name, so check your provider’s docs.
Create the DNS TXT record — in your domain’s DNS manager (Cloudflare, GoDaddy, etc.), create a new TXT record. Set the name field to your selector (e.g., default._domainkey) and paste the full public key into the value field, including the quotes and the full string. Don’t omit or trim any part.

Validate and wait

After adding the record, wait 15–30 minutes for DNS propagation. Then test it using a public validator like DKIMvalidator.com or RFC 6376, which standardizes DKIM. If validation fails, recheck your selector, formatting, and syntax. Common issues include missing quotes, extra spaces, or truncated keys.

The 5 steps described in “Generate and publish your DKIM key”, in order.

Once verified, your CRM’s outbound emails will carry a digital signature. Email providers like Gmail and Outlook use this to verify authenticity. Without it, your CRM messages may be flagged as spam or rejected with a 550 5.7.1 error. If you’re unsure about your DNS setup, use tools like MxToolbox to audit TXT records. For higher email volume, validate your list first to avoid sending to invalid addresses — clean your list with Email List Validation before integration.

How to test if SPF and DKIM are working after configuration

After setting up SPF and DKIM for your CRM integration, send a test email to a major provider like Gmail or Outlook. Then, inspect the full message headers using a tool like Mail-Tester or Gmail’s built-in header inspector. Look for Authentication-Results: ...spf=pass and dkim=pass. If either says fail or neutral, check your DNS records or CRM settings, then rerun the test.

Step-by-step verification process

Use your CRM to send a test message to a Gmail or Outlook account. These providers log detailed authentication data in email headers.
Open the received email and view the full headers. In Gmail, click the three-dot menu > "Show original." In Outlook, use "View message source" or forward to a tool like Mail-Tester.
Look for two key lines in the headers: Authentication-Results: ...spf=pass and Authentication-Results: ...dkim=pass. Both must show pass to confirm full authentication.
If SPF shows fail or softfail, your SPF record may be missing, incomplete, or incorrectly aligned with the sending domain.
If DKIM shows fail, verify your DKIM selector and public key are published correctly in DNS, and that your CRM is signing messages with the right domain.
If one check passes but the other fails, focus on the failing mechanism first. Misalignment between the "from" domain and the signing domain is a common cause of DKIM failure.
Re-check DNS records via a tool like MXToolbox to ensure no typos or missing TXT records.
After fixing, retest. Authentication results can take up to 48 hours to update in some systems due to DNS caching.

What to do if tests fail

If both checks fail, ensure your CRM is using the correct sending domain in its SMTP configuration. Many CRMs default to a generic domain (e.g., sendmail.yourcompany.com) instead of your verified brand domain.

Let’s say you’re using HubSpot, Salesforce, or Klaviyo. Their documentation may require setting up a custom sender domain. If you’ve done that, double-check the SPF inclusion (e.g., include:_spf.yourcompany.com) and DKIM key placement.

DNS propagation delays are normal. Allow 1–2 hours after updating records before testing again.

You can use bulk email list validation to verify sender domains in mass, ensuring your list doesn’t rely on domains with weak or missing authentication.

Why bulk email verification helps prevent 550 5.7.1 errors before they happen

Many 550 5.7.1 errors aren’t due to incorrect SPF or DKIM setup—they happen because you’re sending to invalid, role-based, or disposable email addresses that are rejected by mail servers before your authentication even gets tested. By cleaning your list beforehand with email verification, you catch these bad addresses early, reducing bounce rates and protecting your sender reputation from damage.

Bad addresses trigger rejections even with perfect setup

You might have SPF, DKIM, and DMARC perfectly configured, but sending to a role-based address like admin@ or sales@ can still result in a 550 5.7.1 error if the domain blocks unverified sources or automatically rejects such addresses. These errors aren’t about your authentication—they’re about the recipient’s policies. A list full of such addresses guarantees bounces, even with flawless technical setup.

Let’s be clear: you can’t fix a bad list with better headers. The safest approach is to stop sending to invalid or suspicious addresses in the first place. Email List Validation checks each address in your CRM list against real-time SMTP checks, catch-all detection, disposable domain filters, and role-based address rules. With 98.9% accuracy, it flags invalid, risky, or unverifiable emails before they ever leave your system.

Preventing waste protects reputation

Every rejected email impacts your sender reputation—especially if the domain blocks your IP or flags you as a potential spammer. High bounce rates, even if temporary, can trigger rate-limiting or blacklisting. A clean list means fewer failures, lower risk of domain blocks, and consistent inbox placement.

Verification isn’t just about removing invalid emails—it’s about protecting your deliverability. You can’t reliably fix your reputation after it’s damaged; it’s far better to prevent the damage before it starts. Bulk validation helps you build a list that’s not only clean but also respectful of email server policies.

For the most consistent results, integrate verification into your CRM workflow. Whether you’re using Mailchimp, HubSpot, or SendGrid, tools like Email List Validation integrate directly to flag and remove risky addresses before they’re sent. See how it works at bulk email list cleaning or check real-time verification options at real-time email verification. The goal isn’t just to avoid errors—it’s to send only to addresses that are likely to receive and engage.

Real examples of CRM integrations that caused 550 5.7.1 errors

550 5.7.1 errors often stem from misaligned SPF or DKIM records when CRM tools send emails from custom domains. You might think your email setup is solid, but even small oversights—like missing a service’s IP in SPF or misconfiguring a DKIM selector—can block entire campaigns. These errors typically come from unauthorized senders or failed authentication, and they’re common when integrating third-party tools like HubSpot, Klaviyo, or SendGrid with CRMs.

HubSpot with an incomplete SPF record

A sales team used HubSpot to send outreach emails from their company domain. Their SPF record listed only their in-house mail servers and excluded HubSpot’s IP ranges. As a result, 40% of their messages were rejected with a 550 5.7.1 error. The receiving server checked SPF and found that HubSpot wasn’t authorized, triggering the block. This is a common issue when email vendors aren’t added to DNS records—especially when teams assume that the CRM handles authentication automatically.

Klaviyo with a misconfigured DKIM selector

In another case, a marketing team connected Klaviyo to their CRM via Zapier. They set up DKIM but used the wrong selector—common when copying templates without verifying the correct name. The DKIM signature failed validation, even though the email was sent from a legitimate platform. This caused messages to be tagged as unauthenticated, leading to 550 5.7.1 errors from strict email gateways like Google and Microsoft. DKIM requires exact alignment: selector, domain, and private key must all match what the receiving server expects.

SendGrid IP change without SPF update

A company used SendGrid through a CRM for transactional emails. After SendGrid updated its IP pool, the company never refreshed their SPF record. Old IPs were removed from the allowlist, and new messages were automatically blocked. The error message—550 5.7.1—was the same across multiple providers, indicating that the sending IP wasn't authorized in SPF. This is why it’s critical to monitor changes in third-party infrastructure and update DNS accordingly.

These failures are preventable. Double-check SPF includes all sending platforms. Ensure DKIM selectors match the public key registered in DNS. Stay alert when vendors change IPs. For ongoing verification, test your setup before large sends. You can also verify list health with tools like bulk email list cleaning to catch invalid or poorly configured senders before they hurt your deliverability.

How to avoid 550 5.7.1 errors in future integrations

550 5.7.1 errors often stem from misconfigured DNS records or sending from unverified domains. You avoid them by validating all sending domains, testing with small lists, and ensuring SPF and DKIM are correctly set and maintained—especially when switching email providers or IP addresses. Let’s walk through how.

Pre-deployment checks to prevent delivery fails

Always verify the domain used for sending before deploying any CRM integration. A domain not properly authenticated will trigger rejection from receiving servers.
Use a tool like bulk email list cleaning to scrub your contact list for invalid, disposable, or role-based addresses that increase bounce risk and hurt sender reputation.
Never send to your full list on first integration. Test with a small, targeted subset—10–20 contacts—to validate headers and delivery behavior before scaling.
Inspect email headers from test sends using tools like MxToolbox or DKIM RFC 6376 to trace alignment and authentication status. Look for missing or failed DKIM/SPF results.

Maintaining alignment after changes

After switching email providers or IP addresses, review and update your SPF and DKIM records. Even a single missing or misconfigured record can cause 550 5.7.1 errors.
SPF records must include all authorized sending sources, including your CRM or marketing platform. Overloading them with too many mechanisms can cause parsing errors—limit to 10 includes per record.
DKIM keys must remain active and correctly aligned with your sending domain. Some providers rotate keys automatically—but if you’ve set up the key manually, ensure it’s not expired or invalidated.
Use a real-time email verification API in your workflows to catch invalid or risky addresses at the point of entry, reducing future delivery issues.
Monitor inbox placement with periodic tests. A drop in inbox placement can signal sender reputation issues even if delivery appears successful.

A clean list and proper authentication are the twin pillars of inbox placement

Authentication with SPF and DKIM is essential, but it only works when paired with a sender reputation built on valid, engaged recipients. Sending to invalid or role-based addresses — even with correct headers — triggers rejection by most mail servers.

Use real-time verification to identify and remove high-risk addresses before they enter your CRM. This prevents 550 5.7.1 and similar errors that harm deliverability, even with flawless DNS records.

Combine DNS-level authentication with proactive list hygiene. This dual approach ensures your message reaches inboxes, not spam traps or bounces. Over time, consistent sending behavior builds long-term trust with inbox providers.

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 550 5.7.1 mean in email delivery?

It means the receiving server rejected your message due to authentication failure, most commonly from missing or misconfigured SPF or DKIM records.

Can a CRM integration fail SPF even if my domain is set up correctly?

Yes — if the CRM uses a different sending domain (e.g. via a subdomain or third-party service), that domain must have its own SPF record.

How do I know if my DKIM is working?

Check the email header for `dkim=pass`. Use a public DKIM checker to validate the signature against the DNS record.

Should I include my CRM provider in my SPF record?

Yes — if the CRM sends emails from your domain or subdomain. Add `include:provider.com` to your SPF record.

What happens if I have multiple SPF records?

Email providers reject the message. Only one SPF TXT record is allowed per domain; merge all sources into a single record.

Can a disposable email address cause a 550 5.7.1 error?

No — disposable addresses don’t trigger 550 5.7.1 errors directly. But sending to them harms deliverability and is avoidable with list validation.

How often should I check my SPF and DKIM records?

After any change to your email provider, IP address, or CRM integration. Periodically audit them at least quarterly.

Does Email List Validation help with DKIM setup?

Not directly. It helps you identify invalid addresses before sending. But it’s used by teams to reduce bounces and protect sender reputation.

Can I test SPF and DKIM without sending an email?

Yes — use tools like MXToolbox, DKIMvalidator.com, or DNS lookup services to verify records without sending a message.

What’s the easiest way to fix an SPF misconfiguration?

Use a DNS tool to check your current SPF record, merge all allowed sources into one `include:` statement, and remove duplicates.

Do role-based email addresses (e.g. info@, support@) cause 550 5.7.1 errors?

Not directly. But they often lack sender reputation and can trigger spam filters. Use list hygiening to remove them from bulk sends.

Is 98.9% accuracy in email verification real?

Yes — Email List Validation reports 98.9% accuracy across bulk and real-time verifications. This is based on internal testing against industry standards.