Add Third-Party Senders to Your SPF Record

The short answer: Edit your existing SPF TXT record and add the vendor's include: value before the final -all or ~all, keeping one record per domain and staying within 10 DNS lookups. But for DMARC, SPF is often not what matters: most platforms send from their own bounce domain, so SPF will not align with yours. Set up the vendor's DKIM for your domain as well.

Adding a marketing platform, CRM or helpdesk is two jobs, not one. The SPF edit gets mail authorised. The DKIM setup is what usually makes it pass DMARC. This guide covers both, with the include values we are confident of, the pitfalls, and a cleaner long-term pattern using a dedicated subdomain.

Background reading if you need it: what an SPF record is and the SPF record syntax guide.

Step Zero: Understand Which Domain SPF Checks

SPF does not check the address people see in the From line. It checks the domain in the envelope sender (also called MAIL FROM or Return-Path), which is usually invisible to recipients.

When Mailchimp or SendGrid sends on your behalf, the envelope sender is normally the vendor's own bounce domain, not yours. Consequences:

• SPF is evaluated against the vendor's record, and passes, no matter what is in your record.
• That pass does not align with your From domain, so it does not count for DMARC.
• The include: in your root record is then irrelevant to authentication for that vendor.

You still add the include when the platform sends with your domain in the envelope sender (some CRMs, transactional services and helpdesks do, or can be configured to). Whether it matters depends on the platform, so check the vendor's authentication documentation. A message header tells you for certain; look at smtp.mailfrom and header.d in the received copy:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@mail.vendor-platform.example header.s=k1;
  spf=pass smtp.mailfrom=bounce.vendor-platform.example;
  dmarc=fail (p=NONE) header.from=yourdomain.com

Here SPF and DKIM both pass, yet DMARC fails because neither domain matches yourdomain.com. Fixing that is a DKIM job, covered below.

SPF Include Values for Common Platforms

HubSpot is deliberately not in this table. HubSpot's authentication setup centres on DKIM and CNAME records for your sending domain rather than a root-record include, and the details change by product and by whether you use a dedicated sending domain. Follow the instructions inside HubSpot's domain-authentication wizard rather than copying an include string from a blog, including this one.

The same applies to every row: providers do occasionally change their SPF infrastructure. Treat this table as a starting point and confirm in the vendor's current help centre before publishing. Our SPF checker will flag an include that does not resolve.

How to Edit the Record Correctly

An SPF record is one TXT record at the root of your domain:

v=spf1 include:_spf.google.com include:servers.mcsv.net -all

Each platform you add is another include: placed after v=spf1 and before the final all:

v=spf1 include:_spf.google.com include:servers.mcsv.net include:_spf.salesforce.com -all

Rules that prevent most breakage:

1. One SPF record per domain. Two TXT records starting v=spf1 produce permerror. Edit the existing one.
2. Keep all last. Anything after it is ignored.
3. Do not add a vendor you will not use. Every extra include costs lookups.
4. Mind the 255-character string limit. Long records must be split into several quoted strings in one TXT record; most DNS hosts do this for you.
5. Re-check the lookup count after every change (next section).

Step by step

1. Log in to wherever your DNS is hosted (Cloudflare, GoDaddy, Namecheap, Route 53, your registrar).
2. Find the TXT record at the root (@) whose value begins v=spf1.
3. Add the vendor's include before the -all or ~all.
4. Save. Changes normally appear within minutes to a few hours, depending on the record's TTL.
5. Run the SPF checker and confirm the new include resolves and the count is within limits.

If you would rather not edit by hand, the SPF generator lets you pick providers and shows the lookup count as you go.

Watch the 10-Lookup Limit

SPF allows 10 DNS lookups per evaluation, counted across every nested include. Google alone uses several (its record nests further includes), so a domain with Google Workspace plus four or five other senders can easily cross the line, and when it does the entire record returns permerror.

This is the single biggest hazard when adding vendors. The full counting rules, a worked example and the fixes (removing senders, subdomains, flattening) are in SPF too many DNS lookups, so they are not repeated here. The short version: add one vendor at a time and re-check after each.

