How to Maintain DMARC Compliance with Third-Party Senders

Most small businesses don't send email from just one place. Marketing goes through Mailchimp, invoices through Stripe, support tickets through Zendesk, transactional messages through SendGrid, and the odd newsletter through a CRM. Each of those is a "third-party sender" — and each one can break your DMARC compliance if it isn't set up correctly.

The good news: fixing third-party senders isn't technically hard. The hard part is knowing they exist in the first place. This guide walks through auditing, configuring, and monitoring every service that sends mail as your domain.

Step 1: Build the inventory

You can't fix what you don't know about. Start by publishing a DMARC record in reporting mode (p=none) and collecting aggregate reports for a few weeks. Reports will reveal every IP and ESP sending as your domain — including ones you forgot about.

v=DMARC1; p=none; rua=mailto:[email protected]

Use the free DMARC record checker to confirm the record is valid, then watch the reports roll in. You'll almost certainly be surprised by what you find.

Step 2: Categorise each sender

Not all senders are equal. Sort them into three buckets:

The third category is the easy win — most domains have two or three zombie services that stopped being used years ago but still have SMTP credentials lying around. Disabling them removes risk instantly.

Step 3: Configure DKIM for every remaining sender

DKIM is the most important authentication mechanism for third-party senders. Unlike SPF, DKIM survives forwarding, and it's the mechanism most ESPs rely on for DMARC alignment.

Every reputable ESP will give you one or more CNAME records (or occasionally TXT records) to add to your DNS. Typical formats:

s1._domainkey.yourdomain.com   CNAME   s1.domainkey.esp.com
s2._domainkey.yourdomain.com   CNAME   s2.domainkey.esp.com

After publishing, send a test email and verify the DKIM signature aligns with your domain — not the ESP's. This is what makes DMARC pass.

Step 4: Configure SPF (carefully)

SPF is trickier because the SPF record has a hard limit of 10 DNS lookups. Every include: counts toward that limit, and stacking ESPs will blow through it quickly.

A typical small business SPF might be:

v=spf1 include:_spf.google.com include:mailgun.org include:sendgrid.net ~all

If you're nearing 10 lookups, you have two options:

1. Drop SPF-only senders that also support DKIM, and rely on DKIM alignment instead
2. Use SPF flattening (a maintained service that rewrites includes into IPs)

Don't just add more includes until SPF silently breaks — use the DMARC record checker to catch failures early.

Step 5: Verify alignment

DMARC doesn't care if SPF and DKIM pass in isolation. It cares that they pass and align with the From: header domain. An email from [email protected] signed by esp.com will fail DMARC even if the DKIM signature is valid.

To fix this, most ESPs offer a "custom sending domain" or "authenticated domain" feature. Turn it on for every third-party sender that matters.

Step 6: Monitor forever

Third-party senders change. Vendors rotate DKIM keys. Marketing teams sign up for new tools without telling IT. A record that was valid last month can quietly break tomorrow.

deliverabilitychecker.com monitors authentication health across your sending domains and alerts on changes. And if you need to update your DMARC record as your sender list grows, dmarccreator.com will generate a correct record.

The typical SMB sender list

Most small businesses have some subset of these. If you recognise any, make sure they're authenticated:

• Google Workspace / Microsoft 365 — primary business email
• Mailchimp / Brevo / ActiveCampaign — marketing
• Stripe / Xero / QuickBooks — invoicing and receipts
• Zendesk / Freshdesk / HelpScout — customer support
• HubSpot / Pipedrive / Salesforce — CRM and sales outreach
• SendGrid / Postmark / Mailgun — transactional email
• DocuSign / HelloSign — contracts

Each one needs its own DKIM setup and, where possible, a custom sending domain.