How do I authenticate mail from multiple senders?

21 June 2026 · 14 min read

Most organisations do not send all their email from one place. Marketing goes out through one platform, invoices and receipts through another, the helpdesk through a third, and the actual day-to-day mail through Google Workspace or Microsoft 365. Each of those services wants to send "as" your domain, and each one expects to be authenticated in a slightly different way. The good news is that DMARC was designed for exactly this situation. The catch is that the building blocks underneath it, SPF and DKIM, have sharp edges that bite hard once you go past three or four senders. This article explains how to authenticate many sending services from a single domain without tripping the SPF lookup limit, without breaking DKIM, and without losing DMARC alignment along the way.

If you would rather not manage any of this by hand, this is precisely what DMARC Engine does: it keeps one valid SPF record under the limit, hosts a DKIM key per vendor, and watches alignment in the reports so nothing silently falls out of policy. The rest of this article is the manual version, so you understand what is happening underneath.

The mental model: three independent checks

Before adding a single record, it helps to be clear about what "authenticated" actually means, because multi-sender setups fail when people conflate the three mechanisms.

SPF authorises which IP addresses are allowed to send mail using your domain in the envelope sender (the MAIL FROM, also called the Return-Path). It is published as one TXT record on your domain and it is checked against the connecting server's IP.
DKIM attaches a cryptographic signature to each message. The receiver fetches a public key from a DNS record at selector._domainkey.yourdomain.com and verifies the signature. Each sender uses its own selector, so multiple senders coexist with no conflict.
DMARC ties the two together. It checks that at least one of SPF or DKIM passes and that the passing mechanism is aligned with the domain in the visible From header.

The single most important word above is alignment. A message can pass raw SPF and raw DKIM and still fail DMARC, because the domain that passed was the sending platform's own domain, not yours. Multi-sender authentication is really an exercise in getting alignment right across many vendors at once. For the precise definition see DMARC alignment, and for a full explanation of how the five records fit together read the five records that protect email.

SPF: the one record everyone fights over

SPF is where multi-sender setups go wrong first, because there is only ever one SPF record per domain and it has a hard ceiling.

One record, not many

RFC 7208 is explicit: a domain must publish a single SPF record. If a receiver finds two TXT records that both start with v=spf1, the result is a permerror and SPF effectively fails for everyone. So when a new vendor tells you to "add this SPF record", they almost always mean "add this include to your existing SPF record". You merge, you do not append a second record.

A merged record for, say, Google Workspace plus a marketing platform plus a transactional provider looks like this:

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

Note the single v=spf1 at the start and the single -all at the end. Everything in between is the union of every sender's mechanisms.

The 10-lookup limit is the real enemy

Here is the rule that catches almost everyone running many senders: SPF allows a maximum of 10 DNS lookups while evaluating a record. Each include:, a, mx, ptr, exists and redirect counts, and crucially the lookups are recursive. When you write include:_spf.google.com, that include itself contains more includes, and every one of those counts against your budget. A single vendor can easily consume two, three or four of your ten lookups on its own.

Once you exceed ten, SPF returns permerror, and from a DMARC perspective that is treated as a failure. The maddening part is that it can pass for months and then break the day a vendor quietly adds an include to their own record, with no change on your side at all. See the SPF 10-lookup limit for the formal definition.

Roughly how the budget gets spent in practice:

Google Workspace: about 3 lookups
Microsoft 365: about 3 lookups
A typical marketing platform (Mailchimp, Klaviyo): 1 to 2 lookups
A transactional provider (SendGrid, Postmark, SES): 1 to 2 lookups
Your CRM, billing, support desk and any "send as" tools: 1 each, and they add up fast

Two big mailbox providers plus three or four ESPs and you are already brushing against, or past, the ceiling.

Watch out for void lookups too

Separately from the 10-lookup limit there is a 2 void lookup cap: if more than two of your lookups return no record (NXDOMAIN or empty), that is also a permerror. Stale includes for vendors you stopped using are the usual cause. See void lookup. When you offboard a sender, remove its include the same day.

