使用官方的java电子邮件包是最简单的:

public static boolean isValidEmailAddress(String email) {
   boolean result = true;
   try {
      InternetAddress emailAddr = new InternetAddress(email);
      emailAddr.validate();
   } catch (AddressException ex) {
      result = false;
   }
   return result;
}

可以像其他答案中提到的那样使用Apache Commons验证器。

pom.xml:

<dependency>
    <groupId>commons-validator</groupId>
    <artifactId>commons-validator</artifactId>
    <version>1.4.1</version>
</dependency>

build.gradle:

compile 'commons-validator:commons-validator:1.4.1'

导入:

import org.apache.commons.validator.routines.EmailValidator;

代码:

String email = "myName@example.com";
boolean valid = EmailValidator.getInstance().isValid(email);

并允许本地地址

boolean allowLocal = true;
boolean valid = EmailValidator.getInstance(allowLocal).isValid(email);

Apache Commons通常被认为是一个可靠的项目。但是请记住，如果你想确保它是一个真实的电子邮件，并且所有者希望它在你的网站上使用，你仍然需要发送一封验证邮件到这个地址。

编辑:有一个错误，它对域名的限制太大，导致它不接受来自新顶级域名的有效电子邮件。 此错误已于03/Jan/15 02:48在common -validator版本1.4.1中解决

您想验证什么?电子邮件地址?

只能检查电子邮件地址的格式是否符合要求。参见标准:RFC2822。最好的方法是使用正则表达式。如果不发一封邮件，你永远不会知道是否真的存在。

我检查了公共验证器。它包含一个org.apache.commons.validator.EmailValidator类。看起来是个不错的起点。

尽管有许多替代Apache commons的方法，但它们的实现充其量只是基本的(就像Apache commons的实现本身一样)，在其他情况下甚至是完全错误的。

我也会远离所谓的简单的“非限制性”正则表达式;没有这样的事。例如，@根据上下文被允许多次使用，你怎么知道需要的那个在那里?简单的正则表达式无法理解它，即使电子邮件应该是有效的。任何更复杂的东西都很容易出错，甚至包含隐藏的性能杀手。你要怎么维护这样的东西?

我所知道的唯一一个全面的RFC兼容的基于regex的验证器是email-rfc2822-validator，它的“精炼”regex适当地命名为Dragons.java。它只支持较旧的RFC-2822规范，尽管它足够满足现代需求(RFC-5322在日常使用范围之外的地方更新了它)。

但真正需要的是一个词法分析器，它可以正确地解析字符串，并根据RFC语法将其分解为组件结构。EmailValidator4J在这方面似乎很有前途，但仍然很年轻，而且有局限性。

另一种选择是使用webservice，比如Mailgun经过实战测试的验证webservice或Mailboxlayer API(只使用第一个谷歌结果)。它不是严格的RFC兼容，但是对于现代需求来说已经足够好了。

我在这个地址上维护了一个类:http://lacinato.com/cm/software/emailrelated/emailaddress

它基于Les Hazlewood的类，但有许多改进并修复了一些错误。Apache许可证。

I believe it is the most capable email parser in Java, and I have yet to see one more capable in any language, though there may be one out there. It's not a lexer-style parser, but uses some complicated java regex, and thus is not as efficient as it could be, but my company has parsed well over 10 billion real-world addresses with it: it's certainly usable in a high-performance situation. Maybe once a year it'll hit an address that causes a regex stack overflow (appropriately), but these are spam addresses which are hundreds or thousands of characters long with many many quotes and parenthesis and the like.

RFC 2822和相关规范在电子邮件地址方面是非常宽松的，所以这样的类对于大多数用途来说是多余的。例如，以下是一个合法的地址，根据规范，空格和所有:

"<bob \" (here) " < (hi there) "bob(the man)smith" (hi) @ (there) example.com (hello) > (again)

没有邮件服务器允许这样做，但是这个类可以解析它(并将其重写为可用的形式)。

我们发现现有的Java电子邮件解析器选项不够持久(也就是说，它们都不能解析一些有效地址)，因此创建了这个类。

该代码有良好的文档记录，并且有许多易于更改的选项来允许或禁止某些电子邮件表单。它还提供了许多方法来访问地址的某些部分(左侧、右侧、个人姓名、注释等)，解析/验证邮箱列表头，解析/验证返回路径(在头中是唯一的)，等等。

编写的代码有一个javamail依赖项，但是如果您不想要它提供的次要功能，那么很容易删除它。