How We Check Live MX Records in Under 50ms using Cloudflare Workers

When building an email validation API, speed is the ultimate feature. If your API takes 3 seconds to validate an email, the user abandons your signup form. The challenge is that live DNS lookups (checking MX records to see if an email domain actually exists) are notoriously slow.

Here is how we architected EmailGuard to perform deep validation—including MX record lookups and typo-squatting detection—in under 50ms.

1. The Edge Computing Advantage

Traditional APIs sit in a centralized database (like AWS us-east-1). If a user from Tokyo pings your API, they suffer 200ms of latency just in geographical travel time.

By deploying our validation logic entirely on Cloudflare Workers, the API code executes on the edge node physically closest to the user. A user in Tokyo hits a server in Tokyo. Geographic latency drops to near zero.

2. DNS-over-HTTPS (DoH) Fallbacks

To check if a domain can actually receive mail, we must ask the internet's DNS system for `MX` (Mail Exchange) records. To do this serverlessly, we use DNS-over-HTTPS.

Our Worker concurrently queries Cloudflare DNS (1.1.1.1) and falls back to Google DNS (8.8.8.8). To ensure our API never hangs a customer's frontend, we wrap these external fetch calls in an AbortController. If the upstream DNS hangs for more than 2.5 seconds, we fail gracefully with a 424 Failed Dependency status, allowing the signup to proceed rather than breaking the UX.

3. In-Memory Caching (The Fast Path)

80% of your users sign up with gmail.com or outlook.com. It makes no sense to perform an external DNS lookup for Gmail 10,000 times a second.

We implemented a V8 in-memory Map() cache inside the Cloudflare Worker. When an MX record is verified once, it is stored in the Worker's memory cache. Subsequent lookups for that domain resolve locally in less than 5ms.

4. Levenshtein Distance Optimization

To catch typos (like gmil.com), we run a Levenshtein distance algorithm against an array of major providers. Because this algorithm is O(n*m) and CPU-intensive, we implemented a dynamic threshold: short domains only allow a distance of 1, while long domains allow 2. Furthermore, exact matches hit a `break` statement instantly, skipping the heavy math entirely.