E-Mail-Adresse in Java validieren

Eine E-Mail-Adresse in Java zu validieren, sind eigentlich drei Prüfungen, die sich einen Namen teilen. Die meisten Tutorials greifen zu einer Regex, bestätigen, dass die Zeichenkette wie eine Adresse geformt ist, und erklären es damit für erledigt — doch die Form ist das am wenigsten nützliche der drei Dinge, die Sie eigentlich wissen wollen. Echte Validierung ist geschichtet: eine günstige Formatprüfung, ein DNS-Lookup für die Mail-Route der Domain und eine SMTP-Postfachprüfung. Javas Standardbibliothek und Jakarta Mail decken die ersten beiden sauber ab; die dritte ist ein Netzwerkproblem, das man besser auslagert. Dieser Leitfaden baut jede Schicht mit lauffähigem Code auf und zeigt genau, wo jede von ihnen aufhört.

Die kurze Antwort#

Verwenden Sie jakarta.mail.internet.InternetAddress (oder Apache Commons Validator) für die Syntax, den in das JDK integrierten JNDI-DNS-Provider für den MX-Lookup und eine Verifizierungs-API für die SMTP-Postfachprüfung — das Günstigste zuerst, mit Kurzschluss, sobald eine Prüfung entscheidend ist. Öffnen Sie keine SMTP-Verbindungen von Ihrer Anwendung aus, um Postfächer selbst zu prüfen: Der ausgehende Port 25 ist auf den meisten Hosts blockiert, und die Antwort hängt von der Reputation der Sende-IP und vom Greylisting ab, das Sie nicht neu implementieren wollen. Jede Schicht schließt Adressen günstiger aus als die vorherige; nur die letzte kann eine Adresse einschließen.

Schicht 1: Syntax mit Jakarta Mail#

Jakarta Mail — die Bibliothek, die von javax.mail umbenannt wurde, als sie in den Namensraum von Jakarta EE wechselte — liefert einen Adress-Parser, auf den Sie sich statt auf eine selbst gebastelte Regex stützen können. Konstruieren Sie eine InternetAddress und rufen Sie validate() auf: Der Konstruktor parst die Adresse, und validate() erzwingt die RFC-822-Syntax und wirft bei allem Fehlerhaften eine AddressException.

import jakarta.mail.internet.AddressException;
import jakarta.mail.internet.InternetAddress;

public static boolean isValidSyntax(String email) {
    if (email == null || email.length() > 320) {
        return false;
    }
    try {
        InternetAddress address = new InternetAddress(email);
        address.validate();
        // Rejects "Jane <jane@example.com>": the parser keeps only the address part.
        return email.equals(address.getAddress());
    } catch (AddressException e) {
        return false;
    }
}

Dieser letzte Vergleich schließt eine Lücke, die die meisten Beispiele übersehen. InternetAddress parst laut Dokumentation auch die Form Personal Name <user@host.domain>, und validate() prüft nur den Adressteil, sodass Jane <jane@example.com> beide Schritte besteht. Ohne den Vergleich bekäme Schicht 2 die Domain example.com>. Wenn getAddress() der unveränderten Eingabe entsprechen muss, fällt alles durch, was einen Namen oder spitze Klammern enthält.

Eines sollten Sie wissen: validate() ist bei der Domain nachsichtig. Es akzeptiert jane@localhost und jane@example — kein Punkt erforderlich — weil RFC 822 punktlose Domains erlaubt. Das ist hier in Ordnung. Schicht 1 ist ein Formattor, keine Zustellbarkeitsprüfung, und der DNS-Lookup von Schicht 2 ist das, was tatsächlich entscheidet, ob die Domain Mail empfangen kann. Halten Sie diese Prüfung nachsichtig und lassen Sie DNS das Aussortieren übernehmen; der formalen Perfektion mit einer größeren Regex hinterherzujagen, ist ohnehin ein aussichtsloses Spiel.

Wenn Sie eine ältere javax.mail-JAR verwenden, ist der Code identisch bis auf den Paketnamen. Und wenn Sie ohnehin bereits von Apache Commons Validator abhängen, ist dessen EmailValidator eine gute Alternative für Schicht eins — er ist eine Spur strenger (er lehnt punktlose Domains standardmäßig ab):

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

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

Bevorzugen Sie Jakarta Mail, wenn Sie es ohnehin zum Versenden von Mail nutzen — eine Abhängigkeit weniger. Beide Bibliotheken beantworten immer nur die Syntaxfrage. Dasselbe gilt für @Email aus Bean Validation, das der Spring-Boot-Leitfaden behandelt.

