SPF, DKIM and DMARC: How Email Authentication Fits Together

SPF, DKIM and DMARC are three DNS-published standards that let a receiving mail server check whether a message really comes from the domain it claims. SPF lists the hosts allowed to send for a domain. DKIM attaches a cryptographic signature verified against a public key in DNS. DMARC ties both results to the visible From address through alignment, and publishes the domain owner's policy for messages that fail.

None of the three is optional any more for anyone sending at volume. Gmail and Yahoo began enforcing sender requirements in February 2024, and Outlook.com followed in May 2025. The standards themselves have also moved. In May 2026 DMARC was republished as RFC 9989, a Standards Track document that obsoletes RFC 7489, the version most references still cite.

What does SPF check?

SPF (Sender Policy Framework) answers one question: is this sending host allowed to use this domain? It is specified in RFC 7208, published in April 2014 as a Proposed Standard. RFC 7208 obsoletes RFC 4408 and has since been updated by RFC 7372, RFC 8553 and RFC 8616.

The problem it addresses is stated in the abstract. SMTP itself never checks the sender's domain:

existing protocols place no restriction on what a sending host can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands.

SPF lets the domain owner publish the hosts that are authorized to send with its domain name, and lets the receiving host check the connecting server against that list. The list lives in a DNS TXT record on the domain. Microsoft's documented example for a Microsoft 365 domain is v=spf1 include:spf.protection.outlook.com -all. Google's for Google Workspace is v=spf1 include:_spf.google.com ~all. Gmail's own error text describes -all as "a hard fail policy".

The detail that matters for everything below: SPF evaluates the envelope sender, the MAIL FROM domain used during the SMTP conversation (and, under RFC 7208, the HELO/EHLO domain). That is not the From address a person sees in their mail client. The two can differ, and on mail sent through a third-party platform they often do.

Record syntax, lookup limits and the qualifiers are covered in the SPF guide.

What does DKIM prove?

DKIM (DomainKeys Identified Mail) attaches a signature to the message itself. It is specified in RFC 6376, published in 2011 and designated an Internet Standard (STD 76). RFC 6376 obsoletes RFC 4871 and RFC 5672 and has been updated by RFC 8301, RFC 8463, RFC 8553 and RFC 8616.

The abstract describes the purpose:

DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message.

The verifying server checks the signature against a public key it retrieves from the signer's own DNS. The key is published under a name built from a selector and the _domainkey label. Google Workspace's default selector is google, so its key sits at google._domainkey on the domain. Microsoft 365 uses two CNAME records, selector1._domainkey and selector2._domainkey, and documents that these names are the same for every Microsoft 365 organization.

A passing signature survives relaying, because it travels with the message rather than depending on the connecting IP. But it proves something narrower than many people assume. RFC 6376 is explicit:

DKIM separates the question of the identity of the Signer of the message from the purported author of the message.

The signing domain, carried in the signature's d= value, does not have to be the domain in the From header. A message can carry a perfectly valid DKIM signature from a domain that has nothing to do with the sender the reader sees.

Selectors, key rotation and signature tags are covered in the DKIM guide.

What does DMARC add?

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the layer that connects SPF and DKIM to the From address. A domain owner publishes a DMARC policy record, and receivers use it to decide whether a message that claims to come from that domain has actually been authenticated by it.

The current specification is RFC 9989, edited by T. Herr and J. Levine. dmarc.org reports that the RFC Editor published it on May 20, 2026, alongside two companion documents. Its header is unambiguous: "This document obsoletes RFCs 7489 and 9091." The reporting mechanisms now have their own documents. RFC 9990 covers aggregate reporting and RFC 9991 covers failure reporting, and the RFC Editor's page for RFC 7489 now reads: "This RFC is now obsolete, see RFC 9989, RFC 9990, RFC 9991."

The status change is the significant part. RFC 7489, edited by M. Kucherawy and E. Zwicky, was an Informational document. RFC 9989 is a Proposed Standard on the Standards Track. In dmarc.org's words, the three documents made "the changes and enhancements previously referred to as "DMARCbis" official."

