SPF, DKIM and DMARC: Authenticating Your Sending Domain So Email Reaches the Inbox

Marketing and transactional email (order confirmations, password resets, invoices) leave from a business's domain, but mailboxes trust it only when it proves the sender is the owner. SPF, DKIM and DMARC are the 3 mechanisms that do this, and since February 2024 Google and Yahoo require them from bulk senders.

This article draws on IETF standards (RFC 7208, RFC 6376, RFC 9989) and the official help pages of Google, Yahoo and Microsoft, checked on October 22, 2026. It covers what each mechanism does, why mail can fail despite a pass, the DMARC rollout and checking.

Key points

• SPF states which servers may send for a domain, DKIM attaches a cryptographic signature, and DMARC passes only when SPF or DKIM authenticates a domain that matches the From line.
• Alignment is often missed: SPF or DKIM can report "pass" while DMARC still fails if the authenticated domain differs from the From domain.
• SPF allows only 1 v=spf1 record per domain and at most 10 DNS lookups; exceeding the limit or publishing 2 records produces a permerror (RFC 7208).
• Senders of more than 5,000 messages a day to personal Gmail need SPF, DKIM, DMARC (at least p=none), one-click unsubscribe for marketing mail and a spam rate below 0.30%. Yahoo is similar, with no published volume threshold.
• RFC 9989 (May 2026) replaces RFC 7489, drops pct and adds t and np. The safe path is p=none with rua, fix every legitimate source, then quarantine and reject.
• Verify with Google Postmaster Tools (personal Gmail only, about 24 hours delay) and the Authentication-Results header.

How SPF, DKIM and DMARC differ

Per RFC 7208 (April 2014), SPF (Sender Policy Framework) lets a domain owner publish which servers may send for it. The receiver checks the domain in the MAIL FROM command (Return-Path, where bounces go) and the HELO domain.

Per RFC 6376 (September 2011), DKIM attaches a cryptographic signature to the message. The responsible domain is in the d= tag, the selector (key label) in s=, and the public key in a TXT record at selector._domainkey.domain.

Per RFC 9989 (May 2026), DMARC requires SPF or DKIM to authenticate a domain matching the From line, and lets the owner say how failing mail should be handled and where reports go.

Why all 3? Per Microsoft Learn (July 3, 2026), SPF does not compare MAIL FROM with the From line, so an attacker can register a domain, pass SPF and forge From; DKIM has the same gap. DMARC closes it with alignment.

From-domain alignment: where much mail fails

Alignment means the authenticated domain must match the From domain. Per RFC 9989, relaxed mode (the default) accepts the same organizational domain; strict mode requires an identical one.

For SPF, DMARC looks only at the MAIL FROM domain. A third-party sending service often points Return-Path to its own domain: SPF passes but does not align with the business's From domain. Then DKIM alone carries DMARC, so d= must be the business's own domain.

A message passes DMARC when at least 1 identifier aligns; RFC 9989 recommends both. Google warns strict mode can get subdomain mail rejected; relaxed is usually enough (Set up DMARC, October 20, 2026).

SPF: 1 record, at most 10 DNS lookups

Per RFC 7208, a domain with more than 1 record starting with v=spf1 produces a permerror (permanent error). The RFC also caps terms that trigger DNS queries at 10: include, a, mx, ptr, exists and redirect. The ip4, ip6 and all terms do not count; going over 10 is a permerror.

Counting is a trap: Google's Set up SPF page (October 20, 2026) says "up to 10 include tags", but the RFC also counts nested includes. Microsoft Learn says each include needs at least 1 lookup, possibly more.

At the limit: drop unused services, swap include for ip4 or ip6 if the provider guarantees fixed IPs, and move streams to subdomains. Microsoft Learn advises a subdomain for bulk email services you do not control.

Google recommends ending with ~all (softfail); Microsoft Learn suggests starting with ~all, then -all once all sources are known. Because SPF often breaks on forwarding, RFC 9989 says p=reject must not rely on SPF alone.

DKIM: long enough keys, 1 selector per service

Per RFC 8301 (January 2018), signers must not use rsa-sha1, must use RSA keys of 1024 bits or more and should use 2048 or more. Google and Yahoo also require 1024 bits or more and recommend 2048.

Each sending service (marketing, CRM, invoicing) should sign with its own key and selector under the business's domain, so replacing one key does not touch the others.

Google, Yahoo and Microsoft requirements for bulk senders

Google. The Email sender guidelines page (undated, read October 22, 2026) sets requirements from February 1, 2024. Every sender to Gmail needs SPF or DKIM, valid forward and reverse DNS (PTR), TLS, RFC 5322 format and a Postmaster Tools spam rate below 0.3%.

Senders of more than 5,000 messages a day also need SPF and DKIM, DMARC (policy may be none), a From domain aligned with SPF or DKIM, and, for marketing mail, one-click unsubscribe plus a visible unsubscribe link in the body. Google advises a spam rate below 0.10%.

Per Google's FAQ (undated), the rules apply to mail to personal Gmail, not Workspace accounts. Close to 5,000 messages or more in 24 hours makes a bulk sender, subdomain mail counts toward the primary domain, and the status never expires. From November 2025 Google ramps up enforcement, with temporary and permanent rejections.

One-click unsubscribe is required only for marketing mail, not transactional mail such as password resets; Google recommends honoring requests within 48 hours. Per RFC 8058 (January 2017), the message needs List-Unsubscribe and List-Unsubscribe-Post headers, both covered by the DKIM signature.

Yahoo. The Sender Requirements & Recommendations page (undated) is similar: SPF and DKIM, DMARC at least p=none and passing, aligned From, one-click unsubscribe honored within 2 days, spam rate below 0.3%. Yahoo's FAQ says it covers AOL, publishes no volume threshold, and advises separating marketing from transactional mail.

