> For the complete documentation index, see [llms.txt](https://docs.zingg.ai/latest/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.zingg.ai/latest/zingg-concepts/zingg-configuration/field-definition/match-types/email-match.md). # EMAIL Match Fuzzy-matches only the local part of an email address before the @ symbol and ignores the domain. Built for datasets where the same person appears with different email domains. ### What EMAIL does `EMAIL` splits an email address at the `@` symbol, discards the domain entirely, and scores the local part (the portion before `@`) using the similarity function. It is not an exact/binary comparison; it is `FUZZY`. This handles the common scenario where the same person has a work email and a personal email, or where an organization's email domain changes over time. ### What `EMAIL` matches and what it does not
Value AValue BMatch?
j.smith@company.comj.smith@other.comYes - identical local part, domain ignored
j.smith@company.comjohn.smith@company.comPartial - local parts differ but share "smith"; scores a graded similarity, not a hard match or non-match
support@ibm.comsupport@microsoft.comYes - identical local part, even though the organisations are unrelated
[null]j.smith@company.comYes - a null/blank value on either side is an automatic match; add NULL_OR_BLANK if you want nulls excluded
### When to use `EMAIL`
Email address fields in multi-system datasets Any dataset where the same person or organisation may appear with different email domains across source systems. Work email in CRM, personal email in e-commerce,\ university email in a registration system - all with the same local part. `EMAIL` ignores the domain and matches on the local part, which is the most stable identifier.
When domain differences are expected and normal After an acquisition, employees may appear in one system with their old company domain and in another with their new one. `EMAIL` handles this automatically.
### When not to use `EMAIL`
When the domain is part of the identity signal If you are matching organisations rather than individuals, the domain is often the most reliable identifier. "" and "" have the\ same local part but are completely different organisations. Use `EXACT` on the full email field when the domain matters.
When you need domain to factor into the score too `EMAIL` ignores the domain unconditionally - "" and "" are scored purely on "j.smith" vs "john.smith", with no credit or penalty for the domain being the same. If the domain itself should count towards the score (not just be a tie-breaker), use `FUZZY` on the full email field instead. Note this compares the whole string including the domain, so it doesn't restrict fuzziness to the local part the way `EMAIL` does, and dissimilar domains with similar local parts can drag the score down.
{% hint style="success" icon="right-long" %} **Related types**: * `EMAIL_OPTIMISED` - same as EMAIL, faster at production scale (ENT) * `EXACT` - use when the full email including domain must match exactly * `FUZZY` - use when local parts also have variation **Read more**: [Match types](/latest/zingg-concepts/zingg-configuration/field-definition/match-types.md) {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.zingg.ai/latest/zingg-concepts/zingg-configuration/field-definition/match-types/email-match.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.