Build or Buy Email Verification? What an In-House Checker Takes

Build the cheap layers of email verification yourself, and buy the mailbox check unless verification is your product. Syntax, MX and disposable-domain checks are a day of work with open-source tools. A mailbox-level SMTP check is a different job. It needs outbound port 25, which the major clouds block by default, IP addresses with a clean reputation, catch-all detection, greylisting retries and ongoing per-provider maintenance. Most teams that build it end up running a small mail operation they did not plan for.

This guide breaks verification into its components, rates each one for effort and upkeep, and gives a decision table at the end.

The layers of an email check

"Email verification" is five checks stacked on top of each other, and their costs differ by orders of magnitude. Our post on syntax, MX and SMTP checks explains what each catches.

Layer	What it catches	Build effort	Ongoing upkeep
Syntax	Malformed addresses	Hours, with a library	None
Typo suggestions	gmial.com, hotmial.com	Hours	Occasional
Domain and MX lookup	Domains that cannot receive mail	Hours	None
Disposable and role detection	Throwaway domains, info@, sales@	A day, plus a list	Weekly list updates
Mailbox check over SMTP	Mailboxes that do not exist	Weeks	Continuous
Catch-all detection	Domains that accept every address	Days, on top of SMTP	Continuous

The first four layers are worth building in-house almost always. They are fast, offline or DNS-only, and they make a good first filter on a signup form. Our language guides show working code for JavaScript and Node.js and Python.

The last two layers are where build-versus-buy is a real decision.

What the mailbox check needs

An SMTP mailbox check opens a connection to the recipient's mail server, starts a mail transaction, names the recipient, reads the reply and disconnects before sending anything. Simple to describe. Here is what it takes to run.

1. A server that can reach port 25

Mail servers accept incoming mail on port 25. The large clouds block outbound connections to it by default:

• AWS, EC2 documentation: "By default, Amazon EC2 allows outbound traffic over port 25 only to private IPv4 addresses. Traffic over port 25 is blocked to public IPv4 addresses and IPv6 addresses." You can request removal.
• Google Cloud, sending email from an instance: "Due to the risk of abuse, connections to destination TCP Port 25 are blocked".
• Azure, troubleshooting outbound SMTP: "The Azure platform blocks outbound SMTP connections on TCP port 25 for deployed VMs", except on Enterprise Agreement and MCA-E subscriptions, where even then "there's no guarantee that external domains accept the incoming emails".

Serverless functions inherit the same limits. Our post on why cloud providers block port 25 covers the providers that do allow it, and what happens when a verifier runs where it cannot connect.

2. IP addresses mail servers will talk to

Mail servers judge the connecting IP before they answer anything useful. You need:

• Correct reverse DNS (PTR) that matches the hostname your checker announces with HELO/EHLO.
• An IP outside residential and dynamic ranges. Spamhaus's Policy Blocklist "lists IP space that should not be sending email directly to the Internet/direct-to-mx". A checker on an office connection or a cheap dynamic IP will be refused.
• A clean history. If the IP was previously used for spam, some servers will reject you before the mailbox question. Check it with a blacklist lookup before you start, and monitor it after.

3. Rate limits and politeness

A checker that opens too many connections to one provider looks like a dictionary attack, and gets throttled or blocked. You need per-domain and per-provider concurrency limits, back-off on temporary errors, and a queue. This is why verification services publish throughput limits. Ours is 45 addresses a minute per account, listed on the pricing page. A large list queues rather than being rejected.

4. Greylisting and temporary failures

Some servers answer an unfamiliar sender with a temporary 4xx code on purpose. That technique, greylisting, is described in RFC 6647: it exploits the fact that bulk spam software "does not perform retransmission attempts after receiving an SMTP temporary failure". A real mail server retries. RFC 5321 says "the retry interval SHOULD be at least 30 minutes".

Your checker therefore needs a retry queue that comes back later, and a result state for "not answered yet" that is not the same as invalid.

5. Catch-all detection

If a domain accepts every recipient, a 250 for your address means nothing. Detecting this means probing a random, made-up address on the same domain first and remembering the result per domain. It sounds trivial. In practice you must decide how often to re-test, how to handle domains that accept the random probe intermittently, and what to tell the user. Our explainer on catch-all domains covers the logic.

The share is not small. In SimpleVerifier's Email List Health Report 2026, 27.5% of 54,463 domains accepted a made-up address, rising to 60.3% of domains behind an email security gateway.

6. Provider-by-provider behaviour

The large mailbox providers do not behave alike, and they change. From the same report, covering checks between 10 September and 12 October 2026:

