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.

Most teams treat email authentication as an IT checkbox that got ticked in 2015. The mailbox providers ended that arrangement. Send more than 5,000 messages a day to Gmail and you are required to run SPF, DKIM, and a DMARC policy, with your visible From domain aligned to one of them. Yahoo mirrors the requirement. Unauthenticated bulk mail no longer gets filtered. It gets refused at the door.

The ground also just moved. In May 2026, DMARC became a standards-track protocol: RFC 9989 obsoleted the 2015 informational spec most guides still teach. The pct= tag that generations of rollout advice leaned on is now historic, and receivers are told to ignore it. In its place: a t=y testing mode that applies your policy one level down while reporting as if it were fully enforced, and an np= tag that closes the spoofing gap on subdomains that do not exist. If your authentication guide predates this year, it is teaching a retired mechanism. This playbook is written for the protocol as it stands.

The mechanics compress to one paragraph. SPF authorizes the servers allowed to send for your domain, and it breaks the moment mail gets forwarded. DKIM signs the message itself and survives transit. DMARC ties either one to the From address your customer actually sees, through a rule called alignment, and then tells receivers what to do when the tie fails. Alignment is where real programs break. An Authentication-Results header reading spf=pass, dkim=pass, dmarc=fail means your platform authenticated itself, not you. The fix is never a looser policy. It is a custom Return-Path and your own DKIM signing domain, so the mail your vendors send belongs to your name instead of theirs.

Here is the part nobody assigns: who owns this. In my programs, marketing drives the authentication guidance and engineering implements and signs off. That split is deliberate. The From domain is a marketing asset. DNS is an engineering surface. And when authentication fails, the damage lands on marketing's numbers, not on a server dashboard. Authentication without a single accountable owner is the version nobody audits until a campaign bounces.

On architecture, the published convention says separate your streams on subdomains, and for most programs that is the right default. At enterprise volume I run it differently: root-domain sending, with marketing on marketing IPs and transactional on transactional IPs, never intermingled. The principle is the same either way, and it is the one that matters: your streams never share a reputation surface. A promotional stumble must not be able to touch a password reset. On the IP question, the line I use is 100,000 sends a day. Above it, dedicated IPs buy you control of your own reputation. Below it, a good shared pool lends you a reputation you have not earned yet, and you should accept the loan.

Run the four steps below and you end up with two artifacts: an audit readout that says exactly what is broken and where, and a staged enforcement plan that gets you to p=reject on evidence instead of hope.

SIGNALS IT IS WORKING

Every stream's Authentication-Results reads dmarc=pass with alignment.

The aggregate reports have gone weeks without surfacing an unknown legitimate sender.

The policy sits at p=reject and no legitimate mail was lost getting there.

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 |