Free email tool

Email Validator

Check the syntax of an address, confirm the domain can actually receive mail, and spot disposable and role accounts before you send to them.

Try , , , ,

Checks syntax in your browser and looks up the domain over encrypted DNS. It does not open an SMTP session, so it cannot confirm that a mailbox exists, and it never claims to. The part of the address before the @ is not sent anywhere.

Mail servers fail like everything else. Pulsetic watches the SMTP and IMAP ports your mail depends on and tells you when one stops answering.

What can be checked, and what cannot

Email validation sounds like it should be a yes or no question. It is not, and the gap between what people expect and what is actually knowable is where most confusion lives.

Three things can be checked from outside, quickly and reliably. Whether the address is well formed. Whether its domain exists. And whether that domain publishes MX records, which is how it announces that it accepts mail and where to send it. An address that fails any of those will not receive mail, and you can say so with confidence.

One thing cannot be checked: whether the mailbox exists. That answer lives only on the receiving mail server, and the only way to ask is to start an SMTP conversation and issue a RCPT TO command for that specific address. It is a legitimate protocol feature, and it is also precisely how address harvesters work, so most serious mail servers now refuse to answer honestly. Many accept every address you ask about, whether it exists or not. Others quietly add you to a blocklist for asking. This tool does not ask.

The signals worth acting on

A domain with no MX record is the clearest one. Strictly, senders may fall back to the domain's A record, so mail sometimes still lands. In practice that fallback is honoured inconsistently, which is worse than a clean failure: the address works for some senders and not others, and nobody can tell you why. On your own domain, publish an MX record.

Disposable domains are the second. Mail to a throwaway inbox is deliverable and worthless, and the address will be gone within the hour. The catch is that the list of these services is enormous and changes weekly, so no check against a curated list can be complete. Treat a flag as reliable and the absence of one as merely uninformative.

Role addresses are the softest signal. Mail to info@ or support@ arrives perfectly well. It matters only in bulk: shared inboxes generate more complaints, and enough complaints affects the reputation of everything else you send. For a single message, it is nothing to worry about.

Why SPF and DMARC are reported separately

Most validators fold these into a single score, and that is a mistake worth naming. SPF and DMARC control whether someone can send mail pretending to be a domain. They have no bearing on whether mail sent to that domain arrives.

A domain with no SPF record still receives mail perfectly. What it cannot do is stop others from forging its address, which is a real problem for whoever owns it and no problem at all for you writing to them. So this page reports those records under their own heading, as information about the domain rather than a judgement on the address. If it is your own domain and the news is bad, the SPF checker and DMARC checker examine both properly, including the ten-lookup limit that quietly breaks SPF.

Frequently asked questions

  • Can this tool tell me if an email address really exists?

    No, and be wary of any free tool that says it can. Confirming a mailbox means opening an SMTP conversation with the receiving server and asking about that specific address. It is blocked on most networks, it gets the asking server blocklisted, and it is the same technique address harvesters use. What this tool does instead is check everything that can be checked without contacting anyone: the syntax, whether the domain can receive mail at all, and whether the address carries signals worth a second look.

  • What does the tool actually check?

    Six things. That the address is well formed under RFC 5322. That the domain exists in DNS. That it publishes MX records, meaning it is set up to receive mail. Which provider runs that mail. Whether the domain is a known disposable address service. And whether the local part is a role account rather than a person.

  • Why does it say "Deliverable-looking" instead of valid?

    Because that is the honest ceiling for a check that never contacts the mail server. Correct syntax and working MX records mean the address can receive mail. They cannot tell you the mailbox was ever created, or that it has not since been closed. "Deliverable-looking" says exactly as much as the evidence supports.

  • What is a role address, and why is it flagged?

    An address that belongs to a function rather than a person: info@, support@, sales@, admin@. They are perfectly valid, and mail to them arrives. They are flagged because they behave differently in bulk sending. They are often shared inboxes or aliases, they attract higher complaint rates, and some list providers treat them as a quality signal. If you are sending one message, ignore the flag.

  • What is a disposable email address?

    A throwaway inbox from a service like Mailinator or Guerrilla Mail, usually created to get past a signup form and abandoned minutes later. Mail to one is technically deliverable and practically pointless. The list of these services runs to thousands of domains and changes constantly, so this tool checks a curated list of the well-known ones. A domain that is not flagged has not been proven to be permanent.

  • The domain has no MX record. Is the address broken?

    Probably, but not certainly. When a domain publishes no MX record, the standard says senders may fall back to its A record and deliver to that address instead. Plenty of mail servers still honour that fallback and plenty do not, so mail to such an address arrives unpredictably. If it is your own domain, publish an MX record.

  • Does a missing SPF or DMARC record mean mail will bounce?

    Not for mail sent to the address. Those records control whether someone else can send mail pretending to be from that domain, which is an outbound spoofing question, not an inbound delivery one. This tool reports them separately for that reason. If you want them examined properly, the SPF checker and DMARC checker go much deeper.

  • Is the address I type sent anywhere?

    The address itself is never transmitted. Syntax is checked in your browser, and only the domain part is looked up, over encrypted DNS, exactly as your mail client would. The part before the @ never leaves the page.

Trusted by teams at companies around the world