E-Mail-Validierung per Regex in Java (wenn es sein muss)#

Wenn Sie keine Bibliothek einbinden können oder eine einzige Regel mit dem Frontend teilen müssen, halten Sie die Regex nachsichtig und kompilieren Sie sie nur einmal:

import java.util.regex.Pattern;

// Dot-separated runs with no whitespace, @ or quotes, one @,
// then a domain with at least one dot.
private static final Pattern EMAIL = Pattern.compile(
    "[^\\s@.\"]+(?:\\.[^\\s@.\"]+)*@[^\\s@.]+(?:\\.[^\\s@.]+)+",
    Pattern.UNICODE_CHARACTER_CLASS);

public static boolean looksLikeEmail(String email) {
    return email != null && email.length() <= 320 && EMAIL.matcher(email).matches();
}

Es ist dasselbe nachsichtige Muster, das der Artikel Warum die E-Mail-Validierung per Regex scheitert empfiehlt: Der Punkt bleibt aus den Zeichenfolgen des lokalen Teils heraus, sodass a..b@example.com, .a@example.com und a.@example.com alle durchfallen. Es braucht weder ^ noch $, weil matches() die gesamte Eingabe abdecken muss; find() sucht nach einer passenden Teilzeichenkette und würde daher junk jane@example.com junk akzeptieren. UNICODE_CHARACTER_CLASS sorgt dafür, dass \s auch Unicode-Leerzeichen erkennt, wie in JavaScript.

Vermeiden Sie zwei häufige Fallen: eine TLD-Obergrenze wie [a-zA-Z]{2,7}, die echte TLDs wie .photography ablehnt, und ausufernde „RFC 5322"-Muster, die Formen akzeptieren, die kein Anmeldeformular haben will. Ein Treffer beweist die Form, mehr nicht.

Schicht 2: Kann die Domain überhaupt Mail empfangen?#

Eine Domain ohne Mail-Route kann für niemanden Mail annehmen, also eliminiert ein schneller DNS-Lookup (zuerst MX, dann als Rückfall die eigene Adresse der Domain) tote Domains, falsch geschriebene Firmennamen und erfundene TLDs. Java erledigt das ganz ohne externe Abhängigkeit: Das JDK bringt einen DNS-Service-Provider für JNDI mit, sodass Sie das MX-Attribut über einen DirContext auflösen.

import java.util.Hashtable;
import javax.naming.NameNotFoundException;
import javax.naming.NamingException;
import javax.naming.directory.Attribute;
import javax.naming.directory.DirContext;
import javax.naming.directory.InitialDirContext;

public static boolean hasMailRoute(String domain) {
    Hashtable<String, String> env = new Hashtable<>();
    env.put("java.naming.factory.initial", "com.sun.jndi.dns.DnsContextFactory");
    env.put("com.sun.jndi.dns.timeout.initial", "2000"); // don't hang on a slow resolver
    env.put("com.sun.jndi.dns.timeout.retries", "1");

    DirContext ctx = null;
    try {
        ctx = new InitialDirContext(env);
        Attribute mx = ctx.getAttributes(domain, new String[] { "MX" }).get("MX");
        if (mx != null && mx.size() > 0) {
            return true;
        }
        // No MX: mail goes to the domain's own address (A or AAAA), the implicit MX.
        // One type per call: asking for several at once sends an ANY query.
        for (String type : new String[] { "A", "AAAA" }) {
            Attribute addr = ctx.getAttributes(domain, new String[] { type }).get(type);
            if (addr != null && addr.size() > 0) {
                return true;
            }
        }
        return false;
    } catch (NameNotFoundException e) {
        return false; // NXDOMAIN: the domain doesn't exist
    } catch (NamingException e) {
        return true;  // timeout or resolver failure: can't tell, so don't reject
    } finally {
        if (ctx != null) {
            try { ctx.close(); } catch (NamingException ignored) { }
        }
    }
}

Trennen Sie die Domain am letzten @ von der Adresse ab, damit Sie zitierte lokale Teile nicht aus dem Tritt bringen:

String domain = email.substring(email.lastIndexOf('@') + 1);

hasMailRoute("gmail.com");               // true
hasMailRoute("company-that-folded.com"); // false

