ON THIS PAGE
By Efe Berke Colaker, Founder at GetleadReviewed by the Getlead editorial team for accuracy. Last updated October 2026.
Most outbound programs discover a bounce problem when sending accounts suddenly stop working. A campaign launches Monday, but providers block the workspace by Wednesday because bounce rates crossed the 5% limit.
The root cause is usually a raw list scraped from a database and loaded directly into a sending tool. Email verification tests an address through network protocols before sending, which confirms a receiving server will accept messages.
For example, a team buying 1,000 contacts from a vendor might find only 400 are active. Checking those addresses before sending protects the domain reputation so the campaign keeps running.
The cost of skipping the check
Sending messages to inactive addresses creates hard bounces that damage your domain reputation. Mailbox providers constantly monitor the ratio of delivered messages to failed delivery attempts. A high bounce rate signals that the sender is guessing addresses or using outdated data.
Providers enforce strict limits on bounces before applying penalties. You must maintain a low spam rate and avoid sending to invalid accounts to stay in the inbox. Bounces contribute to a poor sender reputation, causing legitimate messages to land in the spam folder.
If you do not verify your lists, your overall deliverability will steadily drop. Teams often ignore this mechanical failure until their open rates fall below 10%. Fixing a damaged domain takes weeks of manual activity, which pauses all revenue generation.
Google Workspace requires senders to maintain a spam rate below 0.3%. If your bounce rate exceeds 5% for three consecutive days, Google automatically throttles your outbound delivery. Microsoft 365 employs similar defensive mechanisms for its Exchange servers.
When a sender hits a 7% bounce rate, Microsoft routes all subsequent messages to the quarantine folder. Administrators must manually release these messages, which rarely happens in practice. If you ignore these limits, the recovery process requires technical effort.
Recovering a penalized domain
Consider a worked example of a damaged domain. A sales team sends 5,000 emails daily without verification, hitting a 12% bounce rate. Google Workspace flags the domain after 48 hours, dropping inbox placement from 85% to 12%.
To recover a penalized domain, follow a rehabilitation procedure. First, stop all outbound sending immediately, and second, audit your DNS records to ensure SPF, DKIM, and DMARC pass. Third, enroll the domain in a warmup tool, starting at five emails per day and increasing by two daily.
The financial impact of this downtime scales linearly with your team size. If you employ five sales representatives, a 21-day penalty pauses 105 days of collective outreach. Assuming each representative books two meetings weekly, the penalty costs 30 lost meetings.
You can calculate the exact revenue loss by multiplying those 30 meetings by your historical close rate. If you close 20% of meetings at a $5,000 average deal size, skipping verification costs $30,000 in closed revenue.
How the mechanism works
A standard bulk email verifier runs three distinct tests on every contact in your file. This process involves a sequence of technical checks that do not send an actual message.
- Syntax check: validates the text string against standard email formatting rules.
- DNS check: queries the domain records to confirm a mail server exists.
- SMTP handshake: pings the specific mailbox on the server without sending a payload.
First, the system performs a syntax check to ensure the address follows standard formatting rules. This catches obvious human errors like missing symbols or misplaced spaces. The syntax check also validates the top-level domain against the official IANA database.
If a prospect mistypes their address as user@company.con, the syntax check flags the invalid extension. Next, the tool queries the domain name system to verify the mail exchange records. This step confirms the domain has a server configured to receive incoming mail.
The DNS check phase involves querying specific record types. The verifier requests the MX records for the target domain, and if the DNS server returns no MX records, the verifier immediately marks the address as invalid.
If the MX records exist, the verifier checks their priority values. A domain might have a primary mail server at priority 10 and a backup at priority 20. The verifier always attempts to connect to the lowest priority server first.
The SMTP handshake sequence
Finally, the verifier initiates a standard SMTP handshake with the receiving server. It asks the server if the specific mailbox exists before closing the connection without sending data. The SMTP handshake follows a precise sequence of commands.
The verifier connects to port 25 and issues an EHLO command to identify itself, and the receiving server responds with a 250 OK code if it accepts the connection. Next, the verifier sends a MAIL FROM command with a blank sender address.
If the server accepts this, the verifier sends a RCPT TO command containing the target email address. The server response to this final command determines the verification status. A 250 response code means the mailbox exists and is ready to receive mail, whereas a 550 response code indicates the mailbox does not exist, resulting in a hard bounce.
The verifier immediately sends a QUIT command to terminate the session. Some servers employ greylisting to block automated verification attempts. When the verifier sends the RCPT TO command, a greylisted server returns a 450 response code.
This temporary failure code forces the verifier to retry the connection after 15 minutes. A verification tool automatically handles these greylisting delays in the background. It queues the address, waits the required 15 minutes, and initiates a second SMTP handshake.
The four result statuses
Every address returns one of four statuses based on the server response. Valid addresses are safe to email because the receiving server explicitly confirmed the mailbox exists. Invalid addresses will bounce, so you must remove them immediately to protect your domain.
Catch-all addresses belong to servers that accept all incoming mail, even for nonexistent users. Unknown addresses occur when the receiving server blocks the verification attempt entirely or times out.
Fewer than half of the addresses scraped from public sources are valid. Sending to the entire list without filtering would result in a bounce rate near 20%. This failure rate guarantees a suspension from major mailbox providers within the first week.
You must filter the list before loading it into your cold email software. Removing the invalid addresses protects your infrastructure. Consider a raw list of 10,000 scraped contacts.
Based on our distribution, you will find 4,340 valid addresses and 2,390 invalid addresses. You will also identify 1,670 catch-all addresses and 1,600 unknown addresses. If you send to all 10,000 contacts, the 2,390 invalid addresses generate a 23.9% bounce rate.
This immediately triggers spam filters and ruins your sender reputation. Filtering the list leaves you with a safe segment of 4,340 valid prospects. You can further segment the 4,340 valid addresses by their source data quality.
If 2,000 addresses came from LinkedIn scraping, they typically show a 95% delivery rate. If 2,340 addresses came from a generic database, expect an 85% delivery rate. This segmentation allows you to allocate your best sending domains to your highest quality data.
Route the 2,000 LinkedIn contacts through your primary Google Workspace accounts. Route the remaining 2,340 database contacts through secondary Microsoft 365 accounts to distribute risk.
Calculating the true cost of data
The cost of acquiring these 10,000 scraped contacts varies by provider. If you pay $0.02 per lead, the raw list costs $200. After filtering out the 5,660 unusable addresses, your actual cost per valid lead increases to $0.046.
This adjusted cost per lead dictates your campaign ROI calculations. If you need 100 valid leads to book one meeting, your data cost per meeting is $4.60. Factoring in this true cost prevents you from underestimating your customer acquisition expenses.
Handling catch-all and unknown addresses
Catch-all servers present a specific problem for outbound sales teams running high volume campaigns. The server accepts the message during the SMTP check, but it might silently discard it later. Some catch-all domains route mail to a central inbox, while others drop it.
You cannot know if a human will ever read the message. Sending to too many catch-all addresses lowers your overall engagement metrics. You must balance the potential value of the contact against the risk to your domain reputation.
Unknown results require a different approach because the server actively refused the verification connection. This happens when a security appliance rate-limits the verification tool during a bulk check. You can try verifying these specific addresses again after a few hours.
If they still return an unknown status, treat them as invalid to protect your sender reputation. Risking a hard bounce is never worth the potential value of a single contact.
Testing catch-all addresses safely
To safely test catch-all addresses, follow a segmentation procedure. First, isolate all catch-all contacts into a separate campaign file. Second, mix these contacts with known valid addresses at a ratio of one catch-all to four valid addresses.
Third, send this mixed campaign using a secondary domain that does not handle your primary revenue. Monitor the bounce rate closely over 48 hours. If the bounce rate exceeds 3%, pause the campaign and discard the remaining catch-all contacts.
You can also use an email warmup tool to offset the risk of catch-all addresses. Configure the warmup tool to generate 40 incoming messages per day for your sending account. This artificial engagement dilutes the negative impact of any catch-all bounces.
You can identify catch-all domains by analyzing the MX records during the DNS check phase. Domains using Google Workspace rarely configure catch-all routing by default. Conversely, domains hosted on legacy Microsoft Exchange servers frequently enable catch-all routing to prevent data loss.
This infrastructure pattern allows you to predict catch-all behavior before sending. If the MX record points to google.com, you can trust a valid status with 99% confidence. If the MX record points to a custom hostname, proceed with caution.
Implementing a retry protocol for unknown results
When dealing with unknown addresses, you must implement a retry protocol. Export all unknown results into a dedicated CSV file. Wait 24 hours to allow any temporary IP bans or rate limits to expire on the receiving servers.
Upload the CSV file to your verification tool for a second pass. Our data shows that 15% of unknown addresses resolve to a valid status on the second attempt. Delete the remaining 85% that still return an unknown status.
Integrating the check into your workflow
Contact data decays constantly as people change jobs or companies shut down operations. An address that was valid in January might return a hard bounce in June. You should verify your contacts immediately before launching the campaign to ensure accuracy.
Do not rely on checks performed months ago when you first built the lead list. Real-time verification prevents stale data from ruining your current outbound efforts. You can automate this process using a verification API connected directly to your CRM.
Our verified lists achieved a 0.51% bounce rate and a 35.8% open rate across all campaigns. Cleaning your list directly impacts your final campaign performance. You spend less time dealing with spam filters and more time negotiating with interested prospects.
The verification cost is negligible compared to the lost revenue from a burned sending domain. Protecting your sender reputation ensures your messages continue to reach the inbox. Build the verification step into your standard operating procedure.
Automating the verification workflow
Consider the financial math of a burned domain. A new domain costs $12 while a Google Workspace inbox costs $7 per month, but warming up that inbox takes 14 days where you cannot send revenue-generating emails.
If a sales representative generates $500 in pipeline per day, a 14-day warmup period costs $7,000 in lost pipeline. Because verifying 10,000 contacts costs approximately $40, spending this amount to protect $7,000 in pipeline represents a mandatory investment for any outbound team.
To automate this workflow, set up a Zapier integration between your CRM and your verification tool. Create a trigger that fires when a new lead enters the CRM, and add an action step that sends the email address to the verification API.
Configure the API to return the status directly to a custom field in your CRM. Build a filter in your sending tool that only imports contacts where this custom field equals valid. This automation eliminates manual CSV uploads and prevents human error.
You can also integrate verification directly into your web forms to block invalid data at the source. When a prospect submits a demo request, the form pings the verification API in real time. If the API returns an invalid status, the form prompts the user to correct their email address.
Establishing a data decay policy
You must also establish a data decay policy for your existing CRM records. Create an automated rule that flags any email address older than 90 days. Route these flagged addresses back through the verification API before including them in new campaigns.
This 90-day reverification cycle catches prospects who recently changed jobs, so if a previously valid address returns an invalid status, update the contact record immediately. This prevents your team from wasting time personalizing emails for employees who left the company.
Sources and method
The Google email sender guidelines provide the baseline rules for spam rates and authentication limits. We use these published limits to define the maximum acceptable bounce rate.
MailerSend explains the technical mechanics of SMTP checks in their article on what email verification is. Their breakdown of the handshake process informs our definition of the verification sequence.
ZeroBounce details the difference between active and safe addresses in their post on what email validation is. We reference their definitions when categorizing catch-all and unknown server responses.
Figures were checked in October 2026.
Frequently asked questions
How does email verification work?
It uses syntax checks, DNS queries, and SMTP handshakes to confirm a mailbox exists without sending a message. The tool pings the server and reads the response code to determine if the address is active.
Why do we need email verification?
Sending messages to invalid addresses causes hard bounces that damage your domain reputation. Mailbox providers track these bounces and will send your future messages to the spam folder if your rate gets too high.
What happens if you don't verify your email?
Your bounce rate will increase, signaling to providers that you are a spammer. Eventually, your sending accounts will be suspended, and your legitimate messages will fail to reach the inbox.
Is email verification legit?
Yes, it relies on standard network protocols to query mail servers. It is a standard practice for any business that sends bulk messages or runs outbound sales campaigns.
What is a catch-all email address?
A catch-all address belongs to a server configured to accept all incoming mail for a domain, even if the specific user does not exist. These addresses are risky because the message might be silently discarded later.