E-Mail-Verifizierungsergebnisse richtig verstehen

Prüfen Sie zuerst, ob das Ergebnis der E-Mail-Verifizierung abgeschlossen ist. Rufen Sie bei status: pending dieselbe Prüfung später erneut ab. Lesen Sie bei einem fertigen Ergebnis zunächst status und action, danach reason_codes und checks. confidence fasst die Belege zusammen; freshness zeigt, wann sie erhoben wurden.

Behalten Sie diese Felder zusammen. Eine Adresse mit wenigen Belegen erfordert eine andere Entscheidung als eine Adresse, deren Eingabe oder Domain einen eindeutigen Ablehnungsgrund liefert.

Schlussfolgerung und empfohlene Aktion lesen

Emvero hat vier abschließende Statuswerte. Der gesonderte Zustand pending bedeutet, dass die Prüfung noch wartet oder läuft.

Die Referenz zu den Ergebnissen beschreibt die Felder. Der Status fasst technische Belege zusammen; die Aktion empfiehlt einen Ablauf. Beide haben unterschiedliche Aufgaben. Eine Wegwerfadresse kann risky mit allow ergeben. Nachgewiesenes Catch-all-Verhalten kann dagegen zu risky mit allow_with_email_confirmation führen.

Auch eine negative SMTP-Beobachtung verlangt Sorgfalt. Emvero gibt einen bei der Probe als nicht vorhanden eingeordneten Empfänger derzeit als unknown mit SMTP_RECIPIENT_REJECTED_AMBIGUOUS zurück. Die Aktion lautet allow_with_email_confirmation. Anders als ein eindeutiger Syntax- oder Domainfehler reicht diese Probe nicht für eine Ablehnung aus.

Die Ursache in reason_codes und checks finden

reason_codes enthält maschinenlesbare Namen für Beobachtungen und Grenzen. SMTP_RCPT_ACCEPTED betrifft die Annahme des Empfängers, DISPOSABLE_DOMAIN eine Domain-Eigenschaft, DNS_NXDOMAIN eine fehlende Domain und SMTP_GREYLISTED eine temporäre SMTP-Zurückstellung. Prüfen Sie, welchen Teil des Ablaufs ein Code beschreibt, bevor Sie daraus eine Regel für Adressen ableiten.

Eine Beschränkung am Zielserver beschreibt, was die Probe dort feststellen durfte. Ein Fehler des Dienstes beschreibt ein Problem beim Verifizierer. Keiner dieser Fälle beweist ein fehlerhaftes Postfach. Die Referenz der Ursachencodes enthält das vollständige Vokabular. Die Codes sind stabile Kennungen, können aber ergänzt werden. Speichern Sie unbekannte Werte und behandeln Sie sie mit einer Auffangregel, statt allein wegen ihres Namens abzulehnen.

Die Felder in checks zeigen den erreichten Prüfstand:

• syntax ist valid oder invalid. domain und mail_routing können außerdem unknown sein.
• smtp ist accepted, rejected, skipped, unknown oder pending. Ein übersprungener Schritt wurde nicht ausgeführt. Auch smtp: rejected kann mit dem Gesamtergebnis unknown zusammen auftreten.
• accept_all ist yes, no oder unknown.
• disposable, role_account, public_provider und smtp_utf8_required beschreiben Eigenschaften der Adresse oder Domain.

mail_routing: valid zusammen mit smtp: unknown zeigt eine andere Lücke als domain: unknown. Im ersten Fall gibt es Belege für den Mailweg, im zweiten ist bereits die Domain ungeklärt. Entscheiden Sie anhand der Ursache, ob eine weitere Prüfung helfen kann. Der Vergleich von unknown und undeliverable behandelt diese Entscheidung.

confidence und freshness richtig verwenden

confidence ist ein Evidenzwert von 0 bis 1. Er ist keine kalibrierte Zustellwahrscheinlichkeit: 0.7 bedeutet nicht, dass 70 % der Nachrichten ankommen. Auch eine Regel wie confidence > 0.85 belegt weder Postfachzugriff noch garantierte Zustellung. Verwenden Sie den Wert zum Sortieren innerhalb eines Status oder für die Reihenfolge einer manuellen Prüfung. Die Dokumentation zu confidence erklärt den Wert. Der Vergleich von Zahlenwert und Belegen zeigt, warum er die anderen Felder nicht ersetzt.

freshness erfasst getrennte Beobachtungszeiten für DNS und SMTP:

{
  "freshness": {
    "dns_checked_at": "2026-09-05T09:14:22Z",
    "smtp_checked_at": "2026-09-05T09:14:23Z"
  }
}

