An email verifier checks evidence available before sending. A bounce is the receiving system's response to a real delivery attempt after sending. A so-called email bounce checker cannot know every future bounce because delivery also depends on the sender, message, timing, and receiving policy.
Mailthentic does not offer a tool that sends test campaigns or promises to predict every bounce. It verifies address and domain signals before a legitimate send. Your sending platform remains the source of actual bounce events and codes.
Pre-send verification and post-send bounce data
| Question | Email verifier | Sending platform |
|---|---|---|
| Is the syntax plausible? | Checks before sending | May reject malformed input |
| Does the domain accept inbound mail? | Checks domain and MX evidence | Learns during delivery too |
| Does the recipient appear valid? | Uses available evidence, sometimes inconclusive | Receives the authoritative response to that attempt |
| Was this message blocked by policy? | Cannot know in advance | Records the actual response |
| Did the mailbox become full? | Usually cannot know in advance | Records a temporary or permanent response |
What a verifier can identify before sending
A verifier can inspect syntax, domain existence, MX routing, disposable providers, role addresses, catch-all behavior, and available SMTP recipient evidence. Use the free email checker for a DNS-level view or the bulk email verifier for permission-based CSV and XLSX lists.
A clear recipient rejection can support an invalid result. A server acceptance is not a delivery promise. Gateways, catch-all domains, privacy controls, throttling, and temporary errors can all leave the result risky or unknown.
Why a verified address can still bounce
- The mailbox was disabled after verification.
- The mailbox is full or temporarily unavailable.
- The recipient server blocks the sender's IP, domain, or message.
- Authentication or policy requirements are not met.
- The sender exceeds a provider rate limit.
- A catch-all gateway accepted the verification probe but rejected later.
- The address was valid at verification time but changed before the send.
See why verified emails still bounce for the full decision framework.
Hard bounce, soft bounce, and policy rejection
A hard bounce usually signals a permanent failure, such as a nonexistent recipient. A soft bounce usually signals a temporary condition, such as a full mailbox or temporary server failure. Some rejections concern content, reputation, authentication, or local policy rather than address existence.
Do not classify solely from the first digit or a friendly label. Store the enhanced status and server text supplied by your sender. The hard bounce versus soft bounce guide explains suppression and retry choices, while SMTP response codes explained provides the protocol context.
A safe bounce decision framework
- Before sending: Verify permission-based addresses and keep risky or unknown results in separate segments.
- At send time: Use an authenticated sending domain, follow provider limits, and send content recipients expect.
- After sending: Ingest the actual bounce code and response text from the sending platform.
- For permanent recipient failures: Suppress promptly and investigate repeated source errors.
- For temporary failures: Apply a limited retry policy rather than immediately deleting the address.
- For policy failures: Fix authentication, reputation, content, or rate issues before blaming the mailbox.
Related domain checks
Use an MX lookup to inspect inbound routing and the domain health checker to review SPF, DKIM, and DMARC. These checks explain part of the delivery context, but neither reproduces an actual campaign delivery.
Reduce avoidable uncertainty before a send
Check one address without confusing pre-send evidence with a guaranteed bounce prediction.
Ready to verify your email list?
Start free with 50 verification credits. No credit card required.