Which properties HubSpot uses to deduplicate records

HubSpot blocks some duplicates on its own. It does that by comparing one property per object when a record comes in. Knowing which property it uses, and where it applies, explains many of the duplicates that still get through.

The answer changes with the entry point. A record typed in by hand, a form submission, an import and an API call are each handled a little differently.

In this post, you'll see which properties HubSpot compares for each object and at each entry point. You'll also see what it doesn't compare and how to give your own objects a key. What each HubSpot plan adds is covered in our guide to HubSpot deduplication on free and paid plans.

The short answer: one property per object

HubSpot's automatic deduplication uses email for contacts and the company domain name for companies. Every object also has a Record ID, and you can create properties that require unique values. Here's how that looks per object, as of October 2026.

Source, as of October 2026: HubSpot's knowledge base, Deduplicate records in HubSpot.

The Record ID is a default property that stores each record's unique value. It's most useful in imports, where it tells HubSpot exactly which existing record a row should update.

What HubSpot compares at each entry point

The same property behaves differently depending on how a record arrives.

Records created by hand

If you add a contact with an email that already exists, HubSpot alerts you and won't let you add it. For companies, HubSpot alerts you that a company with that domain already exists.

Forms

A submission with a known email adds its information to the existing contact. If someone submits a form with their secondary email, that address replaces the primary email on their contact.

Properties that require unique values aren't supported in forms. A submission without an email is matched through browser cookies, and an unrecognized visitor can become a new contact. Our post on why web forms create duplicate contacts covers this source in depth.

Imports

A row that matches an existing email updates that contact instead of creating a new one. Companies match on their primary and secondary domain names, unless you choose a custom unique value property instead.

Rows without an email, domain, Record ID or unique value each become a new record. A row that matches several existing contacts returns an import error and isn't imported.

The API and sync apps

HubSpot's developer docs call email the primary key for contacts, and an upsert by email updates contacts that already exist. Companies created through the API aren't deduplicated by domain. That includes companies from installed third-party sync apps, where HubSpot notes that custom rules may apply.

Sources, as of October 2026: HubSpot's knowledge base, Deduplicate records in HubSpot and Form submissions without email addresses, and HubSpot's developer docs, Contacts API.

What HubSpot doesn't compare when records come in

At entry, HubSpot compares that one property and nothing else. That leaves some common duplicates outside its reach.

• Names: two contacts with the same name, company and phone but different emails stay two contacts.
• Phone numbers and addresses: neither is part of the check at entry.
• A second email: a person with a work and a personal address can exist twice. Our post on matching personal and work emails covers how to connect them.
• Companies without a domain: with nothing to compare, each one is new.
• Deals and tickets: HubSpot's deduplication page lists no automatic property for either.

Domains have their own traps, like country endings and subsidiaries that share one website. Our guide on finding duplicate companies by domain covers them.

Where names and phone numbers do count

HubSpot's duplicate management tool works on records already in the CRM. It compares a set list of properties every day and suggests contact and company pairs to review.

Custom duplicate rules let you choose the properties yourself. You get up to two rules per object for contacts or companies, each with up to nine properties. Both the tool and the custom rules depend on your subscription, which the HubSpot plans guide linked above explains.

Source, as of October 2026: HubSpot's knowledge base, Review and manage duplicate records.

How to give each object a key you trust

What counts as a duplicate is case by case: what one team considers a duplicate, another may not. So the key that keeps your records unique depends on your data. These principles help.

Keep email and domain filled in

HubSpot's protection only works when the property has a value. Make email required on forms where you can, and add a domain to every company you create by hand.

Give deals and custom objects a unique property

HubSpot's own example is an order number that requires a unique value for each deal. Any ID from another system works the same way, as long as every record has one.

Import with the key your file has

Include the Record ID when you're updating records you exported from HubSpot. When a file uses secondary emails as the identifier, leave the Record ID column out, or the secondary email replaces the primary one.

Ask each integration what it matches on

Companies from the API and sync apps skip the domain check. For each tool that writes to HubSpot, find out which property it uses to find an existing record before it creates one.

Know your keys before you clean

HubSpot's native deduplication rests on one property per object: email for contacts and domain for companies. Imports add the Record ID and any property you set to require unique values. Each entry point applies those keys a little differently, and deals, tickets and API-created companies get no automatic check.

Many duplicates that reach HubSpot arrive through one of those gaps. Knowing which key each source uses tells you where to look first and which fields to match on when you clean.

Frequently asked questions