How would you validate user-submitted email addresses at ingestion?

WHAT THIS TESTS: This question isn't really about your knowledge of RFC 5322. It's a test of practical judgment and system design. The interviewer wants to see if you understand that perfect validation is impossible and often counterproductive. They are looking for a layered approach that balances data quality with user experience and engineering effort. A senior answer moves from simple string checks to network-level verification and business rules.

A GOOD ANSWER COVERS: A strong answer proposes a multi-layered validation strategy, acknowledging the trade-offs at each step. First, perform simple syntactic validation: check if the string is non-empty, contains exactly one '@' symbol, and has non-empty local and domain parts. Avoid complex regex. Second, perform semantic and network validation by doing a DNS lookup for MX (Mail Exchange) records on the domain. No MX records means the domain can't receive email. Third, apply business logic validation by checking the domain against a blocklist of known disposable email providers (e.g., mailinator.com) to prevent abuse. Finally, mention that the ultimate validation is an asynchronous confirmation loop: sending a verification email with a unique link.

COMMON WRONG ANSWERS: The biggest red flag is trying to write or advocate for a "perfect" RFC 5322 compliant regex. These are notoriously complex, hundreds of characters long, and still fail to cover all edge cases, often rejecting valid emails. This approach shows a lack of practical experience. Another mistake is stopping at a simple '@' check without considering deliverability (MX records) or abuse vectors (disposable emails).

LIKELY FOLLOW-UPS: "How would you implement the MX record check? What are the performance implications?" (Answer: Use a DNS query library; it can be slow and requires caching and timeouts). "How would you maintain the disposable email provider list?" (Answer: Use a third-party service API or a subscription list, with a periodic update job). "What if the MX check times out?" (Answer: Treat it as a temporary failure; either optimistically accept the email and flag for later re-validation, or reject with a user-friendly message).

ONE CONCRETE EXAMPLE: For the email "test@example.com": Syntactic: It has one '@', the local part "test" is not empty, and the domain "example.com" is not empty. Pass. Network: Perform a DNS lookup for MX records on "example.com". Assuming it has them, this passes. A lookup on "example.invalid-domain" would fail. Business Logic: Check if "example.com" is on our disposable provider blocklist. It's not. Pass. Confirmation: Send a welcome email to "test@example.com" with a verification link. The user clicking this is the final proof of validity.