Staying under the limit: flattening

The standard fix is SPF flattening: resolving all those nested includes down to the underlying IP addresses and ranges, then publishing those directly so each one costs zero recursive lookups. Instead of include:sendgrid.net consuming a chain of lookups, you publish the ip4: and ip6: blocks it ultimately points to.

The obvious objection is correctness. Senders change their IP ranges without warning, so a flattened record that is correct today can be silently wrong next month, which is worse than hitting the lookup limit because mail starts failing with no error on your DNS. That is why flattening is only safe if it is continuously re-resolved and re-published whenever a vendor changes its ranges. Doing that by hand is a recurring chore that no one remembers to do.

This is one of the core jobs DMARC Engine handles for you: it flattens your SPF automatically and keeps it fresh as vendors change, so you stay under ten lookups without ever maintaining a list of IP blocks by hand. The mechanics are covered in automatic SPF flattening explained, and you can test where your domain stands right now with the SPF checker. If your record is already broken, fix a failing SPF record walks through the common causes.

A blunt truth about SPF and alignment

Even when SPF passes, it often does not help DMARC for hosted senders. SPF aligns on the Return-Path domain, and most ESPs set the Return-Path to their own domain for bounce handling (something like bounces.mailer.example.net). That passes raw SPF, but it does not align with your From domain, so it contributes nothing to DMARC. This is exactly why DKIM matters so much in a multi-sender world, and why you should never rely on SPF alone to carry DMARC.

DKIM: the mechanism that actually scales

DKIM is the workhorse of multi-sender authentication because it has none of SPF's scaling problems.

Selectors mean unlimited senders

Every DKIM key lives at its own selector: s1._domainkey.yourdomain.com, mailchimp._domainkey.yourdomain.com, google._domainkey.yourdomain.com, and so on. Because each vendor publishes under a different selector, there is no merging, no shared record, and no upper limit on how many senders you can authenticate with DKIM. Ten vendors means ten _domainkey records, each completely independent. See DKIM selector for the detail, and check any vendor's published key with the DKIM checker.

Per-vendor DKIM is non-negotiable for alignment

Because hosted SPF almost never aligns, DKIM is usually the only mechanism keeping a hosted sender DMARC-compliant. When a vendor signs with a key published on your domain, the DKIM d= tag is your domain, and that gives you alignment regardless of what the Return-Path says.

So the rule for every new sender is: turn on DKIM with your own domain as the signing domain, not the vendor's shared signing. Most platforms call this "authenticated domain", "branded sending", "custom DKIM" or "dedicated domain". If a vendor only offers signing with d=theirplatform.com, that mail will never align for you, and you should treat that as a deliverability red flag.

Practical DKIM hygiene across many senders

Use a 2048-bit key where the vendor allows it. Some still default to 1024.
Keep selectors distinct. Never reuse one vendor's selector for another. If you re-onboard a sender, let it generate a fresh selector rather than recycling an old record.
Rotate keys periodically, and remove the old selector record only after the vendor has fully cut over, so in-flight mail still verifies.
Remove dead selectors when you drop a vendor, the same way you prune SPF includes.

Because DKIM scales cleanly, the strategic conclusion is straightforward: lean on DKIM for alignment, and treat SPF mainly as a courtesy that keeps a few simple senders happy and reduces some backscatter. For a deeper tour of how the mechanisms interact, see email authentication overview.

The subdomain strategy: divide and conquer

Once you have more than a handful of senders, the single cleanest structural decision is to stop sending everything from your root domain and start splitting senders across subdomains. This is the technique that turns an unmanageable tangle into something you can reason about.

Why subdomains help

