Author: Shoaibdethoadmin

Sender reputation is the score mailbox providers assign to your sending identity, and it decides whether your mail reaches the inbox, the spam folder, or nothing at all. There is no dashboard where you can read it. It is inferred from how recipients behave, and it is the accumulated result of every send you have made.

What is actually being scored

Reputation attaches to several things at once, and they do not move together.

• Domain reputation – tied to your sending domain and the domain in your From: header. This is the durable one. It follows you between ESPs and it is the hardest to repair.
• IP reputation – tied to the sending IP. On a shared IP you inherit the behaviour of every other sender on it. On a dedicated IP the score is entirely yours, which cuts both ways.
• Subdomain reputation – a subdomain carries its own reputation, which is why sending marketing from mail.yourbrand.com and transactional mail from notify.yourbrand.com keeps a campaign problem from taking down your password resets.

The signals that move it

Complaint rate – the heaviest weight

When a recipient clicks “report spam”, that is the most direct statement available about whether your mail is wanted. Google requires bulk senders to keep spam rates below 0.1% and to never reach 0.3%. Cross 0.3% and you become ineligible for mitigation support until you have held below it for seven consecutive days.

Bounce rate – the consent proxy

Repeatedly attempting delivery to addresses that do not exist tells a provider you are mailing a list you did not build or do not maintain. The industry convention is to stay under 2%, and healthy senders sit under 1%.

Engagement – the positive signal

Opens, clicks, replies, moves out of the spam folder, additions to the address book. Providers weight recent engagement heavily. A list of 5,000 people who read your mail outperforms 50,000 who ignore it, both in revenue and in reputation.

Spam trap hits – the hardest hit

Trap hits carry disproportionate weight because there is no innocent explanation for them. A single pristine trap hit can trigger a blocklist listing.

Authentication and consistency

Correct SPF, DKIM and DMARC are table stakes. Beyond that, providers reward predictability: consistent volume, consistent cadence, consistent sending infrastructure. A domain that sends 2,000 messages a week for a year and then suddenly sends 200,000 looks compromised, regardless of intent.

The diagnostic that tells you where you stand

You cannot read your score, but you can read its effects. Three patterns, three different causes:

• Opens falling, bounces flat – you are being filtered, not bouncing. Reputation problem. Look at complaints and traps.
• Bounces rising, opens flat – list decay. Clean it.
• Delivery fine at some providers, terrible at one – a provider-specific reputation issue or a blocklist. Check the rejection strings and the public blocklists for your domain and IP.

Seed testing – sending to accounts you control at each major provider and checking placement – gives you visibility that your ESP’s delivery statistics do not. “Delivered” in a dashboard means accepted by the server, not placed in the inbox.

Repairing a damaged reputation

Repair is slower than damage and follows a fixed sequence.

1. Stop the bleeding. Pause sends to anything unengaged. Continuing to mail a bad list while trying to recover does not work.
2. Clean thoroughly. Verify everything, remove invalid addresses, segment catch-alls, delete disposable and role addresses, and purge any segment from a source you cannot document.
3. Fix authentication. Confirm all three records pass and that your From: domain aligns.
4. Rebuild on your best audience. Send only to people who have engaged in the last 30-90 days. This is the group most likely to open, and opens are what rebuilds the score.
5. Ramp volume gradually. Increase over weeks, not days, holding cadence steady.
6. Widen slowly. Bring back progressively less-engaged segments only while complaint and bounce rates stay flat. If either moves, stop and narrow again.

Expect weeks, not days. Domain reputation in particular is deliberately slow to recover, because the alternative would let spammers reset by behaving well for an afternoon.

The part nobody can shortcut

There is no service that repairs sender reputation directly. Warm-up tools, seed lists and consultants can help you measure and pace the recovery, but the score moves only when real recipients at real addresses engage with your mail.

Which is why hygiene is the foundation rather than a maintenance chore. Cleaning the list removes the addresses that generate the negative signals and concentrates your sending on the people generating the positive ones.

Ready to see what is actually in your list? EmailListClean verifies up to 10,000 addresses a minute at 99.2% accuracy, from $100 for 250,000 emails. Start with 100 free credits or see volume pricing.

Two categories of technically valid email address do more damage than dead ones: disposable addresses, which expire within hours, and role addresses, which reach a shared inbox rather than a person. Neither will bounce. Both will quietly degrade every metric mailbox providers use to judge you.

Disposable addresses

Disposable or temporary email services hand out a working mailbox for a few minutes to a few days. Someone wants your lead magnet without giving you a real address, so they grab one, download the file, and never open the mailbox again.

The address is real at the moment of signup, so a basic syntax or MX check passes it. Then the service recycles it, and one of two things happens:

• The address stops existing, and your next send to it hard-bounces.
• The service keeps accepting mail indefinitely into a void, so you pay to send to nobody forever and your engagement rate falls.

Some disposable domains are also operated as, or eventually become, spam traps. The upside of keeping these addresses is zero – the person behind one has explicitly signalled they do not want a relationship.

Handling them

Block at the form. Real-time verification at signup identifies disposable domains and rejects the submission before it becomes a record. This is far better than cleaning them out later, because the lead magnet has already been delivered by then.

