Email Address Cleaning and Validation Prompt

This prompt is designed for CRM and marketing operations engineers who need a deterministic, auditable normalization step for raw email address strings before they enter a system of record. The primary job-to-be-done is to transform free-text input from signup forms, CSV imports, or API payloads into a structured object that downstream systems can trust. It handles whitespace trimming, domain lowercasing, RFC 5322 format validation, and classification of disposable or role-based addresses. The output is not just a cleaned string; it is a decision record that separates valid, routable emails from invalid ones, each with an explicit rejection reason. This is a classification and normalization step, not a verification step—it prepares data for SMTP checks or real-time mailbox validation but does not replace them.

The ideal user is an engineer building an ingestion pipeline who needs to reduce bounce rates, prevent disposable signups, and maintain a clean CRM. Required context includes the raw email string and, optionally, a list of known disposable domains or role-based prefixes to flag. The prompt is most effective when wired into a pre-ingestion stage where invalid records are routed to a quarantine table or a human review queue rather than silently dropped. It is not suitable for real-time email verification (it does not ping mail servers), for detecting catch-all domains, or for assessing email reputation. Use it when you need structured, explainable decisions at ingestion time, not when you need to confirm mailbox existence.

Avoid using this prompt as a standalone guard against all forms of email abuse. It will not catch typos that result in valid but incorrect domains, nor will it detect temporary email addresses that are not in your disposable domain list. Always pair it with a downstream verification service for high-assurance workflows. If your pipeline processes PII, ensure the prompt's input and output are handled in compliance with your data governance policies. The next step after understanding this boundary is to copy the prompt template, adapt the placeholder lists to your domain, and integrate it with a validation harness that logs every rejection reason for auditability.

This prompt template is designed to be placed directly into your system instructions for an LLM tasked with email normalization. It accepts a raw email string and a set of configuration parameters, then returns a structured JSON object containing the cleaned address, its validity status, and detailed rejection reasons when applicable. The template uses square-bracket placeholders for all variable inputs, ensuring you can adapt it to different risk tolerances, downstream system requirements, and operational contexts without modifying the core logic.

textCopy
You are an email validation and normalization engine. Your task is to process a single raw email address and return a structured JSON object.

## Input
- Raw Email: [RAW_EMAIL_INPUT]

## Configuration
- Disposable Domain List: [DISPOSABLE_DOMAINS]
- Role-Based Prefix List: [ROLE_BASED_PREFIXES]
- Allowed Domains (if domain-restricted): [ALLOWED_DOMAINS]
- Output Schema: [OUTPUT_SCHEMA]

## Processing Rules
1. **Clean**: Trim leading/trailing whitespace. Remove any `mailto:` prefix if present.
2. **Normalize**: Convert the domain part (after the '@') to lowercase. Preserve the case of the local part (before the '@') as-is, per RFC 5321.
3. **Validate Format**: Check the address against RFC 5322 standards. It must have exactly one '@', a non-empty local part, a non-empty domain with at least one dot, and no invalid characters.
4. **Flag Disposable**: If the domain is in the provided [DISPOSABLE_DOMAINS] list, set `is_disposable` to true.
5. **Flag Role-Based**: If the local part matches any prefix in [ROLE_BASED_PREFIXES] (e.g., admin@, info@, support@), set `is_role_based` to true.
6. **Check Domain Restriction**: If [ALLOWED_DOMAINS] is provided and not empty, the domain must be present in that list. If not, flag as `domain_not_allowed`.

## Output Instructions
Return ONLY a valid JSON object conforming to the [OUTPUT_SCHEMA] provided. Do not include any text outside the JSON object. If the input is invalid, the `normalized_email` field should be null and the `rejection_reasons` array must contain specific, non-generic reasons.

To adapt this template, replace the square-bracket placeholders with your specific values. For [DISPOSABLE_DOMAINS], provide a JSON array of strings like ["mailinator.com", "guerrillamail.com"]. For [ROLE_BASED_PREFIXES], use an array such as ["admin", "info", "sales", "support", "noreply"]. The [OUTPUT_SCHEMA] should be a JSON Schema object defining the exact structure you expect, including fields for normalized_email, is_valid, is_disposable, is_role_based, and rejection_reasons. If you are not enforcing a domain allowlist, set [ALLOWED_DOMAINS] to an empty array []. For high-risk workflows where a bad email could cause a customer-facing error, ensure your application layer validates the JSON output against the schema before ingestion and routes any record with is_valid: false or a non-empty rejection_reasons array to a human review queue.

This prompt is designed to be a single step in a larger data pipeline, not a standalone chatbot interaction. The implementation harness should treat the LLM call as a deterministic transformation function: structured input in, structured output out. The harness is responsible for enforcing the output schema, handling model failures, and routing records based on the status field. The prompt itself is stateless, so the harness must supply all context—the raw email string and any domain blocklists or configuration—in each request.

Wire the prompt into your application using a model that supports strict JSON mode or structured outputs (e.g., GPT-4o with response_format: { type: 'json_object' } or Claude with tool-use extraction). Before calling the model, pre-process the input by trimming leading/trailing whitespace and rejecting null or empty strings at the application layer to avoid wasting tokens. After receiving the response, validate the JSON against the expected schema: status must be one of valid, invalid, risky, or disposable; normalized_email must be present for valid and risky statuses; rejection_reasons must be a non-empty array for invalid and disposable statuses. If validation fails, retry once with the validation error injected into the prompt as additional context. If the retry also fails, log the raw response and route the record to a manual review queue.

For high-throughput pipelines, implement batching with care. Send records individually or in small batches (5–10) within a single prompt, requesting a JSON array in response. Always include a unique record_id in the input and require it in the output to maintain traceability. Log every normalized result—including the original input, normalized output, model version, and timestamp—to an audit table. This audit trail is critical for debugging normalization drift when model behavior changes. For domains with strict deliverability requirements, add a post-processing step that checks risky emails against your internal suppression lists before routing to downstream systems. Never send disposable or invalid emails to your CRM or marketing automation platform; route them to a quarantine table for periodic review.