Microsoft. Microsoft's announcement for high-volume senders to Outlook.com blocked Click Star's tools (error 403), so it was not read in full. Per the search-result summary of that page, the threshold is more than 5,000 messages a day and SPF, DKIM and DMARC are required. Secondary sources conflict on the consequence of failing, so none is asserted.

DMARC rollout: p=none, quarantine, reject and reports

RFC 9989 sets the order: aligned SPF and DKIM, a report mailbox, DMARC with p=none and rua (monitoring mode), reading reports, fixing every failing legitimate stream, then enforcement. The fixing must precede enforcement (a MUST in the RFC) and can take months.

For domains whose users post to public mailing lists, the RFC advises against p=reject; if used anyway, p=none for at least 1 month, then quarantine for as long. Google is faster: p=none for about 1 week, then quarantine for a small share (for example 10% or 1%), raised gradually, after SPF and DKIM have run 48 hours.

RFC 9989 replaces RFC 7489 (March 2015) and RFC 9091 (experimental): pct is gone; t=y asks receivers to apply a policy 1 level lower while testing; np, taken from RFC 9091, covers non-existent subdomains; a DNS Tree Walk finds the organizational domain. Reports move to RFC 9990 (aggregate) and RFC 9991 (failure).

Google (Recommended DMARC rollout, October 20, 2026) and Microsoft Learn (Set up DMARC, July 17, 2026) still show pct in samples; Yahoo's FAQ cites RFC 7489. Click Star infers a long transition.

Rua reports are XML files, covering 1 UTC day, preferably gzipped (RFC 9990). If the receiving address is on another domain, it must publish an authorization record under _report._dmarc. Ruf reports can contain real message content and Gmail does not support ruf per Google, so rua is primary.

Illustrative DNS records for example.com

Sample records for example.com and a hypothetical service; use the values your provider issues.

example.com.                TXT "v=spf1 ip4:203.0.113.10 include:spf.mailer.example.net ~all"
s1._domainkey.example.com.  TXT "v=DKIM1; k=rsa; p=MIIBIjANBg...(shortened)"
_dmarc.example.com.         TXT "v=DMARC1; p=none; rua=mailto:[email protected]"

SPF allows 1 IP and 1 sending service, DKIM puts the key at selector s1, DMARC is in monitoring mode.

How to verify: Postmaster Tools and Authentication-Results

Google Postmaster Tools has Compliance status, Spam rate, Authentication and Delivery errors dashboards. Data covers only mail to personal Gmail, is not real time (usually 24 hours) and may be missing on low-volume days; Compliance can take 7 days to reflect changes.

To add a domain, choose the DKIM d= domain or the SPF (Return-Path) domain and verify with a TXT or CNAME record. Google says the Domain and IP Reputation dashboards will be retired.

For one message, open it in Gmail, choose "Show original" to see the headers (per Google), then find Authentication-Results. RFC 8601 defines this header to record the spf, dkim and dmarc results the receiver computed.

What this means for Vietnamese businesses

Click Star found no public measurement of DMARC adoption among Vietnamese businesses. A technical inference: small and midsize businesses often send from many places (mailboxes, CRM, email marketing, website forms, accounting), each needing a place in SPF and an aligned DKIM signature.

Google's and Yahoo's rules attach to the recipient, not the server's location: a list of tens of thousands sent in batches can reach 5,000 in 24 hours.

Click Star's view. Email authentication is infrastructure, not a feature of one marketing tool. Configured only inside each tool, every provider change risks mail landing in spam unnoticed.

Click Star holds that a business should inventory sending sources, move marketing and transactional streams to subdomains, read rua regularly, and move to reject only after reports stay clean for several sending cycles. Disclosure: Click Star offers digital marketing, CRM and integration services.

A 30-day path for a business starting from zero

A Click Star reference framework, not from outside sources; the order follows RFC 9989 and days may stretch.

• Days 1 to 3: list every system sending mail under the domain and the From domain each uses.
• Days 4 to 7: merge into 1 SPF record (at most 10 lookups) and enable 2048-bit DKIM per system with d= set to the business's domain.
• Days 8 to 14: publish DMARC p=none with rua to a dedicated mailbox, test from every system and read Authentication-Results.
• Days 15 to 30: read rua daily, fix unaligned streams, add one-click unsubscribe and add the domain to Postmaster Tools.
• After day 30: only when reports are clean, move to quarantine and watch; reject once every legitimate source passes.

Common mistakes

1. Publishing 2 SPF records for one domain (often by adding a service in a separate record), giving a permerror.
2. Forgetting third-party senders such as CRM, website forms or invoicing, so their mail fails once the policy reaches quarantine or reject.
3. Stacking includes until SPF exceeds 10 lookups, without recounting after each service added.
4. Treating "SPF pass" or "DKIM pass" as enough while the authenticated domain differs from the From domain.
5. Moving DMARC to reject too early, before reports cover every stream or while users still post to public mailing lists.
6. Mixing marketing and transactional mail on one domain or IP, so one spam-reported campaign drags down order confirmations.
7. Pointing rua to a personal mailbox nobody reads; Google advises a dedicated mailbox or analysis service.

What is not known

Click Star has no measurement of Vietnamese DMARC adoption, could not read Microsoft's post in full and does not know how domestic mailbox providers treat mail that fails authentication. Authentication does not guarantee the primary inbox; Google says only that authenticated mail is less likely to be rejected or marked spam.

Google's guidelines and FAQ pages and Yahoo's page show no update date. Google writes its threshold as "more than 5,000" in one place, "close to 5,000 or more" in another. It is unclear how far receivers have deployed the RFC 9989 Tree Walk or how they treat legacy pct.