For addresses already in your list: remove them. There is no segmentation argument here. Nobody’s disposable address becomes valuable later.

One operational note – the list of disposable domains changes constantly. Services appear weekly. Detection has to be maintained continuously; a static blocklist you downloaded last year is close to useless.

Role-based addresses

Role addresses are function-based rather than personal: info@, sales@, support@, admin@, contact@, hello@, billing@, webmaster@, abuse@.

These are usually real, actively monitored mailboxes. The problem is not existence – it is consent and complaint behaviour.

• No individual consented. Whoever submitted info@company.com to your form cannot grant permission on behalf of everyone who reads that inbox.
• Multiple readers, unpredictable reactions. Five people see your message. Any one of them can mark it as spam, and that complaint counts against you exactly the same as one from a personal address.
• Some are monitored specifically for abuse reporting. abuse@ and postmaster@ exist to receive complaints about senders. Mailing them with marketing is a category error, and it is noticed.

Role addresses generate spam complaints at a materially higher rate than personal addresses. Given that Google requires bulk senders to hold complaint rates under 0.1% – and never touch 0.3% – a role-heavy list is a structural risk, not a rounding error.

Handling them

Unlike disposables, role addresses call for judgement rather than deletion.

• Marketing and newsletters: exclude them. The complaint risk outweighs the reach.
• Transactional and account mail: keep them. billing@ is exactly where an invoice should go.
• B2B outbound where the role address is the only route in: segment separately, send low volume from a distinct sending identity, and monitor complaints closely.
• Always: hard-exclude abuse@, postmaster@, spam@ and noreply@ from every marketing send.

Stopping both at the source

Form-level defences cost almost nothing and prevent nearly all of this:

1. Real-time verification on every signup form, rejecting disposable domains outright.
2. A soft warning on role addresses – “we recommend a personal work address so you do not miss anything” – which converts a meaningful share of them into usable contacts.
3. Double opt-in on public forms, which disposable users almost never complete.
4. Typo correction at the point of entry, so a mistyped real address is recovered rather than lost.

Then run a periodic pass over what you already have. On a list that has never been screened, disposable and role addresses together commonly account for a few percent of records and a disproportionate share of complaints.

For the full cleanup sequence, see how to clean an email list.

Ready to see what is actually in your list? EmailListClean verifies up to 10,000 addresses a minute at 99.2% accuracy, from $100 for 250,000 emails. Start with 100 free credits or see volume pricing.

A catch-all domain is configured to accept mail for every address at that domain, whether or not the mailbox exists. Send to anything@example.com and the server says yes. That behaviour makes catch-alls the single hardest category in email verification, and the reason your results file has a column you were not expecting.

Why organisations run catch-alls

The setup is deliberate and often sensible:

• Nobody wants to lose a message because a customer typed jon instead of john.
• Mail for departing employees keeps flowing to a successor rather than vanishing.
• Teams use ad-hoc aliases for vendors, forms and tracking without provisioning a mailbox for each.
• Legacy addresses from an old naming convention still need to work.

Catch-alls are common on small business domains, professional services firms, and any organisation running its own mail server rather than a large hosted platform.

Why verification cannot resolve them

An SMTP mailbox check works by asking the receiving server whether a specific address exists. On a catch-all domain, the answer is always yes – for real mailboxes and for addresses that were never created. The check is not failing; the server is simply not disclosing the information.

So a verifier returns accept-all or risky rather than valid or invalid. That is the honest answer. Any service that reports every catch-all address as “valid” is passing your risk back to you with a confident label on it.

What it costs you to guess wrong

Catch-all addresses fall into three groups you cannot tell apart from the outside:

• Real mailboxes – a person reads them. These are often your best B2B contacts.
• Non-existent addresses that get silently discarded – the server accepts the message, then drops it. No bounce, no delivery, no engagement. You pay to send into a void and your engagement rate quietly falls.
• Non-existent addresses that get routed to a monitored inbox – the worst case. Someone reads mail sent to an address that was never real, and marks it as spam.

That third group is why catch-alls are a reputation problem rather than just a wasted send. The complaint rate from a poorly handled catch-all segment can be several times your normal rate, and complaints are graded far more harshly than bounces.

How to handle them

Segment, always

Never fold catch-all addresses into your main send. Put them in their own segment so their bounce and complaint behaviour is measurable separately. If you mix them in, you will not be able to tell which half of your list caused a problem.

Judge by engagement history, not by the verifier

Your own data is better than any external check here. A catch-all address that has opened three of your last ten emails is real and valuable – keep it. A catch-all address acquired eighteen months ago that has never engaged is probably a typo or a departed employee. The verifier cannot make that call; you can.

Send in controlled volumes

If you have no engagement history – a fresh B2B list, for instance – send to the catch-all segment in small batches from a sending identity that is not carrying your main campaigns. Watch complaint rate and engagement. Promote the addresses that engage; suppress the ones that stay silent after two or three attempts.

Apply extra scrutiny to high-value names

