Email authentication, from p=none to p=reject without breaking your mail.

/ TL;DR

01 — Why authentication matters now, not eventually

For most of email's history, authentication was a best practice that responsible senders implemented and lazy ones ignored without much consequence. That window closed in 2024. Gmail and Yahoo began enforcing SPF, DKIM, and DMARC requirements for bulk senders in February 2024, Microsoft formally adopted equivalent rules in May 2025, and the soft-enforcement windows that gave operators time to comply have now closed. In 2026, non-compliant bulk mail to the three biggest mailbox providers is rejected at the SMTP level — not delivered to spam, not silently filtered, but bounced outright.

The threshold for "bulk" is lower than most operators assume. Gmail defines it as roughly 5,000 messages per day to Gmail addresses, and transactional and triggered mail counts toward that total. A growing SaaS sending password resets, receipts, and notifications can cross 5,000 daily Gmail messages without noticing — at which point the bulk sender rules apply and unauthenticated mail starts being rejected. It's no longer just a marketing-team concern.

Despite this, adoption remains remarkably low. Industry analyses consistently find that the majority of internet-facing domains either have no DMARC record at all or have one stuck at p=none in perpetual "monitoring" mode that provides no protection. Multiple 2025 surveys put the share of top-10-million domains with no DMARC record above 80%. If your domain is in that group, every email you send is operating under the older, looser rules — which means you're one mailbox provider update from a deliverability emergency.

The good news is that getting authentication right isn't conceptually difficult. The work is mostly identification — finding every system that sends mail on your behalf and making sure each one is properly aligned — and the rollout, done correctly, takes about eight weeks of mostly-waiting between deliberate policy changes. The bad news is that doing it wrong can break your legitimate mail in ways that are surprisingly hard to diagnose, which is why teams sometimes spend years sitting at p=none rather than risk the move to enforcement.

02 — The three protocols, what each one actually does

SPF, DKIM, and DMARC are often discussed together, which obscures the fact that they answer three distinct questions about a piece of mail. Understanding what each one proves — and equally important, what it doesn't — is the foundation for everything else.

SPF — the IP-level allowlist

SPF (Sender Policy Framework) is a DNS TXT record that lists the IP addresses and hostnames authorized to send mail for a given domain. When a receiving server gets a message, it looks up the SPF record at the domain in the message's Return-Path header and checks whether the sending IP appears in the list. If yes, SPF passes. If no, SPF fails.

A simple SPF record looks like v=spf1 include:_spf.google.com ~all, which means "Google's servers are authorized to send mail for this domain, and anyone else should be soft-failed." The include: mechanism lets you import another domain's SPF record, which is how third-party senders like SendGrid or Mailgun get added.

SPF has two important limitations. First, it checks the Return-Path, not the visible From header — which means a message can pass SPF while having a completely fake From address, because SPF doesn't look at it. Second, SPF breaks on forwarded mail: when someone forwards your message, the forwarding server's IP isn't in your SPF record, so SPF fails. That's why SPF alone isn't enough, and why DKIM exists as the more durable signal.

DKIM — the cryptographic signature

DKIM (DomainKeys Identified Mail) adds a digital signature to every outgoing message, generated using a private key on the sending server and verifiable against a public key published in DNS. The signature covers the message headers and body, so any modification in transit will cause it to fail. Crucially, DKIM survives forwarding — because the signature is attached to the message itself, not derived from the path it travels.

A DKIM-Signature header includes a d= tag that identifies the signing domain. The receiving server fetches the public key from [selector]._domainkey.[d-domain] and uses it to verify the signature. If the signature checks out, DKIM passes. The selector lets you rotate keys without invalidating existing signatures.

Like SPF, DKIM proves something narrow: that this specific message was signed by whoever controls the d= domain, and that the content wasn't altered. It doesn't say anything about the visible From address. A spammer with their own domain can sign messages perfectly correctly with their own DKIM key — the signature will validate, but it doesn't make the message legitimate. That's the gap DMARC fills.

DMARC — the policy and reporting layer

DMARC (Domain-based Message Authentication, Reporting and Conformance) sits on top of SPF and DKIM and answers the question they leave unanswered: is the sender who the visible From header claims to be? It does this by requiring that at least one of SPF or DKIM passes and that the passing protocol's authenticated domain aligns with the From domain.

A DMARC record is published at _dmarc.yourdomain.com as a TXT record. The most important tags are:

• →v=DMARC1 — version identifier, required first.
• →p= — the policy: none (monitor only), quarantine (treat as suspicious), or reject (block).
• →rua=mailto:... — where aggregate reports are sent.
• →ruf=mailto:... — where forensic (per-message failure) reports are sent. Many receivers no longer support this.
• →pct= — percentage of failing mail to which the policy applies (25/50/75/100). The vehicle for gradual rollout.
• →aspf= and adkim= — alignment mode for SPF and DKIM, r (relaxed, default) or s (strict).

