Email Verification: Safe, Role, Catch-All, Invalid And Unknown Explained

Safe or deliverable

A Safe result generally means the verifier found strong evidence that the address is technically capable of receiving mail. This is the cleanest outcome for normal contact creation. It does not prove that the person gave marketing consent, but it does reduce the technical risk of immediately mailing a dead mailbox.

For a form workflow, Safe addresses are normally the straightforward case: accept the contact, apply the intended list or tag, record consent evidence where appropriate and allow the relevant automation to continue.

Role accounts

Role addresses are mailboxes such as info@, sales@, support@ or accounts@ that represent a function rather than one named person. They are common in business-to-business environments and are not automatically bad addresses. Their suitability depends on the context in which the address was supplied.

If somebody deliberately submits info@theircompany.example through a business enquiry or resource form, rejecting the address purely because it is role-based may throw away a legitimate lead. Email Foundry therefore supports a policy where Safe and Role Account results can both be accepted for public forms while other outcomes are rejected.

The marketing team should still consider relevance and consent. Email Foundry is designed for permission-based audiences, so a role address should only be used where the recipient relationship and lawful basis make that communication appropriate.

Catch-all

A catch-all domain is configured to accept mail for addresses even when the receiving system does not confirm whether the specific mailbox exists. That makes verification uncertain. The SMTP conversation can look successful even though the exact recipient may later bounce or route into a catch-all mailbox that nobody actively monitors.

Because the verifier cannot establish the same certainty as a Safe result, catch-all addresses are often a poor fit for automated admission into a marketing database. If your policy is “Safe and Role only”, a catch-all result should remain outside Contacts rather than being created first and cleaned up afterwards.

Invalid

An Invalid result indicates strong evidence that the address cannot receive mail as supplied. Reasons can include a non-existent mailbox, malformed address, dead domain or an explicit rejection during verification. These addresses should not enter a normal emailable audience.

Sending repeatedly to invalid addresses wastes capacity and increases bounce risk. If invalid addresses arrive through an import, the system should reject or quarantine them before they become campaign recipients. If they arrive through a public form, the visitor-facing workflow can still acknowledge receipt before background verification decides whether the address is admitted.

Disposable

Disposable email services provide temporary addresses that may disappear shortly after use. They can be useful for privacy in some contexts, but they are usually poor inputs for a long-term marketing database. A temporary mailbox can inflate lead counts while providing little chance of durable engagement.

If the goal is ongoing email communication, disposable results are normally safer to reject. This is especially true for lead magnets, free trials or public forms that are frequent targets for low-intent signups.

Unknown

An Unknown result means the verifier could not reach a confident conclusion. The receiving system may have timed out, blocked verification probes or behaved in a way that makes the mailbox status unclear. Unknown is not the same as invalid, but it is also not the same as Safe.

When a workflow is designed to fail closed, Unknown should remain outside the emailable contact database until there is stronger evidence. That approach protects reputation at the cost of admitting fewer uncertain addresses.

Do not make the visitor wait for the verifier

Verification APIs can take several seconds. Making a form visitor stare at a spinner while an external service performs mailbox checks is bad conversion design. A better architecture separates the visitor experience from the contact-admission decision.

1. The visitor submits the form.
2. The site records the submission immediately.
3. If verification is enabled, the visitor sees a message such as “Thanks! Your details are pending verification.”
4. The verification job runs in the background.
5. Safe or Role Account results are created or updated as Contacts.
6. Catch-all, invalid, disposable, unknown and other rejected outcomes are not admitted.
7. Only accepted contacts receive list/tag actions and form-triggered automations.

This avoids the worst of both worlds: you do not slow the form down, and you do not create a contact before you know whether it passes the chosen quality gate.

Verification should be visible later

Operations teams need to know why a contact was accepted or rejected. Email Foundry stores verification history and contact-level verification fields so the result can be inspected and used in segmentation. That creates an audit trail rather than turning verification into an invisible black box.

It also helps diagnose unexpected results. If a business inbox was rejected as catch-all, the team can see that outcome and decide whether a different acquisition or verification policy is appropriate for a specific workflow.

Action plan

Write down your acceptance policy before connecting a verifier. Decide which results are allowed for imports, manual creation and public forms. For most public lead-capture workflows, Safe and Role Account is a clear conservative rule. Keep catch-all, disposable, invalid and unknown results out of the live marketing database unless you have a deliberate reason to handle them differently.

Finally, keep verification separate from consent. Verification tells you whether an address appears technically usable. Consent and legitimate marketing expectation tell you whether you should send marketing to it.

Make verification policy explicit before the first submission

The most important operational decision is not which badge a verifier displays. It is what each result is allowed to do. A team should decide the acceptance policy in advance and apply it consistently at import, form admission and pre-send checks. For a public lead form, Email Foundry can use a deliberately simple rule: Safe and Role Account may be admitted, while Catch-All, Invalid, Disposable, Unknown and any unapproved result remain outside the emailable contact database.

That distinction matters because a form submission and a contact are not necessarily the same thing. The submission can be acknowledged and stored immediately for operational evidence while the address is still pending verification. Only after an approved result arrives should the system create the emailable contact, apply lists and tags, record the consent state and trigger downstream automations. This prevents a questionable address from entering a welcome sequence during the few seconds before verification finishes.

Monitor the policy, not only individual addresses

Verification reporting becomes more useful when you review the mix of results over time. A sudden increase in Invalid results may indicate a broken acquisition source, typo-heavy form, imported legacy file or deliberate abuse. A large Catch-All share may be normal for a particular B2B audience, but if your policy rejects catch-all addresses the marketing team should understand the conversion trade-off. Role Account volume may also tell you something about the type of leads a campaign is attracting.

Keep the raw result and verification date available for audit and segmentation. Reverification can then be targeted instead of performed blindly across the whole database. The goal is not to repeatedly reverify addresses that have not changed; it is to keep enough evidence to make sensible sending decisions as the list ages.