E-Mail-Adressen mit JavaScript prüfen: ein Formularbeispiel

Um eine E-Mail-Adresse mit JavaScript zu prüfen, verwenden Sie ein HTML-Feld mit <input type="email"> und required. Mit checkValidity() ermitteln Sie, welche Rückmeldung nötig ist. Eine bestandene Formatprüfung klärt weder die Existenz von Domain und Postfach noch den Zugriff darauf. Das erläutert auch die MDN-Referenz zum E-Mail-Eingabefeld.

Ein Formular zum Ausprobieren

Speichern Sie das Beispiel als HTML-Datei und öffnen Sie es im Browser. Geben Sie eine Adresse ein und wählen Sie Continue oder drücken Sie die Eingabetaste. Das Beispiel zeigt das Ergebnis der Formatprüfung lokal an. Für eine Registrierung müssen Sie den erfolgreichen Zweig mit Ihrem eigenen Server-Endpunkt verbinden. Die englischen Beschriftungen und Meldungen im Code sind Beispieltexte, die Sie an Ihre Oberfläche anpassen können.

<form id="email-form" novalidate>
  <label for="email">Email address</label>
  <input id="email" name="email" type="email" autocomplete="email"
         required aria-describedby="email-feedback">
  <p id="email-feedback" aria-live="polite"></p>
  <button type="submit">Continue</button>
</form>

<script>
const form = document.querySelector("#email-form");
const email = document.querySelector("#email");
const feedback = document.querySelector("#email-feedback");

email.addEventListener("input", () => {
  feedback.textContent = "";
  email.removeAttribute("aria-invalid");
});

form.addEventListener("submit", (event) => {
  event.preventDefault();

  if (!email.checkValidity()) {
    const message = email.validity.valueMissing
      ? "Enter an email address."
      : email.validity.typeMismatch
        ? "Enter an address in email format."
        : "Check the email address.";

    feedback.textContent = message;
    email.setAttribute("aria-invalid", "true");
    email.focus();
    return;
  }

  email.removeAttribute("aria-invalid");
  feedback.textContent = "Format accepted. Send the address to your server.";
});
</script>

So behandelt das Beispiel Fehler

novalidate unterdrückt die automatische Prüfung beim Absenden. Der ausdrückliche Aufruf von checkValidity() funktioniert weiterhin. valueMissing kennzeichnet ein leeres Pflichtfeld, typeMismatch einen Fehler im E-Mail-Format. Diese Prüfungen sind in der HTML-Spezifikation zur Constraint Validation API beschrieben.

Das Label benennt das Feld. Bei einem Fehler zeigt der Code eine passende Meldung an, setzt aria-invalid und legt den Fokus wieder auf das Eingabefeld. aria-describedby ordnet den Hinweis dem Feld zu. Über aria-live="polite" werden geänderte Hinweise für assistive Technologien zugänglich. Sobald die Person die Eingabe bearbeitet, entfernt der Code die bisherige Meldung und die Fehlerkennzeichnung. Die Rückmeldung hängt also nicht allein von Farbe ab.

Wenn Ihnen die Fehlermeldungen des Browsers genügen, richten Sie eine POST-Übermittlung an Ihren Server-Endpunkt ein. Entfernen Sie anschließend novalidate und den JavaScript-Submit-Handler. Das HTML-Feld übernimmt bereits die Formatprüfung; JavaScript steuert hier Wortlaut und Position der Rückmeldung.

Vor der Serveranbindung testen

Probieren Sie die folgenden Eingaben aus. Die Ergebnisse beziehen sich auf die Browserprüfung dieses Formulars. Dabei wird keine Netzwerkanfrage gesendet.

Korrigieren Sie nach einem Fehler den Wert und senden Sie das Formular erneut ab. Die alte Meldung und aria-invalid sollten verschwinden. Testen Sie die Schaltfläche und die Eingabetaste, denn beide können das Formular absenden.

Die Domains sind fiktive Beispiele: RFC 2606 reserviert example.com und example.org für Dokumentation. Eine akzeptierte Beispieladresse weist daher kein echtes Postfach nach.

Wann ein eigener regulärer Ausdruck sinnvoll ist

Behalten Sie für dieses Formular die E-Mail-Regeln des Browsers bei und verwenden Sie JavaScript für die Rückmeldung. Ein zusätzlicher regulärer Ausdruck ist eine weitere Regel, die Sie pflegen müssen. Wenn Ihre Anwendung bewusst nur Adressen einer bestimmten Organisation zulässt, dokumentieren Sie diese fachliche Vorgabe und setzen Sie sie auch auf dem Server durch.

Übergeben Sie Adressen, die die Prüfung bestehen, unverändert an den Server. Würden Sie im Plus-Beispiel +orders entfernen, änderten Sie den eingegebenen Wert. Dieses Beispiel prüft eine einzelne Adresse nach den Regeln des Browserfelds. Für ungewöhnliche oder internationalisierte Formate müssen Sie gesondert festlegen, was Sie unterstützen, und Formular, Server-Parser und Maildienst gemeinsam testen.

Nach der Formatprüfung auf dem Server weitermachen

Übermitteln Sie den Wert über den normalen Formular- oder API-Weg an Ihren Anwendungsserver. Prüfen Sie die Daten dort unabhängig: Ein Client kann die Browserprüfung umgehen und direkt eine Anfrage senden. Diese Grenze beschreibt der MDN-Leitfaden zur Formularvalidierung.

Im Beispiel verhindert event.preventDefault() das Absenden. An der Stelle der Erfolgsmeldung würden Sie die Anfrage Ihrer Anwendung ergänzen. Prüfen Sie die Serverantwort, bevor Sie den Ablauf fortsetzen. Schlägt die Anfrage fehl, zeigen Sie eine verständliche Meldung an und ermöglichen Sie einen erneuten Versuch. Die lokale Erfolgsmeldung allein darf weder ein Konto anlegen noch eine Adresse als verifiziert kennzeichnen.

Nach der serverseitigen Formatprüfung hängt der nächste Schritt davon ab, welche Frage Sie beantworten müssen:

Die Gegenüberstellung von Syntaxprüfung und SMTP-Prüfung hilft bei der Wahl der Prüftiefe. Eine vollständige Emvero-Prüfung kann über SMTP Belege zum Empfänger sammeln, ohne eine Nachricht zu senden. Serverbeschränkungen oder Zeitüberschreitungen können zum Ergebnis unknown führen. Damit ist nicht nachgewiesen, dass die Adresse nicht zustellbar ist. Rufen Sie die E-Mail-Verifizierungs-API von Ihrem Server aus auf, damit die Zugangsdaten privat bleiben.

Der Leitfaden für die Prüfung im Registrierungsformular zeigt, bei welchen Ergebnissen Sie die Anmeldung fortsetzen und wann eine Bestätigung sinnvoll ist.