Email authentication

SPF DKIM DMARC: the short answer

A campaign can have SPF, DKIM and DMARC records in DNS and still fail authentication. The usual reason is simple: the domains don't line up.

SPF says which systems may send for a domain. DKIM adds a verifiable signature to the message. DMARC checks whether SPF or DKIM passed for a domain aligned with the visible From address, then tells the receiving system what to do if neither does.

That's the useful model. These records do different jobs. A green SPF check doesn't make DKIM valid, and a DKIM pass doesn't guarantee DMARC will pass.

SPF is about the sending path

SPF is a DNS policy for the envelope sender, also called the return-path domain. It lists the systems allowed to send mail for that domain.

The receiving system looks at the sender that connected to it and compares that sender with the SPF record. If the sending system isn't listed, SPF fails.

The mistake I see most often is treating SPF as permission for anything using a particular visible From address. It isn't. SPF checks the envelope sender, not necessarily the address the recipient sees.

Say a 40-person recruiting software company sends from hello@acme-recruiting.com, but its outbound platform uses bounce.mailvendor.com as the return path. The vendor's sending infrastructure might pass SPF for bounce.mailvendor.com. DMARC can still fail if that domain doesn't align with acme-recruiting.com.

That's the part people miss. Authentication and alignment are separate checks.

SPF also breaks when the record describes the setup as it used to be. A company might send ordinary mailbox traffic through Google, campaign traffic through an outbound provider and transactional mail through a third service. If the team adds the first two to SPF and forgets the third, only some messages fail. A test from one mailbox looks fine. A campaign using another path does not.

There's another basic DNS problem: multiple SPF records. A domain should have one SPF policy. Adding a second record instead of editing the first can make the policy invalid. The record also has a lookup limit, so piling on provider includes isn't a harmless way to keep adding senders.

SPF needs to describe the actual route the message takes today. Not the route someone planned during onboarding.

DKIM proves the message was signed

DKIM attaches a cryptographic signature to an email. The signature includes a signing domain and selector. The receiving system retrieves the matching public key from DNS, then checks whether the signature is valid and whether the signed parts of the message changed.

It doesn't prove that the sender is a trustworthy company. It proves that a domain signed the message and that the signed content still matches.

The failure is often boring. Someone changes the selector in the sending platform but doesn't publish the new DNS record. Or the key is published at the wrong hostname. Or a domain gets replaced during a mailbox migration and the old signing setup stays in place.

Here's a common trigger. A 12-person agency moves outbound mail from one provider to another on Friday afternoon. The new provider signs with selector s2, but DNS still contains only s1. Messages leave normally. The campaign editor reports no obvious failure. Recipients see DKIM fail because the public key for s2 can't be found.

DKIM can also pass and still fail the DMARC check. If the message signs as mailer.vendor.com while the visible From address uses agency.com, the signature may be perfectly valid. The domains simply aren't aligned.

That's why checking headers for "DKIM: pass" isn't enough. Look at the signing domain too.

DMARC is where the other checks meet

DMARC checks the visible From domain against the domain authenticated by SPF or DKIM. If either one passes and aligns, DMARC can pass. If both fail, or pass for unrelated domains, DMARC fails.

The domain owner then publishes a policy such as:

• p=none, which asks receiving systems to monitor rather than enforce
• p=quarantine, which suggests treating failures as suspicious
• p=reject, which asks receiving systems to reject failing messages

The policy applies to messages that fail DMARC, not to every message from the domain.

This is where teams get the setup wrong. They collect SPF and DKIM records like paperwork, then assume DMARC is covered. DMARC isn't a third checkmark. It evaluates the relationship between the visible From address and the other authentication results.

A campaign can fail DMARC when SPF passes for the wrong domain, DKIM passes for a non-aligned signing domain, the visible From domain changes, or a legitimate sending service was never added to the authentication setup.

And a stricter policy can expose a problem that was already there. If a domain moves from p=none to p=reject, the policy didn't create the mismatch. It stopped allowing the mismatch to pass quietly.

My opinion: teams turn on p=reject too early because the record looks finished in a DNS checklist. Start with reporting, identify every legitimate sender, fix alignment, then enforce. Otherwise you're using the receiving mailbox as your test environment.

Why campaigns go quiet without an obvious error

The dangerous authentication failures happen after the message leaves the sending system.

The campaign may still be active. Contacts may still be selected. Mailboxes may still log in successfully. The receiving system makes its authentication and policy decision later, and the campaign tool may never see a useful error.

A broken DKIM selector can remove one authentication path. A missing SPF include can affect only one provider. A changed From domain can make both paths fail alignment. A DNS edit made at 10 a.m. can be the reason reply rates drop that afternoon, even though nothing changed in the campaign itself.

Consider a 60-person B2B SaaS company that adds a new outbound domain after its main domain starts getting too much traffic. The team copies the mailbox setup, starts a campaign and forgets to publish the DKIM key for the new domain. The old domain continues to send normally, so the issue is easy to miss. The new campaign is the one that suffers.

Checking DNS once during setup won't catch this. Authentication depends on several moving parts: the DNS zone, the mailbox identity, the message headers and the sending path actually in use.

In Workloom, domains, mailboxes, warmup and deliverability are provisioned and watched together. Buying the domain, writing its DNS zone, provisioning mailboxes and starting warmup happen as one orchestrated setup instead of four separate tickets. DNS is abstracted across two backends and chosen per domain, so live domains can move one at a time without a sending gap.

Every live domain is rechecked every six hours. If mail routing or sender authentication regresses, campaigns pause themselves. That matters because continuing to send while authentication is known to be broken only creates more failed messages to investigate later.

Authentication is one part of sending health

SPF, DKIM and DMARC don't replace reputation management or volume control. They establish whether the receiving system can verify the sender and apply the domain's policy. They don't make an overloaded mailbox healthy or turn an unwanted message into a wanted one.

Workloom acts for each mailbox directly, so nobody on the team has to keep an OAuth consent screen open or discover that a token expired overnight. A per-mailbox rate limiter keeps each account inside its provider's ceiling of 250 operations per second. Warmup intensity runs on a five-step dial from paused to maximum, and warmup mail is tagged when it arrives so it doesn't distort inbox, reply-rate or campaign reporting.

The practical check is straightforward: confirm that SPF authorizes the real sending path, DKIM uses a published key with an aligned domain, and DMARC applies the policy you actually intend. Then keep checking after provider changes, domain changes and mailbox migrations. That's when authentication usually breaks.