- May 2022
- Engineering Memo · External Release
Email address validation is frequently treated as a binary question — validate or don't validate. The more operationally significant question is when to validate: at the moment of acquisition (when the contact submits their address), at send time (before each campaign), or both. Each approach has different technical requirements, different operational costs, and different effects on the downstream metrics that determine deliverability performance.
This note documents both validation timing approaches, the specific validation checks available at each timing, and the data-driven case for prioritising acquisition-time validation over send-time validation for programmes that must choose one.
Acquisition-Time Validation: Stopping Invalids at the Source
Acquisition-time validation intercepts invalid addresses at the moment a contact submits their email address — on a sign-up form, during a checkout flow, at a lead generation page. The validation runs in real time, before the address enters the database, and can prevent invalid addresses from ever appearing in the contact list. The checks available at acquisition time:
Syntax validation: Confirms the address format matches RFC 5322 — a local part, an @ symbol, and a domain. Catches obvious formatting errors (missing @, spaces in the address, double @) before the form submits. This check is instantaneous and has no network dependency. It should run client-side (JavaScript) for immediate feedback and server-side for robustness against client-side bypass.
Domain MX record check: Queries the DNS for MX records for the address's domain. If the domain has no MX record, no mail can be delivered to it. This check catches addresses at domains that have expired, been created for testing without email configuration, or that do not exist. Requires a network DNS query (typically 100–300ms) that can be performed asynchronously after form submission but before database insertion.
Disposable domain detection: Checks the domain against a maintained list of disposable email address providers (Mailinator, Guerrilla Mail, Yopmail, and hundreds of others). Contacts who sign up with disposable domains have low intent — they want the lead magnet or gated content but not the ongoing email relationship. Blocking these domains at signup reduces complaint rates from this structurally low-intent segment.
SMTP-level mailbox verification (ping): Some commercial validation services can verify whether a specific mailbox exists by initiating a partial SMTP session with the destination mail server — connecting, sending EHLO and MAIL FROM, issuing RCPT TO for the address, and checking the response without actually sending a message. If the server returns 550 5.1.1 at the RCPT TO stage, the mailbox does not exist. This check is the most thorough available at acquisition time but has limitations: some ISPs (notably Gmail) return 250 for all RCPT TO requests regardless of whether the mailbox exists (to prevent harvesting), making ping verification unreliable for Gmail-domain addresses.
Figure 1 — Validation Timing: What Each Approach Catches and Misses
Send-Time Validation: Cleaning Before Delivery
Send-time validation runs after contacts are in the database but before each campaign is sent. The primary use case: cleaning a list that contains addresses acquired without validation (a purchased list, a dormant list that has been inactive for 12+ months, or a legacy list from before validation was implemented). The checks available at send time are similar to acquisition-time checks, but applied at bulk scale through a commercial validation API:
Commercial validation services (Kickbox, NeverBounce, ZeroBounce, and others) accept a list of email addresses and return a validity classification for each: valid (deliverable address, MX record present, mailbox likely exists), invalid (invalid address, domain not found, or SMTP verification returned 550), risky (catch-all domain where SMTP verification can't confirm individual mailbox existence, disposable domain, or role account), or unknown (ISP returns 250 for all RCPT TO requests, preventing verification). The valid and invalid classifications are the most actionable; risky addresses require a judgement call about whether to include them in the send.
Send-time validation has a specific application: before sending the first campaign to a list that has not been emailed in 12+ months. During dormancy, a significant proportion of email addresses in the list will have become invalid — mailboxes abandoned, domains expired, accounts deleted. Validating before the first send prevents the high bounce rate that dormant-list sends generate, which would otherwise damage the IP pool's reputation before the re-engagement campaign has a chance to produce engagement signals.
Send-time validation is expensive at scale. Validating 500,000 addresses through a commercial API costs approximately €150–€300, depending on the service and volume. For programmes that send weekly and have well-managed lists with low bounce rates, the ROI of send-time validation before every campaign is questionable — the cost of weekly validation exceeds the cost of the marginal bounce reduction it would achieve. Send-time validation is most cost-effective as an episodic tool applied to specific situations (dormant list re-engagement, acquired list onboarding) rather than as a routine pre-campaign step for well-managed lists.
The Superiority of Acquisition-Time Validation
When programmes must prioritise one validation timing, acquisition-time validation produces better long-term outcomes than send-time validation for three compounding reasons:
Prevention over remediation. Acquisition-time validation prevents invalid addresses from entering the database. Send-time validation removes them after they are already in. The invalid addresses that slip past acquisition-time validation — primarily addresses that become invalid between signup and the first send — are a much smaller category than the invalids that would have entered the database without any acquisition-time filtering. The prevention cost (API call at signup) is lower per address prevented than the remediation cost (API call at send time) because acquisition-time validation catches more invalids per call — the validation is applied to every new contact, including the high proportion of typos and disposable addresses that formation-time filtering most efficiently catches.
Database quality as a durable asset. A database built with acquisition-time validation accumulates only addresses that passed validation at entry. Over time, this produces a database where the baseline bounce rate is determined primarily by natural address churn (contacts who changed email providers, closed accounts, or moved jobs) rather than by the proportion of invalid addresses that entered without validation. This cleaner baseline produces consistently lower bounce rates across all campaigns, without requiring periodic send-time validation passes to maintain acceptable quality.
Engagement quality correlates with validation intent. Contacts who provide an address that passes multi-point acquisition-time validation — syntax correct, domain valid, MX record exists, not a disposable provider — have demonstrated more intent than contacts who typed any address and submitted. The friction of a more thorough validation process at signup slightly reduces conversion rates but improves the quality distribution of the resulting list. The contacts who complete signup despite the (imperceptible to them) validation checks are, on average, more likely to be genuinely interested than those who sign up with a disposable address or a typo that a permissive form accepts.
Table 1 — Validation approach comparison: cost, coverage, and best use case
| Approach | Cost | What it catches | Best for |
|---|---|---|---|
| Syntax only (acq.) | Zero (client-side JS) | Format errors | All forms — baseline minimum |
| MX + disposable (acq.) | €0.001–0.003/address | Invalid domains, disposables | All consumer-facing forms |
| Full ping validation (acq.) | €0.003–0.008/address | Above + some invalid mailboxes | High-value acquisition flows |
| Bulk validation (send) | €0.30–0.60 per 1,000 | All invalids in existing list | Dormant lists, purchased lists |
| Real-time bounce processing | Infrastructure cost only | Addresses invalid at delivery time | All programmes — always run |
The Complementary Role of Real-Time Bounce Processing
Both acquisition-time and send-time validation have a gap that neither closes: addresses that are valid at validation time but become invalid before delivery. An address that passes acquisition-time validation on January 15 may belong to an inbox that is abandoned and eventually deleted by February 10. By the March campaign, the address is invalid but no validation check since acquisition has flagged it. Real-time bounce processing closes this gap — when the March campaign attempts delivery to the now-invalid address, the 550 5.1.1 hard bounce is immediately recorded and the address suppressed, preventing any further delivery attempts.
Real-time bounce processing is therefore not a substitute for acquisition-time or send-time validation — it is the always-running backstop that catches the invalids that both validation approaches miss. The three practices — acquisition-time validation (prevents invalids entering), send-time validation for specific situations (cleans existing invalids before high-risk sends), and real-time bounce processing (catches new invalids as they occur) — form a complete validation stack that addresses all three categories of invalid address timing. Programmes that implement all three achieve the lowest achievable sustained bounce rates without over-investing in validation at any single timing point.
The investment sequencing for a programme building this validation stack from scratch: implement real-time bounce processing first (highest ROI, prevents the most ongoing reputation damage), then implement acquisition-time validation (prevents new invalids from entering), then use send-time validation episodically for the specific situations described above. This sequence prioritises the highest-return investments first and builds the complete stack over a period of months rather than requiring all three components simultaneously.
Implementing Acquisition-Time Validation in Practice
Acquisition-time validation requires integration at the point where contact data enters the system — typically the web form, mobile app sign-up flow, or API endpoint that accepts email submissions. The implementation approach varies by technical stack, but the pattern is consistent: the email address is submitted, validation checks run, the result is evaluated, and the form either accepts the address (valid) or returns an error message prompting correction (invalid) or a softer message for risky addresses.
For web forms, the validation sequence: (1) client-side JavaScript syntax check on blur (when the user leaves the email field), providing immediate feedback for obvious format errors without a server round-trip; (2) server-side MX and disposable check on form submission, before database insertion. The server-side check is the critical one — client-side validation is advisory and can be bypassed by users or bots submitting the form directly. The server-side check ensures that no address passes validation without completing the domain-level checks that client-side JavaScript cannot perform (DNS queries require a server-side request).
The validation API call latency is typically 200–500ms for MX + disposable checks, which adds negligible time to the form submission experience. If the validation API is unavailable (network timeout), the correct fallback is to accept the address with a deferred validation flag rather than rejecting the submission — users should not experience form failures due to validation service outages. Addresses accepted with deferred validation are flagged in the database for validation before the first send, effectively combining acquisition-time and send-time approaches for the failure-mode scenario.
For high-volume acquisition flows — paid social campaigns that inject thousands of leads per hour, chatbot flows, API integrations with lead generation platforms — the validation API must handle the concurrent request volume without becoming a bottleneck. Most commercial validation APIs support concurrent requests and have rate limits that accommodate high-volume flows, but these limits should be verified before deploying validation in a high-throughput acquisition context. The validation API becoming a bottleneck during a peak acquisition event would be worse than skipping validation for that event.
Catch-All Domains: The Validation Grey Zone
Catch-all domains — domains configured to accept email sent to any local part, regardless of whether the specific mailbox exists — create a challenge for all validation approaches. An SMTP-level ping to a catch-all domain returns 250 OK for any recipient address, regardless of whether the mailbox exists. This means validation correctly identifies the domain as accepting email, but cannot determine whether the specific mailbox (user@catch-all-domain.com) exists or not.
Catch-all domains are common in corporate and small business email environments — particularly for company-hosted domains where the mail server is configured to capture all unrecognised addresses in a single inbox rather than bouncing them. This means that B2B contact lists often contain a significant proportion of catch-all domain addresses — some valid (the specific employee's mailbox exists on the catch-all domain), some invalid (the address was guessed or entered incorrectly but the catch-all accepted the validation ping).
The correct handling of catch-all addresses in validation: classify them as "risky" rather than "valid" or "invalid," and make a programme-specific decision about whether to include them in sends based on the acquisition context. B2B lists where catch-all addresses were acquired through genuine interest signals (content download, webinar registration) can typically include catch-all addresses with lower risk than B2C lists where catch-all addresses may represent a higher proportion of low-quality or guessed contacts. Monitor the bounce rate for catch-all domain addresses specifically to calibrate the correct treatment for the programme's specific audience mix.
The ROI Case for Acquisition-Time Validation
The return on investment for acquisition-time validation can be calculated from the specific reduction in bounce rate it produces and the reputation benefit that lower bounce rate generates. For a programme acquiring 10,000 new contacts per month, with an historical new-contact bounce rate of 2.5% (from unvalidated forms): without validation, 250 new contacts per month generate hard bounce signals at ISPs. With MX + disposable domain validation, approximately 40% of these invalids (those with obvious invalid domains or disposable providers) are filtered at acquisition, reducing the new-contact bounce contribution to approximately 150 per month.
The 100 fewer monthly hard bounce signals translate to a measurable reduction in the accumulated invalid-address signals that ISPs use in reputation assessment. Over 12 months, this represents approximately 1,200 fewer hard bounce signals from new contacts — a meaningful improvement in the programme's ISP signal quality at a validation cost of approximately €30–€100 per month (depending on the validation service and per-request pricing).
The full ROI includes the avoided cost of send-time validation that would otherwise be required to clean up the unvalidated accumulation: at 2.5% monthly bounce rate for new contacts, the unvalidated list grows increasingly bounce-prone over time, eventually requiring a full send-time validation pass to maintain acceptable bounce rates. The cost of that validation pass (typically €150–€600 for a full list of 100,000 contacts) exceeds the accumulated cost of the acquisition-time validation that would have prevented the problem. Acquisition-time validation is not only more effective — it is more economical at scale than the periodic send-time clean-up it replaces.
The choice between validation timings is ultimately a choice between prevention and remediation. Prevention through acquisition-time validation produces cleaner lists, lower sustained bounce rates, and better reputation trajectories at a cost that is typically lower per invalid address prevented than remediation through send-time validation. For programmes implementing validation for the first time, or evaluating whether their current validation coverage is adequate, acquisition-time validation deserves to be the primary investment — supplemented by send-time validation for the specific scenarios where it adds value, and always backed by real-time bounce processing as the always-running backstop that catches what both validation approaches miss.
Validation and Double Opt-In: Complementary Practices
Validation and double opt-in serve related but distinct purposes. Validation confirms that an email address is technically deliverable. Double opt-in confirms that the person who submitted the address can access it and actively wants to receive the programme's communications. A contact who submits a technically valid but misspelled address (gmail.com mistyped as gmai.com) fails validation, catching the error. A contact who submits their correct address but never intends to engage with the programme passes validation but would benefit from the double opt-in filter.
Validation and double opt-in together provide complementary quality signals: validation filters on technical deliverability; double opt-in filters on intent. For programmes where both are implemented, the combination produces the highest-quality subscriber base -- technically valid addresses submitted by contacts who have actively confirmed their interest by clicking the confirmation link. This combination produces the lowest bounce rates, lowest complaint rates, and highest engagement rates of any acquisition practice, at the cost of reduced acquisition conversion rates (some contacts who intend to subscribe never complete the confirmation step).
For programmes that cannot implement both, the priority depends on the acquisition context: consumer programmes with high disposable email address rates benefit most from validation (filtering the technically invalid segment that double opt-in would also catch, but more immediately); B2B programmes where almost all addresses are corporate and technically valid benefit more from double opt-in (filtering the low-intent segment that validation would pass). Understanding the specific quality problems the programme faces -- primarily technical invalids, or primarily low-intent contacts -- guides the prioritisation between validation and double opt-in when both cannot be implemented simultaneously.
Validation is the technical layer of list quality management; double opt-in is the intent layer. Together, they address the two distinct categories of list quality problems that generate the bounce rates and complaint rates that damage deliverability. Implementing both, starting with the layer that addresses the programme's dominant quality problem, is the quality management approach that produces the most durable list quality improvement over time. The investment in either or both -- measured in API cost, conversion rate reduction, or engineering time -- is consistently returned through the reputation improvement, inbox placement gains, and reduced remediation costs that clean, validated lists produce.
The timing of validation -- at acquisition, before each send, or at delivery via bounce processing -- is the architectural decision that determines the quality trajectory of the email list over time. Get the architecture right: prevent invalids at the source with acquisition-time validation, clean specific problem scenarios with targeted send-time validation, and catch everything else in real-time with bounce processing. The combination is the complete validation stack that sustains list quality as the programme grows without requiring constant reactive remediation.
List validation is not a one-time event but a continuous practice embedded at multiple points in the contact lifecycle. The programmes that validate consistently -- at acquisition, before high-risk sends, and through real-time bounce processing -- maintain the list quality that makes every infrastructure investment produce its intended return. Those that validate reactively -- only when bounce rates have already damaged reputation -- spend more on remediation than prevention would have cost, and recover more slowly than prevention would have allowed. The timing decision matters; acquisition-time validation first, always backed by real-time bounce processing, is the correct default for most programmes.
Infrastructure Assessment
Our managed infrastructure includes real-time bounce processing as standard, with guidance on acquisition-time validation integration for client sign-up flows and episodic send-time validation for dormant and acquired list scenarios. Request assessment →