HN Debrief

Lies we tell ourselves about email addresses

  • Programming
  • Infrastructure
  • Security
  • Developer Tools

The post is a tour of common programmer assumptions about email addresses that stop being true the moment you leave the happy path. It covers things like quoted local parts, non-ASCII addresses, IP literals, plus aliases, long or unusual TLDs, and the gap between what the RFCs allow and what real products accept. The practical advice is simple: do as little syntactic filtering as possible, then verify by sending mail instead of trying to prove correctness up front.

If your product collects email addresses, verify ownership instead of hard-rejecting unusual but valid formats, and audit every downstream system that touches them. Also treat email as unreliable infrastructure for login and recovery, not an instant, universal transport you can safely build UX around.

Discussion mood

Mostly sympathetic and slightly exasperated. People agreed the post was directionally right because they have repeatedly hit broken validators in the wild, especially around new TLDs, plus addressing, and subdomains. The frustration deepened around products that skip ownership verification or force email-based login flows that assume instant delivery and same-device access.

Key insights

  1. 01

    New TLDs still break production systems

    Long TLDs are not an edge case in practice. People using .healthcare, .consulting, .company, and .email reported that major companies and even healthcare systems rejected their addresses or treated them as invalid. That turns a naming choice into an operational liability. A domain that looks modern or brand-friendly can still be toxic to forms, SSO, and support workflows years later.

    If email reliability matters, test your domain choice against real signup and vendor flows before you commit. For customer-facing products, keep a boring .com fallback if you can.

      Attribution:
    • frereubu #1
    • dspillett #1
    • connorgurney #1
    • julian_t #1
    • dijit #1
    • thih9 #1
  2. 02

    Catch-all aliases are useful beyond spam

    Owning your own domain and accepting arbitrary aliases gives you much more than disposable addresses. People use it to trace leaks, disable compromised aliases, share a single address with a spouse for schools and insurance, and route messages cleanly by purpose. The important nuance is that catch-alls work best when aliases are disposable and revocable. They are less useful as a pure anti-spam trick because spammers can guess common names once they know the domain accepts everything.

    If your users value control over inbound mail, alias support is a real product feature, not a nerdy edge case. If you run your own domain, prefer explicit aliases you can turn off over a permanent open catch-all.

      Attribution:
    • greengreengrass #1 #2
    • FLHerne #1
    • garaetjjte #1
    • kurttheviking #1
    • scottmcmac #1
    • mesrik #1
    • UltraSane #1
  3. 03

    Unverified ownership causes real privacy failures

    The damage from bad email handling is not limited to failed signups. People with common or early-issued addresses described receiving contracts, invoices, student loan paperwork, sports venue access details, gambling accounts, and drug program messages that belonged to someone else. That happens because many systems treat "string entered into a form" as "verified contact point" and start sending sensitive mail immediately. The product bug is not fancy parsing. It is skipping proof that the recipient actually controls the inbox.

    Do not send sensitive data or complete account setup until the address has been confirmed. Audit legacy systems and vendor tools that still treat unverified email as good enough.

      Attribution:
    • riddley #1
    • cestith #1
    • undebuggable #1
    • zephen #1
    • tracker1 #1
    • rmunn #1
    • Semaphor #1
  4. 04

    Email login flows are brittle security theater

    Using emailed links or one-time codes as the primary login path creates a fragile UX and often a weaker security model than teams admit. People pointed out delayed delivery, spam filtering, same-device assumptions, browser-profile mismatches, auto-opened verification links, and the absurdity of locking users out of the service they need to access their email. For many users with password managers or passkeys, forced magic-link flows are not simplification. They are added failure modes.

    Offer passwords or passkeys alongside email-based recovery. If you send action links by email, make the server side idempotent and avoid flows that depend on immediate delivery or a single device.

      Attribution:
    • amiga386 #1
    • Terr_ #1
    • technion #1
    • CPLX #1
    • paradox460 #1
    • atoav #1
    • Ekaros #1
  5. 05

    Self-hosted mail is viable with modern DNS hygiene

    People running their own domains pushed back on the idea that outbound mail is basically impossible for small operators. The consistent advice was that the hard part is not SMTP itself. It is IP reputation and correct SPF, DKIM, and DMARC setup. A decent VPS host with a stable IP can be enough. Using an established provider for outbound mail also works if you do not want to manage reputation directly.

    If you self-host or support custom domains, treat deliverability as a DNS and reputation problem first. Budget time for SPF, DomainKeys Identified Mail, Domain-based Message Authentication, Reporting, and Conformance, and stable outbound infrastructure.

      Attribution:
    • picofarad #1
    • greengreengrass #1
    • mrighele #1
  6. 06

    LLMs still reinforce bad validator habits

    Asking an LLM for an email regex often produces exactly the kind of overconfident, overfitted validator the post warns against. Even when the model says no regex is perfect, it still tends to hand developers a more complicated pattern than they need, which nudges them back toward blocking valid addresses. The issue is not just wrong syntax. It is that the tooling keeps feeding the instinct that email should be solved with one clever pattern.

    Do not delegate email policy to generated regex snippets. Set a product rule instead: minimal format check, verify by email, and keep warnings non-blocking where possible.

      Attribution:
    • Freak_NL #1 #2
    • FinnKuhn #1

