---
title: "E-Mail-Verifizierung und Bestätigung: Wann brauchen Sie was? | Emvero"
description: "Vergleichen Sie Adressprüfung und E-Mail-Bestätigung. Erfahren Sie, warum ein zustellbares Ergebnis den Bestätigungslink nicht ersetzt und beide Zustände getrennt bleiben."
url: https://emvero.io/de/blog/email-verification-vs-email-confirmation/
language: de
updated: 2026-10-10
---

Blog

# E-Mail-Verifizierung und Bestätigung im Vergleich

Die Verifizierung prüft die Adresse. Die Bestätigung belegt den Zugriff auf eine Nachricht. So halten Sie beide Ergebnisse bei der Registrierung getrennt.

Veröffentlicht 2026-10-06

Eine E-Mail-Verifizierung prüft vor dem Versand, ob eine Adresse nutzbar erscheint. Bei der E-Mail-Bestätigung verwendet jemand einen Link oder Code aus einer Nachricht an diese Adresse. Wenn der Kontozugang von der Kontrolle des Postfachs abhängt, brauchen Sie die Bestätigung auch nach einem positiven Prüfergebnis.

Beide Schritte werden häufig als „E-Mail verifizieren“ bezeichnet. Legen Sie fest, welche Frage Ihr System beantworten muss: Was lässt sich aus der Mailinfrastruktur über die Adresse ableiten, oder kann jemand auf eine dort zugestellte Nachricht zugreifen?

## Welche Belege die beiden Schritte liefern

| Frage | E-Mail-Verifizierung vor dem Versand | Bestätigung per E-Mail |
| --- | --- | --- |
| Was geschieht? | Syntax, Domain und Mailweg werden geprüft. Eine vollständige Prüfung kann zusätzlich SMTP-Belege zum Empfänger erheben. | Ihre Anwendung sendet eine Nachricht und prüft den zurückgegebenen Link-Token oder Code. |
| Sendet Emvero bei der Prüfung eine Nachricht? | Nein. Die SMTP-Probe endet vor `DATA`; eine Domain-Prüfung öffnet keine SMTP-Sitzung. | Ihre Anwendung oder Ihr E-Mail-Dienst sendet die Bestätigungsnachricht separat. |
| Was kann ein positives Ergebnis belegen? | Die vorhandenen Belege sprechen dafür, die Adresse für den nächsten Schritt zu akzeptieren. | Jemand hat auf die Nachricht zugegriffen und die Bestätigung zu diesem Zeitpunkt abgeschlossen. |
| Was bleibt unbelegt? | Postfachkontrolle, persönliche Identität und künftige Zustellung. | Ausschließlicher oder dauerhafter Besitz, persönliche Identität und künftige Zustellung. |