Ein fehlendes oder leeres MX-Attribut bedeutet, dass die Domain keinen MX-Eintrag veröffentlicht; eine NameNotFoundException (eine Unterklasse von NamingException) bedeutet, dass sie sich überhaupt nicht auflöst. Manche Domains nehmen Mail über einen A- oder AAAA-Eintrag mit implizitem MX an, daher fragt das Snippet ersatzweise "A" und "AAAA" ab, wenn das MX-Set leer zurückkommt, und zwar einen Typ pro Aufruf: JNDI macht aus einer Anfrage nach mehreren Typen eine ANY-Abfrage, die viele DNS-Server nur noch mit einem minimalen Platzhalter beantworten. Für die überwältigende Mehrheit echter Adressen ist eine MX-Prüfung der richtige Filter. Da der Lookup auf einem DNS-Resolver blockiert, behalten Sie die obigen Timeouts in einem Anmeldepfad bei und behandeln Sie einen vorübergehenden Fehler als „später erneut prüfen", nicht als harte Ablehnung — ein DNS-Schluckauf sollte einen echten Kunden nicht abweisen. Deshalb liefert jede andere NamingException, etwa ein Timeout, true und überlässt die Entscheidung Schicht 3. Um eine Domain von Hand zu prüfen, nutzen Sie den MX-Record-Lookup.

Schicht 3: Existiert das Postfach tatsächlich?#

Die Schichten 1 und 2 können eine Adresse nur ausschließen. Eine Domain kann perfekte MX-Einträge veröffentlichen und trotzdem kein Postfach unter der Adresse haben, die Sie in Händen halten — noreply-9f2x@gmail.com ist syntaktisch gültig auf einer Domain mit aktiver Mail-Route, und es ist trotzdem ein Postfach, das nie angelegt wurde. Die Bestätigung, dass ein bestimmtes Postfach existiert, erfordert die SMTP-Zustellkonversation: Verbindung zum Mail-Host aufbauen, RCPT TO ausgeben, den Antwortcode lesen und die Verbindung trennen, bevor irgendetwas gesendet wird. Es steckt mehr dahinter — Catch-all-Domains akzeptieren jede Adresse und hebeln eine naive Prüfung aus — wie E-Mail-Verifizierung funktioniert durchläuft die gesamte Pipeline.

Sie können SMTP in Java mit einem rohen Socket skripten, aber Sie sollten es nicht aus Ihrer Anwendung heraus ausführen. Die meisten Cloud-Anbieter blockieren den ausgehenden Port 25, die Antwort hängt von der Reputation der IP ab, von der aus Sie sich verbinden, und empfangende Server greylisten unbekannte Absender und drosseln deren Rate — sodass eine Prüfung, die in einem lokalen Test besteht, in der Produktion still fehlschlägt oder Sie auf eine Blockliste bringt. Das ist die Schicht, die es sich zu delegieren lohnt.

Die Verifizierungs-API von Qualisend durchläuft diese Pipeline von einer reputationsgeführten Infrastruktur aus, die genau dafür gebaut ist. POST /verify liefert sofort ein Urteil aus den lokalen Prüfungen (Syntax, DNS, Erkennung von Wegwerfadressen und Tippfehlern) plus eine job_id; ist die Postfachprüfung noch ausstehend, landet ihr Urteil auf diesem Job. Java 11+ bringt java.net.http.HttpClient mit, sodass Sie keine HTTP-Abhängigkeit brauchen; kombinieren Sie es mit Jackson (oder Gson), um das JSON zu lesen. Bewahren Sie Ihren Schlüssel in einer Umgebungsvariablen auf und codieren Sie ihn niemals fest:

import java.io.IOException;
import java.net.URI;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;
import java.time.Duration;
import java.util.Map;

import com.fasterxml.jackson.databind.JsonNode;
import com.fasterxml.jackson.databind.ObjectMapper;

public class QualisendClient {
    private static final String BASE_URL = "https://app.qualisend.com/api/v1";

    private final HttpClient http = HttpClient.newHttpClient();
    private final ObjectMapper mapper = new ObjectMapper();
    private final String apiKey = System.getenv("QUALISEND_API_KEY"); // holds YOUR_API_KEY

    /** POST /verify: a job_id plus the instant verdict under "result". */
    public JsonNode verify(String email) throws IOException, InterruptedException {
        String payload = mapper.writeValueAsString(Map.of("email", email));
        return send(HttpRequest.newBuilder()
            .uri(URI.create(BASE_URL + "/verify"))
            .header("Content-Type", "application/json")
            .POST(HttpRequest.BodyPublishers.ofString(payload)));
    }