Against the grain

  1. 01

    Early validation can save real users

    Rejecting overly strict formats is bad, but doing nothing until after a verification email is also sloppy for consumer UX. Some people simply mistype or misremember their address, never get the message, and assume your product is broken. Immediate hints like typo suggestions or soft warnings catch a large share of those failures at the moment they can still be fixed. That is a better use of validation than pretending you can prove full correctness.

    Keep the validator permissive, but add typo detection and "did you mean" prompts for common mistakes. Measure whether those prompts reduce failed onboarding before you strip them out.

      Attribution:
    • farfatched #1 #2
    • layer8 #1
    • account42 #1
  2. 02

    Verification mail can be abused at scale

    Blindly firing off verification emails on every signup attempt creates its own deliverability risk. Bad actors can use signup forms to generate bounces and reputation damage, and major providers do care about patterns of undeliverable mail. The stronger point here is not to restore strict regexes. It is that signup abuse controls and sending reputation are part of the email-validation problem too.

    Put rate limits, abuse detection, and sender reputation monitoring in front of verification email. Treat verification as part of an anti-abuse pipeline, not a free side effect of account creation.

      Attribution:
    • jiveturkey #1 #2
    • trumpdong #1
    • AndroTux #1 #2
  3. 03

    Ignoring rare edge cases is often reasonable

    A few commenters argued that product teams should not contort mainstream software around obscure RFC-valid forms like source routing, quoted local parts with embedded @ signs, or literal IP domains. Those addresses are technically real, but almost nobody uses them for ordinary SaaS accounts, and supporting them can create downstream bugs in systems that were never built for that complexity. The useful boundary is between rejecting common real-world addresses and declining ancient protocol oddities.

    Expand support for formats real customers actually use, especially aliases, subdomains, and modern TLDs. Be explicit if you choose not to support archaic RFC-only forms, and do not let that justify breaking common ones.

      Attribution:
    • dvh #1
    • ale42 #1
    • account42 #1
    • echoangle #1

In plain english

ASCII ↩
American Standard Code for Information Interchange, a basic character set used by older computer systems and many Internet protocols.
DKIM ↩
DomainKeys Identified Mail, a system that cryptographically signs email so receivers can verify it was authorized by the sending domain.
DMARC ↩
Domain-based Message Authentication, Reporting, and Conformance, a policy that tells receivers how to handle mail that fails SPF or DKIM checks.
RFC ↩
Request for Comments, the formal documents that define many Internet standards and protocols.
SPF ↩
Sender Policy Framework, a DNS-based rule that says which servers are allowed to send email for a domain.
SSO ↩
Single Sign-On, a login system that lets one identity provider authenticate a user across multiple services.
VPS ↩
Virtual Private Server, a rented virtual machine used to host applications or services on the Internet.

Reference links

Background reading on address falsehoods and regex

Standards and protocol references

Hosting and self-hosting tools

Comics and cultural references

  • xkcd 1279
    Used to support the claim that many people accidentally use someone else's Gmail address.
  • xkcd 1172
    Used jokingly to argue that some RFC-valid email forms are too pathological to care about in product design.