If you use CallRail with HubSpot, you may have seen duplicate contacts appear when calls are logged.
This usually happens when CallRail can’t confidently match an incoming call to an existing HubSpot contact. According to CallRail, the integration tries to associate activity using the HubSpot cookie or a phone-number match. If it can’t find a match, it can create a new contact instead. In some cases, that new record uses a placeholder email ending in @call.com.
That makes the contact useful for activity logging, but it also makes HubSpot deduplication much harder. HubSpot automatically deduplicates contacts by email address, so a placeholder @call.com email will not match an existing contact that already has the person’s real email.
Over time, this can lead to a few common problems:
The good news is that these CallRail duplicates are manageable.
In this guide, we’ll cover:
@call.com emails mean
CallRail tries to connect call activity to the right HubSpot contact. According to CallRail’s help center, activities are linked to an existing HubSpot contact based on the HubSpot cookie or phone number. If there is no existing contact match, a new one is created.
In practice, CallRail tries to match records like this:
That’s when duplicates can appear.
A contact may already exist in HubSpot, but if the match fails because of formatting differences, missing phone data, the number being stored in the wrong field, or timing between systems, CallRail may create a second contact instead of linking activity to the original one.
@call.com Mean in HubSpot?One of the clearest signs of a CallRail-created duplicate is a placeholder email ending in @call.com.
CallRail’s HubSpot integration supports creating @call.com email addresses for new contacts, and CallRail says that contacts created via the HubSpot cookie may still receive a @call.com email even if that setting is disabled, because HubSpot requires an email address in that situation.
This matters because HubSpot’s native contact deduplication is based on the Email property. When a new contact is added, HubSpot checks for a matching email address. If the existing record has the person’s real email but the new CallRail-created record has something like 15551234567@call.com, HubSpot will not treat them as the same contact.
So when you see an email ending in @call.com, it often means:
@call.com emails always duplicates?No. A @call.com email is not automatically a duplicate.
But it is a very strong signal that the record was created by the CallRail integration and should be reviewed carefully, especially if another contact already exists with:
This is the most direct cause.
In CallRail’s HubSpot integration settings, you can choose either:
If new-contact creation is enabled, duplicates become much more likely whenever matching is imperfect.
HubSpot automatically deduplicates contacts by email address. That works well when the same email is present on both records. It works poorly when one record has the real email and the other has a placeholder @call.com address.
This is why CallRail duplicates are often harder to catch with HubSpot alone.
CallRail’s documentation says HubSpot’s phone-number validation requires E.164 formatting, and CallRail provides a setting to send phone numbers in that format. If that setting is off, CallRail still sends data to HubSpot, but you won’t be able to use HubSpot’s phone-number validation feature.
Even when validation is not the direct cause, inconsistent phone formatting across systems can reduce matching accuracy and make duplicate detection harder.
A contact may already exist in HubSpot, but if the usable number is stored in a secondary or custom phone field rather than the field your process relies on, the match may fail.
This is a common CRM hygiene problem: the data exists, but not in the right place for consistent matching and duplicate review.
Sometimes the duplicate is not caused by CallRail alone. It happens because CallRail creates a contact immediately after a call, while another HubSpot workflow, form process, import, or sync later creates a separate record for the same person.
When several systems can create contacts, timing gaps make duplicates much more likely.
The best way to detect CallRail duplicates is to focus on the signals that matter most for this integration: placeholder emails, phone numbers, and source patterns.
@call.com email addressesThis is the fastest place to start.
Build a HubSpot view or list of contacts whose email contains @call.com. Those records are not always duplicates, but they are often the highest-value group to review first.
If your duplicate checks treat punctuation, spaces, or local formatting as meaningful differences, you will miss a lot of CallRail duplicates. Phone-based matching works much better when numbers are normalized into a consistent format. If you want to align more closely with HubSpot’s validation model, E.164 is the cleanest choice. You can use HubSpot's native phone number formatting workflow action.
Do not limit your checks to a single property.
To detect more duplicates, use Koalify Duplicate Rules to compare phone numbers across:
This is one of the most important improvements you can make. If the original contact and the CallRail-created contact store the same number in different fields, email-based detection alone will miss them.
If your integration is set to create new contacts, review recently created contacts that also have:
@call.com emailsThose patterns often surface duplicates quickly.
If you want to identify HubSpot duplicates that are coming from CallRail considering the following Koalify setup:
Duplicate Rules
Fuzzy Rules
Once you’ve found duplicates, the next step is deciding which record should stay.
In most cases, the best record to keep is not the CallRail-created placeholder contact. It’s usually the original HubSpot contact, because that record is more likely to contain:
A good rule of thumb is to avoid keeping records with placeholder @call.com email addresses as the surviving record whenever a more complete HubSpot contact already exists.
If you’re using Koalify Primary Duplicate Rules, the primary-record logic should favor records that:
@call.com in the Email propertyThat gives you a much cleaner surviving record after the merge.
Once your primary-record logic is in place, you can use a workflow with Koalify’s Merge Duplicate Record action to merge likely duplicates automatically.
A practical enrollment setup would include conditions like:
@call.comFalseYou can also combine that with source-based filters if you have reliable integration-source data in HubSpot.
This is usually the most effective automation pattern: let Koalify detect the likely duplicate based on phone logic, then let the workflow merge only the lower-quality non-primary record.
Before turning on automatic merging, test your rules on a small segment first to make sure unrelated contacts are not being grouped together.
This is especially important for cases like:
A few small changes can reduce future duplicate creation:
@call.com email creation if you truly need it. CallRail recommends this only when your HubSpot configuration requires an email address for each contact.If CallRail is creating duplicate contacts in HubSpot, the problem usually is not the call itself. It is the matching logic around cookies, phone numbers, and placeholder email addresses.
When CallRail cannot confidently match an interaction to an existing HubSpot contact, it may create a new record. And when that new record uses a placeholder @call.com email, HubSpot’s built-in email-based deduplication usually will not catch it automatically.
The fix is usually straightforward:
Once those pieces are in place, CallRail duplicates become much easier to control.