Email & Phone Verification: screen the contact details before you pay for identity

Every applicant costs the same to verify. The one who filled the form honestly, and the one who opened a mailbox this morning on a domain registered last week. Both consume a full identity check against paid data sources, and you find out which was which only after you have paid for the answer.

Email & Phone Verification is now live in Dotfile. It screens the two things an applicant hands over first, before any of that runs.

The two cheapest facts you already have

An email address and a phone number look like contact details. They are also the longest paper trail most applicants carry, and they are the hardest part of a fabricated identity to fake convincingly.

A mailbox either exists or it does not. A domain was registered on a date, and that date does not move. An address has been seen before by other organisations, or it has never been seen by anyone. A number resolves to a mobile network, or to a voice over IP provider that costs nothing to abandon. None of that requires the applicant to do anything, and none of it requires a document.

What comes back

The check returns four groups of signals, each on its own section of the check page.

Email validation confirms the address is deliverable and reports the risk of a bounce.

Email verification signals is where the history sits. Whether the mailbox actually exists behind a valid domain. When the address was first seen, and when its domain was. How many times those details have been searched in the last seven days, and by how many organisations. Plus a fraud risk score with the band it falls in.

Mobile validation reports whether the number is live, what kind of line it is, and the network behind it, both current and original.

Fraud risk carries the two aggregate scores, a trust score and a fraud score, each with its risk band, the rules that fired, and the signals that fed the score.

Read together, these turn a form submission into a shape. An address first seen in 2015 on a domain registered in 2014, searched once in the last week by one organisation, is an ordinary person. An address first seen three days ago, on a domain first seen three days ago, already searched eleven times by four organisations, is a pattern, and it is a pattern you can act on before you have spent anything verifying who they claim to be.

The order is the point

The screen runs first. When your verification profile is configured for it, a contact detail that fails stops the paid identity sources from being queried at all. They do not run, and they are not billed.

That inverts the usual sequence. Most teams end up using their identity check as their first fraud filter, which means paying full price to discover that an applicant was never worth checking. Putting a few cents of contact screening in front of it means the expensive step only ever runs on applicants who cleared the cheap one.

Every signal shows its work

A score on its own is an assertion. Compliance teams do not get to make assertions to a regulator.

So every row on the page names the provider result codes behind it, and the page collects all of them in one place. "Mailbox existence: does not exist" sits next to the code that reported it. The plain language interpretation at the top of the check reads the whole picture, and it is written to keep two findings apart that are easy to confuse: a source that could not run because information was missing is not the same as a source that contradicted what the applicant said.

One deliberate limit, worth knowing before you rely on it. The provider reports the absence of a mailbox, never its presence. The row tells you a mailbox does not exist. It never claims one is real.

On the API too

The signals come back on the check through the API, under `fraud_signals`, with the same structure the console shows: trust, fraud score, email verification, email validation, mobile validation. Every field is optional, so a signal absent from the response is simply absent from your data rather than a null you have to interpret. The existing check webhooks cover it, with nothing new to subscribe to.

Dotfile is partnering with GBG for this check, through the same platform that already powers eKYC. If you run eKYC today, there is nothing new to integrate.

Read the documentation, or ask your Customer Success Manager to enable it on your workspace.