For most of email’s history, the rules for getting mail delivered were informal. Large receivers published guidelines, and senders who ignored them found their delivery rates quietly degrading with no explanation. Nothing was mandatory.
That changed in February 2024, when Gmail and Yahoo simultaneously introduced published, enforceable requirements for bulk senders. Microsoft followed with its own requirements for Outlook consumer mailboxes in 2025. The informal era is over.
This article covers what the requirements actually are at a technical level, how to verify you meet each one, and what "bulk sender" means in practice — because the threshold catches more organisations than most people expect.
Who counts as a bulk sender
Gmail’s threshold is 5,000 messages or more to Gmail addresses in a single day, measured per sending domain. Once you cross it, the requirements apply permanently — Google does not un-designate you afterwards.
Two things about that number surprise people.
It counts recipients, not campaigns. A single newsletter to 5,200 subscribers, of whom 5,100 are on Gmail, crosses the line on its own.
It counts all mail from the domain, including transactional. Order confirmations, password resets, appointment reminders and invoice notifications all count. A mid-sized e-commerce site with no marketing list at all can be a bulk sender purely on transactional volume.
Below the threshold, a reduced set of requirements applies: you still need SPF or DKIM, valid forward and reverse DNS, and a low spam complaint rate. The authentication baseline is not optional for anyone any more.
Requirement one: authenticate with SPF and DKIM
Below the threshold, one of the two is enough. Above it, you need both.
SPF is a TXT record listing the IP addresses authorised to send for the envelope sender domain:
example.com. IN TXT "v=spf1 ip4:203.0.113.10 include:_spf.google.com -all"
DKIM is a public key published under a selector, with the corresponding private key held by the sending server:
selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0B..."
Use a 2048-bit RSA key. 1024-bit keys still validate but are increasingly treated as a weak signal, and there is no good reason to keep one.
To verify both are working end to end, send a message to an address you control at a Gmail account and inspect the headers. In the Gmail interface, open the message, choose "Show original", and look at the summary block at the top. You want SPF: PASS, DKIM: 'PASS' with domain example.com and DMARC: 'PASS'. If any shows a domain you do not recognise, your mail is being sent by a service you have forgotten about.
Requirement two: a DMARC record
The minimum policy is p=none:
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
That is genuinely the minimum. p=none enforces nothing — it exists so the receiver can see you have published a policy at all, and so you get aggregate reports.
Publishing p=none and stopping there is the single most common half-measure in this whole area. It satisfies the letter of the requirement and provides no protection against anyone spoofing your domain. Treat it as the starting position of a rollout towards p=quarantine and then p=reject, driven by what the aggregate reports tell you.
Requirement three: alignment
This is the requirement that catches the most senders out, because it is invisible until you look for it.
DMARC does not merely check that SPF and DKIM pass. It checks that the domain they passed for matches the domain in the visible From: header. That is alignment.
The classic failure looks like this. You send through a marketing platform. The platform’s own SPF record covers the envelope sender, which is something like bounces@mail.platform.com. SPF passes — for platform.com. Your From: header says hello@example.com. The domains do not match, so SPF does not contribute to DMARC. If DKIM is also signing as platform.com rather than as example.com, DMARC fails outright despite both underlying checks passing.
The fix is the same at every provider, even though they call it different things: configure a custom sending domain, or a "branded" or "authenticated" domain, so that both the envelope sender and the DKIM d= value sit under a subdomain of your own domain — typically something like mail.example.com.
Relaxed alignment (adkim=r, aspf=r, which are the defaults) means a subdomain aligns with the organisational domain. So mail.example.com aligns with example.com. Strict alignment (s) requires an exact match.
Requirement four: one-click unsubscribe
For subscribed marketing mail, messages must include one-click unsubscribe headers as defined in RFC 8058, and the resulting request must be honoured within two days.
That means two headers, both present:
List-Unsubscribe: <https://example.com/unsub?id=abc123>, <mailto:unsub@example.com?subject=abc123>
List-Unsubscribe-Post: List-Unsubscribe=One-Click
The mechanism is precise about what happens next. When the recipient clicks the unsubscribe control in their mail client, the client sends an HTTP POST to the URL, with a body of List-Unsubscribe=One-Click. It is not a GET. Your endpoint must accept POST, must not require the user to be logged in, and must not present a confirmation page — the whole point is that no further interaction happens.
An endpoint that only handles GET is the most common implementation bug here. It looks correct when you click the link in a browser and fails silently for every real unsubscribe.
Transactional mail — receipts, password resets, delivery notifications — is exempt. If you are sending both from the same domain, this is a good reason to separate them onto different subdomains, so that your marketing subdomain’s reputation and your transactional subdomain’s reputation are tracked separately.
Requirement five: spam complaint rate below 0.3%
Gmail asks senders to keep the reported spam rate below 0.3%, and recommends staying under 0.1%. This is measured in Google Postmaster Tools, which is the only place you can see it.
If you send bulk mail and have not registered your domain in Postmaster Tools, do that first — before anything else in this article. You cannot manage a number you cannot see, and Postmaster Tools is also where you will see your domain and IP reputation, authentication pass rates, and encryption rates.
Registration requires proving domain ownership via a DNS TXT record, and data only appears once you are sending meaningful volume to Gmail. Historical data is not backfilled, so registering early matters.
The 0.3% figure sounds generous until you convert it. On a 50,000-recipient send, 150 complaints breaches it. Complaint rates of that order come from list quality problems — purchased lists, addresses collected without clear consent, or lists that have not been mailed in a year — far more often than from content.
Requirement six: forward and reverse DNS
Your sending IP must have a PTR record, and that PTR record must resolve forward to the same IP.
# Reverse: IP to name
dig +short -x 203.0.113.10
# mail.example.com.
# Forward: name back to IP
dig +short A mail.example.com
# 203.0.113.10
The two must agree. A missing PTR, or a PTR pointing at a generic hostname from your provider’s pool, is a strong negative signal — and one of the most common reasons that mail from a self-managed VPS lands in spam.
You cannot set a PTR record yourself. It is delegated to whoever controls the IP block, which means your hosting provider. Any provider offering mail-capable IP addresses should let you set it; if yours will not, that IP is not suitable for sending.
The HELO or EHLO name your server announces should also be a fully qualified hostname that resolves, and ideally should match the PTR.
Requirement seven: TLS in transmission
Connections must use TLS. In practice, every mainstream MTA does this already via opportunistic STARTTLS, so this requirement is rarely the thing that trips a sender up. It is worth confirming rather than assuming:
openssl s_client -starttls smtp -connect gmail-smtp-in.l.google.com:25 -crlf
If the handshake completes and you see a certificate chain, outbound TLS is working from that host.
A verification checklist
Run through this against a real message rather than against your configuration notes:
- Send a test message to a Gmail address you control. Open "Show original". Confirm SPF, DKIM and DMARC all show PASS, and that DKIM’s domain is yours.
dig +short TXT _dmarc.example.com— confirm a record exists and note the policy.dig +short -x <your sending IP>and the forward lookup on the result — confirm they match.- View the raw source of a marketing message and confirm both
List-UnsubscribeandList-Unsubscribe-Postheaders are present. - POST to your unsubscribe URL with
curl -X POST -d 'List-Unsubscribe=One-Click' <url>and confirm it returns a success status and actually unsubscribes. - Log into Postmaster Tools and check the spam rate over the last 30 days.
Any of these failing is a delivery problem you have right now, whether or not you have noticed it yet.
FXRM configures SPF, DKIM, DMARC and PTR correctly on every domain we host, on IP space we control and monitor. See our email hosting → or talk to us about a deliverability review →.