Ein funktionierender Mailweg betrifft die Domain. Auch eine Annahme des Empfängers kann auf Catch-all-Verhalten beruhen. Daraus lässt sich nicht ableiten, wer die Adresse eingegeben hat. Der Artikel zum [Ablauf der E-Mail-Prüfung](https://emvero.io/de/blog/how-email-verification-works/) beschreibt den gesamten Prozess.

Die [Leistungsbeschreibung von Emvero](https://docs.emvero.io/) nennt diese Grenze ausdrücklich: Der Dienst sendet keine Nachricht, und eine positive Prüfung ersetzt keine Bestätigung der Postfachkontrolle.

## Eine zustellbare Adresse kann noch unbestätigt sein

Angenommen, jemand gibt `alex@example.com` ein. Dieses Beispiel ist frei erfunden; es wurde weder ein Postfach geprüft noch eine Nachricht gesendet.

Ihre Anwendung erhält ein abgeschlossenes Ergebnis mit `deliverable` und `allow`. Damit kann die Registrierung fortgesetzt werden. Die Prüfung zeigt jedoch nicht, ob die Person versehentlich eine funktionierende Adresse eingegeben hat, die jemand anderem gehört. Wenn Sie daraus eine Bestätigung ableiten, setzen Sie den Postfachzugriff voraus, ohne ihn geprüft zu haben.

Speichern Sie das Prüfergebnis getrennt von einem Anwendungsfeld wie `email_confirmed_at`. Dieses Beispielfeld gehört zu Ihrer Anwendung, nicht zur API von Emvero. Setzen Sie es erst, wenn Ihr Server eine gültige Bestätigung für das Konto und die eingegebene Adresse akzeptiert hat. Bewahren Sie daneben das Prüfergebnis auf, damit beide Entscheidungen nachvollziehbar bleiben.

Bei einer Adresse für ein Team oder eine Aufgabe hilft Ihnen die [Regel für Rollenadressen bei der Registrierung](https://emvero.io/de/blog/block-role-based-email-signups/), zwischen Anmeldeadresse und separatem Kontakt zu unterscheiden.

Für dieselbe Adresse können Verifizierung und Bestätigung unterschiedliche Ergebnisse liefern:

| Belege zur Adresse | Bestätigung in der Anwendung | Was sich daraus ableiten lässt |
| --- | --- | --- |
| `deliverable` | Nicht abgeschlossen | Die Prüfung spricht für die Adresse; die Kontrolle des Postfachs ist noch unbestätigt. |
| `unknown` | Abgeschlossen | Die Person konnte auf die Bestätigungsnachricht zugreifen, obwohl die Vorabprüfung keine klare Antwort lieferte. Behalten Sie beide Befunde. |
| `risky` | Abgeschlossen | Die Bestätigung belegt einen Zugriff; das Signal, das zur Einstufung als riskant führte, bleibt bestehen. |
| `pending` | Nicht abgeschlossen | Die Empfängerprüfung läuft noch, und die Postfachkontrolle ist unbestätigt. Das sind unabhängige Zustände. |

Lesen Sie `status`, `action` und `reason_codes` zusammen. Bei Emvero kann `risky` je nach Ursache mit `allow` oder `allow_with_email_confirmation` verbunden sein. `unknown` bedeutet, dass die Belege keine klare Antwort erlauben; `undeliverable` rechtfertigt nach der aktuellen Auswertungsregel eine Ablehnung. Der Artikel [Verifizierungsergebnis auswerten](https://emvero.io/de/blog/reading-a-verification-result/) erklärt den Unterschied zwischen Status und Empfehlung.

## Beide Schritte nutzen, wenn der Kontozugang von E-Mail abhängt

Eine Prüfung vor dem Versand kann einen Format- oder Domainfehler erkennen, solange die Person ihn noch korrigieren kann. Die Bestätigung liefert danach den Beleg für den Zugriff, den die Adressprüfung nicht erheben kann.

Richten Sie die Registrierung nach der zurückgegebenen Aktion und Ihren Produktregeln aus. Bei `reject` bitten Sie um eine Korrektur. Bei `allow_with_email_confirmation` setzen Sie den Ablauf mit einer erforderlichen Bestätigung fort. Behalten Sie diesen Schritt auch bei `allow` bei, wenn die Postfachkontrolle Voraussetzung ist. Die technische Empfehlung, fortzufahren, berechtigt nicht zum Zugriff auf das Konto eines anderen Menschen.

Bei `pending` rufen Sie das abgeschlossene Ergebnis später ab oder wenden die Ausweichregel Ihres Formulars an. Unterscheiden Sie laufende Arbeit von einem abgelaufenen Bestätigungslink, einer unbeantworteten Nachricht und einem abschließenden Ergebnis mit `unknown`. Die [Anleitung zur Prüfung im Registrierungsformular](https://emvero.io/de/guides/signup-form-validation/) behandelt die umfassendere Umsetzung.

Bei einer bestehenden Kontaktliste kann die Verifizierung aktuelle Belege zur Adresse liefern, ohne jede Person anzuschreiben. Dafür müssen Sie keine unerbetenen Bestätigungsnachrichten an die Liste senden. Ob jemand einer Kampagne zugestimmt hat, muss Ihre Anwendung separat festhalten.

## Die Bestätigung an die geprüfte Adresse binden

Korrigiert die Person ihre Adresse vor der Bestätigung, prüfen Sie den neuen Wert. Verhindern Sie, dass eine Bestätigung für die alte Adresse auch die neue bestätigt. Aus dem Bestätigungsdatensatz muss hervorgehen, welche Adresse tatsächlich bestätigt wurde.

Verwenden Sie kryptografisch zufällige Token, die nur einmal und innerhalb eines begrenzten Zeitraums gültig sind. Das empfiehlt [OWASP zur E-Mail-Bestätigung](https://cheatsheetseries.owasp.org/cheatsheets/Email_Validation_and_Verification_Cheat_Sheet.html#email-ownership-verification). Prüfen Sie die Bestätigung auf Ihrem Server, bevor Sie sie speichern.

Läuft ein Bestätigungsversuch ab oder bleibt er unvollständig, speichern Sie diesen Ausgang separat. Der Zugriff wurde damit nicht nachgewiesen; ebenso wenig wurde belegt, dass die Adresse `undeliverable` ist. Ermöglichen Sie eine Korrektur oder einen erneuten Versand nach den Regeln Ihrer Anwendung.

Keiner der beiden Schritte belegt persönliche Identität, Einwilligung in Marketing, Interesse oder künftige Platzierung im Posteingang. Eine Bestätigungsnachricht kann auch in einem gemeinsam genutzten Postfach eingehen oder an eine andere Adresse weitergeleitet werden. Eine abgeschlossene Bestätigung ist daher ein Beleg für den Zugriff zu diesem Zeitpunkt.

Für die Adressprüfung nutzen Sie die [API zur E-Mail-Verifizierung](https://emvero.io/de/email-verification-api/) von Ihrem Server aus. Nachrichtenversand und Bestätigungszustand bleiben in Ihrer Anwendung.

## Begriffe, die hier vorkommen

### SMTP-Handshake

Ein Austausch von Befehlen und Antworten mit einem Mailserver. Eine Postfachprüfung kann so die Empfängerantwort lesen, ohne eine E-Mail zu senden.

### Catch-All-Domain

Eine Domain, deren Mailserver auch Adressen ohne eigenes Postfach annimmt. Die Annahme beweist deshalb kein einzelnes Postfach.

### Greylisting

Der Mailserver lehnt einen unbekannten SMTP-Versuch zunächst ab und erwartet eine spätere Wiederholung. Deren Erfolg ist nicht garantiert.

## Situationen, für die das gilt

### Eine Adresse im Registrierungsformular prüfen

Auf der anderen Seite der Anfrage wartet jemand - die Latenz bestimmt also das Design, und eine falsche Ablehnung kostet Sie die Kundschaft.

[Alle Beiträge](https://emvero.io/de/blog/)

## Wählen Sie, was Sie als Nächstes prüfen möchten.

Starten Sie eine Prüfung in Ihrem Konto und sehen Sie sich die Belege im Ergebnis an.

Kostenlos starten