dmarc.org's December 2025 summary of the final drafts lists the main changes:

• The Public Suffix List is replaced by a DNS Tree Walk for finding a domain's Organizational Domain.
• The pct=, rf= and ri= tags are deprecated.
• A new np= tag sets policy for non-existent subdomains, and the psd= tag is carried over from RFC 9091.
• The SPF result DMARC uses comes from the MAIL FROM domain only, with no fallback to HELO.

The record format is unchanged in principle. RFC 9989 states that the policy record "is published in the DNS as a TXT record at the name created by prepending the label "_dmarc" to the domain name", so the policy for example.com lives at _dmarc.example.com. The policy itself is one of p=none, p=quarantine or p=reject. Yahoo and Valimail both use "enforcement" to mean quarantine or reject.

Tags, reporting and the path from p=none to p=reject are covered in the DMARC guide.

How do SPF, DKIM and DMARC work together?

Through alignment. Taken alone, SPF authenticates the envelope domain and DKIM authenticates the signing domain. Neither is tied to the From domain the recipient reads. DMARC supplies that tie. RFC 9989, section 1:

A DMARC result of "pass" requires not only an SPF or DKIM pass verdict for the email message but also and more importantly that the domain associated with the SPF or DKIM pass be "aligned" with the Author Domain

The Author Domain is the domain in the From header. Alignment comes in two modes. RFC 9989 defines them precisely: domains are "in "relaxed alignment" if they have the same Organizational Domain", and "in "strict alignment" if and only if they are identical." Under relaxed alignment, bounces.example.com aligns with example.com. Under strict alignment it does not. The RFC's own assessment is that "In practice, nearly all Domain Owners have found relaxed alignment sufficient to meet their needs."

Two consequences follow from the definition. One aligned pass is enough: DMARC needs SPF or DKIM, not both. And a pass that is not aligned counts for nothing, however valid it is.

Worked example: passing SPF and DKIM, failing DMARC

A company sends receipts from receipts@example.com through a third-party sending platform. The platform authenticates the message with its own domain, mailer.example.net, rather than the company's.

Both underlying checks pass. The message is genuinely from the platform, and both protocols confirm it. DMARC still fails, because nothing in the message proves that example.com authorized it. If example.com publishes p=reject, Gmail's documented response is 550 5.7.26 with the text "Unauthenticated email from domain-name is not accepted due to domain's DMARC policy."

Either of two changes fixes it:

1. Align DKIM. Have the platform sign with d=example.com, using a key published under a selector on example.com. This aligns under both relaxed and strict modes.
2. Align SPF. Set the MAIL FROM to a subdomain such as bounces.example.com, and publish an SPF record there that authorizes the platform's hosts. This aligns under relaxed mode, because bounces.example.com and example.com share an Organizational Domain. It does not align under strict mode.

Microsoft's guidance for Outlook.com asks for alignment "with either SPF or DKIM (preferably both)". Doing both means a message still passes DMARC if one of the two breaks in transit.

What do Gmail, Yahoo and Outlook.com require?

All three large consumer mailbox providers now publish authentication requirements. They overlap, but the thresholds and enforcement steps differ.

Gmail

From February 1, 2024, Google states that "email senders who send more than 5,000 messages per day to Gmail accounts must meet the requirements in this section." For those senders that means SPF and DKIM, a DMARC record with alignment, a reported spam rate below 0.30% (Google recommends staying below 0.10% "and avoid ever reaching a spam rate of 0.30% or higher"), one-click unsubscribe plus a visible unsubscribe link on marketing and subscribed mail, and no impersonation of Gmail From headers. On DMARC, the bar is low: "Your DMARC enforcement policy can be set to none."

Below the threshold, Gmail's error reference still says it "requires all senders to authenticate with either SPF or DKIM."

Two scope details are easy to miss. The guidelines, previously called "Bulk sender guidelines", "don't apply to messages sent to Google Workspace accounts". They cover personal Gmail recipients only. And enforcement has tightened. Google's FAQ states: "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." Enforcement is described as "gradual and progressive", with new domains on an accelerated schedule. Google defines a new domain as "any domain that hasn't sent more than 5,000 emails a day to personal Gmail accounts since January 1, 2024."

