Theme

Popular tools

Email Checker: Verify Any Email Address

See if an email address is real without sending anything: we ask its mail server and show you the conversation. Or send your own email to a test address for a full deliverability report.

Sources: DNS (MX, SPF, DMARC) · a live SMTP check from our server, stopped before DATA · our own mail server for test mail (Cloudflare Email Routing as the backup) · SpamAssassin 4

We ask the address's mail server, as a sender would, and stop before anything is sent.

Try

Nothing is sent to the address. We log the domain and reply code; an answer is kept up to a day under a keyed hash, without the address.

How to verify an email address without sending an email

A mail server says whether it knows an address before any message is sent. We ask that question, then hang up.

Sending an email is a short conversation between two servers. The sender says hello (EHLO), names a return address (MAIL FROM), names the recipient (RCPT TO), and only then sends the message (DATA). The receiving server answers each line with a three-digit code (RFC 5321).

We hold the conversation up to RCPT TO and read the answer. Then we reset (RSET), ask once more about a made-up address at the same domain (the control), and say goodbye with QUIT. DATA is never sent, so nothing reaches anyone's inbox, and the empty return address means nothing can bounce back.

probe.dnsrobot.netOur checking server · Mumbai · 198.51.100.25mx-in.g.apple.comThe domain's mail server · Apple · 203.0.113.17
  1. 220 hfd-mx01.apple.com -- Server ESMTP (Oracle Communications Messaging Server 8.1.0.28.20250821 64bit (built Aug 21 2025))295 ms
  2. EHLO probe.dnsrobot.net
  3. 250 hfd-mx01.apple.com · 8BITMIME · PIPELINING · CHUNKING …140 ms
  4. MAIL FROM: <>empty sender: nothing can bounce back
  5. 250 2.5.0 Address Ok157 ms
  6. RCPT TO: <postmaster@apple.com>1
  7. 250 2.1.5 postmaster@apple.com Ok1200 ms
  8. RSET · MAIL FROM:<> · RCPT TO: <5b1c71ed2e78ecf2@apple.com>2a made-up address at the same domain
  9. 550 5.1.1 unknown or illegal alias: 5b1c71ed2e78ecf2@apple.com2145 ms
  10. DATA never sent: we stop before the message
  11. QUIT
  1. Syntax1 ms
  2. Domain & MX181 ms
  3. Lists< 1 ms
  4. Mail server1.5 s
A real check of postmaster@apple.com, the role address every mail domain must have (RFC 2142), from our server in Mumbai: 7 replies in 1.5 s. The server refuses the made-up address (550 5.1.1), which is what makes its yes to the real one believable.
Email checker result for postmaster@apple.com: deliverable, with the SMTP conversation and the made-up control addressEmail checker result for postmaster@apple.com: deliverable, with the SMTP conversation and the made-up control addressThe verdictDeliverable, Undeliverable, Accept-all, Risky or Unknown, with the reply codes that decided it and one sentence saying why.The four stepsSyntax, the domain's mail servers, the disposable and role lists, then the mail server itself, each with its time.The answers that decidedThe address and a made-up address at the same domain: a yes to the first and a no to the second makes the yes believable.The conversationEvery command our server sent and every reply the mail server gave, as it happened, with each reply's code and time.Nothing sentDATA is never sent: the conversation stops before a message exists, so nothing reaches the inbox and nothing can bounce.
A real check of postmaster@apple.com, the role address every mail domain must have: the verdict, the four steps, the two answers that decided it and the whole SMTP conversation, stopped before DATA. Select a number to see what each part shows.

What each email verifier result means

Five answers, each tied to the reply that produced it.

Deliverable needs two things: a yes for the address and a no for a made-up one at the same domain (or a provider measured to check every address). Without the second answer, a yes is only a yes from a server that might say yes to anyone.

