Email Address Normalization Prompt Template

This prompt is designed for CRM integrators, data engineers, and identity resolution teams who need to clean and standardize email addresses produced by large language models. The core job-to-be-done is transforming a raw, potentially malformed email string from a model's output into an RFC-compliant, deduplicatable identifier suitable for ingestion into a customer data platform or system of record. It handles common model failure modes such as hallucinated domains, missing '@' symbols, inconsistent alias handling (plus-addressing), and the inclusion of display names or angle brackets. Use this when your pipeline receives email addresses as part of a larger unstructured or semi-structured model response, and you cannot trust the upstream model to have performed validation itself.

You should reach for this prompt when downstream systems require strict format compliance (e.g., a CRM API that rejects invalid emails) or when you need to deduplicate contacts across multiple sources. The prompt is built to resolve common ambiguities: it normalizes Gmail's dot-ignoring behavior, strips sub-addresses when instructed, corrects known domain typos (e.g., 'gmial.com' to 'gmail.com'), and flags disposable email addresses from a reference list. It is not a replacement for a full email verification service (SMTP check, mailbox existence), but it acts as a critical pre-flight repair step that reduces downstream validation failures and duplicate records. The ideal user is an engineer building a data pipeline who needs a reliable, testable normalization function that can be evaluated against a golden dataset of known inputs and expected outputs.

Do not use this prompt for real-time user-facing validation during account sign-up. In that context, a deterministic library running client-side is faster, cheaper, and more predictable. This prompt is also inappropriate for generating or inferring email addresses that were not present in the input; its job is normalization, not enrichment. Avoid using it as a spam classification tool—while it detects disposable domains, it does not assess email reputation or deliverability. Finally, if your pipeline handles Personally Identifiable Information (PII) subject to GDPR or similar regulations, ensure that the prompt's execution environment and logging practices are compliant. The prompt itself should not log or store raw email addresses outside of approved data processing boundaries. Before deploying, pair this prompt with a validation harness that checks for false-positive domain corrections and unintended alias stripping, as these are the most common production failure modes.

This template provides the core instruction set for an LLM to act as an email normalization engine. It accepts a raw email address string—often malformed, inconsistently cased, or containing display names—and returns a structured JSON object with the normalized address, domain correction flags, alias resolution, and disposable email detection. The prompt is designed to be dropped into a post-generation repair pipeline where upstream model outputs require canonicalization before ingestion into a CRM, CDP, or identity resolution system.

codeCopy
SYSTEM:
You are an email normalization engine. Your job is to take a raw email address string and return a strictly valid JSON object following the [OUTPUT_SCHEMA]. Apply the normalization rules below. Do not invent information. If the input is not a valid or repairable email address, set the `valid` field to `false` and provide a reason.

NORMALIZATION RULES:
1. Trim whitespace and remove display names (e.g., "John Doe <john@example.com>" becomes "john@example.com").
2. Lowercase the local part and domain.
3. For known provider domains (Gmail, Googlemail, Outlook, Hotmail, Yahoo, Yandex, Protonmail, Zoho, iCloud, Fastmail):
   a. Remove dots from the local part for Gmail/Googlemail addresses.
   b. Resolve plus-address aliases by extracting the base address and the tag separately.
   c. Correct common domain typos using the [DOMAIN_CORRECTION_MAP].
4. Flag the address if the domain is a known disposable email provider from [DISPOSABLE_DOMAIN_LIST].
5. Flag the address if the domain has invalid MX records based on [MX_CHECK_RESULTS].
6. Do not alter the domain for non-provider addresses beyond lowercasing and typo correction.

[OUTPUT_SCHEMA]:
{
  "original": "string (the raw input)",
  "normalized": "string (the cleaned email address)",
  "valid": "boolean",
  "reason": "string (explanation if invalid)",
  "flags": {
    "is_disposable": "boolean",
    "is_plus_address": "boolean",
    "plus_tag": "string | null",
    "domain_corrected": "boolean",
    "original_domain": "string | null",
    "mx_valid": "boolean | null"
  },
  "base_address": "string | null (the address without plus tag, if applicable)"
}