Yahoo

Yahoo began enforcement in February 2024 and says it will "continue to gradually roll out enforcement as we monitor compliance metrics". Enforcement of its List-Unsubscribe policy began in June 2024. Yahoo does not publish a volume threshold: "We will not specify a volume threshold." The 5,000-per-day figure often attributed to Yahoo is Google's and Microsoft's, not Yahoo's.

On DMARC, Yahoo's FAQ is a strong recommendation rather than a numeric rule: "Yahoo strongly urges senders to publish a DMARC policy for each domain that sends mail." It goes further for domains being abused: "If you have a spoofing problem, you should be implementing a DMARC enforcement policy (p=quarantine or p=reject) regardless." The Sender Hub FAQ lists no enforcement dates after June 2024.

Outlook.com

Microsoft announced its requirements on April 2, 2025, for its consumer service covering outlook.com, hotmail.com and live.com addresses. Domains sending over 5,000 emails per day must pass SPF and DKIM and publish DMARC at "At least p=none and align with either SPF or DKIM (preferably both)."

Microsoft documents the rejection as 550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level. The rollout did not start there. After May 5, 2025, Microsoft said Outlook "will begin routing messages from high volume non-compliant domains to the Junk folder", with rejection to follow "in the future (date to be announced)". The Outlook.com postmaster policy page describes the same order: Junk first, rejection "shortly". A non-compliant sender may therefore see Junk placement, a 5.7.515 rejection, or both, and Microsoft has not published a date at which rejection applies to all such traffic. Microsoft also reserves "the right to take negative action, including filtering or blocking."

Which Gmail errors point to an authentication failure?

Gmail returns specific enhanced status codes when authentication is the reason. The 4xx forms are rate limits: the message was deferred and can be retried. The 5xx forms are blocks.

Note that 5.7.26 covers three different failures. Read the text, not just the code. The DMARC variant is the one the worked example above produces.

Gmail's bulk-sender codes sit next to these but are not caused by SPF, DKIM or DMARC records: 550 5.7.25 when the sending IP has no PTR record or the forward DNS does not point back to it, 550 5.7.28 for an unusual rate of unsolicited mail from an IP, and 550 5.7.29 when the message was not sent over TLS.

For the wider family of 5.7.x policy rejections, see SMTP 550 5.7.1. For every reply code and how to read enhanced status codes, see the SMTP error codes reference.

How widely is DMARC deployed?

There is no neutral, independent figure. The recent numbers come from vendors, measure different samples, and should be read separately.

• Valimail, 2026 State of DMARC Report (February 25, 2026). Reports that 78% of domains have a DMARC record, and that enforcement (quarantine or reject) rose from 35% to 42% during 2025. The press release does not state the sample. Valimail's summary: "While 78% of domains now have a DMARC record, the 36-point gap between reporting and enforcement proves that compliance does not equal protection."
• EasyDMARC, 2026 DMARC Adoption Report (March 2026). Based on "the top 1.8 million domains globally". Reports DMARC on 937,931 of them (52.1%), up from 47.7% in 2025, with 411,935 domains at p=quarantine or p=reject.

The gap between 78% and 52.1% is a difference in what was counted, not a contradiction to be averaged away. dmarc.org cautions against its own long-running record counts for the same reason: they reflect every validly formatted record DomainTools captured over roughly 15 years, including surges of non-genuine records, so they are not a reliable adoption measure.

What both vendor reports agree on is the direction. Publishing a DMARC record is far more common than enforcing one.

How Trueguard handles this

SPF and DKIM records are public DNS, so they say more than whether a domain authenticates. A value such as include:spf.protection.outlook.com, a selector1._domainkey record, or a google._domainkey record indicates which provider hosts the domain's mail. Trueguard's email validation reads these records, alongside other DNS signals including MX records, to identify the mailbox provider before it checks an address. The inference is Trueguard's own, not a statement from Google or Microsoft, and it is one-directional: Google's DKIM selector can be customized, so a missing google._domainkey record does not rule Google out.