Provider	What a mailbox check got
gmail.com	A per-mailbox answer every time a check completed: of 44,298 addresses, 94.0% confirmed and 6.0% rejected, none catch-all
yahoo.com	Every one of 557 addresses accepted, so none could be confirmed
mail.ru	Every one of 950 addresses accepted
live.com, msn.com	Refused the checking connection with Microsoft's S3140 block-list reply when probed on 12 October 2026

An in-house checker needs rules for each of these: which to probe, which to report as unverifiable without probing, and how to notice when one changes its behaviour.

What the conversation looks like

A mailbox check is a short SMTP exchange that stops before any message is sent. Simplified, with the checker's lines first:

EHLO check.example.net
250 mx.recipient.example
MAIL FROM:<probe@check.example.net>
250 2.1.0 OK
RCPT TO:<random-x7k2q@recipient.example>
550 5.1.1 User unknown          <- the domain rejects a made-up address
RCPT TO:<jane.doe@recipient.example>
250 2.1.5 OK                    <- so this "yes" means something
QUIT

If the made-up address had been accepted, the second 250 would prove nothing, and the honest result is risky. Every line of this exchange has failure modes: timeouts, 4xx replies, connections refused because of the checker's IP, and servers that answer differently on the second attempt.

7. Why not VRFY?

SMTP has a command made for this, VRFY. Almost nobody answers it honestly. RFC 5321, section 7.3, lets sites disable it and says such a server "MUST return a 252 response, rather than a code that could be confused with successful or unsuccessful verification". So checkers use RCPT TO inside a mail transaction, and quit before DATA.

Worked example: what building costs

The figures below are assumptions for illustration, not quotes. Replace them with your own rates.

Build:

Item	Assumption	Cost
Initial build of SMTP checking, catch-all detection, retry queue, provider rules	3 engineer-weeks at $1,500 a week	$4,500
Server on a host that allows port 25, with a clean static IP	$20 a month	$240 a year
Ongoing upkeep: IP reputation, provider changes, bug reports	4 hours a month at $75 an hour	$3,600 a year
First-year total		about $8,340

Buy (SimpleVerifier list prices):

Volume	Plan	First-year cost
5,000 addresses a month	Pay-as-you-go, six $19 packs of 10,000	$114
Unlimited, with API	Pro, $29.99 a month	$359.88
Unlimited, with API and 5,000 live phone lookups a month	Email + Phone, $49.99 a month	$599.88

On these assumptions, building costs about 14 times as much as the most expensive bought option in year one, and more than 70 times the pay-as-you-go option. The gap only closes if engineering time is free, which it never is, or if volume is so large that per-address pricing dominates. Our verification cost calculator runs the bought side for other vendors' published prices too.

The hidden cost is worse than the visible one. When your checker's IP lands on a block list on a Friday, signups stall or lists come back "unknown" until someone fixes it.

When building makes sense

Build the mailbox check if at least one of these is true.

Situation	Why it changes the answer
Verification is part of the product you sell	You need control over behaviour, and the upkeep is your core work anyway
Data cannot leave your infrastructure	A contractual or regulatory rule outweighs cost.
Very high volume with a mail team already in place	You already manage IP reputation, PTR records and provider relations
You only need the cheap layers	Syntax, MX, disposable and role checks give most of the value on a signup form

Otherwise, buy the mailbox check and keep the cheap layers in-house.

A hybrid that works

Most teams get the best result from a split design.

1. In your own code: syntax, typo suggestions, MX lookup, disposable and role detection. Instant, free, no network dependency beyond DNS.
2. Through an API: the SMTP mailbox check and catch-all detection, for addresses that pass step 1.
3. On a signup form: give the API call a short timeout. If it does not answer in time, accept the address and check it again later, rather than blocking a real user. Our real-time verification guide covers latency budgets.
4. For lists: upload in bulk, or use a resumable script against the API.

The SimpleVerifier API is included in Pro at $29.99 a month with no per-call fees, and our comparison of email verification APIs covers authentication, timeouts and rate limits across vendors.

Questions to answer before you build

• Where will the checker run, and does that host allow outbound port 25?
• Which IPs will it use, do they have correct PTR records, and are they listed anywhere today?
• How will it detect catch-all domains, and how often will it re-test them?
• What happens on a 4xx: retry when, how many times, and what does the caller see meanwhile?
• Which providers will it skip because they never give a per-mailbox answer?
• Who is on call when an IP gets blocked?

If any of these has no owner, buy.

The short version

Syntax, MX, disposable and role checks are cheap: build them. The mailbox check needs port 25 that the big clouds block, clean IPs, polite rate limits, greylisting retries, catch-all detection and constant attention to how each provider behaves. Unless verification is your product or your data cannot leave your servers, buy that layer, and use your own checks as the first filter in front of it.