For a small number of important prospects, a catch-all result is worth resolving manually – check the pattern against other known addresses at the company, or confirm through a different channel. For a list of 40,000, that is not practical, which is what the segmentation strategy is for.

Rules of thumb

• Catch-all with recent engagement – keep and mail normally.
• Catch-all, no engagement, older than 12 months – suppress.
• Catch-all with no history at all – test in small batches, then promote or suppress on the evidence.
• Catch-all that is also a role address – treat with extra caution; complaint risk is higher again.

The proportion of catch-all addresses in a list varies enormously by audience. Consumer lists dominated by Gmail, Outlook and Yahoo will show very few. A B2B list built from small-company domains can run 20-30% catch-all, and how you handle that segment will matter more to your deliverability than anything else in the file.

For how catch-alls fit into the wider verification picture, see how email verification works.

Ready to see what is actually in your list? EmailListClean verifies up to 10,000 addresses a minute at 99.2% accuracy, from $100 for 250,000 emails. Start with 100 free credits or see volume pricing.

SPF, DKIM and DMARC are three DNS records that together answer one question for a receiving mail server: is this message really from the domain it claims? Without all three, major mailbox providers will not accept bulk mail from you at all. With them misconfigured, you will spend weeks blaming your list for a DNS problem.

Here is what each does, in the order you should set them up.

SPF: which servers may send for you

SPF (Sender Policy Framework) is a DNS TXT record listing the servers authorised to send email using your domain. A receiving server compares the sending IP against that list.

Two things break SPF in practice:

• The ten-lookup limit. SPF permits a maximum of ten DNS lookups when evaluating a record. Every include: costs at least one. Stack up an ESP, a CRM, a helpdesk, an invoicing tool and a marketing platform and you will exceed it – at which point SPF returns a permanent error and fails for everyone.
• Multiple SPF records. A domain may have exactly one. Two records is not additive; it is invalid, and receivers treat it as a failure. Merge the mechanisms into a single record instead.

Audit your record whenever you add a new sending tool, and flatten includes if you are near the limit.

DKIM: a signature that proves nothing was altered

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to the message header. Your sending platform signs with a private key; the public key is published in your DNS. The receiver verifies the signature, confirming the message came from an authorised sender and was not modified in transit.

Practical points:

• Use a 2048-bit key where your provider supports it.
• Every sending service needs its own selector and key – your ESP, your CRM and your transactional provider each sign separately.
• Rotate keys periodically, and remove DNS records for services you have stopped using.

DMARC: the policy that ties it together

DMARC (Domain-based Message Authentication, Reporting and Conformance) does two jobs. It tells receivers what to do with mail that fails SPF and DKIM, and it sends you reports about who is sending as your domain.

The policy values:

• p=none – monitor only. Nothing is rejected. This satisfies the minimum requirement from Google, Yahoo and Microsoft, and it is where you start.
• p=quarantine – failing mail goes to spam.
• p=reject – failing mail is refused outright. The strongest protection against domain spoofing, and where you should eventually land.

A minimal starting record looks like this:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

Do not jump straight to p=reject. Run p=none for several weeks, read the aggregate reports, and confirm every legitimate sending source is passing before you tighten. Otherwise you will start rejecting your own invoices.

Alignment: the part everyone misses

Passing SPF or DKIM is not sufficient on its own. Google requires that the organisational domain in your visible From: header matches the domain that authenticated.

The classic failure: you send from hello@yourbrand.com, but the envelope sender your ESP uses is bounce@esp-servers.net. SPF passes – for the ESP’s domain. Alignment fails, because that is not the domain your recipient sees.

The fix is a custom sending domain or return-path at your ESP, usually a subdomain like mail.yourbrand.com, authenticated under your own organisational domain. Every serious sending platform supports this. Set it up before you send anything at volume.

Setup order

1. Inventory every system that sends email as your domain. Marketing platform, CRM, helpdesk, billing, notifications, anything.
2. Publish one SPF record covering all of them, staying under ten lookups.
3. Enable DKIM signing on each platform and publish each public key.
4. Configure a custom return-path or sending subdomain so alignment passes.
5. Publish DMARC at p=none with a reporting address.
6. Read the reports for two to four weeks and fix any legitimate source that is failing.
7. Move to p=quarantine, then p=reject.

How to verify it actually works

Send a test message to an account at a provider you care about and inspect the raw headers. You are looking for three lines reading dkim=pass, spf=pass and dmarc=pass. Anything else is a finding, not a detail.

Do this again after every change to your sending stack. Adding a new tool is the most common way a working setup silently breaks.

Authentication is necessary, not sufficient

Correct authentication gets your mail evaluated. It does not get it delivered. A perfectly authenticated campaign sent to a list full of dead addresses and spam traps still lands in spam, because the provider is now confident about exactly who is sending the bad mail.

Pair authentication with list hygiene and you have covered both halves of what mailbox providers actually grade. The full requirement set is in the bulk sender checklist.

Ready to see what is actually in your list? EmailListClean verifies up to 10,000 addresses a minute at 99.2% accuracy, from $100 for 250,000 emails. Start with 100 free credits or see volume pricing.

