Reading Email Verification Results

Every processed address has a status, a 0-100 trust score and a list of recorded checks. Use the status to segment the list, then open important rows to understand why TrekMail reached that result. A score is evidence about technical risk, not proof of consent, identity or future inbox placement.

Status categories

An Invalid result can come from an unusable address format, a disposable or blocked domain, no usable mail route or an address already suppressed for the current account. It does not mean every Invalid address should be globally deleted without checking for an obvious typo or data-entry error.

Do not confuse a category with a cause

The status summarizes the score. The detail view gives the reason. Two Risky addresses can have very different next steps: one may have a likely domain typo that you can correct, while another may simply have weak domain signals that call for a cautious decision. Exporting all non-Invalid rows without looking at those differences can recreate the risk the verifier was meant to show you.

What influences the score

The verifier combines several kinds of evidence:

• Address and routing checks: address format, internationalized-domain safety, disposable domains, blocked domains and MX routing.
• Account context: an address previously suppressed for the current account is treated as invalid for that account.
• Quality signals: a likely typo, random-looking local part, plus addressing and role-address information.
• Domain signals: SPF and DMARC visibility, reputation indicators, domain age and other available domain information.
• Deep-only evidence: additional risk analysis and, when a receiving system permits it, mailbox-level evidence.

Some checks are intentionally neutral. For example, a role address such as support@ or a familiar free-mail provider can be useful context without being a reason to reject the address. The detail panel shows which checks were skipped, unavailable, passed or flagged.

Understand Deep information carefully

In a Deep job, the result can contain extra mail-server information. A receiving provider may accept, reject, defer, skip or withhold a useful answer. Large providers often do not disclose individual mailbox state through this type of check.

Treat an answer as one signal among others. An acceptance does not confirm that a person owns the mailbox or wants your messages. An unavailable result is not a rejection. The address score remains based on the other checks when the server cannot provide a dependable result.

For a corporate domain, a useful Deep response can be an extra clue. For a large mailbox provider, the core checks may be all that can be relied on. In either case, your campaign's consent evidence and previous engagement history remain more important than a single remote response.

Review before exporting

Use the result filters to make a practical export:

• export Safe + Valid when you want the strongest two groups for a permitted campaign;
• export Risky separately if a team member needs to review source quality;
• export Invalid to correct or suppress bad data in the original system;
• keep Unknown out of a high-stakes send until you have a clearer result.

CSV exports include the email, status, trust score, provider and risk factors. Results remain available for 15 days, so save the export you need with the campaign record.

Example review routine

If an import contains 10,000 addresses, first compare the status counts with the collection source. Open a small sample from Risky and Invalid. If most Invalid rows contain the same typoed domain, fix that source pattern. If Risky rows come from a partner import with no clear permission trail, pause that segment instead of deciding from the score alone. This turns the result into a practical quality-control step.

Use result changes as feedback

If many contacts are Risky or Invalid, investigate the collection path, form validation and import process. Do not simply lower the threshold. Keeping a clear permission trail, handling opt-outs and monitoring bounces will do more for deliverability than treating any verifier score as a promise.