Email authentication, taken all the way to enforcement.

Why is one record never enough?

The most common authentication mistake is believing that a single passing check is the finish line. SPF on its own proves a server was allowed to send, but says nothing about whether the message was altered or whether the visible sender is real. DKIM on its own proves the message is intact and signed, but a spoofer can sign with their own domain and still pass DKIM. DMARC is what binds the two to the address your recipient reads, and it only passes when SPF or DKIM validates on a domain aligned with that From header.

Alignment is where setups that look complete come apart. A message can sail through SPF on the ESP’s domain and through DKIM on a signing subdomain, and still fail DMARC because neither matches the From address the recipient sees. The records are all green; the policy still fails. Reading that gap correctly is most of the skill, and it is invisible to anyone checking the three records in isolation.

What does the receiving server actually check?

It helps to picture the moment a message arrives, because authentication is judged in a fraction of a second and the verdict is unforgiving. The receiver reads your SPF record against the connecting IP, verifies the DKIM signature against the public key in your DNS, and then asks the question that matters most: does either result align with the domain in the From header? If alignment holds, DMARC passes and the message is judged on reputation and engagement from there. If it fails, your published DMARC policy decides what happens next.

When that policy and the providers’ own floor refuse the message, the bounce is specific. Gmail returns 550 5.7.26 for unauthenticated bulk mail; Yahoo answers with 550 5.7.9; Microsoft, since its own enforcement, with 550 5.7.515. None of these lands in spam to be reviewed later — the message is refused at the door and returned to your server. Reading those codes in your logs is often the first hard evidence that authentication, rather than content, is the thing breaking your mail.

The traps that keep senders from passing

A handful of specific faults account for most authentication failures we are called in to fix. None is exotic; all are easy to ship and hard to notice.

1. The ten-lookup limit. SPF stops evaluating after ten DNS lookups and returns an error. Every third-party include spends part of that budget, so senders with many services blow through it. Flattening the record into raw IPs is brittle and breaks when a provider rotates its IPs; a managed include that updates itself is the durable answer.
2. Short DKIM keys. A 1024-bit key configured years ago validates but sits below what providers now expect; Yahoo treats 1024 as the floor. Rotating to 2048 is simple, and a frequent place to break signing if the selector and the stream are not updated together.
3. Selector drift. A DKIM selector left pointing at a key removed during a DNS cleanup means a whole stream leaves unsigned without anyone noticing until DMARC reports show it.
4. Two SPF records. Only one SPF TXT record is valid per domain. A second one, often added by a well-meaning hand, voids both.
5. From misalignment. Authentication passing on a domain other than the visible From is the single most common reason a fully-recorded domain still fails DMARC.
6. Unscoped subdomains. No subdomain policy means subdomains inherit no protection and become the easy door for a spoofer.
7. Third-party sender sprawl. Every tool that sends as you — CRM, helpdesk, billing, marketing — needs its own signing and inclusion. The ones nobody remembers are exactly what break the move to enforcement.

# SPF: is it inside the 10-lookup limit?
$ dig +short TXT example.com | grep spf1
"v=spf1 include:_spf.google.com include:sendgrid.net include:mktomail.com ~all"
# 11 lookups across the includes — over the limit, SPF returns permerror

# DKIM: is the selector live, and the key 2048-bit?
$ dig +short TXT sel1._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkq..."   # 2048-bit, resolves

# DMARC: is it enforcing, or parked at p=none?
$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=none; rua=mailto:[email protected]"
# p=none: monitoring only — a spoofer still passes as your domain

How does DMARC move from monitoring to enforcement?

DMARC has three policy levels, and the entire value of the standard sits in moving through them deliberately. At p=none the receiver monitors and reports but takes no action; this is the starting point, useful only for the report data it produces. At p=quarantine failing mail is sent to spam. At p=reject it is bounced outright, which is the only level that actually stops someone spoofing your domain.

Most domains never leave p=none. The reasons are always the same: nobody is reading the aggregate reports, the full list of legitimate senders was never established, and the team is — reasonably — afraid that tightening the policy will bounce real mail. The way through is methodical rather than brave. The monitoring phase exists to turn the report data into a complete inventory of every source that legitimately sends as your domain. Each is aligned. Only then does the policy tighten, often staged with a percentage tag so a fraction of mail is enforced first and watched before the rest follows. Approached this way, reaching p=reject costs you no legitimate mail and shuts the door on impersonation. The fear is real; the loss is avoidable.

Reading the aggregate reports

The monitoring phase produces a stream of DMARC aggregate reports — XML files the receivers send daily to the address in your record — and learning to read them is what turns p=none from a holding pattern into progress. Each report groups the mail a receiver saw by sending source, and for each source it shows the volume, whether SPF and DKIM passed, and whether either aligned with your domain. Read across a couple of weeks, they become a map of everything sending as you.

That map is the whole point. It surfaces the marketing platform signing correctly, the billing system that was never aligned, and the unfamiliar source that turns out to be either a forgotten internal tool or someone spoofing you. Tooling makes the XML legible; the judgement — which unknown source is friend and which is foe, and what to fix first — stays human. We work from the reports until every legitimate source is accounted for and aligned, which is the only safe basis for tightening the policy.

