Gmail Bulk Sender Rules For Self-Hosted Newsletters

Will your next self-hosted campaign quietly land in spam because of one DNS record you never got around to publishing?

That question used to be rhetorical. Authentication was a nice-to-have, the sort of thing you configured on a slow Sunday after the mail queue was already flowing. Between October 2023 and February 2024, major inbox providers finished converting those recommendations into hard infrastructure requirements, and the grace period closed behind them.

The explicit bulk sender rules trigger at 5,000 or more messages per day to a single provider. If you run a modest community newsletter from a VPS, you may never cross that line. That does not put you outside the blast radius. Reputation algorithms apply their strictest scrutiny to exactly the kind of address space self-hosters occupy: small, low-volume, previously unseen IPs with no sending history to lean on. A fresh droplet with a clean PTR record still starts life as an unknown quantity, and an unknown quantity that fails authentication gets treated as hostile.

So the practical scope is wider than the headline number suggests. The 5,000-message threshold defines who gets audited formally. Everyone else gets audited informally, by the same filters, with less margin for error.

Three things determine whether your mail survives that audit: cryptographic authentication that aligns, an unsubscribe mechanism that works at the protocol level, and a complaint rate you can actually see. The rest of this guide walks each one.

SPF Alone Stopped Being Enough: Getting DMARC Alignment Right

Start with the architecture, because the failure mode here is subtle. SPF validates the envelope sender against your DNS. DKIM signs the message body and selected headers with a private key, letting the receiver verify the signature against a public key in your DNS. DMARC sits on top and asks a different question entirely: does the domain the human sees in the From header match the domain that passed SPF or the domain in the DKIM signature?

That matching step is alignment, and it is where most self-hosted setups come apart. You can hold a perfectly valid SPF record and still fail DMARC, because your relay rewrites the envelope sender to its own domain while your From header still says [email protected]. SPF passes. Alignment fails. The message gets evaluated as unauthenticated.

The Implementation Detail That Saves You

DKIM is the more forgiving of the two paths, because the signature travels with the message regardless of how many hops rewrite the envelope. Sign with the d= value set to your organizational domain, publish the selector record, and alignment holds end to end. Generate keys at 1024-bit cryptographic strength or higher; anything weaker fails modern validation outright, and 2048-bit is the sensible default on any hardware built this decade.

Your DMARC record needs at minimum a p=none directive in the TXT entry at _dmarc.yourdomain.tld. That satisfies the published requirement. It does not mean the receiving MTA stops paying attention. Alignment results feed domain reputation whether your policy is permissive or strict, so p=none buys you a compliance checkbox and a stream of aggregate reports, not immunity. Treat it as the observation phase before you tighten to quarantine.

DKIM Key Strength Check

Before you launch anything, verify the actual bit length of the key your MTA is signing with, not the one in your notes. Legacy OpenDKIM configurations carried over from older servers sometimes still hold 512-bit keys that silently fail every validation attempt. The boundary is 1024-bit; below it, the signature is treated as absent.

Google's own documentation is the authoritative reference for which combinations satisfy the bulk sender tier, and it is worth reading in full rather than second-hand: Google's official Email Sender Guidelines.

Injecting List-Unsubscribe Headers That Actually Pass

A blue "unsubscribe" link at the bottom of your template does not satisfy the requirement. Neither does a bare mailto: header on its own. The compliance check happens at the protocol layer, before the recipient ever renders your HTML.

RFC 8058 defines the mechanism. Two headers must appear in the payload together:

List-Unsubscribe containing an HTTPS URL, optionally alongside a mailto address
List-Unsubscribe-Post carrying the exact value List-Unsubscribe=One-Click

When both are present, the provider renders a native unsubscribe control in its own interface and issues an HTTP POST to your URL when the user clicks it. Your endpoint must accept that POST and process the removal without requiring a confirmation page, a login, or a second click. A handler that returns a "are you sure?" form fails the spirit and, increasingly, the letter of the check.

What This Means for Sendy, Mailtrain, and SES Scripts

Sendy and Mailtrain both inject these headers in current releases, which makes the real risk a stale installation sitting three versions behind on a box nobody has touched since 2022. Check the raw source of a test send; the headers are either there or they are not.

Custom Python scripts talking to AWS SES are the common gap. SES will happily relay whatever you hand it, so if your email.message.EmailMessage object never sets those headers, nothing downstream adds them for you. Add them explicitly before you call the send API, and generate a per-subscriber token in the URL so the POST handler knows who to remove.

Pre-Launch Testing Window

Budget 48 to 72 hours between finishing your configuration and launching a campaign. DNS propagation for new DKIM selectors and DMARC records is unpredictable, and you want a full round of header testing against a real Gmail account before thousands of messages commit your domain to a reputation score.

One useful exemption: the header injection mandate covers commercial and bulk mailing lists. Transactional messages such as password resets, purchase receipts, and account alerts sit outside it. Do not bolt a one-click unsubscribe onto your password reset flow.

Keeping Complaints Below 0.1% Over a Rolling Month

The spam complaint ceiling is roughly 0.3%. That is the absolute limit, enforced by major providers, and crossing it triggers filtering consequences you cannot argue your way out of. The number you should actually operate against is approximately 0.1%, measured over any rolling 30-day period, because the ceiling leaves no headroom for a single bad campaign.

The mechanics are blunt. A recipient hits "Report spam" and that action attaches to both the sending IP and the authenticated domain. Deletion without opening does not count. Ignoring the message does not count. The complaint button does, and it compounds: each one adjusts the classifier's confidence for every subsequent message from the same pair.

Drawing on a pass through several homelab mail configurations, the pattern that pushes small senders past about 0.1% is almost never malice. It is a dormant list, imported from an old system, mailed for the first time in a year to people who no longer recognize the sender name.

Google Postmaster Tools is the only direct window into how Gmail categorizes your domain. Register your sending domain, verify it with a DNS record, and watch the spam rate, domain reputation, and authentication dashboards. Worth knowing its limits: the data covers Gmail traffic only, reports lag by roughly a day, and low-volume senders often see sparse or suppressed charts, so it tells you about one receiver rather than the whole internet.

Complaint Math

At a 10,000-subscriber list, around 0.1% is ten complaints. Ten. That is the entire operational budget for a send, which is why list hygiene matters more than subject-line cleverness.

The Standing Audit for Custom Mail Infrastructure

Pull the whole thing into a checklist you run on a schedule rather than once at setup:

Verify SPF, DKIM, and DMARC records resolve correctly, with DKIM keys at 1024-bit or above and a From header that aligns with the signing domain.
Confirm your newsletter software injects both RFC 8058 headers and that the POST endpoint removes subscribers without a confirmation step.
Keep Postmaster Tools registered and check the spam rate after every campaign, not just when something breaks.

Self-hosted mail rewards attention and punishes neglect. Keys rotate, software versions drift, DNS gets edited during an unrelated migration, and any one of those changes can quietly break alignment on a Tuesday afternoon with no error message to tell you.

And this is already live. Enforcement commenced in February 2024, which means non-compliant infrastructure is not being warned or throttled or queued for later review. It is being dropped at delivery, right now, message by message.