EmailGuard

Knowledge base

Normalization

How the normalized field collapses provider-specific aliases so duplicate signups map to one mailbox, and when subaddressing is set.

The normalized field returns a canonical mailbox string you can use for deduplication keys, uniqueness constraints, and fraud checks. EmailGuard applies provider-specific rules after syntax validation succeeds.

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:

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 only after syntax validation succeeds. 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 the original input unchanged in structure when no alias rules apply (typical for corporate domains).

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": "[email protected]",
    "syntax_validation": true,
    "normalized": "[email protected]",
    "subaddressing": true,
    "public_domain": true
  }
}

Corporate domain (no alias rules applied):

{
  "data": {
    "email": "[email protected]",
    "syntax_validation": true,
    "normalized": "[email protected]",
    "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

  • Normalization never runs when syntax_validation is false; normalized echoes the trimmed input instead.
  • Use normalized for database unique indexes; keep the original email for audit trails and support lookups.

Related docs