September 7, 2026 · 10 min read

Email deliverability for review requests: SPF, DKIM and DMARC

The three DNS records that decide whether a review request reaches the inbox, and the May 2026 DMARC change most guides have not caught up with.

A review request that lands in a spam folder is worse than one you never sent. You have spent the goodwill of asking, the customer never saw the message, and nothing in your dashboard tells you what happened. The request shows as sent. It simply did not arrive.

This is the least glamorous part of collecting reviews and the part most likely to quietly waste the whole effort. It is also fixable in an afternoon, mostly by editing DNS records you may never have touched. What follows is what the mailbox providers and the specifications actually say, with the parts that changed in 2026 flagged, because a good deal of the advice published on this subject is now out of date.

The three records, and what each one actually proves

The confusion around SPF, DKIM and DMARC comes from a reasonable assumption: that they are three versions of the same idea, and that doing any one of them is broadly enough. They are not, and it is not.

SPF is RFC 7208, published in April 2014. It is a DNS record listing the servers permitted to send on behalf of your domain. The critical detail is which address it checks. SPF validates the envelope sender — the return path used during the SMTP conversation — and the specification is blunt that it should not be stretched further: checking other identities against an SPF record is "NOT RECOMMENDED because there are cases that are known to give incorrect results."

The envelope sender is not the address your customer sees. SPF is a note on the envelope, not on the letterhead.

Two practical constraints. Section 4.6.4 sets a hard ceiling: implementations "MUST limit the total number of those terms to 10 during SPF evaluation." The terms that count are include, a, mx, ptr, exists and the redirect modifier. Chain enough services together and the record silently stops working. Second, the qualifiers in section 4.6.2 mean different things: -all is a hard fail, ~all is a softfail. Google recommends ~all, not the stricter option, which surprises people who assume tighter is always better.

DKIM is RFC 6376, September 2011. It attaches a cryptographic signature over selected headers and the body, published at a DNS name built from the signature itself: a d= of example.com and an s= of foo.bar means a lookup of foo.bar._domainkey.example.com. Key length guidance was updated by RFC 8301 in January 2018, which says signers "SHOULD use RSA keys of at least 2048 bits" and that verifiers "MUST NOT consider signatures using RSA keys of less than 1024 bits as valid." Note that 2048 is a recommendation, not a requirement — anyone telling you it is mandatory is overstating the spec.

A DKIM failure is also less dramatic than it sounds. The RFC is explicit that "signature verification failure does not force rejection of the message." It feeds local policy rather than deciding the outcome.

DMARC is the one that matters for the address your customer reads. It ties the visible From header to the other two through a concept called alignment, and it is the reason passing SPF or DKIM on its own is not sufficient. A message "can bear a valid signature from any domain, even one used by a bad actor" — so DMARC additionally requires that the authenticated domain match the domain in the From header.

What changed in May 2026

Almost every guide to this subject cites RFC 7489. That reference is now out of date, and the substance changed with it.

RFC 7489 was published in March 2015 as an Informational document on the Independent Submission stream. The IETF Datatracker was unusually direct about its standing: it "is not endorsed by the IETF and has no formal standing in the IETF standards process." DMARC was, formally, a widely-adopted convention rather than a standard.

That ended in May 2026. RFC 9989 obsoletes RFC 7489 and RFC 9091, is published on the IETF stream, and carries the status Proposed Standard. Aggregate reporting moved into RFC 9990 and failure reporting into RFC 9991.

One substantive change matters for anyone copying a record out of an older tutorial: the pct tag no longer exists. Appendix A.6 of RFC 9989 is titled "Removal of the 'pct' Tag," and the tag is absent from the registry in section 4.7. Unknown tags "MUST be ignored" by conforming receivers, so a leftover pct=100 is inert rather than harmful — but it is no longer part of the specification.

It is worth knowing that Google's own DMARC setup page still publishes an example record containing pct=100. Google's support pages carry no last-updated date and no changelog, so there is no way to tell whether that reflects a considered position or documentation that has not been revised. The safe course is to publish no pct tag at all.

The policy values are unchanged: none means the domain owner "offers no expression of preference," quarantine means such mail is considered suspicious, and reject means failures are treated as clear evidence the domain is being misused. RFC 9989 recommends starting at p=none with an rua address collecting aggregate reports, which is also Google's advice. Google adds a practical warning: aggregate reports arrive in volume, so do not point rua at a mailbox a person reads.

What the mailbox providers require

Three providers publish requirements. They are similar, not identical, and the differences are where businesses get caught.

Sources: Gmail's sender guidelines and its FAQ, Yahoo's best practices, and Microsoft's 550 5.7.515 error page. All accessed 7 September 2026; none of these pages displays a last-updated date.

Four things are worth pulling out of that table.