Between February 2024 and May 2025, the three largest consumer mailbox providers moved from publishing best practices to enforcing requirements. Google, Yahoo and Microsoft now apply concrete technical rules to bulk senders, and mail that fails them is deferred or rejected rather than filtered into spam.

This is the current state of those requirements and what each one demands of you.

Who counts as a bulk sender

Google defines a bulk sender as anyone sending close to 5,000 messages or more to personal Gmail accounts within a 24-hour period. That is 5,000 to Gmail consumer addresses, not 5,000 total – a list of 30,000 with a typical Gmail share crosses the line on a single campaign. Microsoft applies a comparable 5,000-per-day threshold to outlook.com, hotmail.com and live.com addresses.

Once you cross the threshold, you do not drop back out of scope by sending less next week. Build for the requirements regardless of volume; everything on this list is good practice at any size.

Authentication: SPF, DKIM and DMARC

All three providers require all three records.

• SPF – publishes which servers are allowed to send for your domain.
• DKIM – cryptographically signs your messages so the receiver can verify they were not altered and did come from you.
• DMARC – tells receivers what to do when SPF and DKIM fail. A policy of p=none satisfies the minimum requirement.

Google additionally requires alignment: the organisational domain in your From: header must match the domain used in either your SPF or DKIM authentication. Passing SPF for some third-party sending domain while your From: address says something else does not count.

The setup order that avoids problems is covered in the authentication checklist.

Spam complaint rates

Google is specific: keep spam rates below 0.1%, and prevent them from ever reaching 0.3% or higher. Senders who cross 0.3% become ineligible for mitigation support, and eligibility only returns after seven consecutive days below that line.

Microsoft treats low complaint rates as a strong expectation rather than a hard published threshold, but the practical effect is the same.

Complaint rate is where list hygiene shows up indirectly. Mail that lands in spam collects complaints at a much higher rate than mail in the inbox, so a reputation problem caused by bounces becomes a complaint problem that deepens the reputation problem. Cleaning breaks that loop at the start.

One-click unsubscribe

Marketing and promotional messages must support one-click unsubscribe using List-Unsubscribe headers as specified in RFC 8058. Google requires unsubscribe requests to be honoured within 48 hours; Microsoft specifies two days.

Transactional messages are exempt. A password reset does not need an unsubscribe link.

The header is not a substitute for a visible unsubscribe link in the message body – you need both. And “honoured within 48 hours” means actually suppressed, not queued for the next manual list sync.

Infrastructure requirements

• TLS for SMTP connections.
• Valid forward and reverse DNS records for your sending IPs (FCrDNS).
• RFC 5322 compliant message formatting.
• No impersonation of Gmail From: headers, and no forwarding practices that break authentication without repair.

Most senders on a reputable ESP inherit these automatically. If you run your own mail infrastructure, they are yours to get right.

The one difference that should change your priorities

Google and Yahoo respond to non-compliant mail with temporary deferrals – 4xx errors that give you a window to notice and fix the problem before permanent damage. Microsoft, since 5 May 2025, rejects non-compliant mail outright.

That asymmetry matters. A misconfiguration that Gmail would let you discover through rising deferrals will simply destroy your Outlook delivery with no soft landing. If a meaningful share of your list sits on outlook.com, hotmail.com or live.com, authentication is not a project for next quarter.

A compliance pass you can run this week

1. Confirm SPF, DKIM and DMARC exist and pass – send a test to a seed account and inspect the headers.
2. Confirm From: domain alignment with SPF or DKIM.
3. Confirm List-Unsubscribe and List-Unsubscribe-Post headers are present on marketing sends.
4. Confirm unsubscribes are processed within 48 hours end to end, including any downstream CRM sync.
5. Pull your complaint rate by provider for the last 90 days and check it against 0.1%.
6. Clean the list so bounces are not feeding the complaint problem.
7. Check sending IPs for valid reverse DNS.

Requirements at this level are a floor, not a strategy. Meeting them gets your mail considered. What decides whether it reaches the inbox is sender reputation, and reputation is built on sending wanted mail to addresses that exist.

Ready to see what is actually in your list? EmailListClean verifies up to 10,000 addresses a minute at 99.2% accuracy, from $100 for 250,000 emails. Start with 100 free credits or see volume pricing.

A spam trap is an email address that exists for one purpose: to catch senders who are mailing addresses they should not have. Nobody reads the inbox. Nobody signed up. The only way to hit one is to be mailing a list that was bought, scraped, or never cleaned – which is exactly the conclusion the mailbox provider or blocklist operator draws when you do.

Trap hits are among the most damaging deliverability events available, because unlike a bounce or a complaint, there is no innocent explanation.

The three types, and what each one accuses you of

Pristine traps

Addresses created by blocklist operators and mailbox providers and then published where only a scraper would find them – buried in page source, on abandoned domains, in text harvested by bots. They have never been used to sign up for anything.

Hitting a pristine trap means your list contains scraped or purchased data. There is no other path to the address. These carry the heaviest penalty, and a single hit can be enough to get a sending IP or domain listed.

Recycled traps

Real addresses that belonged to real people, then were abandoned. The provider lets them hard-bounce for a period – typically several months – then reactivates them as traps.