A fresh SPF budget per subdomain. SPF's 10-lookup limit is per-domain. If mg.yourdomain.com only sends through one marketing platform, its SPF record only needs that one platform's include, with eight lookups to spare. Your root domain stops being the dumping ground for every vendor.
Reputation isolation. If your bulk marketing subdomain gets a complaint spike, it does not drag down the reputation of the root domain your invoices and your CEO's personal mail flow through.
Clearer reporting. DMARC aggregate reports are organised by domain, so traffic from each subdomain is easy to identify and reason about.
Blast-radius control. A misconfiguration on a marketing subdomain cannot take down transactional or human email.

A worked layout

A common and robust pattern:

yourdomain.com for human mailbox mail (Google Workspace or Microsoft 365). Keep its SPF lean and let DKIM carry it.
mg.yourdomain.com for marketing and newsletters (Mailchimp, Klaviyo, and similar).
t.yourdomain.com or mail.yourdomain.com for transactional mail (receipts, password resets) via SendGrid, Postmark or SES.
support.yourdomain.com for the helpdesk if it sends a high volume.

Each subdomain gets its own SPF record (one vendor, well under ten lookups), its own DKIM selectors for whatever signs there, and its own DMARC record. Your customers see news@mg.yourdomain.com and receipts@t.yourdomain.com, which is perfectly normal and widely recognised.

Subdomains and DMARC policy inheritance

DMARC policy flows down the tree. A DMARC record on yourdomain.com applies to subdomains that have no record of their own, and you can control subdomain behaviour explicitly with the sp= tag. See the subdomain policy sp tag. The careful pattern during rollout:

Publish a DMARC record on the root with a strict policy and an explicit subdomain policy, for example p=reject; sp=reject.
For any subdomain you are still onboarding, publish its own DMARC record at p=none first, so you collect reports without quarantining anything while you confirm SPF and DKIM are aligned there.
Once that subdomain's reports show consistent alignment, raise its policy to match the root.

A subtle protection point: if you publish p=reject on the root but leave sp unset, the root policy still covers subdomains, but a forgotten subdomain that someone starts sending from will jump straight to rejection. Setting sp explicitly means you decide that behaviour on purpose rather than discovering it through bounced mail. For the recommended sequencing across the whole estate, see how long to reach p=reject.

Tying it together with DMARC: alignment across every sender

Now the payoff. With per-vendor DKIM in place and senders split across subdomains, DMARC alignment becomes achievable for every stream rather than a constant fight.

Relaxed versus strict alignment

DMARC offers two alignment modes, set with aspf and adkim:

Relaxed (the default): the authenticated domain only needs to share the organisational domain. So DKIM signed by mg.yourdomain.com aligns with a From address at yourdomain.com. This is what makes the subdomain strategy work cleanly.
Strict: the domains must match exactly.

For multi-sender, multi-subdomain setups, relaxed alignment is almost always the right choice, because it lets a subdomain's signature align with the parent while still keeping reporting and reputation separated. Only move to strict if you have a specific reason and have confirmed every sender can meet it.

The reports are how you actually know

You cannot eyeball whether twelve senders are all aligned. You read the aggregate (RUA) reports, which list, per source IP and per sending domain, how much mail passed SPF, passed DKIM, and aligned for DMARC. This is the single most useful artefact when authenticating many senders, because it shows you the vendor you forgot about, the new platform marketing signed up for without telling IT, and the spoofers using your domain.

When you read these reports during a multi-sender rollout, you are looking for:

A known sender passing DKIM but not aligned: it is signing with the vendor's domain, not yours. Fix its DKIM to sign as your domain.
A known sender failing both: it has not been authenticated at all yet. Add its SPF include and DKIM selector.
An unknown source sending volume: either a forgotten internal tool, or an actual spoofer. Either way you have just found it.

Walk through a real report in read a DMARC aggregate report, or paste one straight into the DMARC report analyzer. You can confirm the policy itself is valid with the DMARC checker, and once you are at enforcement, check DMARC is working shows how to verify nothing legitimate is being caught.

Do not forget forwarding and lists

Two cases will show up in your reports as failures even when your setup is correct:

