SPF, DKIM, and DMARC: Why Your Email Stopped Getting Delivered

Email authentication isn't a marketing setting, a spam filter, or something your web host handled for you. It's three records in your DNS that decide whether the rest of the internet believes mail claiming to be from your domain.

SPF, DKIM, and DMARC are the three published standards that let a receiving mail server answer one question: did this message really come from the domain in the From line? Without them, the answer is a guess, and since 2024 the largest mailbox providers have stopped guessing in your favor.

That shift is why businesses that changed nothing about their email suddenly found their invoices in junk folders.

What do the three records actually do?

They solve three different pieces of the same problem, and they were designed to work together rather than separately. CISA puts it plainly in its own countermeasure guidance: "These protocols are not intended to work in isolation and should be implemented together" (CISA CM0055).

SPF (Sender Policy Framework) publishes a list of the mail servers allowed to send email for your domain. A receiver checks the sending server's IP address against that list. It's the guest list at the door. SPF is defined in RFC 7208.

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to outgoing messages, which the receiver verifies against a public key in your DNS. It proves the message wasn't altered in transit and that whoever sent it held your private key. It's the tamper-evident seal on the envelope. DKIM is RFC 6376, and it carries the strongest status of the three - it's a full Internet Standard, STD 76.

DMARC ties the other two to the domain a human actually sees in the From line, and tells receivers what you'd like done with mail that fails. This is the piece most businesses are missing, and it's the piece the mailbox providers started requiring.

Has DMARC changed recently?

Yes, and this is worth knowing because most published guidance hasn't caught up.

For eleven years, DMARC was RFC 7489 - an Informational document from the Independent Submission stream, not an IETF standard. In May 2026 that changed. DMARC was published as a Standards Track specification in three documents: RFC 9989 for the core protocol, RFC 9990 for aggregate reporting, and RFC 9991 for failure reporting. RFC 7489 is now formally obsolete.

The revision also sharpened something that almost everyone states incorrectly. The three DMARC policy values are not commands to the receiver. RFC 9989 defines the policy tag as indicating "the message handling preference of the Domain Owner," and describes the values as assessments:

1. `p=none` - "The Domain Owner offers no expression of preference." You get reports and nothing else changes.
2. `p=quarantine` - "The Domain Owner considers such mail to be suspicious. It is possible the mail is valid, although the failure creates a significant concern."
3. `p=reject` - "The Domain Owner considers all such failures to be a clear indication that the use of the domain name is not valid."

So `p=reject` doesn't order anyone to bounce a message. It states that you regard the failure as clear evidence of misuse. The receiver decides what to do with that. In practice the large providers act on it, which is why it works - but the distinction matters when you're troubleshooting why a legitimate message still got through, or why a spoofed one did.

CISA's published path is the staged one: get SPF and DKIM working first, publish DMARC at `none`, read the reports, then move to `quarantine` and eventually `reject` as you gain confidence (CISA, DMARC). NIST recommends all three in SP 800-177 Revision 1, *Trustworthy Email*, which is still the current federal guidance on the subject.

What do the mailbox providers actually require now?

This is the part that changed the stakes, and the requirements differ by provider in ways that matter.

Google. Every sender to Gmail needs SPF or DKIM, valid forward and reverse DNS on the sending host, a TLS connection, and a spam rate under 0.3 percent in Postmaster Tools. Senders of roughly 5,000 or more messages a day to personal Gmail accounts additionally need a DMARC record, From-header alignment with either SPF or DKIM, and one-click unsubscribe on marketing mail (Google email sender guidelines).

Two details from Google's own FAQ that most summaries leave out. First, the DMARC policy can be `p=none` - Google's text says "Your DMARC enforcement policy can be set to none." Second, and more consequential: "Starting November 2025, Gmail is ramping up its enforcement on non-compliant traffic. Messages that fail to meet the email sender requirements will experience disruptions, including temporary and permanent rejections" (Google sender guidelines FAQ). That's a move from junk-foldering to bouncing.

Also worth knowing: bulk sender status is permanent. Google's wording is "Bulk sender status doesn't have an expiration date." Cross the threshold once during a campaign and the requirements stay.

Yahoo. All senders need SPF or DKIM. Bulk senders need both, plus a DMARC policy of at least `p=none` that passes, plus working one-click unsubscribe honored within two days (Yahoo sender best practices).

One correction here, because I see it repeated constantly: Yahoo publishes no volume threshold. Its FAQ says so directly - "We will not specify a volume threshold." The 5,000-a-day number belongs to Google and Microsoft. Anyone quoting a "Yahoo 5,000 rule" is repeating a vendor blog, not Yahoo.

Microsoft. Senders of more than 5,000 emails per day to Outlook.com need all three - SPF, DKIM, and DMARC - as of May 5, 2025. Enforcement is phased: non-compliant messages go to the junk folder first, and Outlook.com will subsequently "reject the messages until the DNS records are corrected" (Microsoft postmaster policies).

What happens to a business that doesn't have these?

Two things, and they're different problems that share one fix.

The first is delivery. Your invoices, quotes, appointment reminders, and password resets start landing in junk folders, and after the November 2025 Gmail change, some of them stop landing at all. You usually don't find out from a bounce - you find out from a customer who says they never got it, weeks later, after you've already sent a second one.

The second is impersonation. Without DMARC at an enforcing policy, anyone can send mail that says it's from your domain and a receiving server has no published instruction to distrust it. That's the mechanism behind a large share of invoice fraud: the message appears to come from your billing address, it asks a customer to update payment details, and your domain lends it credibility you never authorized.

Business email compromise is the category that fraud falls into, and it's the expensive one. The FBI's 2025 Internet Crime Report recorded 24,768 BEC complaints accounting for $3.05 billion in reported losses, out of $20.88 billion in total reported losses across all crime types. Email authentication doesn't stop BEC on its own. It removes the easiest version of it.