An email address becomes risky when available evidence suggests extra uncertainty or a higher chance of failure, but does not conclusively prove the address is unusable. Risk can come from the input, domain, receiving server, address type, or a conflict between otherwise useful checks. The right response is usually review, restriction, or a later retry, not automatic deletion.
Mailthentic separates user-facing valid, risky, invalid, and unknown buckets. Stored results are more specific, while disposable and role-based classifications appear as flags. This matters because “risky” is not a synonym for “invalid,” and a signal is not always a final status.
Risky and invalid answer different questions
An invalid result is supported by decisive negative evidence, such as malformed syntax, a domain that cannot receive mail, or a clear permanent recipient rejection. A risky result preserves an address when evidence suggests caution but cannot justify that final rejection. Unknown means the system could not gather enough evidence for either conclusion, often because a temporary or external condition interrupted the check.
The exact action also depends on context. A shared support inbox can be suitable for a customer service conversation and unsuitable for an individually addressed marketing sequence. A catch-all contact with verified consent and recent engagement has different value from a cold record with no source history.
The 11 signals and what to do with each
1. Invalid syntax
Syntax checks inspect whether the address has a plausible local part, at sign, and domain. Spaces, missing domains, duplicated separators, and other malformed input can fail before any network check begins. This is normally invalid rather than merely risky because the submitted value cannot be used as an address.
Action: stop the send path and ask the source to correct the value. Do not guess at a correction in production. A typo suggestion can be shown to a person, but the corrected address must be confirmed or checked as a new input.
2. Missing or unusable MX routing
MX records identify the servers intended to receive mail for a domain. A domain with no usable inbound mail route normally cannot receive a message. Domain failures and a declared Null MX are stronger negative evidence than a mailbox-level uncertainty.
Action: suppress an address when the domain failure is conclusive. Keep transient DNS lookup failures separate, since a timeout is not proof that the records do not exist. The free email checker provides a DNS-level view for one address.
3. Temporary server responses
A receiving server can defer a request because it is busy, over quota, applying policy, or protecting itself from unfamiliar traffic. Four-class SMTP responses are temporary by design, although the text and later behavior vary. A temporary response says “not now,” not “this mailbox does not exist.”
Action: place the record in an unknown or retry segment. Retry after a bounded delay if the business case warrants it. Do not hammer the server and do not convert the first temporary response into invalid.
4. Catch-all domain behavior
A catch-all domain appears to accept mail for arbitrary recipient names. That behavior can be intentional, or it can be produced by a security gateway that postpones recipient checks. Either way, the accepting response cannot prove that the target mailbox exists. Mailthentic can represent detected behavior as risky_catch_all.
Action: evaluate source, permission, engagement, and business value. Send cautiously only when your policy allows it. Do not delete every catch-all address or label every one deliverable. Read the full catch-all handling guide before setting a blanket rule.
5. Disposable provider classification
Disposable services issue addresses designed for temporary use. The mailbox may function during verification and disappear later. In Mailthentic, disposable is exposed in flags and can contribute to an invalid result in the full verification engine.
Action: choose a policy based on the transaction. A SaaS team may warn or block disposable signups to reduce trial abuse. A low-risk content download may accept the address while withholding sensitive account actions. Explain the rule to users and provide a correction path. The disposable email guide covers the tradeoffs.
6. Role-based local parts
Addresses such as sales@, support@, or accounts@ can represent a group rather than an individual. They can be real and useful, but permission, ownership, and engagement may be harder to attribute. Mailthentic returns role classification as a flag rather than automatically treating every role address as invalid.
Action: allow role inboxes where the message is relevant to that function, especially operational communication. Review or restrict them for individualized outreach. See when role-based addresses are appropriate.
7. Free-provider classification
A Gmail, Outlook.com, Yahoo, or similar consumer address is not inherently disposable or invalid. Free-provider classification describes the provider category and can help a business understand whether an address represents a personal mailbox rather than a company domain. It should not be treated as a negative verification verdict by itself.
Action: use provider type only for a legitimate workflow requirement. Do not block personal addresses from a consumer signup merely because they are free. If a B2B process requires a work address, explain that separate eligibility rule instead of claiming the email failed verification.
8. Greylisting
Greylisting temporarily defers an unfamiliar sender or connection so a legitimate mail system can try again later. During pre-send verification, this protection can prevent a conclusive recipient answer. It is evidence about the current SMTP conversation, not proof about mailbox ownership.
Action: retain the address as unknown or retryable. Use a limited retry policy and accept that some receivers will remain inconclusive. Do not repeatedly probe in a tight loop.
9. Provider-specific uncertainty
Large hosted providers and security gateways do not all reveal recipient existence in the same way. Google-hosted and Microsoft-hosted domains can accept a recipient at the edge without confirming an individual mailbox. Tenant settings can also change behavior within the same provider family.
Action: preserve provider and SMTP evidence, but do not interpret a positive recipient response as universal confirmation. Apply the result status and reason returned by the verification engine, then combine it with consent and engagement data you actually control.
10. Mailbox status uncertainty
The domain may exist, MX routing may work, and the server may accept a connection while the target mailbox remains unconfirmed. This is common when the receiver protects its directory, times out, or delays recipient decisions. A result can therefore be deliverable but unconfirmed, risky, or unknown depending on the full evidence.
Action: do not relabel “unconfirmed” as “confirmed.” For an existing relationship, use prior engagement or an ownership-confirmation flow. For an untrusted imported record, hold it for review or a lower-risk segment.
11. Conflicting verification signals
Real checks can disagree. A valid domain can use a disposable service. An SMTP accept can coexist with catch-all evidence. Strong syntax and MX results can be followed by a temporary recipient response. A role address can be both operationally appropriate and unsuitable for a personal campaign. The conflict itself is useful information.
Action: preserve the individual fields instead of collapsing everything into a home-grown boolean. Prioritize decisive failures, keep uncertainty visible, and route high-value conflicts to a structured review queue.
Use an action matrix, not one universal cutoff
| Result pattern | Recommended default | Possible exception |
|---|---|---|
| Conclusive syntax or domain failure | Suppress and request correction | Human corrects a documented source typo |
| Temporary DNS, connection, or SMTP condition | Hold and retry later | Time-sensitive flow can fail open with separate ownership confirmation |
| Catch-all or protected-provider ambiguity | Review or restrict | Recent permission and engagement support cautious use |
| Disposable signal | Apply product-specific policy | Low-risk workflow accepts with limits |
| Role signal | Match message to function | Operational mail can be appropriate |
| Multiple conflicting signals | Preserve evidence and review | A later decisive check resolves the conflict |
What a verification result cannot establish
Verification does not prove that the submitter owns an address, consented to marketing, will remain at the organization, or will receive a future message in the inbox. Mailthentic stops before message content is transmitted during verification. Sender reputation, authentication, message content, receiver policy, and conditions at send time still affect delivery.
For bulk work, keep the detailed export and segment decisions rather than deleting every non-valid row. For application events, preserve pending and unknown states instead of forcing the asynchronous API workflow into an instant yes or no.
Inspect the evidence behind an address
Use the Mailthentic email verification service for a full account workflow, then apply a policy that distinguishes invalid evidence from reviewable risk.
Ready to verify your email list?
Start free with 50 verification credits. No credit card required.