Forwarding breaks SPF, because the forwarding server's IP is not in your record. DKIM usually survives forwarding as long as the message body is not altered, which is yet another reason per-vendor DKIM matters. Background in why forwarding breaks authentication.
Mailing lists often rewrite the subject or add a footer, which breaks DKIM, and they may rewrite the From. ARC exists to preserve the original authentication across these hops. See mailing lists, DMARC and ARC.

Knowing these failure modes in advance stops you from chasing phantom problems. A small percentage of forwarded and list mail failing is expected and is not a reason to hold back enforcement.

A practical onboarding checklist for a new sender

Whenever you add another service to your domain, run the same short routine. It scales to as many senders as you like.

Decide where it sends from. Root domain for human mail, a dedicated subdomain for bulk or transactional. Default to a subdomain for anything high-volume.
Add DKIM as your domain. Generate the key in the vendor's console, choose authenticated or branded signing so d= is your domain or subdomain, and publish the _domainkey record. Verify with the DKIM checker.
Add the SPF include only if the vendor needs envelope authorisation, and only to the right domain's record. Re-check your total lookup count with the SPF checker. If you are near ten, flatten rather than appending another include.
Confirm DMARC alignment in reports before you trust it. Let a few days of mail flow and read the RUA data for that source.
Document the sender. Keep a list of every active sender, its subdomain, its DKIM selector and its SPF footprint, so offboarding is clean and audits are quick.

When you remove a sender, reverse the list: drop its SPF include, remove its DKIM selector, and confirm the lookup count and void-lookup count both stay healthy.

Common mistakes that break multi-sender setups

Two SPF records. Adding a second v=spf1 TXT record instead of merging. Instant permerror.
Silently exceeding ten lookups. Often triggered by a vendor changing their own includes, with nothing changing on your side. Monitor it; do not assume it stays fixed.
Relying on SPF for alignment. Hosted senders set their own Return-Path, so SPF rarely aligns. DKIM is what carries DMARC.
Vendor-domain DKIM. Signing with d=vendor.com passes raw DKIM but never aligns to your domain.
Stale records. Dead includes cause void-lookup failures; dead selectors are loose ends. Prune on offboarding.
Jumping to p=reject before reports are clean. Authenticate every active sender first, confirm alignment in the reports, then enforce.

How DMARC Engine handles all of this for you

Everything above is doable by hand, but it is recurring work that fails quietly the moment a vendor changes their footprint. DMARC Engine is built to remove that ongoing burden across many senders:

It maintains one valid SPF record per domain, automatically flattened and kept under the lookup limit as your vendors change their ranges, so you never get a surprise permerror. See automatic SPF flattening explained.
It hosts per-vendor DKIM keys so every sender signs as your domain and aligns for DMARC, with rotation handled for you. The product detail is at the DKIM product page.
It ingests your DMARC aggregate reports, identifies every sender, flags the ones that are not aligned, and emails you when something changes, so a new unauthenticated sender does not go unnoticed. See the analytics product.
It takes the domain safely from p=none to p=reject without an email outage, which is the whole point of doing this carefully when many services are in play.

If you run more than one domain across all of this, managing multiple domains explains how the same approach scales across an estate, and if you want to keep your existing mailbox provider untouched, keep my provider covers that. To see which sending platforms are recognised out of the box, check which providers are supported.

Where to go next

Audit your current SPF lookup count with the SPF checker and your policy with the DMARC checker.
Confirm a specific vendor's DKIM with the DKIM checker, and your brand logo setup with the BIMI checker.
Paste a real report into the DMARC report analyzer to see exactly which senders are aligned today.
Read the requirements if you are working towards a specific mailbox-provider mandate, and the glossary for any term above.

Authenticating mail from many senders is not hard once you accept the underlying rules: one SPF record under ten lookups, DKIM signed as your own domain for every vendor, subdomains to keep budgets and reputation separated, and relaxed DMARC alignment to tie it together, verified continuously through the reports. Get those four things right and adding the eleventh sender is no harder than adding the second.