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 beschreibt den gesamten Prozess.
Die Leistungsbeschreibung von Emvero 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, 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 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 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. 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 von Ihrem Server aus. Nachrichtenversand und Bestätigungszustand bleiben in Ihrer Anwendung.