Part 2 of a five-part email deliverability playbook.

Here’s the thing nobody tells you when you add a DMARC policy: it doesn’t grade your domain. It grades every individual message, from every individual service, separately.

Your corporate mail goes through Microsoft 365. Marketing sends from HubSpot. The product sends receipts through SendGrid. Support runs on Zendesk. Someone in sales connected a sequencing tool you’ve never heard of. Each of those services has to pass DMARC on its own. And when you tighten your policy, the ones that don’t start failing quietly, one service at a time.

The usual casualty is the one nobody remembers owning.

What “alignment” actually means

DMARC doesn’t just ask “did this message pass SPF or DKIM?” It asks whether the thing that passed matches the domain in the From line. That’s alignment, and it’s where multi-sender setups quietly fall apart. Two flavors:

SPF alignment. The message passed SPF, but for which domain? Lots of ESPs send with their own bounce domain behind the scenes, so SPF passes for bounces.vendor.com, not for you. From DMARC’s perspective, that pass is worthless. Your From says yourdomain.com, the SPF pass says vendor.com. Not aligned.

DKIM alignment. Same idea. A message can carry a perfectly valid DKIM signature: the vendor’s. If it’s signed with d=vendor.com instead of d=yourdomain.com, it “has DKIM” and still fails your DMARC. This is the single most common multi-sender gotcha, because everything looks configured.

The practical consequence: for most third-party senders, custom DKIM is the thing that saves you. When you complete a vendor’s “domain authentication” setup (the step where they have you add CNAME or TXT records), you’re enabling them to sign as your domain. That signature aligns. Skip that step and you’re riding on the vendor’s reputation and failing your own DMARC.

The inventory

Before you tighten anything, make the list. For every service that sends as your domain:

  1. Does it appear in your SPF record? One include: per service that needs it. And mind the 10-DNS-lookup limit, which multi-sender SPF records blow past embarrassingly often.
  2. Is custom DKIM set up, signing as your domain, not theirs? Check the vendor’s domain-authentication settings. If you never added their DNS records, the answer is no.
  3. Does at least one of those two align? DMARC needs one aligned pass, not both. For services behind a relay or gateway (where SPF alignment is structurally hopeless), DKIM is your only lever. Make it count.

The honest version of step zero: you don’t know what’s on the list. That’s what DMARC aggregate reports are for. Run p=none with a rua= address for a few weeks and let receivers tell you who’s actually sending as you. The report entries you can’t identify are the whole reason this exercise exists.

Special case: the security gateway

If your mail routes through Proofpoint, Mimecast, or similar, your SPF record may authorize the gateway, and your actual senders hide behind it. That’s fine (expected, even), but it makes DKIM alignment per-sender even more important, because SPF tells receivers less about who originated the message.

When to actually tighten

Once every service on the list has an aligned pass, follow the standard ramp: quarantine at a low pct, watch reports, ramp to 100, then reject. (I wrote up that sequence separately: the p=none to enforcement playbook.)

The multi-sender version of that journey mostly comes down to discipline. One spreadsheet row per sender, three columns (SPF, DKIM, aligned), and nobody tightens anything until the third column is all yes.

It’s not hard. It’s just tedious, political (someone owns each of those tools, and it’s never the person reading the DMARC reports), and easy to get 90% right. Which, with enforcement, means 10% of your mail breaks. The spreadsheet is the boring part. It’s also the part that saves you.