Hitting a recycled trap means you do not remove hard bounces, or you do not sunset inactive subscribers. Less severe than a pristine hit, but it accuses you of exactly the thing list hygiene is supposed to prevent.

Typo traps

Addresses that exploit common misspellings of major domains – the gmial.com family. Some are operated by blocklist services; some are opportunistic domain owners collecting misdirected mail.

Hitting a typo trap means you accepted a form submission without validating it. This one is genuinely an accident, but the fix is trivial, so providers give little credit for good intentions.

Why you cannot simply look for them

Trap addresses are indistinguishable from real ones by inspection. They use ordinary local parts on ordinary domains. There is no public list – publishing one would defeat the purpose. Anyone claiming to guarantee 100% trap removal is selling something they cannot deliver.

What a verification service can do is identify the patterns that predict traps: addresses on domains with no legitimate signup history, addresses matching known typo-domain patterns, addresses that have hard-bounced and then mysteriously started accepting mail again, and addresses appearing on lists with the fingerprint of scraped data. That is meaningful risk reduction, not a guarantee.

How senders end up with traps

• Bought or rented lists. The single most common route. Assume any purchased list contains pristine traps.
• Scraped addresses. Harvesting from websites and directories collects traps by design – they were planted for you.
• No bounce suppression. Keep mailing an address after it hard-bounces and you will still be mailing it the day it is reactivated as a recycled trap.
• No sunset policy. Deliverable but never-engaging addresses are the pipeline that feeds recycled traps.
• Unvalidated signup forms. Typos walk in the front door.
• Inherited lists. An acquisition, an agency handover, a CRM export from a predecessor. You own the consequences of data you never collected.

What a trap hit actually does

The immediate effects are invisible from inside your ESP dashboard. There is no bounce. There is no complaint. The message is accepted and silently filed as evidence. What follows is:

• Blocklist listings against your sending IP or domain.
• Inbox placement dropping without any change in your bounce or complaint metrics.
• Filtering at specific providers while others still deliver, which makes the problem look like a content issue.
• In serious cases, suspension by your own ESP – trap hits threaten the reputation of their shared infrastructure, not just yours.

The tell is a drop in engagement with no corresponding change in bounces. If opens fall off a cliff and your bounce rate is flat, you are being filtered, not bouncing, and traps are one of the short list of explanations.

Removing traps you already have

1. Verify the list and remove everything flagged invalid, disposable, or high-risk.
2. Purge by source. If part of your list came from a purchase or a scrape, delete that segment entirely. Do not try to salvage it – the value of the good addresses in it is lower than the cost of the traps.
3. Enforce hard-bounce suppression retroactively across every historical import.
4. Sunset the unengaged. Anyone with no opens or clicks in 12 months goes through re-engagement, then suppression.
5. Check the blocklists. Look up your sending domain and IP on the major public lists. Some offer self-service delisting once the underlying behaviour is fixed.

Staying clean

Traps are a consequence of acquisition practice, not bad luck. Permission-based collection with double opt-in, real-time verification at capture, automatic bounce suppression, and a sunset policy will keep almost any sender clear of them indefinitely.

If you are not sure which of your addresses are risky, start with a full cleaning pass and pay particular attention to the catch-all segment, where traps are hardest to detect.

Ready to see what is actually in your list? EmailListClean verifies up to 10,000 addresses a minute at 99.2% accuracy, from $100 for 250,000 emails. Start with 100 free credits or see volume pricing.

Every bounce your platform reports falls into one of two categories, and the difference decides what you do next. A hard bounce is permanent and demands immediate suppression. A soft bounce is temporary and usually resolves itself. Treating them the same way is how senders either destroy their reputation or throw away perfectly good subscribers.

Hard bounce: the address does not exist

A hard bounce is a permanent delivery failure, returned by the receiving server as a 5xx status code. The mailbox is gone, the domain is gone, or the address was never real.

Common causes:

• The mailbox was deleted – an employee left, an account was closed.
• The address contains a typo and was never valid.
• The domain does not exist or has no mail servers configured.
• The receiving server has explicitly blocked your domain or IP.

The rule is absolute: suppress a hard-bounced address immediately and permanently. Do not retry it. Do not let it back in through a re-import six months from now. Repeated delivery attempts to an address a provider has already told you does not exist is one of the loudest bad-sender signals available.

Soft bounce: the address exists but delivery failed

A soft bounce is a temporary failure, returned as a 4xx code. The mailbox is real. Something got in the way.

Common causes:

• The mailbox is full.
• The receiving server is down or overloaded.
• The message exceeded a size limit.
• The server is greylisting – deliberately deferring a first attempt from an unfamiliar sender to filter out spam software that never retries.
• Your sending volume tripped a rate limit at the receiving end.

Most ESPs retry soft bounces automatically over 24 to 72 hours, and most of those messages get delivered. A soft bounce on a single send is not a problem.

Where the distinction gets dangerous

A soft bounce that repeats is not soft. An address that has been “mailbox full” on every send for four months is an abandoned account. Nobody is emptying it because nobody is reading it.

