EmailGuard

Knowledge base

Valid syntax

How EmailGuard validates addr-spec syntax under RFC 5322 and RFC 5321, converts IDNA domains, and exposes syntax_validation in the detect API.

The syntax_validation field tells you whether an address is structurally valid before you store it or send mail. EmailGuard applies RFC-aware parsing, internationalized domain conversion, and continuously updated domain intelligence so obviously invalid addresses fail before they reach your database.

When syntax fails, the API still returns 200 OK with "syntax_validation": false. Downstream flags (role_address, disposable, and so on) are not meaningful until syntax passes.

Standards we apply

RFC 5322 — Internet Message Format

RFC 5322 defines the addr-spec grammar: a local part, @, and a domain. EmailGuard parses the full address with an RFC 5322-aware parser that handles quoted local parts and the messy formats developers paste from CRM exports and signup forms.

We reject addresses that violate practical addr-spec constraints after parsing, including:

  • Missing or misplaced @
  • Empty local part or domain
  • Leading, trailing, or consecutive dots in the local part
  • Domains without a dot or with invalid dot placement

RFC 5321 — SMTP size limits

RFC 5321 limits mailbox sizes on the wire. EmailGuard enforces:

PartMaximum length
Local part64 octets
Domain255 octets

Addresses longer than these limits return "syntax_validation": false even if they look plausible in a UI field.

Internationalized domain names (IDNA)

Unicode domains are converted to ASCII using IDNA2008 lookup rules (RFC 5890, RFC 5891). The domain field in the API response is always the punycode-normalized, lower-case form (for example bücher.example → xn--bcher-kva.example).

Internationalized local parts (SMTPUTF8) are outside what EmailGuard validates today; see RFC 6531 and RFC 6532 for that extension.

Domain and suffix validation

Syntax validation goes beyond a simple @ split. EmailGuard combines several maintained data sources so domain labels reflect how mail actually works on the public internet:

  • IANA root zone data — we validate top-level and delegated suffixes against the official root zone, kept current as new gTLDs and ccTLDs are delegated.
  • Public Suffix List — we use the PSL (and related registry data) to understand registrable domains vs multi-tenant suffixes such as *.github.io, so typos and pseudo-domains do not pass as corporate mail.
  • Additional domain intelligence — third-party and internally maintained feeds augment the public lists for high-churn TLDs and other edge cases that pure RFC parsing alone would miss.

Together, these layers catch addresses that look plausible in a text field but cannot represent a deliverable mailbox on the open internet.

API usage

curl -sS \
  -H "Authorization: Bearer YOUR_KEY" \
  "https://emailguard.co/api/v1/emails/detect?email=not-an-email"
{
  "code": "OK",
  "data": {
    "email": "not-an-email",
    "syntax_validation": false,
    "normalized": "not-an-email",
    "subaddressing": false,
    "role_address": false,
    "public_domain": false,
    "relay_domain": false,
    "disposable": false,
    "domain": "",
    "detection_source": "precomputed"
  }
}

Valid example:

curl -sS \
  -H "Authorization: Bearer YOUR_KEY" \
  "https://emailguard.co/api/v1/emails/detect?email=pat%40example.com"
{
  "data": {
    "email": "[email protected]",
    "syntax_validation": true,
    "domain": "example.com"
  }
}

What syntax validation is not

  • Not mailbox existence. Syntax does not prove the inbox accepts mail (RFC 5321 RCPT probing is a separate class of check).
  • Not deliverability scoring. No bounce prediction or reputation signals.
  • Not DNS MX verification. MX lookup is used for disposable and relay classification, not for the syntax bit itself.

Use syntax_validation as a cheap gate at signup; combine with disposable and role flags for policy.

Related docs