Bulk Email Verification: How to Stop Bounces Killing Your Sender Reputation
The rules changed, and most senders have not noticed
Since 1 February 2024, anyone sending more than 5,000 messages a day to Gmail accounts must meet Google's bulk sender requirements: SPF and DKIM authentication, a DMARC record, one-click unsubscribe on marketing mail, and spam complaint rates reported in Postmaster Tools kept below 0.3% — with below 0.10% recommended as a safer operating level. Yahoo introduced closely aligned requirements at the same time.
Those thresholds are unforgiving. A 0.3% complaint rate is three complaints per thousand delivered messages. Bounces are treated separately but compound the same problem: a list full of dead addresses signals to mailbox providers that you are not managing consent, and reputation damage affects everything you send — including the transactional mail your product depends on.
- 5,000daily messages triggers bulk sender rules
- 0.3%spam complaint ceiling
- 0.10%recommended operating level
- SPF+DKIM
+DMARCrequired for bulk senders
Key takeaways
- Verify before you send, not after you bounce. A hard bounce has already cost you reputation by the time you see it.
- A verifier returns three useful answers, not two: valid, invalid, and genuinely unknown. Treating unknown as invalid throws away real customers.
- Catch-all domains cannot be verified by SMTP — they accept everything. Any tool claiming certainty on those is guessing.
- Authentication is table stakes. Verification without SPF, DKIM and DMARC solves half the problem.
- Re-verify before every large send. Lists decay continuously as people change jobs.
How verification actually works
1. Syntax
Does the address conform to the format defined in RFC 5321? This catches typing errors, stray spaces and impossible characters. It is free, instant and should happen at the point of capture in your signup form, not weeks later in a batch.
2. Domain and MX records
Does the domain exist, and does it publish mail exchanger records? A domain with no MX record cannot receive email at all, so every address on it is dead regardless of the local part. This is also where common domain typos are caught — gmial.com and similar.
3. Risk flags
Is it a disposable address from a throwaway provider? A role account such as info@ or sales@, which tends to attract complaints and is often read by several people? Does it match known spam-trap patterns? These are not automatically invalid, but they belong in a different bucket with a different sending decision.
4. SMTP probe
The verifier opens a conversation with the receiving mail server and asks whether the mailbox exists, without delivering a message. This is the only check that speaks to the actual mailbox — and it is the one that most often returns an ambiguous answer.
What a verifier cannot tell you
Any honest tool has limits, and knowing them protects you from both bad lists and bad vendors.
| Situation | Why it is unknowable | Sensible handling |
|---|---|---|
| Catch-all domain | Server accepts every address, real or not | Mark unknown; send only to engaged contacts |
| Greylisting | Server defers unfamiliar senders by design | Retry later; never mark invalid on one attempt |
| Anti-harvest protection | Provider deliberately returns uniform answers | Mark unknown; rely on engagement signals |
| Full mailbox | Exists but cannot receive today | Soft bounce; retry, then suppress after repeats |
| Active but abandoned | Accepts mail, nobody reads it | Verification cannot help; use engagement data |
Be suspicious of any verifier reporting 99%+ certainty on a list with many corporate domains. Large organisations commonly run catch-all or anti-harvesting configurations, so a genuinely accurate tool will report a meaningful share as unknown. A tool with no unknown category is not more accurate — it is guessing and calling it a result.
Hard, soft and the ones that matter
- Hard bounce — permanent failure: the mailbox does not exist. Suppress immediately and never retry. These are what verification exists to prevent.
- Soft bounce — temporary: mailbox full, server down, message too large. Retry a few times, then suppress if it persists.
- Block — the receiving server rejected you specifically, on reputation or content grounds. This is the serious one, and it means stop sending and investigate rather than retry.
Watch the trend, not the single send. A bounce rate that climbs across consecutive campaigns usually means an ageing list or a broken import, and it is a leading indicator of the reputation damage that follows.
Cleaning a list without destroying it
The instinct after a bad send is to delete everything doubtful. That is expensive: unknown is not invalid, and corporate addresses — often your best customers — are the most likely to be unverifiable.
- Segment by verdict: valid, invalid, unknown, risky.
- Suppress invalid permanently. Do not re-import them next quarter.
- Send to valid first and let reputation stabilise.
- Approach unknown in small batches from a separate subdomain or IP, watching bounce and complaint rates closely.
- Use engagement to resolve the rest. An unknown address that opened twice is a real person; one silent for a year is not worth the risk.
- Re-verify before every large send. People change jobs constantly and lists decay whether or not you touch them.
Authentication: SPF, DKIM, DMARC
Verification manages your recipients. Authentication proves who you are, and Google now requires both from bulk senders.
| Record | What it asserts | Common failure |
|---|---|---|
| SPF | These servers may send for this domain | Too many DNS lookups; exceeding the limit invalidates it |
| DKIM | This message was signed by the domain and not altered | Key rotated in the platform, DNS never updated |
| DMARC | What to do when SPF and DKIM disagree, and where to report | Left at p=none indefinitely, so it does nothing |
Start DMARC at p=none with reporting on, read the reports for a few weeks to find legitimate senders you forgot about — the invoicing tool, the CRM, the helpdesk — then move to quarantine and finally reject. Publishing reject before you know your own senders will bounce your own mail.
Warming up and keeping reputation
- Ramp gradually. A new domain or IP sending thousands on day one looks exactly like a spammer, because that is what spammers do.
- Separate your streams. Transactional and marketing mail on different subdomains so a bad campaign cannot take down password resets.
- Make unsubscribing trivial. One-click unsubscribe is required for bulk senders, and a complaint is far more damaging than an unsubscribe.
- Monitor Postmaster Tools rather than guessing. It reports your spam rate against the threshold you are actually judged on.
- Send consistently. Long silences followed by a large blast are a classic reputation trigger.
Frequently asked questions
What is an acceptable bounce rate?
Aim to keep hard bounces well under 2%, and treat anything above that as a list-quality problem rather than a sending problem. The number worth watching more closely is the spam complaint rate, because Google's published threshold for bulk senders is 0.3% with 0.10% recommended — and complaints damage reputation faster than bounces. Track both as trends across campaigns rather than judging a single send.
Can email verification guarantee delivery?
No, and any vendor implying otherwise is overselling. Verification removes addresses that would hard bounce, which protects reputation; it cannot make a mailbox provider accept your mail. Delivery also depends on authentication, sending history, content, complaint rates and engagement. Verification is necessary and not sufficient — it is the cheapest of the controls, which is why it is the sensible first one.
How often should we re-verify a list?
Before every significant campaign, and at minimum quarterly for any list you mail regularly. Contact data decays continuously as people change jobs, and a list verified six months ago is materially less accurate today. For continuously growing lists, verify at the point of capture as well, which catches typos while the person is still on the form and able to correct them.
Are role addresses like info@ safe to email?
They are valid but higher risk. Role accounts are often read by several people or nobody, and they attract complaints at a higher rate because the recipient rarely feels they personally subscribed. For transactional mail they are fine. For marketing, segment them separately, watch their complaint rate independently, and be quick to suppress — one shared inbox marking you as spam carries the same weight as any other complaint.
What is a catch-all domain and why does it matter?
A catch-all domain is configured to accept mail for any address at that domain, whether or not the mailbox exists. That makes SMTP verification meaningless there: the server says yes to everything, including addresses that will silently discard your message. Many corporate domains are configured this way, which is why an honest verifier marks them unknown rather than valid. Handle them with engagement data and small test batches instead.
Sources
- Google, Email sender guidelines — bulk sender requirements effective 1 February 2024, including the 5,000 message threshold, 0.3% spam rate limit and SPF/DKIM/DMARC requirements.
- Yahoo, Sender best practices — Yahoo's aligned requirements for bulk senders.
- IETF, RFC 5321 — Simple Mail Transfer Protocol — the specification defining address syntax and SMTP responses.
Keep reading
All articles →
Consolidating Your SaaS: When Less is More
Consolidating Your SaaS: When Less is More Modern businesses didn’t set out to build a “tool sprawl”—it happened one well-intentioned subscription at a time. A...
Feb 27, 2026 · 12 min read
Document Management SaaS Solutions
Why Document Chaos Is Costing Businesses More Than They Realize Invoices scattered across inboxes, contracts saved as “final_final_v7,” compliance files living...
Mar 28, 2026 · 11 min read
E-commerce SaaS Platforms: Beyond Shopify
E-commerce SaaS Platforms: Beyond Shopify—Why Growing Brands Are Looking Elsewhere Shopify is often the first name that comes up when a business thinks “online...
Mar 30, 2026 · 13 min read