Abandoned accounts are exactly what mailbox providers convert into recycled spam traps. The provider lets the address hard-bounce for a period, then quietly reactivates it as a trap. Anyone still mailing it is demonstrating that they do not remove dead addresses – which is precisely what the trap is designed to detect.

Set a rule and automate it: three consecutive soft bounces to the same address, treat it as hard and suppress it. Some senders use five. Almost nobody should use “never”.

What your ESP reports is not always the truth

Platforms classify bounces inconsistently. Two failure types get mislabelled often enough to matter:

• Reputation blocks filed as soft bounces. The receiving server returned a 4xx because it does not trust you, not because the mailbox was busy. Retrying makes it worse. Read the actual rejection string – it usually names a blocklist or a policy.
• Authentication failures filed as hard bounces. The address is fine; your SPF, DKIM or DMARC records are not. Suppressing these addresses deletes real subscribers to fix a DNS problem. Check your authentication before you purge.

The habit worth building: when a bounce rate moves suddenly, read the rejection messages before touching the list. Gradual drift is list decay. A sudden spike across previously healthy addresses is almost always infrastructure or reputation.

Handling both correctly

1. Suppress hard bounces on receipt – automatically, permanently, and enforced against future imports.
2. Let soft bounces retry – but count them per address across sends, not per campaign.
3. Convert repeat soft bounces to suppression after three strikes.
4. Read rejection strings on any spike before assuming the addresses are at fault.
5. Verify before sending so most of this never reaches production. A verification pass identifies non-existent mailboxes without a delivery attempt, which means no bounce is recorded against your reputation at all.

That last point is the whole argument for cleaning. A bounce is a permanent entry in your sending history. A verification result is a private lookup nobody grades you on. Same information, radically different cost.

For the thresholds you should be holding yourself to, see what counts as an acceptable bounce rate.

Ready to see what is actually in your list? EmailListClean verifies up to 10,000 addresses a minute at 99.2% accuracy, from $100 for 250,000 emails. Start with 100 free credits or see volume pricing.

Bounce rate is the percentage of messages in a send that the receiving server refused to deliver. It is the one deliverability metric you can move immediately, and the one mailbox providers read most plainly: a sender with a high bounce rate is mailing addresses they did not verify, which usually means a list they did not earn.

What counts as an acceptable bounce rate

The working convention across the industry is to keep total bounce rate below 2%, and strong senders operate well under 1%. Those are not numbers published by Gmail or Microsoft – no mailbox provider publishes a bounce threshold – but they reflect what clean, permission-based lists actually produce.

Treat the bands roughly like this:

• Under 1% – healthy. Normal decay on a maintained list.
• 1-2% – acceptable, but drifting. Schedule a cleaning pass.
• 2-5% – a problem. Filtering is likely already happening and you may not see it in your open rates.
• Over 5% – stop sending to that list. Clean it before the next campaign, not after.

One caveat that matters: what your ESP reports as a bounce and what actually happened are not always the same thing. Some platforms count a 4xx deferral as a soft bounce even when the message is delivered on retry. Look at hard bounces separately – that number is unambiguous.

Why the threshold is not the real issue

Bounces do not damage you by arithmetic. They damage you by signal. Mailbox providers use bounce behaviour as a proxy for consent: a sender who knows their audience does not repeatedly attempt delivery to mailboxes that have not existed for two years.

The downstream effects compound. Gmail requires bulk senders – anyone approaching 5,000 messages a day to personal Gmail accounts – to keep spam complaint rates below 0.1% and never at or above 0.3%. Once your reputation degrades from bounces, more of your mail lands in spam, and mail in the spam folder collects complaints at a far higher rate than mail in the inbox. A bounce problem becomes a complaint problem becomes a blocking problem.

The five things actually causing your bounces

1. Addresses that never existed

Typos at signup are the largest single source on most lists. gmial.com, yaho.com, hotmial.com, a missing character in the local part. These are invisible until you either verify or send.

2. Addresses that stopped existing

Someone leaves a company and IT deletes the mailbox. A personal account goes dormant and the provider reclaims it. This is normal decay, and it is why a list you cleaned a year ago is not clean now.

3. Authentication failures being reported as bounces

If your SPF, DKIM or DMARC records are wrong, receiving servers reject the message and your platform records a bounce. The addresses are fine. Your authentication setup is not. This is worth ruling out before you blame the list, because cleaning will not fix it.

4. Full mailboxes and temporary failures

Soft bounces. Usually harmless in isolation. A mailbox that has been full for six months, though, is an abandoned account, and abandoned accounts are the raw material for recycled spam traps.

5. Blocks recorded as bounces

When a provider refuses your mail because of reputation rather than because the address is bad, many platforms file it under bounces. If your bounce rate jumps overnight across a list that was previously fine, look at the rejection strings before you look at the addresses. A sudden spike is a blocking event, not decay.

How to get the number down

