DEV Community: MailValid.io

Your Email List Is Decaying Right Now

MailValid.io — Sun, 12 Jul 2026 18:11:13 +0000

Verifying an email address at signup only proves it was valid at that moment. It says nothing about whether it's still valid six months later and for most contact databases, a meaningful share of it won't be. If your app verifies once at signup and never again, you're shipping a slow leak, not a fix.

This post covers why lists decay even without a single unsubscribe, what a re-verification job should actually check, and a basic cron-based implementation for keeping a contacts table clean over time.

Why valid-at-signup doesn't mean valid-forever

Email addresses have a shelf life, and email verification once at collection time only confirms the address was live on that specific day. Roughly 22.5% of email contacts become invalid over the course of a year — around 2.1% per month: driven by job changes, account deactivation, provider migrations, and abandoned inboxes. B2B contact lists decay faster than consumer lists, commonly in the 25–30% annual range, largely because employees change jobs and their work addresses get deactivated almost immediately.

If your database has contacts older than a few months and you've never re-verified, you're very likely sending to a nontrivial number of dead addresses without knowing it.

What causes Email list decay

Email list decay is driven by five recurring patterns, and only one of them is under your control.

Job changes — the single biggest driver for B2B lists; an estimated 70% of B2B job-related email addresses change within 12 months of collection.
Company changes — mergers, acquisitions, rebrands, or shutdowns can invalidate an entire domain's worth of addresses at once.
Provider migrations — a contact moves from one email provider to another and abandons the old address.
Account deactivation — mailbox providers periodically purge inactive accounts per their own retention policies.
Signup typos — the one decay source that real-time syntax/MX verification at signup actually prevents.

The first four happen entirely outside your app, on a timeline you don't control, which is exactly why a one-time verification at signup can't be the whole strategy.

Email Spam traps: the risk re-verification catches that bounces don't

A recycled spam trap is a real address that mailbox providers have reclaimed after roughly 12 months of inactivity, then repurposed specifically to catch senders with stale lists. This is the mechanism that makes re-verification more than a bounce-rate optimization — it's a reputation risk mitigation.

There are three recognized spam trap types:

Typo traps - created from signup typos (user@yahooo.com), catching senders who never validated syntax carefully.
Recycled traps - formerly legitimate addresses that went dormant for a year or more and were reclaimed by the provider as a monitoring mechanism.
Pristine traps - addresses that were never real signups at all, created solely to catch senders using purchased or scraped lists.

Recycled traps are the one your own signup-time verification can't catch, because the address was real and valid when the person signed up. It only becomes a trap after months of dormancy — which is precisely the gap a scheduled re-verification job is designed to close.

Designing the re-verification job

A re-verification job needs three things a one-off signup check doesn't:

A cadence - how often each contact gets re-checked (see the how-often section)
Prioritization - verifying your entire table every night at scale is wasteful; segment by last-engagement date or last-verified date and check the stalest/riskiest contacts first
A status write-back, not a delete — store the verification result (valid, invalid, catch-all, disposable, unknown) and last-checked timestamp rather than silently dropping rows, so your sending logic can make the suppress/send decision explicitly

A scheduled job example (Node.js + cron)

javascriptconst cron = require('node-cron');
const db = require('./db');

// Runs nightly at 2am — pulls contacts not verified in 90+ days,
// oldest-first, capped at a batch size to respect rate limits.
cron.schedule('0 2 * * *', async () => {
  const staleContacts = await db.query(`
    SELECT id, email FROM contacts
    WHERE last_verified_at < NOW() - INTERVAL '90 days'
       OR last_verified_at IS NULL
    ORDER BY last_verified_at ASC NULLS FIRST
    LIMIT 5000
  `);

  for (const contact of staleContacts) {
    const result = await verifyEmail(contact.email); // your verification call
    await db.query(`
      UPDATE contacts
      SET verification_status = $1, last_verified_at = NOW()
      WHERE id = $2
    `, [result.status, contact.id]);

    if (result.status === 'invalid') {
      await db.query(`UPDATE contacts SET suppressed = true WHERE id = $1`, [contact.id]);
    }
  }
});

The batch size and interval here are illustrative, tune them to your sending volume and your verification provider's rate limits. The important structural choice is the last_verified_at column: it turns re-verification into an ongoing, queryable process instead of a one-time event.

How often should you re-verify?

