SPF, DKIM, and DMARC Setup: An Email Authentication Playbook for Mid-Market Owners and Operators

SPF, DKIM, and DMARC Setup: An Email Authentication Playbook for Mid-Market Owners and Operators

2026-10-18

The takeaway: Unless you tell the world’s mail servers how to check, anyone can send email that claims to come from your domain. Three DNS records do the telling: SPF, DKIM, and DMARC. Set up the first two for every service that sends mail as you, publish DMARC in monitoring mode, read the reports for at least a month, then tighten the policy in stages. Jump straight to “reject” without reading reports, and the first email you block may be your own invoice.

The three records, in plain words

  • SPF (Sender Policy Framework): a public list, in your DNS, of the servers allowed to send mail for your domain.
  • DKIM (DomainKeys Identified Mail): a digital signature on each message that receivers check against a public key in your DNS.
  • DMARC (Domain-based Message Authentication, Reporting, and Conformance): a DNS record that says what receivers should do when a message fails, and where to send reports. A message passes only if SPF or DKIM passes and that domain matches (“aligns with”) the domain in the visible From: address (RFC 9989).

NIST’s Trustworthy Email guide recommends all three and says it “will also be useful for small or medium sized organizations” (NIST SP 800-177 Rev. 1, February 2019).

Why owners and operators should care

Fraud. Business email compromise (BEC), where fraudsters compromise email accounts or other communications to steer payments, drew 24,768 complaints and about $3.05 billion in reported losses to the FBI’s Internet Crime Complaint Center in 2025 (FBI IC3 2025 report). Those are complaints filed with IC3, not every incident.

Be clear about the limits. DMARC fights exact-domain spoofing only; the standard says it doesn’t address look-alike domains or fake display names (RFC 9989, sec. 2.2). It also does nothing if a criminal logs into a real mailbox. That’s a job for MFA.

Deliverability. Since February 1, 2024, Gmail has required all senders to use SPF or DKIM. Bulk senders, roughly 5,000 or more messages a day to personal Gmail accounts, need SPF, DKIM, a DMARC record (p=none is acceptable), and alignment (Google). Starting November 2025, Gmail began ramping up enforcement, including temporary and permanent rejections (Google FAQ). Yahoo has similar bulk-sender rules (Yahoo Sender Hub), and Outlook.com rejects noncompliant high-volume mail with error 550 5.7.515 (Microsoft Support).

Step 1: List everyone who sends as you

Your email platform, marketing tool, CRM, billing system, help desk, payroll notifications, website forms, and the copier that emails scans. RFC 9989 notes that in all but the simplest setups, owners overlook a server or a third-party sender. Finding them is what monitoring mode is for.

Step 2: Clean up SPF and respect the 10-lookup limit

Publish one SPF record that covers your senders. SPF allows at most 10 terms that trigger DNS lookups, such as “include”; go over and SPF returns an error (RFC 7208, sec. 4.6.4). Every SaaS tool that says “just add our include” spends one of the 10. RFC 9989 also warns that a hard-fail “-all” can get mail rejected before DMARC is ever checked.

Step 3: Turn on DKIM everywhere

Enable DKIM signing with your domain in every sending service. Google requires keys of at least 1024 bits for personal Gmail accounts and recommends 2048. DKIM carries the most weight: forwarding usually breaks SPF but leaves DKIM intact, so RFC 9989 says any domain publishing p=reject MUST sign with DKIM, not rely on SPF alone.

Step 4: Publish DMARC at p=none and read the reports

Start in monitoring mode with a record like v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. The “rua” address collects aggregate reports from receivers showing who sent as your domain and whether it passed. The reports are XML, so use a parsing tool or service. Fix every legitimate sender that fails. RFC 9989 says getting confident can take many months, depending on how often you send.

Step 5: Tighten in stages

Move to p=quarantine (failures go to spam), then consider p=reject (receivers refuse them). RFC 9989 adds a test flag, t=y, that asks receivers to apply one level below your stated policy while you test. It takes over part of what the old pct= tag did.

Where the guidance differs. CISA’s Binding Operational Directive 18-01 (October 16, 2017) required federal agencies to reach p=reject within a year, calling reject “the strongest protection against spoofed email” (CISA BOD 18-01). RFC 9989, published May 2026, is more cautious: domains whose users might post to mailing lists SHOULD NOT publish p=reject, and any that do should run p=none for at least a month, then p=quarantine for as long, and warn users that mailing-list participation may be hindered.

A practical middle path:

  • Domains that never send mail (parked or defensive ones): head to p=reject after a p=none check of the reports, the sequence CISA set out for agencies.
  • Your main domain: quarantine is a solid stop. Go to reject only when reports are clean, DKIM covers every sender, and you’ve weighed the mailing-list tradeoff.

Step 6: Keep it from rotting

Name an owner. Review reports monthly. Add “Does this send email as us?” to every new software purchase, and recheck everything when you change email platforms.

Where outside help fits

The records are small; the sender inventory and report reading are where projects stall. Email authentication often surfaces on the control gap list an insurer or big customer hands you, which is part of Yellow Coop’s Secure work (what we do), in fractional engagements of 1 to 4 days a week (how we engage). If you don’t know what your DMARC record says today, book a 20-minute call.

Internal links: What We Do, How We Engage, CIO vs CTO vs CISO, Track Record, Contact, Insights.

Sources