Unknown is honest, not a failure: the server refused to talk to our checking server, asked us to wait, or didn't answer. It says nothing about the address, so we never turn it into “invalid”.

  • Deliverable
    The address
    250
    A made-up one
    550

    The server knows the address and refuses a stranger at the same domain.

    Send.
  • Undeliverable
    The address
    550 5.1.1
    Or the domain
    null MXno such domain

    The server says the mailbox doesn't exist, or the domain takes no mail at all.

    Don't send: it would bounce.
  • Accept-all
    The address
    250
    A made-up one
    250

    The server says yes to anything, so its yes proves nothing.

    Send only if you got it from the person.
  • Risky
    The domain
    disposable list
    Or the mailbox
    552full

    It exists, but it won't last or can't take mail right now.

    Avoid it for anything you need later.
  • Unknown
    The address
    451554no answer
    Or DNS
    SERVFAIL

    The server wouldn't answer or asked us to come back. Not a no.

    Check again later, or just send.
Every result comes from a reply code (RFC 5321) or a fact about the domain, never a guess. Role, free, alias and legacy addresses are flags beside the result, never the result.

Which email providers can be verified

What a check can tell depends on the provider. We measured 65 mail domains, run by 53 providers, from our server.

Most consumer providers refuse unknown addresses at RCPT, so a check there is reliable. Some accept everything and sort mail later; Outlook.com sometimes says yes once to stop address harvesting; a few refuse servers they don't know.

We never use password-recovery or sign-up pages to test an address, as some checkers do: it breaks the providers' terms and is exactly how attackers find accounts.

Measured from our serverOctober 22, 2026 · 65 domains, 10 of them companies
Checks every address42 domainsAn unknown address gets a 5xx at RCPT, so a yes is a real yes.
  • 163.com
  • au.com
  • biglobe.ne.jp
  • comcast.net
  • daum.net
  • docomo.ne.jp
  • ezweb.ne.jp
  • freenet.de
  • gmail.com
  • gmx.com
  • gmx.de
  • hanmail.net
  • hey.com
  • i.softbank.jp
  • icloud.com
  • kakao.com
  • laposte.net
  • libero.it
  • mail.com
  • mailbox.org
  • naver.com
  • o2.pl
  • ocn.ne.jp
  • orange.fr
  • posteo.de
  • proton.me
  • qq.com
  • rambler.ru
  • rediffmail.com
  • seznam.cz
  • sfr.fr
  • softbank.ne.jp
  • terra.com.br
  • tuta.io
  • uol.com.br
  • web.de
  • wp.pl
  • yandex.ru
  • zoho.com
  • apple.com
  • microsoft.com
  • salesforce.com
Says yes to some made-up addresses2 domainsOutlook.com: 2 of 12 made-up addresses got 250 once. We ask twice.
  • hotmail.com
  • outlook.com
Accepts every address9 domainsA yes proves nothing here: these servers accept first and sort mail later.
  • mail.ru
  • yahoo.co.jp
  • amazon.com
  • github.com
  • google.com
  • netflix.com
  • shopify.com
  • spotify.com
  • stripe.com
Turn our server away for now8 domainsThey want our server's reverse DNS to match, forward and back. Yahoo's own error list also shows that mail to unknown accounts bounces after it is sent.
  • aol.com
  • att.net
  • bol.com.br
  • cox.net
  • free.fr
  • nifty.com
  • verizon.net
  • yahoo.com
Greylist or defer3 domainsA 4xx. Fastmail greylists: the same question a minute later gets an answer. onet.pl and interia.pl defer by a rule with an end date or a delivery limit, which waiting won't change.
  • fastmail.com
  • interia.pl
  • onet.pl
Asks not to be checked1 domainDeutsche Telekom: we don't connect at all.
  • t-online.de
Companies show their mail platform's mark (Microsoft 365, Google Workspace, Proofpoint, iCloud). A company's answer is its own setting, not the platform's rule: microsoft.com checks every address, github.com on the same platform accepts any.

Catch-all, greylisting and refusals: when an address can't be confirmed

Three ways a mail server avoids answering, and how each one shows up in the result.

An accept-all (catch-all) server says 250 to every address, real or not. Many Microsoft 365 companies work this way without knowing: Directory-Based Edge Blocking only refuses unknown addresses when the domain is set to Authoritative.

Greylisting answers 451 to senders it hasn't seen, then accepts the same question a minute later (RFC 6647). Refusals can come at any step up to RCPT (bol.com.br's came at RCPT itself), but they name our server, not the address, so the result is Unknown, never a no.

Accept-all
  • sam.example@example.org250
  • 9e2b7c41d0a8f365@example.org250

