Google Workspace email deliverability

Reputation problems are downstream of authentication problems in the majority of tenants we look at. If SPF returns permerror, receiving systems treat the domain as having no policy, DMARC alignment fails for any sender not covered by DKIM, and every marginal message gets scored against you. No amount of warm-up fixes that.

The first hour is spent counting lookups, checking key length in the admin console, and reading the last fortnight of DMARC aggregate reports to see who is actually sending. It is common to find two or three senders nobody in the room can identify, which is a security finding as much as a deliverability one.

Sending over five thousand messages a day to Gmail addresses puts a domain into the bulk sender rules, which require authentication, one-click unsubscribe headers on marketing mail, and a spam complaint rate kept under the published threshold. Organisations get caught by this not through marketing but through automated notifications: booking confirmations, invoices, portal alerts.

Where transactional mail crosses that threshold, we usually split it onto a dedicated subdomain with its own DKIM selector and its own reputation. The commercial domain then stops carrying the risk of a badly behaved application, and a bad week for the notification system no longer affects whether the sales team's mail arrives.

Once reputation is low, configuration fixes take effect immediately but the score recovers on a lag of two to four weeks of clean sending. During that period volume should be held steady rather than paused, because a domain that stops and restarts looks more like a compromised account than one that sends consistently.

We track recovery in the postmaster tools dashboard and in aggregate report pass rates, and we hold weekly checkpoints. If the trend has not moved after three weeks, the cause is almost always a sender still failing alignment that nobody has attributed yet.

A dated record of every DNS change made, a sender inventory naming each system authorised to send as the domain, the DMARC policy state with the date it was tightened, and a monitoring arrangement so that the next unattributed sender is noticed within days rather than after a campaign fails.

The sender inventory is the artefact with the longest life. Most deliverability regressions are caused by a new tool being adopted by one department without anyone updating DNS, and an inventory with an owner per sender is what makes that a five-minute change rather than an outage.