The Step Most Guides Skip: DKIM Alignment

DMARC passes when either SPF or DKIM passes and aligns with the From domain. For most third-party senders, DKIM is the reliable route. Every serious platform supports signing with a key tied to your domain, usually via CNAME or TXT records you publish. The names differ by vendor; the pattern is:

s1._domainkey.yourdomain.com.   CNAME   s1.domainkey.u12345.vendor.example.
s2._domainkey.yourdomain.com.   CNAME   s2.domainkey.u12345.vendor.example.

Copy the exact hostnames and targets from the vendor's authentication screen; they are unique to your account. Once verified, the vendor signs with d=yourdomain.com, DKIM aligns, and DMARC passes even if SPF does not align.

Where to find it in the platforms in this guide:

• Mailchimp: Settings, then Domains, then Authenticate for your sending domain.
• Salesforce: Setup, search for "DKIM Keys", create a key for your domain and publish the CNAMEs it shows.
• HubSpot: the domain connection and email-authentication settings in your account's settings.
• SendGrid, Mailgun, Postmark, Amazon SES: their "domain authentication" or "sender signature" setup pages.

Menu names move; search the vendor's help centre for "authenticate domain" or "DKIM" if a path has changed. Verify with the DKIM checker, and if a signature fails afterwards see DKIM signature failed.

The Cleaner Pattern: A Dedicated Subdomain per Sender

Instead of stacking every vendor onto your root domain, give each class of mail its own subdomain:

Benefits:

• Each subdomain gets its own 10-lookup budget, so adding a vendor never breaks your mailbox SPF.
• A reputation problem on newsletters does not damage the domain staff use for day-to-day mail.
• DMARC at the root covers subdomains by default (via the sp= tag if you set one), and aggregate reports show each source separately, which makes reading DMARC reports easier.

The trade-off is setup effort and the need for each subdomain to be authenticated. Most vendors support a custom sending or return-path subdomain for precisely this reason.

Verify End to End

1. Send a test from the platform to a Gmail address.
2. Open the message, choose the three-dot menu, then Show original.
3. Confirm spf=pass, dkim=pass and dmarc=pass, and read header.d and smtp.mailfrom to see which domains were checked.
4. For a clearer breakdown, paste the headers into the email header analyzer.

If DMARC fails while SPF and DKIM pass, the cause is alignment: set up the vendor's DKIM for your domain. If the whole thing is a mess, run through why your emails are going to spam. For store-specific setups see Shopify email authentication, and for mailbox platforms see Microsoft 365 authentication and DMARC for Google Workspace. The overall model is in SPF, DKIM and DMARC explained.

Troubleshooting After You Add a Sender

A frequent DNS-host quirk is the doubled domain: entering s1._domainkey.yourdomain.com into a host that appends the domain itself produces s1._domainkey.yourdomain.com.yourdomain.com. Look at the record as published, not as typed.

Frequently Asked Questions

Do I need to add every email tool to my SPF record?

Not necessarily. If a tool sends with its own bounce domain, SPF is checked against the vendor and your record is irrelevant for authentication. Add the include only when the vendor's documentation says it sends using your domain as the envelope sender. DKIM for your domain is needed either way.

Can I have two SPF records if I use multiple platforms?

No. Two records starting v=spf1 on the same domain cause permerror. Combine all includes into one record or move senders to subdomains.

Why does my email pass SPF but fail DMARC?

SPF passed against a different domain from your From address, so it is not aligned. Authenticate the sending domain with the vendor so DKIM signs as your domain.

Should I use the vendor's include or paste their IP addresses?

Use the include unless you are at the lookup limit. Pasted IPs go stale when the vendor changes infrastructure. The lookup-limit guide explains flattening trade-offs.

How long until SPF changes take effect?

Often minutes, occasionally hours, depending on the TTL of the old record and resolver caches. Re-test with the SPF checker rather than waiting a fixed time.

Next Step

Run the SPF checker after every vendor change, or get a free email audit to see SPF, DKIM and DMARC together. If you would like each sender authenticated for you, see the email security setup service.