SPF, DKIM and DMARC: What Each Record Does and What Gmail and Outlook Require

SPF, DKIM and DMARC are three DNS-based email authentication methods, and each answers a different question. SPF asks whether the server that delivered a message is allowed to send for a domain. DKIM asks whether a signature on the message verifies against a public key the signing domain published. DMARC asks whether at least one of those two checks passed for the same domain the reader sees in the From address, and tells receivers what to do if neither did. If you send more than 5,000 messages a day to Gmail or Outlook.com consumer addresses, you need all three. If you send less, they are still how a receiver tells your mail from a forgery.

This article explains what each record checks, where they commonly break, what Google and Microsoft require, and a rollout order that does not block your own mail. It is a research-based explainer: we did not send test mail through Gmail or Outlook.com, and where we could not confirm a detail from a primary source we say so.

What each record checks

Two terms need defining. The envelope sender is the address given to the receiving mail server in the SMTP conversation, also called MAIL FROM or the reverse-path. It is not the same as the From header your mail client displays. RFC 7208 specifies that SPF verifiers check the HELO and MAIL FROM identities, and that checking other identities is not recommended. SPF on its own therefore says nothing about the From address a person reads, which is the gap DMARC closes.

SPF

An SPF record lists who may send for a domain. A minimal example for a domain that sends through Google Workspace and one other provider:

example.com.  TXT  "v=spf1 include:_spf.google.com include:mail.provider.example -all"

The ending is a qualifier plus the all mechanism. RFC 7208 defines + (pass), - (fail), ~ (softfail) and ? (neutral); with no qualifier, + is assumed. -all says anything not listed should fail. ~all (softfail) is weaker. We did not verify how individual receivers treat the two when SPF is combined with DMARC, so do not assume they behave identically.

The constraint that surprises teams is the lookup limit. RFC 7208 section 4.6.4 says implementations must limit DNS-querying terms to 10 per evaluation. The include, a, mx, ptr and exists mechanisms and the redirect modifier count; ip4, ip6 and all do not. Exceeding 10 produces a permerror. The same section says implementations should allow no more than two void lookups (queries returning an empty answer or NXDOMAIN) and also returns permerror past that. Each include can itself contain more terms that count, so a record with several marketing, support and billing vendors can pass review and still fail at evaluation. Count the terms after expanding every include.

DKIM

DKIM signs selected headers and the body of each message. The signing domain is named in the d= tag and the selector in the s= tag; RFC 6376 combines them to build the DNS name of the public key. Its example is d=example.com with s=foo.bar, which is looked up at foo.bar._domainkey.example.com. Selectors let one domain hold several keys at once, which is how you run separate keys for separate vendors and rotate them without downtime.

Because the signature travels inside the message, DKIM usually survives plain forwarding, whereas SPF is tied to the connecting IP address. That explains the standard advice to deploy both rather than choose one. We did not find, and do not claim, a figure for how often each method survives forwarding in practice.

DMARC and alignment

A DMARC record is published at _dmarc.<domain>:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

RFC 7489 defines three policies in the p tag: none (no specific action requested), quarantine (treat failing mail as suspicious) and reject (reject failing mail, ideally during the SMTP transaction). The sp tag sets a different policy for subdomains and, if absent, p applies. The rua tag lists where to send aggregate reports; per RFC 7489, if rua is absent, no aggregate reports are generated.

Alignment is the part that makes DMARC more than “SPF or DKIM passed.” RFC 7489 requires that the From domain match the domain that SPF or DKIM authenticated. In relaxed mode, the two only need the same Organizational Domain (for example mail.example.com aligns with example.com). In strict mode, only an exact match of the fully qualified domain names counts. The aspf and adkim tags choose the mode for SPF and DKIM separately and both default to relaxed.

This is why mail from a third-party platform can pass SPF yet fail DMARC. If the vendor sends with its own envelope sender domain, SPF passes for the vendor’s domain, which does not align with your From domain. The fix is usually to have the vendor sign with a DKIM key under your domain, or to configure a custom return-path domain, so that at least one method passes and aligns.

What Google and Microsoft require

Both providers state requirements for high-volume senders. The thresholds and scope are specific, so read them before assuming they apply to you.

Two cautions on that table. First, Google’s page also recommends keeping the spam rate below 0.10% and avoiding 0.30% or higher; the two figures are a recommendation and a threshold, not one rule. Second, for Microsoft we read the announcement published April 2, 2025 and updated April 30, 2025. It says rejected messages will carry the code 550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level, but we found no later official Microsoft statement giving a rejection date. Third-party sources disagree about whether and when rejection began, so we treat the date as unconfirmed. Planning to the stricter outcome costs little.

These rules apply by volume and recipient, not by who you are. A 200-message-per-day sender is outside the stated thresholds but still benefits from the same records, because the records are what stop other people using your domain.

The DMARC update: RFC 9989

In May 2026 the IETF published RFC 9989, which is on the Standards Track and obsoletes RFC 7489 (an Informational document published in March 2015) and RFC 9091. The reporting formats move to companion documents, RFC 9990 and RFC 9991. From the parts of RFC 9989 we read, the changes that affect a record are:

• The pct tag is replaced by a t tag for DMARC policy test mode.
• An np tag sets the policy for non-existent subdomains.
• A psd tag lets public suffix operators flag a Public Suffix Domain.
• The Organizational Domain is no longer found using the Public Suffix List. A “DNS Tree Walk” with a limit of eight DNS queries replaces it.

We could not read the whole document, including its “Changes from RFC 7489” appendix, so this is not a complete change list. We also did not test how Gmail, Outlook.com or other receivers treat the new tags. Until a receiver documents otherwise, keep v=DMARC1 records that you have verified working, and change tags deliberately rather than all at once.

A rollout order that does not block your own mail

1. Inventory senders. List every system that sends mail with your domain in the From address: corporate mail, marketing platform, help desk, billing, CRM, monitoring alerts, applications. The shadow senders are the usual cause of surprises. Our guide to auditing SaaS apps connected to your company is a useful starting point for finding them.
2. Publish DMARC at p=none with a rua address. This changes no delivery behavior and starts aggregate reports. Use a mailbox or reporting service that can parse them; the reports are XML.
3. Fix alignment per sender. For each source in the reports, make DKIM sign with your domain or align the return-path. Check the SPF lookup count after each addition.
4. Move to quarantine, then reject. Do it when reports show your legitimate sources aligned. Under RFC 7489 the pct tag can apply the policy to a share of mail while you gain confidence; under RFC 9989 the t test-mode tag takes that role, so confirm which your receivers honor.
5. Set sp (and np if your receivers support it) deliberately so unused subdomains cannot be spoofed.
6. Watch the reports continuously. New vendors appear without anyone telling security. Reports are how you learn about them before a customer does.

Email authentication reduces spoofing of your domain. It does not detect phishing from lookalike domains, compromised legitimate accounts, or stolen sessions; for the latter see how session hijacking works even after MFA and phishing-resistant MFA.

Sources and verification

Checked on October 10, 2026. We did not send test messages or inspect any live DNS records.

AuthenticationCompliance