If email from a perfectly legitimate system suddenly starts landing in spam (or bouncing), it usually isn't because "deliverability is mysterious".
It's because mailbox providers have been steadily raising the floor for what counts as a well-behaved sender.
This isn't just about inbox placement, either. A lot of these rules are the "make spoofing harder" layer. If that motivation helps the whole thing click, How to prevent email spoofing? is the plain-language version.
Gmail, Yahoo, and Microsoft don't publish one single universal checklist that covers every situation. But in practice, the same handful of requirements show up again and again:
This guide focuses on what tends to matter in production, and how to implement it without creating a new outage.
When it's time to sanity-check the exact wording of the big providers, these are the most directly relevant official references:
If DMARC is still a bit fuzzy, start with What is DMARC?. For SPF and DKIM basics: What is SPF? and What is DKIM?.
Mailbox providers score more than the content of one email.
They look at whether:
From: domain is authenticatedThe part that surprises people is the first bullet.
It's easy to get SPF to pass and still fail DMARC, because DMARC cares about the domain recipients see.
That visible domain is the domain in the From: header (RFC 5322.From). DMARC then checks whether SPF or DKIM passed and is aligned to that domain.
If that sentence feels annoyingly specific, that's normal. The practical walkthrough is in DMARC alignment: From vs Return-Path (strict vs relaxed).
For a real example of how "everything is passing, but the wrong identity is being authenticated", Solved: Google Calendar invites failing DMARC checks is exactly that pattern.
SPF answers: "Is this IP allowed to send for the envelope sender domain?" (the 5321.MailFrom domain).
Provider checklists usually treat SPF as table-stakes. For example, Google calls out SPF (or DKIM) for all senders and SPF+DKIM for bulk senders in its Email sender guidelines.
If the sending is through Microsoft 365, Microsoft's SPF reference is also worth having open while editing DNS (it includes the common failure modes like multiple SPF records and lookup depth): Set up SPF to identify valid email sources for your custom cloud domains
Practical SPF rules that keep setups stable:
1) Publish exactly one SPF record per domain
Multiple SPF TXT records is a common self-inflicted failure. Many receivers treat that as SPF permerror, which means SPF effectively fails.
2) Keep SPF scoped to the domain that actually appears in the envelope sender
If the sending platform uses a bounce domain that isn't under the domain in From:, SPF may pass but DMARC can still fail due to misalignment.
3) Watch the 10-DNS-lookup limit
This is where SPF becomes brittle. Includes stack up, and one day a new include pushes it over the limit.
Reassurance: SPF doesn't have to be perfect to move forward. In many real deployments, DKIM is the more reliable aligned signal, and SPF becomes "nice to have" rather than the primary pass.
DKIM answers: "Was this message signed by a domain, and did the signed content survive transit?"
If the sending is through Microsoft 365, Microsoft's DKIM walkthrough is a good reference for the mechanics (and it doubles as a checklist for the usual gotchas): Set up DKIM to sign mail from your cloud domain
For provider requirements, what usually matters is not DKIM in the abstract, but aligned DKIM:
From: billing@example.comd=example.com (or a subdomain, if relaxed alignment is used)In practice, DKIM is the least painful way to satisfy DMARC because:
Two operational details that matter more than people expect:
If you suspect a provider setup "looks right" but isn't actually signing reliably, Your Google Workspace DKIM setup may be broken (and you may not know it) is a good example of how that happens.
DMARC is where providers get a clear policy and a reporting mechanism.
Google and Microsoft both publish practical DMARC setup guidance that matches how DMARC is actually evaluated at large receivers:
At a minimum, DMARC should exist, and aggregate reporting should be enabled:
v=DMARC1; p=none; rua=mailto:dmarc@example.comThat record does two important things:
From there, the "real" work is cleaning up all legitimate senders until DMARC passes consistently, then moving to enforcement (p=quarantine / p=reject) in a controlled way.
If the goal is a staged rollout that doesn't break vendors, A (sane) DMARC setup process for busy domains is the practical approach.
If a quick overview helps before getting into the weeds, DMARC setup stages is the shorter map.
rua vs rufDMARC has two reporting families:
rua (aggregate XML reports): this is the useful, scalable data.ruf (forensic / failure reports): message-level reports, heavily restricted by many providers and often sensitive.In 2026, many large mailbox providers either don't send ruf at all or send it in a very limited form.
One concrete example (worth knowing because it surprises teams mid-rollout): Google's Set up DMARC guidance explicitly notes that Gmail doesn't support ruf failure reporting.
And because ruf can be a privacy and operational headache, it tends to be omitted unless there's a very specific need.
DMARCPal does not process ruf reports. If ruf is used for some reason, don't put a DMARCPal report address in ruf.
If DMARC tags feel like alphabet soup, DMARC record tag cookbook (p, sp, pct, rua, ruf, fo, ri, rf) keeps it grounded.
PTR (reverse DNS) is not a DMARC concept, but it still affects how "real" a mail server looks.
Both Google and Yahoo explicitly call out forward+reverse DNS (PTR/rDNS) as part of their sender requirements for delivered mail: Gmail Email sender guidelines and Yahoo Sender Requirements & Recommendations.
This matters most when the mail is being sent directly from infrastructure under your control (own MTA, cloud VM, dedicated IP). If a SaaS platform or ESP is sending, that vendor usually owns the IP and its PTR.
When PTR does matter, a sane baseline looks like this:
mailout1.example.com)localhost, not a random cloud default)This isn't about passing a single formal "PTR test".
It's about not tripping easy credibility checks that filters apply before even looking at DMARC.
For most modern sending, STARTTLS should be enabled and working with reasonable certificates and ciphers.
Providers differ on how strictly they enforce TLS for all traffic, but the direction is consistent: encrypted transport is expected, especially for bulk mail.
Google lists TLS as a baseline sender requirement in its Email sender guidelines.
Two practical gotchas:
If inbound TLS policy is also on the roadmap, MTA-STS and TLS-RPT are the next layer (separate from DMARC). That topic deserves its own deep dive.
For bulk and marketing mail, mailbox providers increasingly expect unsubscribe to be both present and easy.
This is not vague "best practice" anymore: both Google and Yahoo call out one-click unsubscribe support for bulk marketing/subscription mail in their sender requirements: Gmail Email sender guidelines and Yahoo Sender Requirements & Recommendations.
The practical implementation is:
List-Unsubscribe headerList-Unsubscribe-Post: List-Unsubscribe=One-Click (RFC 8058)Example headers (pattern, not copy/paste-ready values):
List-Unsubscribe: <mailto:unsubscribe@example.com?subject=unsubscribe>, <https://example.com/unsub?id=...>
List-Unsubscribe-Post: List-Unsubscribe=One-ClickWhy this matters operationally:
Reassurance: One-click unsubscribe isn't "extra polish". It's a safety valve that protects reputation when someone simply doesn't want the mail anymore.
This is the short list that tends to get domains back into a compliant, stable posture:
1) Ensure DKIM signing is enabled for every legitimate sender using the domain.
2) Ensure SPF exists and is correct for the envelope sender domains that are actually used.
3) Publish DMARC with rua reporting, then fix alignment issues until DMARC passes reliably.
4) If sending from owned IPs, fix PTR and forward-reverse DNS, and make EHLO/HELO sane.
5) Ensure STARTTLS works reliably.
6) For bulk mail, implement List-Unsubscribe and one-click unsubscribe.
If multiple senders share the same From: domain and things keep stepping on each other, strongly consider moving streams onto dedicated subdomains. DMARC subdomain policy best practices: sp, dedicated records, and inheritance gotchas explains how to do that without falling into the inheritance traps.
And if DNS questions keep popping up while doing this work (especially where records are published), What is an apex domain? DNS zone apex explained (SPF, DKIM, DMARC) clears up the "where does this record live?" confusion.