    /** GET /jobs/{id}: the job's status and, once completed, its results. */
    public JsonNode job(String jobId) throws IOException, InterruptedException {
        return send(HttpRequest.newBuilder()
            .uri(URI.create(BASE_URL + "/jobs/" + jobId + "?include=results"))
            .GET());
    }

    private JsonNode send(HttpRequest.Builder builder) throws IOException, InterruptedException {
        HttpRequest request = builder
            .header("Authorization", "Bearer " + apiKey)
            .timeout(Duration.ofSeconds(10)) // throws HttpTimeoutException past this
            .build();
        HttpResponse<String> response =
            http.send(request, HttpResponse.BodyHandlers.ofString());
        if (response.statusCode() / 100 != 2) {
            throw new ApiException(response.statusCode(),
                response.headers().firstValue("Retry-After").orElse(null));
        }
        return mapper.readTree(response.body());
    }

    /** A non-2xx reply. It extends IOException, like HttpTimeoutException. */
    public static class ApiException extends IOException {
        public final int status;
        public final String retryAfter; // seconds, sent with a 429

        ApiException(int status, String retryAfter) {
            super("Qualisend responded " + status);
            this.status = status;
            this.retryAfter = retryAfter;
        }
    }
}

Lesen Sie die Felder, die Sie interessieren, aus dem result-Knoten heraus:

JsonNode body   = client.verify("jane@example.com");
JsonNode result = body.get("result");

String  status     = result.get("status").asText();  // deliverable | risky | undeliverable | unknown
int     score      = result.path("score").asInt();    // 0–100 confidence
String  smtp       = result.path("smtp").asText();    // pending | cached | skipped
String  reason     = result.hasNonNull("reason")
                         ? result.get("reason").asText()  // machine-readable reason, null while pending
                         : null;
boolean disposable = result.path("sub_flags").path("disposable").asBoolean();
String  jobId      = body.path("job_id").asText();    // where the mailbox verdict lands

Die genaue Struktur der Antwort — jeder sub_flags-Schlüssel und jeder reason-Code — steht in der API-Referenz. Für die Live-Validierung bei der Anmeldung reicht der status meist aus, um zu handeln: undeliverable ablehnen, risky und unknown nach Richtlinie behandeln und disposable-Adressen am Eingabefeld kennzeichnen.

Das SMTP-Urteil abholen: den Job abfragen#

Prüfen Sie smtp, bevor Sie status als endgültig behandeln. Bei cached (ein aktuelles Ergebnis wurde wiederverwendet) oder skipped (die lokalen Prüfungen waren eindeutig) ist das result endgültig und reason ist gesetzt. Bei pending steht die Postfachprüfung in der Warteschlange und läuft erst, nachdem die Antwort zurückgekommen ist; status ist daher ein vorläufiges unknown und reason ist null: Lehnen Sie die Adresse deshalb nicht ab. Server, die Greylisting betreiben, antworten einem unbekannten Absender erst bei einem erneuten Versuch, sodass das Postfach-Urteil Minuten statt Sekunden dauern kann.

Bei der Anmeldung hat das Sofort-Urteil fehlerhafte Syntax, tote Domains und Wegwerfadressen bereits abgefangen, also lassen Sie ein ausstehendes unknown durch. Wenn Sie die Antwort zum Postfach brauchen, fragen Sie den Job aus einem Hintergrund-Worker ab, nie aus dem Request-Thread, und hören Sie nach einer festen Zahl von Versuchen auf:

// Runs in a background worker, never on the request thread.
public JsonNode awaitMailboxVerdict(String jobId, int maxAttempts)
        throws InterruptedException {
    for (int attempt = 0; attempt < maxAttempts; attempt++) {
        try {
            JsonNode job = client.job(jobId);
            String status = job.path("status").asText();
            if (status.equals("completed")) {
                return job.path("results").path(0); // the post-SMTP verdict
            }
            if (status.equals("canceled") || status.equals("failed")) {
                break;
            }
        } catch (IOException e) {
            // 429, 5xx or a timeout: try again on the next pass
        }
        // queued or processing: back off (5, 10, 20, 40, then 60 s), then ask again
        Thread.sleep(Math.min(60_000L, 5_000L << Math.min(attempt, 4)));
    }
    return null; // gave up: treat the address as unknown and re-check later
}

Die Zeile enthält dieselben Felder status und reason wie das Sofort-Ergebnis. Jede Abfrage ist ein API-Aufruf und zählt gegen dasselbe Rate-Limit pro Workspace wie /verify, also verlängern Sie die Abstände zwischen den Versuchen, statt in einem festen, kurzen Intervall abzufragen. Rufen Sie /verify nicht erneut auf, um ein ausstehendes Ergebnis zu aktualisieren; das startet eine neue Prüfung (und verbraucht einen weiteren Credit), statt diese abzuschließen.