[CONSTRAINTS]:
- Return ONLY the JSON object. No markdown fences, no commentary.
- If the domain was corrected, set `domain_corrected` to `true` and include the `original_domain`.
- If the input is irreparably malformed (e.g., missing @, invalid characters after cleaning), set `valid` to `false` and `normalized` to `null`.

USER:
Normalize this email address: [INPUT]

To adapt this template, replace the square-bracket placeholders with your specific configuration. [INPUT] receives the raw email string from your upstream model output. [DOMAIN_CORRECTION_MAP] should be a JSON object mapping common typos to correct domains (e.g., {"gmial.com": "gmail.com", "yaho.com": "yahoo.com"}). [DISPOSABLE_DOMAIN_LIST] should be a JSON array of known disposable email domains. [MX_CHECK_RESULTS] should be a boolean or null value from your DNS validation layer. If you don't have MX check infrastructure, remove that rule and the mx_valid field from the schema. For high-volume pipelines, consider caching the domain correction map and disposable domain list outside the prompt to reduce token usage and latency.

This prompt is designed to be called as a post-generation repair step, not as the primary extraction prompt. The typical integration pattern is: (1) your upstream model or pipeline produces a raw email string, (2) you run basic syntax validation, and (3) if validation fails or you require canonicalization, you invoke this prompt with the raw email as [INPUT]. This separation keeps your primary prompt fast and delegates normalization to a dedicated, testable step that can be versioned and monitored independently.

Wire the prompt into an idempotent normalization function that accepts a raw email string and returns a structured result. The function should: validate the input is a non-empty string, call the LLM with the prompt template, parse the JSON response, and validate the output against an expected schema (normalized_email, normalization_performed, disposable, warnings). If the model returns malformed JSON, use a JSON repair step (from the Malformed JSON and Structured Format Repair pillar) before retrying. Implement a maximum of 2 retries with exponential backoff; if normalization still fails, return the original email with normalization_performed: false and a warnings entry indicating repair failure. This prevents the normalization step from becoming a blocking failure point in your pipeline.

For domain correction, maintain an allowlist of known provider domains (gmail.com, yahoo.com, outlook.com, etc.) and their common typos. The prompt should only correct domains when there is a high-confidence match against this list. Log every domain correction with the original and corrected values for auditability. For plus-address handling (e.g., user+tag@domain.com), the prompt should preserve the local part but note the alias in normalization_performed. If your application requires alias stripping, make this a configurable parameter passed via [CONSTRAINTS] rather than hardcoding it into the prompt. This lets different downstream systems apply different alias policies without maintaining separate prompts.

Disposable email detection should be treated as a flag, not a block. The prompt returns disposable: true when the domain matches known disposable providers. Your application harness should decide whether to reject, quarantine, or flag these records based on business rules. Maintain a regularly updated disposable domain list and consider supplementing the LLM check with a deterministic lookup for known domains, using the LLM primarily for catching new or obscure disposable services. Log disposable detection rates to monitor for false positives that could block legitimate users.

Model selection matters for this task. Use a fast, cost-effective model (e.g., GPT-4o-mini, Claude Haiku, or a fine-tuned small model) because normalization is a high-volume, low-complexity operation. Avoid using large models for this step unless you are also performing complex reasoning about ambiguous addresses. If processing batches, implement concurrent requests with a semaphore to control rate limits, and collect results with per-record error handling so one failed normalization does not block the entire batch.

Before deploying, build an eval harness using the Contact Canonicalization Eval Rubric from this pillar. Test against a golden dataset that includes: valid RFC-compliant addresses, common typos (gmial.com, yaho.com), plus-address variants, disposable domains, internationalized email addresses, and edge cases like quoted local parts. Measure precision on domain correction (false-positive corrections erode user trust) and recall on disposable detection. Set a minimum precision threshold of 99.5% for domain corrections before enabling automatic correction in production; below that threshold, flag for human review instead. Monitor these metrics in production and trigger a prompt review if correction precision drops.