Normalization

The normalized field returns a canonical mailbox string you can use for deduplication keys, uniqueness constraints, and fraud checks. EmailGuard applies provider-specific rules whenever the address is parseable into a local part and domain — including cases where syntax validation fails only because the TLD is not in IANA.

The companion boolean subaddressing is true when normalization changed the local part (for example stripping a +tag suffix). See Subaddressing for how to interpret that flag in signup flows.

Why normalize

Users create multiple account rows from one inbox:

• Gmail ignores dots in the local part (j.doe@gmail.com equals jdoe@gmail.com)
• Plus addressing adds tags (user+promo@gmail.com)
• Some providers strip - or _ in addition to dots

Without normalization, your database treats these as distinct people. EmailGuard returns one normalized value per logical mailbox, using provider-aware rules we maintain and expand over time.

How it works

Normalization runs whenever EmailGuard can parse a local part and domain (including invalid-TLD cases). For each address, EmailGuard:

1. Lowercases and canonicalizes the domain (including IDNA conversion).
2. Applies provider-specific alias rules where the mailbox host is a known consumer or hosted-mail provider—collapsing plus-tags, dot aliases, and similar tricks that providers treat as the same inbox.
3. Returns light canonicalization only when no alias rules apply (typical for corporate domains and unknown typo hosts).
4. When a typo suggestion is present, also normalizes suggested_email against the suggested domain so Gmail-style corrections include stripped dots and + tags.

We do not publish an exhaustive provider matrix; coverage improves as we add hosts and alias behaviors. Custom domains and most work email pass through with light canonicalization only.

API examples

Gmail with dots and a plus tag:

curl -sS \
  -H "Authorization: Bearer YOUR_KEY" \
  "https://emailguard.co/api/v1/emails/detect?email=jane.doe%2Bnewsletter%40gmail.com"

{
  "data": {
    "email": "jane.doe+newsletter@gmail.com",
    "syntax_validation": true,
    "normalized": "janedoe@gmail.com",
    "subaddressing": true,
    "public_domain": true
  }
}

Corporate domain (no alias rules applied):

{
  "data": {
    "email": "Pat.Smith@Acme.Corp",
    "syntax_validation": true,
    "normalized": "pat.smith@acme.corp",
    "subaddressing": false
  }
}

Standards context

Plus addressing is widely implemented using the + delimiter described in RFC 5233 (Sieve — Subaddress Extension). Gmail dot aliasing is provider behavior, not an RFC requirement; we document it because it affects deduplication in production signup data.

The addr-spec grammar itself is defined in RFC 5322. Normalization happens after that parse step.

Implementation notes

• Provider-specific normalization never runs when syntax_validation is false.
• When parsing fails completely, normalized echoes the trimmed input.
• When the address parses but the TLD is invalid, normalized uses the parsed local part and lower-case ASCII domain so typo suggestions can still point at the corrected mailbox.
• Use normalized for database unique indexes; keep the original email for audit trails and support lookups.

Related docs

• Subaddressing
• Email detection overview
• Detect email characteristics API
• Normalize plus-addressed emails at signup