The baseline applies to everyone. A business sending forty review requests a day is far below every stated threshold, but Gmail's all-sender requirements have no volume floor at all: SPF or DKIM, valid forward and reverse DNS, TLS, messages formatted per RFC 5322, and spam rates under 0.3 percent. Being small exempts you from the bulk rules, not from the basic ones.

Bulk status is permanent. Gmail's FAQ states that senders classified as bulk are "permanently classified as such," and that changes in sending practices do not reverse it. One unusually busy month is enough.

Outlook.com rejects rather than filters. Microsoft's support page describes the outcome plainly: the message "was rejected because the domain in your 5322.From email address didn't pass the required email authentication level." The SMTP error is 550 5.7.515. That is a bounce, not a spam folder. I have seen the widely-repeated claim that Microsoft junks non-compliant mail first and rejects only later, along with a specific 2025 start date, but I could not confirm either from a Microsoft page, so I am not repeating them as fact.

ARC is not a Gmail requirement. The phrase appears nowhere in Gmail's sender guidelines, despite how often it is listed alongside the other three in vendor summaries.

The spam rate deserves one clarification, because both of the common phrasings are wrong. Gmail's stated requirement is below 0.3 percent. Gmail's separate guidance is that senders "should keep their spam rate below 0.1% and should prevent spam rates from ever reaching 0.3% or higher." So 0.1 percent is the target and 0.3 percent is the line not to cross. Saying Google requires 0.1 percent overstates it; treating 0.3 percent as comfortable understates it.

You measure this in Postmaster Tools, which requires verifying the domain by DNS record — specifically the DKIM signing domain or the SPF return path, not necessarily your From domain. Google states no minimum volume for data to appear, only that data "might be missing if the total number of messages for a given day is too low." A small business will often see empty dashboards with no indication of when they will fill.

The legal layer, which is separate

This is general information, not legal advice. Rules vary and change; talk to a lawyer about your own situation.

Authentication decides whether a message is delivered. CAN-SPAM decides whether you were allowed to send it. The FTC's compliance guide requires accurate header information, a subject line that "must accurately reflect the content of the message," a valid physical postal address, a clear opt-out mechanism, and honouring opt-outs "within 10 business days." That is business days, not calendar days.

Whether a review request counts as a commercial message is genuinely unsettled. Under 16 CFR 316.3, a message is transactional only where it "consists exclusively of transactional or relationship content," and none of the five statutory categories in 15 U.S.C. 7702 covers asking for feedback. I found no FTC guidance or enforcement action resolving the question, so I cannot tell you the answer. The trap is the dual-content test in section 316.3(a)(2): bundle a coupon or a rebooking link into the request and the message tips toward commercial. Treating review requests as commercial mail — postal address, working opt-out, honoured promptly — is compliant either way, which is why it is the sensible default.

The FTC's stated penalty is up to $53,088 per email, set by the January 2025 inflation adjustment and unchanged since; no 2026 adjustment has been published. Enforcement is infrequent rather than absent. The most recent publicly announced action appears to be Verkada in August 2024, a $2.95 million penalty covering data-security counts alongside CAN-SPAM allegations over roughly 30 million emails sent with no opt-out mechanism and no physical address. Both of the two most recent CAN-SPAM actions turned on the opt-out.

Numbers I am deliberately not giving you

Searching this topic returns a great many confident statistics: what percentage of email reaches the inbox, how much DMARC improves deliverability, what share of domains have it configured, what open rate a review request can expect. I could not trace any of them to a primary source, so none of them appear above.

The same applies to the minimum daily volume before Postmaster Tools shows data, which is widely quoted and which Google has never published, and to Microsoft's enforcement timeline, where two search summaries gave contradictory years and neither matched a page I could load.

If a deliverability guide leads with a percentage and does not link to a methodology, assume it was copied from another guide that did the same.

What to do next

1. Send a message to a Gmail address you control, open it, and use "Show original." It reports SPF, DKIM and DMARC as pass or fail in three lines. Do this before changing anything, so you know what is actually broken.
2. Send from a subdomain rather than your main domain — something like mail.yourbusiness.com. A reputation problem then stays contained instead of affecting the address you use for invoices and customer replies. This is how ReviewHero sends, with SPF, DKIM and DMARC published on a dedicated sending subdomain.
3. Publish SPF and DKIM through whatever service sends for you, then confirm the SPF record stays within ten DNS-querying terms.
4. Publish DMARC at p=none with an rua address pointing at a dedicated mailbox. Include no pct tag. Leave the policy at none until the reports show your legitimate mail passing.
5. Verify the domain in Postmaster Tools using the DKIM or SPF domain. Expect empty dashboards at low volume, and do not read that as a problem.
6. Add a working unsubscribe link and a real street address to the template, then confirm the opt-out actually removes the address. That single mechanism is what the recent enforcement actions were about.
7. Once the reports stay clean over several weeks, move DMARC to quarantine, then to reject. There is no prize for rushing this and a real cost to getting it wrong.