---
title: "What makes an email address valid: four layers"
url: "https://lookvalid.com/blog/industry/what-makes-an-email-address-valid.md"
canonical_url: "https://lookvalid.com/blog/industry/what-makes-an-email-address-valid"
last_updated: "2026-10-22"
type: "conceptual"
summary: "Valid syntax, a working domain, a real mailbox and safety to send are four separate questions. See what each layer proves, with RFC references and a sample."
related: ["https://lookvalid.com/products/email-domain-check.md", "https://lookvalid.com/tools/email-domain-checker.md", "https://lookvalid.com/docs/quickstart.md", "https://lookvalid.com/glossary/mx-record.md", "https://lookvalid.com/glossary/smtp-verification.md"]
---

# What makes an email address valid: four layers

Valid syntax, a working domain, a real mailbox and safety to send are four separate questions. See what each layer proves, with RFC references and a sample.

People say an address is valid and mean four different things. The address may be well formed, its domain may accept mail, its mailbox may exist, or sending to it may be a good idea. Each is a separate layer with its own evidence, and a check that blurs them gives answers nobody can act on.

## Layer one: syntax

RFC 5322 defines an address as a local part, an at sign and a domain. The local part is a dot-atom or a quoted string, and the standard says the dot-atom form should be used whenever the local part can be written that way [1]. RFC 5321 adds length limits for the SMTP envelope: 64 octets for the local part, 255 for the domain and 256 for the whole path [2]. The path includes two angle brackets, so a plain address tops out at 254 characters, the limit our check applies.

RFC 6531 extends SMTP so that mailbox names may be UTF-8, signalled by the `SMTPUTF8` keyword in the server greeting. A client must not send an internationalized address to a server that did not advertise the extension [3]. Syntax therefore covers more than ASCII, but delivery to such an address depends on the receiving server.

Syntax proves only that the string could be an address. Our check accepts Unicode letters and digits in the local part and rejects quoted local parts and bracketed domain literals as input, so an address that is legal under RFC 5322 can still be refused as invalid input. Rejections of that kind are never billed.

## Layers two to four

The second layer asks whether the domain can receive mail. A sender looks up MX records; if there are none, RFC 5321 says the domain is treated as if it had an implicit MX pointing at its own host [2]. A domain can declare that it takes no mail with a null MX, a single record with preference 0 and the root label, which tells senders the domain accepts no mail [4].

The third layer, whether the mailbox exists, can only be answered by the receiving server, and it may decline to say. RFC 5321 lets a server accept a recipient and report a problem later, and a relay that accepts a message and then cannot deliver it must send a non-delivery notice [2]. The same RFC forbids a server from answering a verification command with success unless it actually verified the address [2]. No outside party can reliably tell you more.

The fourth layer is a judgment about risk: is this a disposable domain, a shared role mailbox such as info@, or a free provider? Those are properties of the domain and the local part, answerable from lists, and they do not prove anything about delivery.

What each layer proves and what it cannot

| Layer | Evidence | Proves | Does not prove |
| --- | --- | --- | --- |
| Syntax | RFC 5322 grammar, RFC 5321 lengths, RFC 6531 for UTF-8 | The string is shaped like an address | That the domain exists |
| Domain | DNS: MX, address records, null MX | Where mail would go, or that it will not | That any mailbox exists |
| Mailbox | The receiving server, at delivery time | Acceptance or a later bounce | That a person reads it |
| Safe to send | Lists of disposable, free and role addresses | The address is risky to use | That a clean address will deliver |

## A domain-check sample

The `email-domain-check` product covers layers one, two and four. It checks syntax, reads MX, SPF and DMARC records from public DNS, and compares the domain and local part against open lists. It never contacts the mail server, so its `smtp_checked` field is always false and layer three stays open.

Check one address

```bash
curl -X POST https://YOUR_API_HOST/v1/email-domain-check \
  -H "Authorization: Bearer $LOOKVALID_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"email":"info@example.com"}'
```

Part of a captured response for info@example.com

```json
{
  "syntax_valid": true,
  "domain": "example.com",
  "has_mx": false,
  "null_mx": true,
  "role_account": true,
  "smtp_checked": false,
  "deliverability_signal": "undeliverable",
  "deliverability_reasons": [
    { "code": "null_mx", "message": "The domain publishes a null MX record, which means it does not accept email." },
    { "code": "role_account", "message": "The address is a shared role mailbox such as info@ or support@, not a person." }
  ]
}
```

Here the syntax is fine but the domain publishes a null MX, so layer two fails and the signal is `undeliverable`. The signal is `good` only when MX records exist and no risk check matched, and the reason text for that case says the mailbox itself was not checked.

## Putting the layers to work

Use syntax at the form field, the domain layer at import, and the risk layer when you decide how to treat an address. Keep layer three for the sending pipeline: a bounce is the only evidence there. Try a single address in the [email domain checker](https://lookvalid.com/tools/email-domain-checker.md), or call the [email-domain-check product](https://lookvalid.com/products/email-domain-check.md) from your own code with the [quickstart](https://lookvalid.com/docs/quickstart.md).

## Sources

1. [RFC 5322: Internet Message Format](https://www.rfc-editor.org/rfc/rfc5322), read 2026-10-19
2. [RFC 5321: Simple Mail Transfer Protocol](https://www.rfc-editor.org/rfc/rfc5321), read 2026-10-19
3. [RFC 6531: SMTP Extension for Internationalized Email](https://www.rfc-editor.org/rfc/rfc6531), read 2026-10-19
4. [RFC 7505: A "Null MX" No Service Resource Record for Domains That Accept No Mail](https://www.rfc-editor.org/rfc/rfc7505), read 2026-10-19

By LookValid engineering. Published 2026-10-19, updated 2026-10-19.

## Related

- [Email Domain Check API](https://lookvalid.com/products/email-domain-check.md)
- [Free email domain checker (MX, SPF, DMARC)](https://lookvalid.com/tools/email-domain-checker.md)
- [Quickstart](https://lookvalid.com/docs/quickstart.md)
- [What is MX record (Mail Exchanger record)?](https://lookvalid.com/glossary/mx-record.md)
- [What is SMTP verification?](https://lookvalid.com/glossary/smtp-verification.md)