Email verification checks whether an address appears usable before you send to it. Email confirmation asks someone to act on a link or code delivered to that address. If account access depends on control of the mailbox, you still need confirmation after a positive verification result.
The distinction is easy to lose because both steps are often called “verify your email”. Decide which question your system needs answered: what the mail infrastructure reveals about an address, or whether someone can access a message sent there.
Compare the evidence each step provides
| Question | Pre-send email verification | Email confirmation |
|---|---|---|
| What happens? | Check syntax, domain and routing; a full check may also gather SMTP recipient evidence. | Your application sends a message and validates the returned link token or code. |
| Does Emvero send a message during the check? | No. The SMTP probe stops before DATA; a domain-only check opens no SMTP session. |
Your application or email provider sends the confirmation message separately. |
| What can a positive result establish? | Available evidence supports accepting the address for the next step. | Someone accessed the message and completed the challenge at that time. |
| What remains unproven? | Mailbox control, personal identity and future delivery. | Exclusive or permanent ownership, personal identity and future delivery. |
A working mail route belongs to the domain. Even recipient acceptance may reflect catch-all behaviour, so it cannot identify the person who submitted the address. Read how the verification checks work for the complete process.
Emvero’s service scope makes this boundary explicit: it sends no message, and a positive check does not replace confirmation of mailbox control.
A deliverable address can still be unconfirmed
Suppose someone submits alex@example.com. This is a synthetic example; no mailbox was checked and no message was sent.
Your application receives a completed deliverable result with allow. That supports continuing the signup. It does not tell you whether the person mistyped a working address belonging to someone else. Setting confirmation from the check would treat the person as having mailbox access without testing it.
Keep the verification result separate from an application field such as email_confirmed_at. This example field belongs to your application, not Emvero’s API. Set it only after your server accepts a valid confirmation challenge for the account and submitted address. Retain the verification result alongside it so you can explain both decisions.
If the address names a team or function, use the role-address signup policy to decide whether it belongs on the login account or a separate contact record.
Verification and confirmation can produce different answers for the same address:
| Address evidence | Application confirmation | What you can conclude |
|---|---|---|
deliverable |
Not completed | The check supports the address; mailbox control is still unconfirmed. |
unknown |
Completed | The person accessed the confirmation message even though the pre-send check was inconclusive. Preserve both findings. |
risky |
Completed | Confirmation adds evidence of access; it does not erase the signal that made the address risky. |
pending |
Not completed | Recipient work is unfinished and mailbox control is unconfirmed. These are independent states. |
Read status, action and reason_codes together. In Emvero, risky can carry allow or allow_with_email_confirmation, depending on the cause. unknown is inconclusive; undeliverable supports rejection under the current evidence policy. The guide to interpreting a verification result explains the difference between a status and a recommendation.
Use both steps when account access depends on email
A pre-send check can identify a format or domain problem while the person can correct it. Confirmation then supplies the evidence of access that the check cannot obtain.
For a signup flow, continue according to the returned action and your product policy. If it is reject, ask for a correction. With allow_with_email_confirmation, continue behind your confirmation step. Even with allow, retain that step wherever mailbox control is a requirement. A technical recommendation to proceed does not grant access to someone else’s account.
If the result is pending, finish retrieving it or apply your form’s fallback policy. Keep work in progress separate from an expired confirmation link, an unanswered message and a terminal unknown result. The signup-form validation guide covers the wider implementation.
For an existing contact list, verification can help assess current address evidence without contacting every person. That task does not require sending unsolicited confirmation messages to the list. Whether a person agreed to receive a campaign is a separate record your application must maintain.
Bind confirmation to the address being confirmed
If the person corrects the address before confirming, check the new value and prevent a challenge for the old address from confirming it. A confirmation record must identify which address was actually confirmed.
Use cryptographically random, single-use, time-limited tokens, as OWASP’s email verification guidance recommends. Validate the challenge on your server before recording confirmation.
When a confirmation attempt expires or never completes, record that outcome separately. You have not established access through that challenge; you have also not established that the address is undeliverable. Keep a correction or resend path available under your application’s rules.
Neither step establishes personal identity, permission to send marketing, engagement or future inbox placement. A confirmation message can also reach a shared or forwarded mailbox, so completed confirmation should be read as evidence of access at that time.
To add the address-evidence step, use the email verification API from your server. Keep message sending and confirmation state in your application.