There's no universal answer, but the decay data gives a reasonable default: at roughly 2% monthly decay, a 90-day re-verification cycle catches most staleness before it compounds into a meaningful bounce or spam-trap risk, without re-checking addresses that haven't had time to go stale. High-value B2B lists with faster job-change turnover may justify a 30–60 day cycle; low-churn consumer lists can often stretch to 6 months.

If you're re-verifying manually or building this in-house, an email verification API that returns a distinct catch-all status (rather than lumping it in with valid) matters more here than at signup time, a domain's catch-all configuration can change between checks, and treating it as a hard valid inflates your list-quality metrics without actually reducing risk. MailValid supports exactly this: bulk re-verification with status codes designed for exactly this kind of scheduled job, plus a real-time API for the signup-time check.

Frequently Asked Questions

Does re-verification replace signup-time verification?
No, they catch different things. Signup-time verification (syntax + MX + SMTP) prevents typo'd and fake addresses from entering your database at all. Re-verification catches addresses that were genuinely valid at signup but have since gone stale.

Will re-verification hurt my sender reputation the way sending mail does?
No. SMTP-level verification checks mailbox existence via a RCPT TO command without completing delivery (no DATA command is sent), so it doesn't count as a send and doesn't itself generate spam complaints, provided it's run through a provider with dedicated verification IP infrastructure rather than your own sending domain.

Should I delete contacts that fail re-verification?
Suppressing them from sends is safer than deleting outright, a suppressed contact might resubscribe, correct a domain-level issue, or represent a data point you still want for reporting. Deletion is a business decision, not a deliverability requirement.

What if a contact I haven't emailed in a year suddenly becomes a spam trap?
This is exactly the recycled-trap scenario. If your last engagement with an address predates your last verification by many months, treat it as higher risk and prioritize it in your re-verification queue rather than assuming dormancy is harmless.

How to Verify Email Addresses Programmatically: SMTP, MX, and API-Based Validation Explained

MailValid.io — Fri, 10 Jul 2026 19:48:53 +0000

Bad email addresses in a signup form don't just clutter your database, they wreck deliverability. A high bounce rate signals to mailbox providers like Gmail and Outlook that your sending domain isn't trustworthy, and that reputation hit follows every email you send afterward, not just the bad ones.

If you're building a signup flow, a CRM integration, or a bulk import pipeline, "email verification" usually gets bolted on as a regex check and forgotten. That's a mistake, regex can only tell you an address is syntactically plausible, not that it exists. This post walks through the three layers of email verification, what each one actually checks, and how to decide which one belongs in your stack.

Why regex alone isn't verification

A regex pattern confirms an address is formatted correctly, it says nothing about whether the mailbox exists. john@company-that-does-not-exist.zzz will pass most email regex patterns without complaint. So will a real-looking address at a domain with no mail server configured, or a mailbox that was deleted two years ago.

True verification requires checking three separate things in sequence: syntax, domain, and mailbox existence. Skipping straight from syntax to "trust it" is why forms full of validated-looking emails still produce 8–15% hard bounce rates on the first send.

Layer 1: Syntax validation

Syntax validation confirms the address follows RFC 5321/5322 structure — local-part@domain.tld — before any network call is made. This is the cheapest check and should always run first, client-side or server-side, to reject obviously malformed input (name@, @domain.com, missing TLD) before you spend a network round-trip on it.

A reasonably strict pattern catches the common cases, but don't over-engineer a fully RFC-compliant regex by hand. The spec allows for edge cases (quoted strings, escaped characters) that are rarely worth supporting and easy to get wrong. Use a maintained library or an API's syntax layer instead of a hand-rolled 200-character regex.

Layer 2: MX record / domain validation

MX record validation checks whether the domain after the @ symbol actually has a mail server configured to receive email. This is a DNS lookup, not an SMTP connection, fast, cheap, and it eliminates a large chunk of fake or typo'd domains (gmial.com, company.con) before you go further.

dig MX gmail.com +short
# 10 alt1.gmail-smtp-in.l.google.com.
# 5 gmail-smtp-in.l.google.com.
# ...

No MX record (and no fallback A record) means no mail can be delivered to that domain, full stop — it's a safe automatic reject.

Layer 3: SMTP handshake verification

SMTP verification opens a connection to the recipient's mail server and asks whether a specific mailbox exists, without actually sending a message. This is the layer that catches deleted accounts, typos in the local part (jhon@ vs john@), and mailboxes that were never created, the failures that syntax and MX checks can't see.

The sequence looks like this:

