The Distribution loop dimension asks whether attention converts into a relationship the publisher controls. A send that is not delivered is not a relationship. This page states the authentication requirements that make delivery possible, what each protocol actually does, where they come from, and how to verify any of it from outside an account.
The short answer
Since February 2024, Google and Yahoo have enforced a shared set of sender requirements. Before that date, authentication was strongly recommended. Since it, authentication is the condition of delivery to their users, and their users are the majority of most publications’ lists.
If you send any email from your own domain, you need SPF or DKIM, valid reverse DNS on the sending IP, and TLS in transit. If you cross the bulk sender line, you need both SPF and DKIM, a published DMARC record, at least one of those two aligned with your From domain, one-click unsubscribe on marketing mail, and a spam complaint rate under 0.3 percent.
The requirement that catches almost everyone is alignment, not authentication. Those are different things, and most platforms report the first while telling you nothing about the second.
What each protocol does
Three records do three separate jobs. Understanding which is which is the difference between fixing a delivery problem and guessing at it.
| Protocol | Question it answers | Where it lives | What it checks |
|---|---|---|---|
| SPF | Is this server allowed to send for this domain? | TXT record on the domain | The envelope sender domain, also called Return-Path |
| DKIM | Was this message altered, and who signed it? | TXT record at a selector under the domain | A cryptographic signature over headers and body |
| DMARC | Does the authenticated domain match the one the reader sees? | TXT record at _dmarc on the domain | Alignment, plus what to do on failure |
SPF
SPF is a published list of the servers permitted to send on behalf of a domain. It is checked against the envelope sender, which is not the address displayed in a mail client. A sending platform typically puts its own domain in the envelope sender so that bounces return to it, which is exactly the condition that makes SPF pass and DMARC fail.
SPF has a hard limit of ten DNS lookups per evaluation. Publishers who accumulate services over time, each adding an include, quietly exceed it, at which point SPF stops passing for everything rather than degrading gracefully. If you have added an include for a newsletter platform, a transactional provider, a helpdesk and a form tool, this is worth checking directly.
DKIM
DKIM attaches a cryptographic signature to the message. The signature covers a chosen set of headers and the body, and it names two things that matter for alignment: a selector, which identifies which key to use, and a d= domain, which identifies who is claiming responsibility for the message.
The d= domain is the one DMARC compares against the From header. If your platform signs with its own domain rather than yours, DKIM passes and DKIM alignment fails. This is the single most common cause of a DMARC failure on an otherwise correctly configured setup.
DKIM also survives forwarding in ways SPF does not, because the signature travels with the message while the envelope sender is rewritten. That is why DKIM alignment is the more robust of the two paths to a DMARC pass.
DMARC
DMARC ties the other two to the address a human actually sees. It does two things: it requires that SPF or DKIM pass and align with the From domain, and it publishes an instruction for what receivers should do when neither does.
The policy tag takes three values. p=none monitors and asks receivers to deliver as they otherwise would. p=quarantine asks them to treat failures as suspicious. p=reject asks them to refuse the message outright. Google and Yahoo require a published record with at least p=none. That is the floor, not a recommendation.
A DMARC record also accepts rua=, an address to send aggregate reports to. This is optional and it is the most useful optional thing in the entire specification, because it is how you discover that a service you forgot about has been sending as your domain and failing for months.
Alignment, which is the part that breaks
Authentication and alignment are separate tests. A message can pass both SPF and DKIM and still fail DMARC, because neither authenticated domain matches the domain in the From header.
Alignment comes in two modes, and relaxed is the default:
- Relaxed. The organizational domains must match. A DKIM signature from
mail.example.comaligns with a From address atexample.com. - Strict. The domains must match exactly. Set with
aspf=sandadkim=s. Rarely what a publisher wants, and a common cause of self-inflicted failure.
The two paths check different fields, which is why they fail for different reasons:
| Path | Compares the From domain against | Typical failure |
|---|---|---|
| SPF alignment | The envelope sender, or Return-Path, domain | Platform uses its own bounce domain |
| DKIM alignment | The d= tag in the DKIM signature |
Platform signs with its own domain, not yours |
Only one needs to pass. In practice, configuring DKIM alignment properly is the better investment, because it is what survives forwarding.
There is a visible symptom worth knowing. When Gmail shows a message as sent via another domain, it is telling you the signing domain does not match the From domain. That indicator is a free alignment check that requires no tooling at all.
The gmail.com From address problem
This deserves its own section because it is the failure most likely to affect a one-person publication, and no amount of platform configuration fixes it.
Gmail publishes a DMARC quarantine policy on gmail.com itself. A publisher who sends through an email platform while putting a personal gmail.com address in the From header fails DMARC by construction. The From domain is gmail.com, the platform cannot align to a domain it does not control, and the receiving server has already been instructed what to do with mail in that state.
The fix is to send from a domain you control. This is also a rubric point rather than only a deliverability one: Owned hub strength asks whether the publisher owns the ground the work sits on, and an email identity on someone else’s domain is a rented one.
The requirements, both tiers
The rules split into obligations that apply to every sender and additional obligations for bulk senders. Google defines a bulk sender as an organizational domain sending roughly 5,000 or more messages per day to personal Gmail addresses.
All senders, at any volume
- SPF or DKIM configured for the sending domain
- Valid forward and reverse DNS, meaning a PTR record, for sending IP addresses
- TLS for transmission
- Message formatting that conforms to RFC 5322
- A From header that does not impersonate Gmail or Yahoo
- A spam complaint rate below 0.3 percent
Bulk senders, additionally
- Both SPF and DKIM configured, not one or the other
- A published DMARC record.
p=noneis the stated minimum - Domain alignment. DMARC must pass through either SPF or DKIM alignment. Authenticating is not sufficient on its own
- One-click unsubscribe via the List-Unsubscribe and List-Unsubscribe-Post headers, as specified in RFC 8058, for marketing and promotional mail, with opt-outs honoured within two days
- A visible unsubscribe link in the message body, in addition to the header
One-click unsubscribe applies to marketing and promotional messages only. Transactional mail such as password resets, receipts and confirmations is excluded.
Why the bulk threshold is the wrong number to watch
Three properties of the classification make the 5,000 figure a poor guide for a small publisher, and they are covered in more detail in what the Gmail bulk sender rules changed for one-person lists.
It is measured at the organizational domain and aggregates every subdomain beneath it. It does not lapse, so a domain that crosses the line once is treated as a bulk sender afterwards. And the all-senders tier has no volume floor at all, so most of the work is required regardless.
The practical reading: configure for the bulk tier and the threshold question stops mattering.
The spam rate threshold in practice
Google guidance is to stay below 0.1 percent and never reach 0.3 percent. The 0.3 figure is where enforcement begins, not a safe operating target. Google states that senders become eligible for mitigation once rates remain below 0.3 percent for a sustained period rather than immediately on a single good send.
Because these are rates rather than counts, a small list has fewer complaints to spend before crossing them:
| Messages sent | Complaints at 0.1% | Complaints at 0.3% |
|---|---|---|
| 1,000 | 1 | 3 |
| 2,000 | 2 | 6 |
| 5,000 | 5 | 15 |
| 10,000 | 10 | 30 |
On a list of 2,000, six readers reaching for the spam button rather than the unsubscribe link puts the domain at the enforcement line for that send. That is the strongest available argument for making the unsubscribe link easier to find than the spam button, and it is why a buried unsubscribe is a deliverability decision rather than a retention one.
The rate is only visible to a publisher through Google Postmaster Tools, which requires verifying the sending domain. A publisher who sends regularly and has never opened Postmaster Tools does not know their own spam rate.
Forwarding, and why ARC exists
Forwarding breaks SPF. The forwarding server is not on the original domain’s permitted list, so SPF fails at the second hop. Mailing lists frequently break DKIM too, by modifying subject lines or appending footers, which invalidates the signature.
Authenticated Received Chain exists to preserve the original authentication result across those hops, allowing an intermediary to vouch that the message authenticated before it was modified. A publisher does not implement ARC; it is the receiving and forwarding infrastructure’s job. It is worth knowing about only so that a forwarded-mail failure is not mistaken for a configuration error on your side.
How to verify this from outside
All of it is checkable without account access, which is why it is admissible teardown evidence.
Check the DNS records
SPF, DMARC and the DKIM key are all public TXT records:
dig +short TXT example.comshows any SPF record, which beginsv=spf1dig +short TXT _dmarc.example.comshows the DMARC record and its policydig +short TXT selector._domainkey.example.comshows the DKIM public key, once you know the selector
Selectors are not discoverable from DNS alone, which is why the message headers are the better starting point.
Read the headers of an actual send
Subscribe to the publication, open a message in Gmail and choose Show original. Three things are visible immediately: the Authentication-Results header states pass or fail for SPF, DKIM and DMARC; the DKIM-Signature header shows the d= domain and the selector; and the Return-Path shows the envelope sender. Comparing the d= domain and the Return-Path against the From domain is the alignment check, done by eye.
This is the method a teardown uses, because it answers the question platforms will not: not whether authentication is configured, but whether it aligns.
Common failure patterns
| Symptom | Likely cause | Fix |
|---|---|---|
| Gmail shows sent via a platform domain | DKIM d= domain does not match From | Configure a signing domain on your own domain |
| SPF and DKIM pass, DMARC fails | Neither path aligns | Fix DKIM alignment, which is the durable one |
| SPF fails intermittently | Ten-lookup limit exceeded | Flatten or remove unused includes |
| Mail vanishes with no bounce | Rejection rather than filtering | Check Postmaster Tools, not the spam folder |
| Works to your own inbox, fails elsewhere | Same-domain delivery bypasses the checks | Test to an external seed address |
| Sends fine, complaints rising | Unsubscribe harder to find than spam button | Header unsubscribe plus a visible link |
How this is used in a teardown
Authentication status is checkable from public evidence: DNS records are public, and a subscribed reader can read the headers of a real send. That is why it sits inside Distribution loop rather than being treated as unverifiable.
The band definitions treat authenticated sends as a condition of scoring above the low bands rather than as a bonus. Band 3 requires that sends exist and are properly authenticated. Band 4 requires that they are authenticated and delivered, which is the alignment question rather than the configuration question.
The diagnostic value is in separating two failures that look identical from the outside. A publication with capture units on every template, a healthy signup rate and a broken alignment record has a loop that leaks at delivery. A publication with perfect authentication and no capture unit has a loop that leaks at capture. Both score badly. They need entirely different fixes, and a teardown that reports one number without saying which is not useful to the subject.
Platform choice affects how much of this you have to do yourself. That comparison is in email platforms ranked by what they cost the distribution loop.
Questions
Do these rules apply if my list is only 500 people?
The all-senders tier applies at any volume, so SPF or DKIM, reverse DNS, TLS and the spam rate limit all apply to you. Only the additional bulk obligations are tied to volume, and the classification is easier to trip than the headline number suggests.
Is p=none enough?
It satisfies the stated requirement. It also provides no protection against someone spoofing your domain, because you have told receivers to deliver failures anyway. Publishing p=none with an rua= address, reading the reports for a few weeks, then moving to quarantine is the conventional path.
My platform says authentication is configured. Am I done?
Not necessarily. Most platforms report that SPF and DKIM are set up without telling you whether either aligns with your From domain. Read the headers of a real send and compare the d= domain to the From domain yourself.
Does any of this help open rates?
Not directly, and it is a precondition for them. A message that is rejected has no open rate at all, and a message routed to spam has a much worse one. Authentication does not make people read; it makes reading possible.
Sources
- Google Workspace Admin Help, Email sender guidelines
- Google Workspace Admin Help, Email sender guidelines FAQ
- RFC 7489, Domain-based Message Authentication, Reporting and Conformance
- RFC 8058, Signalling One-Click Functionality for List Email Headers
Requirements verified August 2026. Google has revised these rules before and has signalled that alignment expectations may tighten further, so this page records the state of the rules on the date given. Every teardown records the version it was scored against.