Timeouts, Rate-Limits und Fail-open#

verify() wirft bei allem außer einem 2xx eine Exception. Das passt zu einem Batch-Job, nicht zu einem Anmeldeformular: Dort verzweigen Sie je nach Fehler, lassen den Kunden durch, wenn das Problem auf Seiten der API liegt, und verifizieren später erneut. Der Leitfaden zur serverlosen Anmeldung nutzt dasselbe Fail-open-Muster:

private final QualisendClient client = new QualisendClient();

private static final JsonNode UNKNOWN =
    new ObjectMapper().createObjectNode().put("status", "unknown");

public JsonNode verifyForSignup(String email) throws InterruptedException {
    try {
        JsonNode body = client.verify(email);
        JsonNode result = body.get("result");
        if ("pending".equals(result.path("smtp").asText())) {
            queueMailboxCheck(body.path("job_id").asText()); // a worker runs awaitMailboxVerdict
        }
        return result;
    } catch (QualisendClient.ApiException e) {
        if (e.status == 429) {
            recheckLater(email, e.retryAfter);     // rate limited: retry after Retry-After seconds
        } else if (e.status == 402) {
            alertOps("Qualisend: out of credits"); // insufficient_credits
            recheckLater(email, null);
        } else if (e.status >= 500) {
            recheckLater(email, null);             // an outage, not the customer's problem
        } else {
            alertOps("Qualisend rejected the request: " + e.status); // 400/401/403: fix the call or key
        }
    } catch (IOException e) {
        recheckLater(email, null);                 // HttpTimeoutException or a dropped connection
    }
    return UNKNOWN;
}

queueMailboxCheck, recheckLater und alertOps stehen für Ihre Job-Queue und Ihr Alerting. Fangen Sie ApiException zuerst ab: Sie ist eine IOException, genau wie HttpTimeoutException, sodass der letzte catch-Block Timeouts und abgebrochene Verbindungen abdeckt. Das Rate-Limit gilt pro Workspace, nicht pro Schlüssel, daher hebt ein zusätzlicher Schlüssel einen 429 nicht auf.

Die Schichten zusammensetzen, um eine E-Mail-Adresse in Java zu validieren#

Das Günstigste zuerst, aufhören, sobald Sie eine Antwort haben. Ein kleines Record hält das Urteil (Records gibt es ab Java 16; auf 11–15 verwenden Sie eine einfache Klasse):

// mailboxPending: act on the local verdict now; the worker reports the mailbox result later.
public record Verdict(String status, String reason, boolean mailboxPending) {}

public Verdict validate(String email) throws InterruptedException {
    if (!isValidSyntax(email)) {
        return new Verdict("undeliverable", "invalid_email", false);
    }
    String domain = email.substring(email.lastIndexOf('@') + 1);
    if (!hasMailRoute(domain)) {
        return new Verdict("undeliverable", "invalid_domain", false);
    }
    JsonNode result = verifyForSignup(email); // fails open to "unknown"
    return new Verdict(
        result.path("status").asText("unknown"),
        result.hasNonNull("reason") ? result.get("reason").asText() : null,
        "pending".equals(result.path("smtp").asText()));
}

Die beiden lokalen Schichten kosten nichts und fangen den meisten Müll sofort ab; die API läuft nur auf Adressen, die den Netzwerk-Roundtrip wert sind. Diese Reihenfolge ist der ganze Trick — dieselbe Form finden Sie auch in den Versionen dieses Leitfadens für Node.js, Python, PHP, Go und C#, denn es ist die Schichtung, nicht die Sprache, die Validierung funktionieren lässt.

Für eine ganze Liste schicken Sie /verify nicht in einer Schleife über eine CSV-Datei: Senden Sie sie an POST /verify/bulk (bis zu 1.000.000 Zeilen) oder laden Sie sie in der App hoch, wie es der Leitfaden zur Listenbereinigung beschreibt.

Bereit, die SMTP-Schicht hinzuzufügen? Lassen Sie eine beliebige Adresse durch den kostenlosen E-Mail-Checker laufen, um zuzusehen, wie eine syntaktisch perfekte Zeichenkette mit einem echten Urteil zurückkommt, oder lesen Sie die API-Referenz für den /verify-Endpunkt, das vollständige result-Envelope und Copy-Paste-Beispiele in jeder oben genannten Sprache.