Valid, catch-all or unknown? Reading email verification results

Separate the checks

Syntax validation checks whether an address fits the verifier's supported format. DNS checks whether the domain advertises mail routing, or in some cases has an address record that can provide fallback routing. These checks can eliminate clear problems without making any contact with a mailbox.

A mailbox check asks the receiving server about the recipient. It is a different kind of evidence. An application should expose which checks ran rather than compress every outcome into a reassuring green score.

Why UNKNOWN is a useful result

A receiving server may greylist a check, refuse the probing host, time out, require a different sender identity or avoid revealing mailbox existence. Network restrictions can prevent the connection from happening at all. These outcomes are incomplete evidence, not proof that the address is valid or invalid.

If your campaign requires verified addresses, keep UNKNOWN contacts in a research queue. Recheck later with an appropriate verifier or exclude them. Repeatedly checking the same blocked network is not a path to better evidence.

What catch-all means

Some domains accept a randomized nonexistent recipient as well as the target address. That response makes it difficult to distinguish a real mailbox from a domain that accepts everything at the SMTP stage.

A catch-all result should not be silently converted into valid. It needs its own policy. In a verified-only workflow, it does not pass. A numerical confidence score is also not a calibrated probability of delivery unless the provider has established that interpretation.

Even a positive SMTP result has limits

A successful recipient response is evidence observed at one point in time. A provider can still accept a message and reject it later, quarantine it or place it in spam. Verification cannot prove recipient consent or guarantee inbox placement.

For that reason, keep authentication, sender health, targeting, opt-outs and delivery monitoring as separate parts of your workflow. A valid address does not excuse an irrelevant message or an ignored suppression record.

A practical data model

Store the result with its provider, timestamp, reason and checks. Preserve source provenance separately from verification. A scraped contact page can explain where an address came from without being mistaken for the mailbox verification result.

• Research evidence: address, company, public source URL and observation date.
• Verification evidence: provider, status, check timestamp and mailbox-check result.
• Contact policy: DNC, suppression, opt-out and prior reply status.
• Campaign state: whether a message is prepared, queued, sent or stopped.

Use the result in ColdPegion

ColdPegion's verification tools expose status and mailbox-check information. If the configured provider cannot establish mailbox existence, the result should remain unknown. Configure the verification provider in your workspace and check the returned evidence before filling a verified-only campaign.

A clean research process can still continue while verification is unavailable. Collect public sources, qualify companies and prepare internal notes; keep those actions separate from permission to send.