Resend recently highlighted Gmail’s requirements for bulk senders delivering more than 5,000 messages a day to Gmail accounts. The threshold makes a good headline. The actual work begins underneath it: domain authentication, alignment, transport security, unsubscribe processing and complaint monitoring all have to agree.
This is why sender compliance is better treated as an operating system than a DNS checklist.
Authentication has to describe the real mail path
Google’s current guidelines require bulk senders to authenticate mail with SPF and DKIM, publish DMARC, use TLS, maintain valid forward and reverse DNS and format messages according to Internet standards. Marketing and subscribed messages also need one-click unsubscribe, plus a clearly visible way to unsubscribe in the message.
SPF answers which servers may send for a domain. DKIM signs the message so the receiving service can verify the signing domain and detect modification. DMARC connects that authentication to the domain visible in the From header and defines a policy for failures.
The records are simple only when the sending architecture is simple. A company may use a transactional provider, a marketing platform, a support desk and an older internal system. Adding each service blindly can exceed SPF lookup limits or leave a forgotten source unauthenticated. Inventory comes before configuration.
One-click unsubscribe is a backend feature
Placing a footer link in an email is not the same as supporting one-click unsubscribe. Gmail expects the standardized list-unsubscribe mechanism for applicable messages, with the request handled promptly. That requires an endpoint able to identify the subscription safely, record the suppression and return success without asking the recipient to log in.
The token in such a URL should be signed, scoped and expire according to a documented policy. The handler should be idempotent: mail scanners and people may open it more than once. It must not expose the address in logs or let an attacker unsubscribe arbitrary users by editing a query string.
Suppression also needs to propagate. If the marketing database marks someone unsubscribed but a weekly job reads an old export, the protocol worked and the product still failed.
Reputation is an ongoing signal
Google asks senders to keep user-reported spam below 0.3%. That figure is a ceiling, not a target. Complaint rate, bounces, delivery delay and authentication failures should be watched by message stream and domain. Transactional receipts should not share every reputation decision with a poorly maintained promotional list.
Crossing 5,000 messages is not the moment to start this work. Google classifies senders based on observed volume, and the operational habits are useful at much smaller scale. Nor is sending 4,999 messages a strategy: requirements and filtering are intended to protect recipients, and inbox placement is never guaranteed by technical compliance alone.
Build a release check for email
An email change deserves the same discipline as an application release. Before increasing volume:
- verify SPF, DKIM and DMARC alignment using real delivered headers;
- test TLS and DNS for every sending service;
- send one-click unsubscribe requests and confirm suppression is immediate and idempotent;
- inspect plain-text and HTML versions in representative clients;
- monitor Gmail Postmaster data and provider events without storing unnecessary personal data;
- separate staging tests from production recipients.
Provider dashboards help, but the receiving mailbox is the final integration test. A green configuration screen cannot show that a forwarded domain broke alignment or that a queue ignored the suppression table.
Gmail’s rules are not a one-time obstacle placed at a traffic threshold. They describe the minimum shape of a mail system that knows who sent a message, why it was sent and how to stop. The teams that encode those answers into everyday operations are less likely to discover them during a deliverability incident.