FREE

Email Authentication

SPF proves the path. DKIM signs the message. DMARC decides what happens when neither matches the name on the envelope. This playbook takes a domain from unauthenticated to enforced without bouncing a single legitimate campaign.

Facts checked August 2026

Email authentication is no longer a one-time IT setup. It is part of running the channel.

Google treats a primary domain as a bulk sender when it sends close to 5,000 messages or more to personal Gmail accounts within 24 hours, and that classification does not expire. Those senders must use SPF, DKIM, and DMARC; direct mail must align the visible From domain with either SPF or DKIM. Yahoo applies the same core authentication controls, but it does not publish a numeric threshold. Noncompliant mail can be spam-foldered, temporarily deferred, or permanently rejected. Authentication is now a delivery requirement, not a checkbox.

The rollout mechanics changed in May 2026. RFC 9989 moved DMARC onto the Standards Track and replaced RFCs 7489 and 9091; RFCs 9990 and 9991 now define reporting. The pct tag is historic and is no longer a rollout control. t=y is narrower: it asks supporting receivers to handle failures one policy level below the published policy while reporting continues. It is not a percentage rollout or a universal safety switch. Receivers that do not support the new tag can ignore it and apply the published policy. The np tag lets you set a separate policy for non-existent subdomains. If a guide still stages enforcement with pct, it is teaching a retired mechanism.

SPF authorizes hosts to use the envelope-sender domain. Forwarding often breaks it because the receiver sees the forwarder’s IP, unless the forwarder rewrites the envelope sender or applies another mitigation. DKIM signs selected headers and a body hash. It can survive forwarding when intermediaries leave the signed content intact. DMARC passes when at least one passing SPF or DKIM identity aligns with the domain in the visible From header. Its policy states your preferred treatment for failures. The receiver still has the last word.

If an Authentication-Results header reads spf=pass, dkim=pass, and dmarc=fail, the passing identities did not align with the domain your customer saw. Lowering p= changes the requested handling; it does not repair alignment. Configure an aligned custom MAIL FROM/Return-Path domain, an aligned DKIM signing domain, or both. I prefer both when the platform supports them.

Authentication needs one accountable program owner. In my programs, marketing owns the requirements and ongoing audit; engineering owns DNS implementation and technical sign-off. That split is deliberate. The visible From domain is a marketing asset. DNS is an engineering surface. When authentication fails, engineering sees the error; marketing absorbs the delivery and performance impact. Name the person responsible for the sender inventory, report review, gap closure, and policy recommendation. Without that owner, the bounce spike becomes the audit.

Separate promotional and transactional mail so one stream does not create avoidable risk for the other. Subdomains are a sound default for most programs. At enterprise volume, I use root-domain sending with marketing and transactional mail on separate IP pools; the pools do not intermingle. That isolates IP reputation, not every domain-level signal. The objective is blast-radius reduction, not perfect separation: a promotional problem should not take password-reset delivery down with it.

For the IP decision, 100,000 sends per day is my operating threshold, not a provider rule. Above that level, stable volume can support dedicated IPs and give you direct control of IP reputation. Below it, a well-managed shared pool is often the lower-risk choice because a dedicated IP may not receive enough steady volume to build and maintain reputation.

Run the four steps below. You will produce two artifacts:

An audit readout that identifies what is broken, where it breaks, and who owns the correction.
A staged enforcement plan that moves each sending domain to the strongest appropriate policy using report evidence at every gate.

SIGNALS IT IS WORKING

Representative direct sends from every production stream show dmarc=pass with the expected aligned domain.

Aggregate reports show no previously unknown legitimate sender across several reporting cycles, and every known sender has an owner.

Domains selected for enforcement have reached their target policy with no measurable increase in legitimate-mail failures attributable to that policy.

REPLACES

The annual authentication panic that starts when a mailbox provider tightens requirements and ends when the bounces stop.

0 of 4 steps complete

STEP 01Inventory every sender, then audit the records

List every platform that sends as your domain. The ESP is the obvious one; the surveys tool, the support desk, the billing system, and the meeting scheduler are the ones that break enforcement later. Then pull the records and read real mail. Check SPF against its hard limit of 10 DNS lookups, because the eleventh returns a permanent error and fails everything. Check DKIM key lengths: 1024-bit minimum, 2048 recommended. Read the Authentication-Results header on a live message from every stream, because the header is the receiver's verdict, not your intention. On dedicated IPs, verify forward-confirmed reverse DNS in both directions; the reverse record usually lives with your provider, the forward record lives in your zone, and a DNS cleanup that deletes the forward half will bounce your next campaign at scale. Output: a sender map and a failure list.

STEP 02Fix alignment before you touch policy

Enforcement punishes whatever is still broken, so repair comes first. Give every third-party sender a custom Return-Path on your domain so SPF aligns. Delegate DKIM by CNAME with a unique selector per platform so keys rotate without tickets and one vendor's compromise never signs another's mail. Prune the SPF record until it fits the lookup limit; retire vendors you no longer use rather than flattening around them. Keep alignment relaxed. Strict alignment reads as rigor and behaves as an outage, because it breaks the standard subdomain architecture every legitimate platform uses.

STEP 03Publish p=none and actually read the reports

Monitoring mode is not a parking spot; it is the evidence-gathering phase. Publish DMARC at p=none with aggregate reports (rua) flowing to an address you monitor, and authorize the destination if it lives on another domain, or the reports simply never arrive. Then read them. Every source that sends legitimate mail should be identified and passing before you advance. The reports are also where shadow senders surface: the tool a team connected two years ago that still sends as your domain. Finding it in a report costs nothing. Finding it in a bounce spike costs a campaign.

STEP 04Enforce in stages, gated on evidence

Advance none to quarantine to reject on what the reports prove, not on what the calendar says. The gates: every known sender passing with alignment for consecutive weeks, no new legitimate source surfacing in the last two, and remaining failures attributable to spoofing or forwarding rather than to anything you own. Under RFC 9989, test the next stage with t=y before you commit to it, and close the non-existent-subdomain gap with np=reject while your live subdomains keep their own posture. Dwell times scale with volume and history; the table below is convention, not compliance. Assign the owner, define the rollback trigger, and write both down. Enforcement you cannot roll back in one DNS change is enforcement you do not control.

| Program profile | At p=none | At p=quarantine |
| --- | --- | --- |
| New domain, or no consistent sending history | 6 to 8 weeks, because thin report volume accrues evidence slowly | 4 to 6 weeks |
| Established domain, moderate volume | About 4 weeks | About 4 weeks |
| Established domain, high volume, multiple streams | 2 to 4 weeks, because dense reports build evidence fast | 4 to 8 weeks, because the blast radius of a mistake is larger |