Diese Zeitstempel nennen den Zeitpunkt der Erhebung, nicht den Empfang der Antwort. Eine Antwort aus dem Cache behält die ursprünglichen Zeitstempel. Legen Sie für Ihren Anwendungsfall ein akzeptables Alter fest. Prüfen Sie auch bei einer erneuten Anfrage die Zeitstempel: Sie kann dieselben zwischengespeicherten Belege zurückgeben. Der Leitfaden dazu, wann Sie eine E-Mail-Liste erneut prüfen sollten, erläutert diese Entscheidung.

Beispiel: eine angenommene Wegwerfadresse

Diese vollständige Antwort ist ein Beispiel mit einer reservierten Beispieldomain. Sie stammt weder aus einer Live-Prüfung noch aus einer Messung für einen bestimmten Anbieter.

{
  "id": "00000000-0000-4000-8000-000000000001",
  "generation": 1,
  "email": "person@disposable.example",
  "normalized": { "domain": "disposable.example", "ascii_domain": "disposable.example" },
  "status": "risky",
  "confidence": 0.85,
  "action": "allow",
  "checks": {
    "syntax": "valid",
    "domain": "valid",
    "mail_routing": "valid",
    "smtp": "accepted",
    "accept_all": "unknown",
    "disposable": true,
    "role_account": false,
    "public_provider": false,
    "smtp_utf8_required": false
  },
  "reason_codes": ["SMTP_RCPT_ACCEPTED", "DISPOSABLE_DOMAIN"],
  "freshness": {
    "dns_checked_at": "2026-09-05T09:14:22Z",
    "smtp_checked_at": "2026-09-05T09:14:23Z"
  }
}

Der SMTP-Empfänger wurde angenommen. DISPOSABLE_DOMAIN ändert jedoch den Status in risky; die Aktion bleibt allow. Ein temporäres Postfach kann technisch funktionieren, obwohl seine begrenzte Nutzungsdauer den Anforderungen Ihres Produkts widerspricht.

Entscheiden Sie diese Geschäftsregel getrennt. Für einen Newsletter könnten Sie die Adresse akzeptieren, für einen kostenpflichtigen Test eine dauerhaft nutzbare Adresse anfordern. Erhalten Sie die zurückgegebenen Belege, damit eine Geschäftsentscheidung nicht wie ein gescheiterter technischer Test aussieht.

Beispiel: eine durch Greylisting zurückgestellte Probe

Auch diese zweite vollständige Antwort dient der Veranschaulichung. Syntax und Mailweg sind gültig, der empfangende Server hat die Verbindung aber zurückgestellt.

{
  "id": "00000000-0000-4000-8000-000000000002",
  "generation": 1,
  "email": "person@greylisted.example",
  "normalized": { "domain": "greylisted.example", "ascii_domain": "greylisted.example" },
  "status": "unknown",
  "confidence": 0.4,
  "action": "allow_with_email_confirmation",
  "checks": {
    "syntax": "valid",
    "domain": "valid",
    "mail_routing": "valid",
    "smtp": "unknown",
    "accept_all": "unknown",
    "disposable": false,
    "role_account": false,
    "public_provider": false,
    "smtp_utf8_required": false
  },
  "reason_codes": ["SMTP_GREYLISTED"],
  "freshness": {
    "dns_checked_at": "2026-09-05T09:14:22Z",
    "smtp_checked_at": "2026-09-05T09:14:23Z"
  }
}

SMTP_GREYLISTED lässt das Ergebnis bei unknown. Damit ist das Postfach weder bestätigt noch als nicht vorhanden bewiesen. Folgen Sie in einem Registrierungsformular der Aktion. Wenn der Zugriff wichtig ist, lassen Sie Ihre Anwendung eine Bestätigungsmail senden; die Probe von Emvero sendet keine E-Mail. Eine spätere Prüfung kann weitere Belege liefern, ohne ein bestimmtes Ergebnis zu garantieren.

Bei der Bereinigung einer E-Mail-Liste halten Sie Adresse und Ursache in einer gesonderten Gruppe fest, bis Sie über erneute Prüfung oder Zurückstellung entscheiden. Jede unbekannte Adresse automatisch anzuschreiben setzt mehr voraus, als diese Antwort belegt.

Die Entscheidungsgrundlage mit der Adresse speichern

Rufen Sie zunächst die Ergebnisse noch laufender Prüfungen erneut ab. Beginnen Sie bei abgeschlossenen Ergebnissen mit action. Verwenden Sie reason_codes für genauere Regeln und checks, um ungeprüfte oder offene Punkte zu erkennen. confidence hilft beim Sortieren, freshness beim Einordnen des Alters der Belege.

Speichern Sie die Belege mit Ihrer Entscheidung, damit Sie eine spätere Freigabe, Bestätigungsanforderung oder Ablehnung erklären können. Die Seite zur API für E-Mail-Verifizierung zeigt, wie Sie eine Prüfung anfordern und das Ergebnis abrufen.