Both got a yes: the server can't tell them apart, so neither can we.

A Microsoft 365 domain set toInternal relay250any addressAuthoritative (Directory-Based Edge Blocking)550 5.4.1an unknown address
Greylisting
0 s451 4.7.1“Recipient address rejected: Temporary deferral, try again soon”
wait at least a minute: same server, same sender, same address (RFC 6647)
60+ s250550the real answer

Fastmail did this to us. The result offers Check again after a minute, never a tight loop. (onet.pl and interia.pl also answered 450, but citing a rule with an end date and a delivery limit: refusals, so we don't offer the wait.)

Refusals: where each server stopped us
connectgreetingEHLOMAILRCPT
nifty.com554
FCrDNS check failed: reverse DNS does not match the connecting IP
free.fr421
Refused. Your reverse DNS entry does not resolve to an IP.
t-online.de554
None/bad reputation … (NOWL)
yahoo.com550 5.7.25
Forward-confirmed reverse DNS failed
bol.com.br450 4.7.25
Client host rejected: cannot find your hostname

A refusal names our server, not the address, wherever it comes (bol.com.br's came at RCPT), so the result is Unknown, never “invalid”.

Codes and texts as the servers sent them to our checking server on October 22, 2026. Four of the five refusals are about reverse DNS (forward-confirmed PTR) and go away once our server's PTR record matches.

Disposable, role, free and alias email addresses

Flags describe the address; they never decide the result on their own.

A role inbox (support@, sales@) is real but shared, a free address is normal for people, an alias forwards to someone's real inbox, and a disposable address is a public inbox that's gone within hours.

Japanese carriers still have addresses with two dots, or a dot before the @. They break the RFC but receive mail, so we ask the mail server about them exactly as typed.

supportrole mailbox (RFC 2142)+orderssubaddress (RFC 5233)@example.comthe domain decides: free, disposable or alias
  • Role inboxpostmaster@support@sales@

    A team inbox: real and often read, but nobody's personal address. RFC 2142 names the ones a domain should have.

  • Free provider

    Anyone can sign up. Normal for people; unusual for a company's own staff.

  • Disposable@mailinator.comabout 9,900 domains

    Public inboxes that vanish within hours. From the disposable-email-domains list (CC0), matched at the registrable domain.

  • Alias service

    Forwards to a real inbox the person keeps private. Not disposable: replies reach them.

  • Legacy carrier addresstaro..yamada@docomo.ne.jp

    Not RFC-valid, still in use: docomo and au let people keep older addresses with “..” or “.@”. We ask the server exactly as typed.

Flags never decide the result on their own: a role inbox can be deliverable, and an alias can be accept-all.

Test your email: how it works

Send one real email to a one-time address; the report builds as each part is checked.

Your test address takes one message for 2 hours. Our own mail server receives it for mailtest.dnsrobot.net over TLS and sees the SMTP session first-hand: the TLS version, the greeting, how the sending server talks. Cloudflare Email Routing is the backup path.

Everything runs on what actually arrived: the address that connected, the headers your service added, the HTML your readers will get. Then SPF, DKIM, DMARC, ARC, the format, the content, the unsubscribe headers, SpamAssassin and the inbox providers' rules.

The full guide, with what a receiving server checks in order and the codes Gmail and Outlook.com refuse with, is on the email deliverability test page.

  1. Your mail appyou press Send14:02:10
  2. Your sending serveryour email serviceSendGrid · 198.51.100.24
    Reverse DNS (PTR)HELO nameBlocklists
  3. Our mail serverreceives it over TLSmailprobe.dnsrobot.net · TLSv1.3
    the SMTP sessionTLS versionEHLO and pipeliningLine endings
    the messageSPFDKIMDMARCARCFormatContentUnsubscribe
  4. Your reportparts appear as they're checked14:02:24
    SpamAssassinGmail · Yahoo · Outlook.com rulesScore
Backup: Cloudflare Email Routingroute1–3.mx.cloudflare.nettakes the mail if our server is down; it doesn't pass on the TLS details
What happens to your message
0 sarrives at our mail server11 sanalysis done: the body and attachments are deleted7 daysheaders, links and the preview deleted (or sooner: Delete report)
The example on this page: a newsletter sent through SendGrid. Each check lights where it happens: the sending server's identity, the SMTP session our server saw, the message's signatures and content, then SpamAssassin and the inbox providers' rules.

How the test scores your message

Ten points, minus deductions that each name their rule. Nothing we couldn't check costs a point.

A score is only useful if you can see how it was made, so the whole table is here, generated from the same code that scores your message. Each deduction rests on an RFC, a mailbox provider's own page or a SpamAssassin rule.

Bulk-only rules, like one-click unsubscribe, deduct only when the message looks like bulk mail. What one message can't show (complaint rates, sending volume) is “can't tell”, and costs nothing.

A made-up report7.8

10 − 1.5 − 0.7 = 7.8

  1. 1Bulk mail without working one-click unsubscribe (RFC 8058: both headers, signed by DKIM)
  2. 2SpamAssassin 3.4
What we foundPoints offPart
Neither SPF passes nor any DKIM signature verifies−3SPF
DMARC fails: no aligned SPF or DKIM pass, and the From domain publishes a policy−2.5DMARC
The From header has no single domain DMARC can apply to−2DMARC
The From domain publishes no DMARC recordbulk mail only−1DMARC
SPF fail: the record says this server may not send−1SPF
SPF softfail or neutral−0.5SPF
No SPF record for the MAIL FROM (or HELO) domain−1SPF
SPF permerror: a broken record or more than 10 DNS lookups−1SPF
The message isn't DKIM-signedbulk mail only−1DKIM
DKIM-signed, but every signature fails (treated as unsigned)bulk mail only−1DKIM
A signature uses an RSA key under 1,024 bits−1DKIM
DKIM passes, but no passing signature matches the From domain−0.5DKIM
The sending address is on a major blocklist−3Sending server
The sending address is on a smaller blocklist−1Sending server
The sending address has no reverse DNS (PTR)−2.5Sending server
The PTR name doesn't resolve back to the sending address−1.5Sending server
HELO is not a fully qualified name−0.5Sending server
The server sent without TLS−1.5SMTP session
Bare LF or CR line endings in the message0a warning, not counted in the score (−0.5 once a source is cited)SMTP session
From is missing, repeated, unreadable, or lists several mailboxes without Sender−2Format
Date is missing or unreadable−1Format
Message-ID is missing or malformed−1Format
Date is more than a day from the time it arrived0a warning, not counted in the score (−0.5 once a source is cited)Format
A field that may appear once appears twice−0.5Format
Lines longer than 998 characters−0.25Format
Images with almost no text0a warning, not counted in the score (−1 once a source is cited)Content
HTML with no plain-text version−0.5Content
HTML over about 102 KB: Gmail may clip it0a warning, not counted in the score (−0.5 once a source is cited)Content
Links through URL shorteners0a warning, not counted in the score (−1 once a source is cited)Content
Links to a bare IP address0a warning, not counted in the score (−1 once a source is cited)Content
Links to a domain that imitates another0a warning, not counted in the score (−2 once a source is cited)Content
javascript:, data: or file: links0a warning, not counted in the score (−2 once a source is cited)Content
Link text shows one domain and the link goes to another0a warning, not counted in the score (−0.5 once a source is cited)Content
An attachment type Gmail blocks0a warning, not counted in the score (−2 once a source is cited)Content
Links to a host Cloudflare's security resolver blocks (malware or phishing)0a warning, not counted in the score (−2 once a source is cited)Content
Scripts, iframes, forms or embedded objects in the HTML−1Content
1Bulk mail without working one-click unsubscribe (RFC 8058: both headers, signed by DKIM)−1.5Unsubscribe
2SpamAssassin's points above 2.0half the points over 2.0, at most 3SpamAssassin
SpamAssassin's score reaches its spam threshold−2SpamAssassin
Not checked, or can't tell from one message0–
The table the score uses (version 2026-10-31.1): 10 minus every row that applies, never below 0. A part we couldn't check deducts nothing; bulk-mail rows cost points only on bulk mail; a row at 0 is a warning we show but don't count in the score.

SPF, DKIM and DMARC alignment in one picture

DMARC passes when SPF or DKIM passes for a domain that matches the From address people see.

An email has two senders: the hidden envelope sender that bounces go to, and the From address people read. SPF checks the first, DKIM checks a signature, and DMARC ties either one to the second (RFC 9989).

Email services usually pass DMARC through DKIM: they sign with your domain (a record you add) while bounces go to their own subdomain.

Return-Path: bounces+48213-9f1c@em.example.orgthe envelope sender (MAIL FROM): SPF checks this one
DKIM-Signature: v=1; a=rsa-sha256; d=example.org; s=s1; …a signature by the From domain
DKIM-Signature: v=1; a=rsa-sha256; d=sendgrid.info; s=smtpapi; …the email service's own signature
From: Example Weekly <news@example.org>what the reader sees: DMARC protects this one
  1. SPF pass198.51.100.24 may send for em.example.orgaligned: em.example.org belongs to example.org
  2. DKIM passthe signature by example.org verifiesaligned: the same domain
  3. DKIM passthe signature by sendgrid.info verifiesnot aligned: a different domain (that's fine)
  4. DMARC passFrom example.org: at least one pass is alignedpolicy p=none · relaxed alignment
SPF checks the hidden envelope sender, DKIM checks a signature, and DMARC asks whether either belongs to the From domain people see. Relaxed alignment compares organizational domains (em.example.org and example.org match); strict compares exact names.

Gmail, Yahoo and Outlook.com sender requirements

Since 2024 the biggest inbox providers publish what they require. Here they are side by side.

Every sender needs SPF or DKIM, working reverse DNS and a well-formed message. Bulk senders also need both SPF and DKIM, a DMARC record aligned with the From address, one-click unsubscribe and a low complaint rate.

Our report checks every rule one message can show, and says “can't tell” for the rest: complaint rates live in Google Postmaster Tools and Yahoo's Sender Hub.

GmailYahooOutlook.com
All sendersBulk senders5,000+ a dayAll sendersBulk sendersno number givenBulk senders5,000+ a day
SPF or DKIM passes4.7.27 · 4.7.30–––
SPF and DKIM both pass4.7.27 · 4.7.30–––
SPF passes––––1
DKIM passes––––1
A DMARC record, p=none or stricter4.7.40 · 5.7.40–––
From aligned with SPF or DKIM (DMARC passes)4.7.32 · 5.7.32––1
Forward and reverse DNS (PTR)4.7.23–––
TLS on the connection4.7.29––––
RFC 5322 message format2–––
No Gmail From: from elsewhere––––
A valid From or Reply-To address––––
One-click unsubscribe (RFC 8058)–––
List-Unsubscribe (mailto or https)––––
A visible unsubscribe link in the body––
Spam complaints under 0.3%–––

requiredrecommended– not in that provider's rules4.7.23the code Gmail answers with when it's missingone message can't show it: we say “can't tell”

1 550 5.7.5152 Gmail also asks for a single address in From.

Gmail and Yahoo since February 2024 (Gmail enforcing harder from November 2025), Outlook.com since 5 May 2025, rejecting with 550 5.7.515. The report checks each row one message can show.

Privacy: what we keep, and what the mail server sees

The address you check isn't kept: its answer is, for up to a day, under a keyed hash and without the address. A test message's body is deleted right after the analysis.

Checking an address sends its mail server a few short commands and nothing else: EHLO, MAIL FROM:<>, RCPT TO for the address and for one made-up address (and once more for Outlook.com), RSET, QUIT. The server sees our server's name, an empty sender and the addresses asked about: not you, and not a message.

A test report keeps the message's headers, its links and a 140-character preview, with the findings, for 7 days so you can share its link; the full body and attachments are deleted right after the analysis. You can delete the report at any time from the report itself.

Verify an address
  1. You type itIt goes to our server over HTTPS, in the request only.
  2. The mail server seesEHLO probe.dnsrobot.net · MAIL FROM:<> · RCPT TO:<…> · RSET · MAIL FROM:<> · RCPT TO:<…> · QUITThese few commands and nothing else: our server's name, an empty sender, RCPT TO for the address and for one made-up address (and once more for Outlook.com). No message, no name, nothing about you.
  3. We keepNot the address. Logs hold the domain and the reply code; a definite answer is kept up to a day under a keyed hash, without the address.
Test your email
  1. The message itselfIts body and attachments are deleted right after the analysis. SpamAssassin reads it in memory on our mail server; nothing is logged.
  2. The reportThe headers, the domains the message links to (with one example link for each) and a 140-character preview: 7 days, or until you press Delete report. Anyone with its link can open it.
  3. We neverforward it, reply to it, or read it by hand.
Checking an address is processing personal data under the GDPR even when nothing is stored, so we keep as little as we can. Spamhaus asks checkers not to offer list cleaning: bulk lists get no mailbox checks.

Frequently asked questions

Is this email checker free?

Yes, with no sign-up. You can verify single addresses (a few a minute), check lists of up to 100 addresses, and run email deliverability tests. The limits are there because every check reaches a real mail server: servers block checkers that ask too often, and that would stop the tool working for everyone.

How do I verify an email address without sending an email?

Enter it above. We look up the domain's mail servers, connect to the first one and ask whether it would accept mail for the address (RCPT TO). Then we ask about a made-up address at the same domain, so we know whether the server tells them apart, and hang up before any message is sent.

How accurate is an email verifier, and can a valid address still bounce?

As accurate as the mail provider allows. Gmail, iCloud and most consumer providers answer clearly; accept-all domains and providers that refuse checks can't be confirmed by anyone. A full mailbox, or a change after the check, can still bounce a valid address. We show which case you're in instead of a made-up percentage.

Will the person know I checked their email address?

No. Nothing reaches their inbox, because the conversation stops before a message is sent. Their provider's server records a connection from our checking server, as it does for every sender that knocks, but it doesn't tell the mailbox owner, and we don't send anything they could see.

Why does a Gmail, Yahoo or Outlook.com address give this result?

Gmail checks every address, so its answers are reliable. Outlook.com sometimes says yes to a made-up address once, so we ask twice and trust only matching answers. Yahoo turns away servers whose reverse DNS doesn't match, ours included for now, so Yahoo addresses come back Unknown. Yahoo's own error list also shows that mail to unknown accounts bounces after it is sent.

What is a catch-all (accept-all) email address?

It's an address at a domain whose mail server accepts mail for every address, existing or not, and sorts it out later. A check can't tell a real mailbox from a made-up one there, so the result is Accept-all. Send to it only if you got the address from the person, and watch for bounces.

Why is my email check result Unknown?

The mail server didn't answer about the address. It greylisted our checking server (try again in a minute), refused it because of a rule about servers, didn't reply in time, or belongs to a provider that asks not to be checked. Unknown is never a no: an address you were given is probably fine.

How do I test my email's deliverability and spam score?

For an email spam test, open Test your email above and copy the one-time address. Send a test email to it: your real message, from the same account and service you normally use. The report builds as each part is checked: the sending server, SPF, DKIM, DMARC, the content, the unsubscribe headers, SpamAssassin and Gmail's, Yahoo's and Outlook.com's rules, with a score out of 10. The email deliverability test page has the same test with its full guide.

Does a 10/10 from a mail tester mean my email lands in the inbox?

No test can promise that. Inbox placement also depends on your sending history and on how often people mark your mail as spam, which only the mailbox providers see. A 10/10 means nothing we can check in one message is wrong. We have no seed mailboxes, so we never claim to measure inbox placement.

Do you store the addresses I check or the emails I send?

Not the addresses: our logs hold the domain and the mail server's reply code, and a definite answer is kept up to a day under a keyed hash, without the address. A test message's full body and attachments are deleted right after the analysis. Its report keeps the headers, the links and a 140-character preview for 7 days, or until you press Delete report.

What does “verify email address” mean, compared with validation?

Validation checks the address's form and its domain: the syntax, and whether the domain has mail servers. Verification also asks the mail server about the mailbox itself. This email checker does both for single addresses; the bulk mode validates every row and lets you verify any row's mailbox when you need it.

Can I check a list of email addresses?

Yes, up to 100 at a time, pasted or from a CSV file, and you can download the results as CSV. Every row gets syntax, domain, mail servers and lists. Mailboxes are checked one at a time, when you choose, because asking a hundred mail servers at once is list washing, which mail servers block.

Missing something?Suggest a feature or a new tool

Related tools