Email Security (DMARC+)

Managing Third-Party Senders

Managing Third-Party Senders

Overview

Most organisations don't just send email from their own mail server. Marketing platforms, CRMs, helpdesks, and other SaaS tools all send email on your behalf. Each one needs to be authenticated before you can enforce DMARC.

This guide explains how to identify third-party senders in your DMARC+ reports and configure authentication for the most common platforms.

How to identify your third-party senders

Open the DMARC+ Dashboard and look at the Top Sending Sources list. For each IP address:

  1. Note whether it's passing or failing DMARC
  2. Identify which service it belongs to (use a reverse IP lookup or the organisation name shown in DMARC reports)
  3. Decide: should this service be sending from my domain?

Common services you'll find:

  • Email marketing: Mailchimp, Klaviyo, Constant Contact, Brevo
  • CRM: Salesforce, HubSpot
  • Support: Zendesk, Freshdesk, Intercom
  • Transactional email: SendGrid, Mailgun, Postmark, Amazon SES
  • Accounting/invoicing: QuickBooks, Xero, FreshBooks
  • HR/payroll systems
  • Your own custom applications

Authentication requirements for each service

For every third-party sender, you need to:

  1. Add their SPF include to your domain's SPF record
  2. Configure DKIM in the service settings (they'll give you a DNS record to publish)
  3. Verify in DMARC+ that the source is now passing

Service-by-service guide

Mailchimp

SPF: include:servers.mcsv.net DKIM: Account → Settings → Domains → click Authenticate next to your domain → publish the CNAME record Mailchimp provides

Klaviyo

SPF: include:kl.klaviyomail.com DKIM: Settings → Email → Sender Profiles → Custom Sending Domain → follow setup wizard

HubSpot

SPF: include:_spf.hubspot.com DKIM: Settings → Marketing → Email → Domains → click your domain → DKIM setup → publish the CNAME record

Salesforce (Marketing Cloud / Sales Cloud)

SPF: include:_spf.salesforce.com (and any additional Salesforce IPs shown in your reports) DKIM: Setup → Email Administration → DKIM Keys → create key → publish TXT record

Zendesk

SPF: include:mail.zendesk.com DKIM: Admin Center → Email → Support Addresses → click your address → DKIM → publish the provided CNAME

SendGrid

SPF: include:sendgrid.net DKIM: Settings → Sender Authentication → Domain Authentication → follow wizard → publish 3 CNAME records

Mailgun

SPF: include:mailgun.org DKIM: Sending → Domains → your domain → DNS records → publish the provided TXT and CNAME records

Amazon SES

SPF: Use a custom MAIL FROM domain (recommended) — SES provides specific SPF instructions per region DKIM: Identity Management → select your domain → DKIM → Easy DKIM → publish the 3 CNAME records AWS provides

Postmark

SPF: Custom MAIL FROM setup — Postmark sends from their infrastructure but aligns with your domain via DKIM DKIM: Sender Signatures → your domain → DKIM → publish the TXT record

Intercom

SPF: include:intercom-mail.com DKIM: Settings → Email → Custom Email Addresses → DNS records → publish provided records

Subdomain strategy for third-party senders

A clean approach for third-party senders: use a dedicated subdomain for each service instead of your root domain.

For example:

Benefits:

  • Keeps your root domain's SPF record clean and under the 10-lookup limit
  • Each subdomain can have its own DMARC policy
  • Makes it easy to track which service sent what in reports
  • If a third-party service is compromised, only that subdomain is affected

Handling the 10-lookup SPF limit

As you add services, your SPF record will grow. The 10-lookup limit is a hard constraint — exceeding it causes PermError and all email fails SPF.

Count your current lookups: Open the SPF Explorer in DMARC+ — it shows your current lookup count.

If you're near the limit:

  1. Remove old services — anything you no longer use
  2. Use subdomains — move some senders to subdomains with their own SPF records (doesn't count toward your root domain's limit)
  3. Replace include chains with IP ranges — some services (SendGrid, AWS SES) have stable IP ranges you can list directly instead of using includes
  4. SPF flattening — tools that automatically resolve all includes to IP ranges and collapse them into a single record (requires regular updates as IP ranges change)

Verifying third-party authentication

After adding SPF and DKIM for a service:

  1. Send a test email through the service
  2. Check DMARC+ Dashboard after the next report cycle (24 hours)
  3. Verify the source IP now shows as passing DMARC
  4. If still failing, check SPF alignment (is the Return-Path using your domain or the service's domain?)