1. Verify the entire list before the next send. Remove everything returned invalid, and hold catch-all and risky addresses in a separate segment.
2. Suppress permanently. A hard-bounced address must never re-enter the list through a future import. Keep a suppression file and apply it on every upload.
3. Fix capture. Real-time verification on signup forms stops the problem at the source. Typo correction at the point of entry recovers real subscribers you would otherwise lose.
4. Check authentication. Confirm SPF, DKIM and DMARC are aligned before assuming the list is at fault.
5. Sunset the dead weight. Addresses that are deliverable but have not engaged in a year are future traps. Run a re-engagement sequence, then suppress the non-responders.

What to expect after a clean

On a list that has never been verified, expect 10-25% of addresses to come back invalid or risky. That number feels alarming until you remember you were already paying to send to them and being judged on the result.

The bounce rate should drop on the very next send. Reputation recovery takes longer – if you have been bouncing heavily for months, expect a few weeks of consistent, clean sending before inbox placement follows.

If you clean thoroughly and bounces stay high, the cause is not the list. Work through the sender requirements and your sender reputation next.

Ready to see what is actually in your list? EmailListClean verifies up to 10,000 addresses a minute at 99.2% accuracy, from $100 for 250,000 emails. Start with 100 free credits or see volume pricing.

Email verification is the process of confirming that an address can actually receive mail, without sending anything to it. It runs a sequence of independent checks – format, domain, mail server, mailbox, and risk signals – and returns a status you can act on before a campaign ever leaves your platform.

The distinction that matters: a bounce is a permanent entry in your sending history that mailbox providers grade you on. A verification result is a private lookup nobody sees. Same information, entirely different cost.

The checks, in order

1. Syntax and format

The cheapest check and the first to run. It rejects addresses that cannot be valid under RFC rules: missing @, illegal characters, spaces, a local part or domain that breaks length limits, malformed top-level domains.

Good engines go further and flag likely typos – gmial.com, yahooo.com, hotmial.com – which can be corrected rather than discarded, recovering real subscribers instead of deleting them.

2. Domain and MX records

Does the domain resolve, and does it publish MX records? A domain with no mail exchanger is not configured to receive email at any address. This catches expired domains, abandoned company domains, and invented domains from fake signups.

3. SMTP mailbox check

The core of real verification. The engine opens an SMTP connection to the receiving mail server and asks whether a specific mailbox exists, using the same conversation a sending server would have – then terminates before any message is transmitted.

No email is sent. Nothing appears in the recipient’s inbox. The server’s response tells you whether the mailbox is real.

Two complications are unavoidable here. Some servers answer positively for every address regardless of whether it exists – these are catch-all domains, and no verifier can resolve them definitively. Others throttle or refuse repeated checks from the same source, which is why verification at scale requires distributed infrastructure rather than a script on one server.

4. Disposable and role detection

Disposable addresses come from services that hand out temporary mailboxes to get past signup forms. They are technically valid and completely worthless – the mailbox expires within hours.

Role addresses – info@, sales@, admin@, support@ – reach shared inboxes rather than individuals. They are usually real, but they generate complaints at a higher rate and represent no single person’s consent. Both categories deserve their own handling.

5. Risk and trap signals

Pattern analysis identifies addresses that correlate with spam traps and other high-risk data: known typo-trap domains, addresses on domains with no legitimate signup history, and addresses that previously hard-bounced but have started accepting mail again – the signature of a recycled trap.

Reading the results

Verification returns four statuses, and the two in the middle are where judgement is required.

• Valid – the mailbox exists and accepts mail. Send normally.
• Invalid – the mailbox does not exist. Remove and suppress permanently.
• Risky / accept-all – the server accepts everything, or the address carries risk signals. Segment it, send in smaller volumes, and watch the bounce rate before folding any of it back in.
• Unknown – the check could not complete, usually because the receiving server throttled the request. Retry after a few days; if it stays unknown, treat as risky.

Any provider reporting 100% valid on a real-world list is either guessing or only running syntax checks. On a list that has never been verified, 10-25% coming back invalid or risky is normal.

Bulk verification vs real-time API

Bulk is the cleanup pass: upload a file, get it back annotated, act on the results. Use it quarterly, before any large campaign, and before migrating to a new sending platform.

Real-time API is the prevention: a single-address check at the moment of signup, returning in well under a second, so bad addresses never enter the database. This is what stops the problem recurring. Typo correction at this point is particularly valuable – catching gmial.com at the form recovers a subscriber you would otherwise lose silently.

Most senders need both. Bulk cleans what you have; the API keeps it that way.

What verification cannot tell you

It confirms a mailbox exists. It does not confirm the person wants your email. An address can be perfectly valid and still generate a spam complaint, and complaints do more damage than bounces – Google requires bulk senders to stay under 0.1% and never touch 0.3%.

Verification also cannot manufacture consent. Verifying a purchased list makes it a list of confirmed-real addresses belonging to people who never asked to hear from you. The bounces go away; the complaints and trap hits do not.

Used properly – on lists you built, alongside a sunset policy and correct authentication – verification is the highest-leverage deliverability work available, because it produces results on the very next send.

Ready to see what is actually in your list? EmailListClean verifies up to 10,000 addresses a minute at 99.2% accuracy, from $100 for 250,000 emails. Start with 100 free credits or see volume pricing.