The wider stack

Three standards beyond the core round out a serious setup. MTA-STS tells sending servers to require TLS when they deliver to your domain, with TLS-RPT giving you a report when that encryption fails — together they close a downgrade gap most domains leave open. ARC preserves authentication results across intermediaries like mailing lists and forwarders, so legitimate forwarded mail is not punished for a break it did not cause. And BIMI, which places your verified logo beside authenticated mail in supporting clients, depends on reaching DMARC enforcement first — the reason it belongs to its own piece of work rather than this one.

Defensive authentication for the domains you do not send from

Spoofers prefer the domains you forget. A parked domain bought for brand protection, a subdomain that never sends mail, an old domain left over from a past campaign — each is a usable identity for impersonation if it carries no policy. DMARC handles this with a subdomain tag, sp=, that sets a separate policy for everything beneath the organisational domain, and with reject policies published on non-sending domains so anyone trying to send as them is refused outright. It costs nothing to send and closes a door most setups leave open. We map every domain and subdomain you own, not only the ones you actively mail, because the unguarded ones are precisely where impersonation starts.

Four myths that keep domains exposed

A few durable misunderstandings keep otherwise careful teams from real protection. Each sounds reasonable, and each is wrong.

1. “A strict SPF record stops spoofing.” SPF only governs the envelope path; a spoofer can pass SPF on their own domain while forging your From address. Closing that gap is DMARC alignment’s job, not SPF’s.
2. “DKIM alone proves the sender.” DKIM proves a message was signed and left your domain intact; it says nothing on its own about whether the visible sender is real. A valid signature on the wrong domain still fails DMARC.
3. “Publishing DMARC protects us.” At p=none it reports and does nothing else. Protection begins at quarantine and reject.
4. “Authentication is a one-time setup.” Every new sending tool, DNS edit and key rotation can break it, which is why it needs watching rather than a single afternoon’s work.

What changes at high volume and across brands?

The mechanics are the same at any scale, but the cost of getting them wrong rises sharply with volume and with the number of brands under one roof. A high-volume sender past the per-provider bulk threshold has no soft landing: a misaligned stream bounces at the door rather than losing a little placement. A portfolio of brands multiplies the surface — each domain its own SPF budget, its own DKIM keys, its own DMARC policy and report stream — and a shortcut taken on one brand tends to surface as a problem on another. We treat each brand’s authentication as its own estate, with the isolation that keeps one brand’s misconfiguration from spending another brand’s reputation, and we keep the whole set documented so a change to one is never an accidental change to all.

Where do the tools stop, and where do we start?

The authentication market is full of capable platforms, and they earn their place. PowerDMARC, Valimail — now part of DigiCert — dmarcian, EasyDMARC and Red Sift’s OnDMARC all aggregate the DMARC reports into something readable, host records so you make fewer DNS edits, and automate the SPF include so it stays inside the lookup limit. If you run many domains, that automation is worth paying for, and we are glad to operate inside whichever one you already use.

What a dashboard cannot do is the judgement that gets a real domain to enforcement. The reports show you that mail is failing; they do not go and fix the misconfigured source, decide which unfamiliar sender is a forgotten legitimate tool versus an impersonator, or carry the responsibility for the moment the policy tightens. That work is hands-on, and it leans on the same infrastructure knowledge we use to run PowerMTA and KumoMTA — because aligning a sending stream is an operations problem before it is a DNS one. We bring it tool-agnostic and independent: we resell none of these platforms, so the advice is about your authentication rather than a subscription. Published pricing gives a sense of the market — automation tools start around 19 US dollars a month for basic alignment, while enforcement tiers are commonly quoted privately from roughly 2,000 a year — and we scope our work to the estate rather than a seat count.

How we run it

The method is the same whether you arrive with a tangle of half-configured records or a clean slate.

1. Inventory the senders. Every service that sends as your domain is identified, from the report data and from a walk through your stack, until the list is genuinely complete.
2. Fix the sources. SPF brought inside the lookup limit, DKIM rotated to 2048 with selectors and streams checked together, alignment corrected on each path.
3. Monitor and read. Aggregate reports are read until the picture is stable and no legitimate source is still failing.
4. Tighten in stages. The policy moves from none to quarantine to reject, staged where useful, each step watched before the next.
5. Hand back a documented setup. Records, selectors and the sender inventory are written down, so the next DNS change does not quietly undo the work.

Authentication done to this standard pays off twice. It clears the bar the providers now enforce, so your mail stops bouncing on a technicality and competes for the inbox on its merits. And it takes your domain off the table for impersonation, which protects the recipients who would otherwise receive a convincing forgery in your name. The second payoff is the one your customers feel even on a day your own mail was never the problem.

The free 25-point audit is the place to start: it shows where your authentication stands today and how far it is from enforcement. From there the work is scoped to how many senders you have and how clean they are — and if your setup is already at reject and simply needs watching, we will tell you that rather than invent a project.