Connect to the domain's MX server on port 25
HELO/EHLO handshake to identify your sending server
MAIL FROM: verify@yourdomain.com
RCPT TO: target@theirdomain.com
Read the response code - 250 means the mailbox accepts mail, 550 means it doesn't
QUIT without sending DATA (so no message is actually delivered)

This is the most accurate layer, and also the most operationally fragile: many mail servers rate-limit or block repeated SMTP probes from unfamiliar IPs, especially if you're running checks at volume from a server with no sending history. That's the practical reason most teams end up using an email verification API rather than opening raw SMTP connections from their own infrastructure. A dedicated service maintains IP reputation and rotation specifically for this, so your app's own sending domain never takes the hit.

Catch-all domains and why they break SMTP checks

A catch-all domain accepts mail to any local part at that domain, so SMTP verification can't distinguish a real mailbox from a nonexistent one. If xyz123nonsense@company.com returns the same 250 OK as ceo@company.com, the server is configured to accept everything and reject nothing at the mailbox level.

This shows up more often than you'd expect on smaller business domains where the mail admin never disabled catch-all routing. A verification pipeline should flag these as a distinct status: catch-all or unknown, rather than lumping them in with confirmed-valid or confirmed-invalid results. Treating a catch-all result as a hard "valid" inflates your list quality numbers without actually reducing bounce risk.

Build vs. buy: when an email verification API makes sense

Running your own SMTP verification at low volume (a signup form doing a handful of checks a day) is fine to build in-house. It stops being fine once you need to verify lists in bulk, because you run into IP reputation limits, greylisting delays, and the maintenance burden of keeping disposable-domain and role-based-address blocklists current.

	Self-built SMTP check	Verification API
Setup time	Hours to days	Minutes (API key)
IP reputation risk	Your infrastructure absorbs it	Provider's dedicated IPs absorb it
Disposable/role-address detection	You maintain the list	Maintained for you
Catch-all handling	Manual logic required	Built-in status
Bulk list cleaning (100k+)	Slow, rate-limit prone	Built for volume
Best for	Low-volume, internal tooling	Signup forms, bulk list cleaning, CRM sync

If you're past the "quick regex check" stage and need mailbox-level accuracy without babysitting SMTP rate limits, an API like MailValid handles syntax, MX, SMTP, catch-all, and disposable-domain detection behind a single endpoint — useful if you'd rather ship the feature than maintain the verification layer.

A minimal Node.js example

Here's a bare-bones example combining syntax and MX checks (the two layers safe to run yourself), with a placeholder for handing off SMTP-level verification to an API:


javascriptconst dns = require('dns').promises;

const EMAIL_REGEX = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;

async function validateSyntax(email) {
  return EMAIL_REGEX.test(email);
}

async function validateMX(email) {
  const domain = email.split('@')[1];
  try {
    const records = await dns.resolveMx(domain);
    return records && records.length > 0;
  } catch (err) {
    return false; // no MX record, or domain doesn't resolve
  }
}

async function verifyEmail(email) {
  if (!(await validateSyntax(email))) return { valid: false, reason: 'syntax' };
  if (!(await validateMX(email))) return { valid: false, reason: 'no_mx_record' };

  // SMTP-level (mailbox existence) verification is best delegated to an API
  // to avoid IP reputation issues from raw SMTP probing at scale.
  // const result = await mailValidClient.verify(email);

  return { valid: true, reason: 'passed_syntax_and_mx' };
}

This gets you two-thirds of the way there for free. The remaining one-third, mailbox-level confirmation is where the infrastructure tradeoffs above actually matter.

Frequently Asked Questions

Does email verification guarantee zero bounces?
No. Verification confirms a mailbox accepted the address at check time, but mailboxes get deleted, quotas fill up, and spam filters can still soft-bounce a valid address. Verification reduces hard bounces significantly; it doesn't eliminate all bounce risk.

Is SMTP verification the same as sending a test email?
No. SMTP verification stops before the DATA command, so no message is actually delivered or seen by the recipient. It only confirms the server's response to RCPT TO.

Why do some verification tools mark valid-looking emails as "unknown"?
Usually because the domain is a catch-all, the mail server is temporarily unreachable (greylisting), or the server refuses to confirm mailbox existence for anti-harvesting reasons. "Unknown" is a legitimate result, not a failure of the tool.

Can I do this entirely client-side in the browser?
Only the syntax layer. MX and SMTP checks require server-side DNS/network access that browsers don't expose for security reasons.