A starter DMARC record in monitoring mode looks like: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; pct=100; This publishes nothing destructive — it just starts the flow of aggregate reports from receivers, which tell you which sending sources are passing and which are failing alignment. That data is the foundation for everything that follows.

03 — The alignment trap: where most teams break

The single most common DMARC failure isn't a broken SPF record or a missing DKIM key. It's alignment. A message can pass SPF perfectly and have a valid DKIM signature and still fail DMARC, because the domain that authenticated isn't the same domain shown in the visible From header. Understanding this distinction is the difference between a smooth rollout and weeks of confused diagnostics.

The scenario is almost universal. Your company sends mail from support@yourcompany.com through a third-party tool — let's say SendGrid. SendGrid actually relays the message through mail.sendgrid.net, and unless you've configured otherwise, the Return-Path becomes something like bounces+12345@sendgrid.net. SPF checks sendgrid.net for that IP, finds it, and passes. DKIM gets signed with d=sendgrid.net by SendGrid's default key, and the signature verifies. Both protocols pass.

And yet DMARC fails. Why? Because the authenticated domain in both cases is sendgrid.net, while the visible From header shows yourcompany.com. Those aren't aligned, even under relaxed alignment which only requires matching organizational domains. Sendgrid.net is a completely different organizational domain from yourcompany.com. The receiver sees a perfectly valid authentication for a domain you don't claim to be sending from, and DMARC correctly concludes that something is wrong.

The fix is to align the third-party sender with your domain, which every major email provider supports through some mechanism. For SendGrid, you set up domain authentication with a subdomain like em1234.yourcompany.com, which routes the Return-Path through your own domain and signs DKIM with d=em1234.yourcompany.com. Now both authenticated domains are subdomains of yourcompany.com, alignment passes under the default relaxed mode, and DMARC succeeds.

The relaxed-versus-strict distinction matters here. Under relaxed alignment (the default), authentication passes if the authenticated domain shares an organizational domain with the From domain — em1234.yourcompany.com aligns with yourcompany.com fine. Under strict alignment, they must match exactly. Most teams should stay on relaxed; strict is appropriate only for high-security domains that genuinely never send from subdomains.

Every third-party sender you use needs this alignment configured. CRM tools, marketing platforms, support desks, transactional providers, accounting systems that send invoices, calendar tools, internal notifications — each one is a potential alignment failure if it sends mail from your domain without being aligned to it. The first job of a DMARC rollout is to inventory every system that sends on your behalf and verify each is properly aligned. The DMARC aggregate reports you start collecting at p=none will surface anything you missed.

04 — The 8-week rollout to p=reject

The safe path from no DMARC to full enforcement is roughly eight weeks. It can be done faster if you have a clean, well-understood sending environment, and it sometimes takes longer for organizations with sprawling third-party tooling — but the structure below is the template most teams should follow.

Hold longer at any step if reports show legitimate senders still failing. The schedule is a maximum-aggressive curve; the right curve for your organization may be slower.

A few principles that make the rollout safe

Never skip the monitoring phase. Teams sometimes publish p=quarantine or p=reject immediately because they "know" their auth is correct. They almost always discover a forgotten third-party sender — an old marketing tool, an analytics service, an internal script — only after that sender's legitimate mail starts disappearing. The p=none phase exists to find these surprises while they're free to fix.

Use pct ramping religiously. The pct tag is a feature that exists specifically to let you de-risk the move to enforcement. Going from p=none directly to p=reject at pct=100 means a single misconfigured sender breaks 100% of its mail immediately. Ramping at 25/50/75/100 gives you days at each step to catch problems before they become invisible-to-everyone outages.

Hold at quarantine if you're nervous. p=quarantine sends failing mail to spam, which is recoverable — a user can fish a message out. p=reject bounces it permanently. For organizations where one mistake would be unacceptable (financial services, healthcare, government), staying at p=quarantine indefinitely is a defensible choice. p=reject is stronger but the failure mode is more severe.

Roll back if you have to. Lowering the policy is fast — a DNS change that propagates within minutes. If something goes wrong, drop to p=none, fix the issue, and re-ramp. There's no shame in this; it's what the gradual rollout is designed to make safe. The teams that hurt themselves are the ones who stay at a broken policy out of stubbornness rather than reverting and trying again.

05 — Reading DMARC aggregate reports without losing your mind

DMARC reports arrive as XML files attached to emails sent by major receivers — Google, Microsoft, Yahoo, and a few others — to the address you specified in your rua tag. They look intimidating at first because raw DMARC XML is verbose, but the structure is consistent and the information you need is straightforward once you know what to look for.

Each report covers a 24-hour window and groups messages by sending source. For each source, you get the IP that sent the mail, the volume, the DMARC result (pass or fail), and which authentication mechanism (SPF, DKIM, or both) passed or failed and aligned or didn't. A simplified record looks something like this:

<record>
  <row>
    <source_ip>198.51.100.42</source_ip>
    <count>347</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>yourcompany.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>em1234.yourcompany.com</domain>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>sendgrid.net</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

Read this from the bottom up. The auth_results show what actually happened: DKIM passed for em1234.yourcompany.com, SPF passed for sendgrid.net. The policy_evaluated then tells you what DMARC concluded after alignment: DKIM aligned (em1234.yourcompany.com is a subdomain of the From domain yourcompany.com), SPF didn't (sendgrid.net is a completely different domain). Because at least one passed and aligned, DMARC overall passes. Disposition is "none" because the policy is p=none.

The pattern to watch for is the opposite: records where both DKIM and SPF show fail in policy_evaluated, and the source IP and From domain together identify a sender you can verify is yours. That's a legitimate sender failing alignment, which needs to be fixed before you can safely move to enforcement.

Reading XML by hand for a domain with significant sending volume is impractical. The reports add up to hundreds of records per day across receivers, and parsing them manually is the kind of task that fills weekly time without producing insight. The pragmatic answer is to use a DMARC monitoring tool — there are several free and paid options that ingest the XML and present aggregate dashboards, often with alerting on new failing sources. You don't have to read every record yourself; you have to make sure something is reading them and surfacing the actionable ones.

One ongoing watch-item even after you've reached p=reject: new alignment failures. As your organization adopts new tools, marketing platforms, or vendors, each one is a potential new sending source that may not be aligned by default. A DMARC monitoring tool flags these as they appear, giving you a chance to align them before they reach significant volume. Without that visibility, you may not realize a new system is silently sending mail that gets rejected.

06 — The mistakes that derail rollouts

The DMARC failures we see most often aren't conceptual. They're operational shortcuts that seemed reasonable at the time and turned out to be expensive.

07 — BIMI: the reward on the far side of enforcement

BIMI (Brand Indicators for Message Identification) is the most concrete payoff for getting DMARC to full enforcement. It displays your verified brand logo next to your message in supporting inboxes — Gmail, Yahoo Mail, Apple Mail, and a growing list of others. That's prime real estate at the exact moment a recipient is deciding whether to open, and a recognizable logo signals trust and legitimacy in a way that plain-text mail cannot.

BIMI has two prerequisites. First, your DMARC policy must be at p=quarantine or p=reject — monitoring mode doesn't qualify. The reasoning is straightforward: BIMI is a trust badge, and a domain that hasn't enforced authentication hasn't earned it. Second, for Gmail you need a Verified Mark Certificate (VMC) from an authorized certificate authority, which involves trademark verification and a paid annual certificate. Other receivers may accept BIMI without a VMC, but Gmail's market share makes VMC essentially mandatory in practice.

The technical setup is then a single DNS record. A BIMI record at default._bimi.yourdomain.com points to an SVG of your logo (in a specific Tiny Profile format) and, where required, to your VMC. Receivers that support BIMI fetch both, verify them, and display the logo when displaying mail that passes DMARC for your domain.

For an ecommerce store, a SaaS, or any brand whose mail competes for attention in crowded inboxes, BIMI is a meaningful upgrade. The work to qualify — finishing the DMARC rollout properly — is work you should be doing anyway. BIMI just adds a visible reward at the end of it.

08 — Maintaining authentication over the long term

Authentication isn't a project you finish; it's a posture you maintain. Once you're at p=reject, the rules of the game shift from "fix everything that's broken" to "keep new breakages from sneaking in." That's a quieter discipline but it's the one that determines whether the rollout work stays valuable a year later.

Three ongoing habits matter most. Continue monitoring DMARC reports — automated tooling makes this low-effort, but it has to actually be happening. When a new sender appears in the reports, treat it as an immediate task rather than something to investigate later. Rotate DKIM keys on a regular schedule, ideally annually, with new selectors so old signatures remain valid during the transition. And audit your SPF record periodically; the 10-lookup limit catches teams who've accumulated includes over the years without realizing the count.

The other piece is organizational. As your company adopts new tools, every procurement of a system that sends mail is a chance to either get alignment right at setup or to break it. Building a checklist into procurement — "does this tool support custom domain authentication? Has it been set up before going live?" — prevents the slow accumulation of unaligned senders that eventually breaks something visible. Authentication is partly DNS and partly process.

The encouraging thing about all of this is that the 80%+ of domains without DMARC creates a meaningful competitive position for the ones who get it right. Mailbox providers genuinely reward authenticated senders, BIMI gives you visual differentiation in the inbox, and the protection against domain spoofing has real business value beyond deliverability. Eight weeks of focused work followed by ongoing maintenance puts you in a small minority of senders who treat email infrastructure with the seriousness it deserves.

09 — Questions