An email list decays whether you use it or not. People change jobs, companies fold, personal accounts get abandoned, and a share of every list was never valid in the first place – typos at signup, fake addresses traded for a lead magnet, and bots filling forms. Cleaning is how you find those addresses before a mailbox provider finds them for you.

This guide walks the process end to end: what to pull, what to check, what to delete, what to keep in quarantine, and how often to run the whole thing again.

Why cleaning matters more than it used to

Mailbox providers no longer grade senders on a curve. Gmail requires any sender pushing close to 5,000 messages or more to personal Gmail accounts in a 24-hour window to authenticate with SPF, DKIM and DMARC, and to keep spam complaint rates below 0.1%, never touching 0.3%. Microsoft began enforcing comparable rules on 5 May 2025 for outlook.com, hotmail.com and live.com addresses – and where Google and Yahoo temporarily defer non-compliant mail, Microsoft rejects it outright.

Invalid addresses feed directly into those metrics. Every dead address is a bounce, and a high bounce rate is the clearest signal a provider has that you are mailing a list you did not earn. Cleaning is the cheapest lever you have on deliverability, and unlike most deliverability work it produces results on the very next send.

Step 1: Export everything, not just the active segment

Pull a full export from your ESP or CRM, including unsubscribes and previously bounced addresses. You want the whole picture, because the addresses causing damage are usually the ones nobody looks at: an import from a trade show three years ago, a list bought by a predecessor, a form with no validation on it.

Keep the original columns intact. Signup date, source, last open and last click are what let you make judgement calls later that a verifier cannot make for you.

Step 2: Deduplicate and normalise before you verify

Verification is priced per address, so paying to check the same address three times is waste. Before you upload:

• Lowercase every address – Sarah@Acme.com and sarah@acme.com are the same mailbox.
• Strip whitespace and stray characters that survived a spreadsheet round trip.
• Remove exact duplicates, keeping the record with the most recent engagement.
• Decide on Gmail dot and plus-address handling – s.chen@gmail.com and schen+news@gmail.com both reach the same inbox.

Step 3: Run verification

A verification pass tests each address through several independent checks. The mechanics are covered in detail here, but the short version:

• Syntax and format – malformed addresses, illegal characters, broken top-level domains.
• Domain and MX – does the domain exist, and does it have mail servers configured to receive anything at all.
• SMTP mailbox check – does the specific mailbox exist, tested without sending an email.
• Spam trap and honeypot detection – addresses seeded specifically to catch senders mailing unverified data.
• Disposable and role detection – burner services and shared inboxes like info@ or sales@.

What comes back is not a simple pass or fail. Expect four buckets: valid, invalid, risky, and unknown. The first two are easy. The middle two are where most of the money is.

Step 4: Act on each bucket differently

Invalid – delete

These addresses do not exist. There is no version of the story where mailing them helps you. Remove them from the sending list entirely and keep a suppression record so a future import cannot reintroduce them.

Valid – mail normally

Deliverable mailboxes. Note that “deliverable” is not “engaged” – an address that has existed for six years and never opened anything is still a candidate for a sunset policy.

Risky – segment, do not bulk send

Catch-all domains accept mail for any address at the domain, so a mailbox check cannot confirm whether one specific inbox exists. Role accounts and low-quality domains land here too. Mail these separately, in smaller volumes, and watch the bounce rate before folding any of them back into your main sends.

Unknown – retry, then decide

Unknowns are usually the result of a receiving server throttling or temporarily refusing the check. Re-run them after a few days. If they stay unknown, treat them as risky.

Step 5: Apply engagement rules the verifier cannot

Verification tells you whether a mailbox exists. It cannot tell you whether the person behind it wants your email. Layer your own rules on top:

• No opens or clicks in 12 months on a monthly-or-more send cadence – move to a re-engagement sequence, then suppress.
• Addresses acquired from a source you cannot document – suppress. If you cannot explain where consent came from, you should not be mailing it.
• Addresses that have complained even once – suppress permanently, regardless of what the verifier says.

Step 6: Stop the leak at the source

Cleaning a list is remediation. Keeping it clean is a system. Add real-time verification at the point of capture so bad addresses never enter, use double opt-in on public forms, and add a typo-correction step that catches gmial.com before the record is written rather than a year later.

How often should you clean?

• Every send, at capture: real-time API verification on signup forms.
• Quarterly: a full list pass for most senders.
• Monthly: if you send several times a week, buy lists of any kind, or run high-volume outbound.
• Always: before mailing any list that has been sitting untouched for more than 90 days, and before any migration to a new sending platform.

The last one is the most commonly skipped and the most expensive. A new sending domain or IP has no reputation to spend, and opening with a bounce-heavy send is the fastest way to start from behind.

What good looks like afterwards

The industry convention is to keep bounce rates under 2%, and the better operators sit well under 1%. If you clean and your bounce rate does not move, the problem is not your list – it is authentication, infrastructure or content, and the sender requirements checklist is the place to look next.

Ready to see what is actually in your list? EmailListClean verifies up to 10,000 addresses a minute at 99.2% accuracy, from $100 for 250,000 emails. Start with 100 free credits or see volume pricing.