How to Use Mailgun's Validation API Without Blocking Real Signups

Mailgun's validation API runs a multi-layered check, syntax, DNS, mailbox detection, and reputation analysis, and returns a result with real nuance: confirmed valid, confirmed invalid (bad syntax, nonexistent domain), and a middle category covering catch-all domains and other addresses it can't fully confirm either way. The most common mistake isn't using the API incorrectly, it's building signup logic that treats everything short of a confirmed valid result as a rejection, which throws away the nuance the check actually provides. Here's a setup that uses it properly.

For background on Mailgun's pricing and how it compares to SendGrid or Postmark, see our full Mailgun profile.

Step 1: Decide Whether You're Validating at Capture or Cleaning an Existing List

Treat real-time validation at the point of signup and bulk validation of an already-existing list as two separate problems with two separate Mailgun features, the validation API for the former, CSV-based bulk validation for the latter, rather than assuming one implementation covers both. A business migrating or auditing an existing database needs the bulk tool first, since the point-of-capture integration only protects addresses added going forward and does nothing for a list that's already accumulated bad addresses over time.

Step 2: Integrate Real-Time Validation at the Actual Point of Capture

Call Mailgun's validation API directly from the signup form, CRM entry point, or application flow where an email address is first collected, rather than validating only after the address has already been added to a sending list. Catching a problem before the address enters your system is a fundamentally different (and cheaper) intervention than discovering it later through a bounce, since a bounce has already cost a send and a small hit to sender reputation that point-of-capture validation avoids entirely.

Step 3: Hard-Block Only Confirmed Invalid Results

Reject a submission outright only for results Mailgun's check confirms unambiguously, a clear syntax error or a confirmed nonexistent domain, since these carry little risk of blocking a real, working address. This is the category where a hard block genuinely costs nothing, an address that fails basic syntax or resolves to no real domain at all was never going to receive a real email regardless of how the form responds to it.

Step 4: Treat a Catch-All Result as a Warning, Not a Rejection

For addresses on a catch-all domain, where Mailgun's check genuinely cannot confirm whether the specific mailbox exists because the domain accepts mail to any address, show a warning asking the user to double-check their entry rather than blocking the submission outright. A catch-all domain is a mail server configuration choice, not evidence the address is fake, and it's reportedly common on corporate and business domains specifically, which means a hard block here disproportionately filters out legitimate business signups rather than catching real problems.

Step 5: Accept the Address if the Validation Call Times Out or Fails

Configure the signup flow to accept an address by default if the validation API call itself fails to return a result in time, rather than defaulting to rejection on a timeout. A validator hiccup is a problem with the check, not evidence about the address, and treating an infrastructure failure on Mailgun's or your own integration's side as grounds to reject a real user's signup punishes them for a problem that has nothing to do with their actual email address.

Step 6: Reserve Disposable-Domain Detection for a Clear Block, With a Clear Message

When the validation check flags an address as coming from a known disposable or temporary email domain, this is a reasonable case for a hard block, since a disposable address is deliberately short-lived and unlikely to receive anything meaningful after initial signup. Pair the block with a clear, specific message explaining that temporary email addresses aren't accepted, rather than a generic "invalid email" error, since a user using a disposable address on purpose understands that message differently than one who's being incorrectly told their real, permanent address is invalid.

Step 7: Run Bulk Validation on Any Existing List Before Relying on This Flow Going Forward

Before treating a newly implemented point-of-capture validation flow as the complete fix, upload the existing list through Mailgun's bulk CSV validation to identify and address already-accumulated bad addresses, since the new real-time flow only governs what gets added from this point forward. Skipping this step means a business can have a well-configured capture-time flow sitting on top of a list that's still carrying years of accumulated invalid or disposable addresses from before that flow existed.

Step 8: Budget for Validation as a Metered Cost Separate From Sending

Confirm whether the plan tier in use bundles validation calls or bills them separately, since on Mailgun's Foundation plan, validation is metered on top of the base sending cost rather than bundled in, only becoming included at the Scale tier and above. A business running real-time validation on every signup at meaningful volume should factor this into its actual Mailgun budget rather than assuming validation comes free alongside the sending plan already being paid for.

Step 9: Track Validation Result Categories as Their Own Metric

Log how many submissions fall into each validation category, confirmed valid, catch-all, disposable, confirmed invalid, as an ongoing metric, rather than only checking bounce rate after sends go out. This is the only reliable way to catch a validation flow quietly costing more conversions than expected: a rising share of catch-all results being silently blocked, for instance, would show up here long before it would show up in any aggregate conversion-rate dashboard that doesn't break the number down this specifically.

Test the Full Flow With Deliberately Chosen Edge-Case Addresses

Before relying on this setup in production, test it with a deliberately chosen set of edge cases rather than only a normal, clearly valid address: a known catch-all domain, a disposable email provider, a syntactically malformed address, and a domain likely to trigger a slow or failed validation response. Confirming each case produces the intended response, a warning for the catch-all, a block for the disposable address, acceptance on a timeout, catches a misconfigured response rule before a real user encounters it rather than after, which is a meaningfully cheaper place to find a mistake in this logic.

Revisit the Policy Periodically as Your Customer Mix Changes

Treat the specific thresholds and response rules configured in this flow as something to revisit periodically rather than a one-time setup decision, since a business's mix of signups, more B2B over time, a new market with different common email providers, can shift how often ambiguous results like catch-all domains actually occur. A validation policy tuned correctly for one customer mix can quietly become miscalibrated as that mix changes, either blocking more real signups than intended or letting through more genuinely risky addresses, and a periodic review of the validation-category metrics from Step 9 is what actually catches that drift before it becomes a real problem.

A Few Mistakes That Undermine This Setup

A handful of habits reliably undo an otherwise well-built validation flow. Treating every non-"confirmed valid" result as a rejection, the single most common mistake, throws away the nuance Mailgun's multi-layered check actually provides and costs real signups on catch-all and ambiguous domains specifically. Running only point-of-capture validation while never bulk-cleaning an existing list leaves years of accumulated bad addresses untouched. And failing to track validation result categories as their own metric means a quietly over-aggressive blocking policy can run for a long time before anyone notices the conversions it's costing.

What This Setup Actually Produces

Built this way, real-time validation at the actual point of capture, hard blocks reserved for genuinely confirmed problems, catch-all and ambiguous results treated as warnings rather than rejections, and bulk cleaning applied to the existing list separately, this setup gets the real benefit of email validation, catching genuinely bad addresses before they become bounces, without its most common, avoidable cost: quietly rejecting real customers whose only mistake was having an email address a validator couldn't fully confirm.

If you're deciding whether Mailgun's deliverability toolkit fits better than SendGrid's broader platform or Postmark's transactional-only focus, our Top 3 Transactional Email Platforms comparison covers that tradeoff in more detail.