Leitfäden
CRM-E-Mail-Adressen prüfen, ohne Historie zu verlieren
Ordnen Sie Prüfbelege dem genauen E-Mail-Wert im CRM zu. Halten Sie das neueste Ergebnis, frühere Beobachtungen und Ihre Versandentscheidung getrennt.
Was bei jeder Antwort zu tun ist
Jedes Mal dieselben vier Ergebnisse. Die Anweisung ändert sich mit der Situation, weil sich mit ihr ändert, was ein Fehler kostet.
| Ergebnis | Was hier zu tun ist |
|---|---|
| Zustellbar | Ergebnis mit Belegzeiten bei der geprüften Adresse speichern. Kampagneneignung separat prüfen; eine ältere zwischengespeicherte Beobachtung nicht als neu kennzeichnen. |
| Riskant | Kontakt behalten und Gründe festhalten. Eine Regel für die geplante Nachricht anwenden; das Rollenmerkmal nicht als gescheiterte Postfachprüfung behandeln. |
| Nicht zustellbar | Nicht mehr an den geprüften Wert senden, bis eine Korrektur oder neue Belege die Entscheidung ändern. Historie bewahren; Verifizierung allein ist keine Löschregel. |
| Unbekannt | Das neue uneindeutige Ergebnis samt Gründen erfassen. Frühere Belege als Historie behalten; ein altes deliverable nicht stillschweigend für den Versand weiterverwenden. |
Das Ergebnis einem E-Mail-Feld zuordnen
Ein Kontakt kann Unternehmensdaten, Zuständigkeiten, Geschäfte und Korrespondenz enthalten. Die Prüfung betrifft sein E-Mail-Feld. Speichern Sie die übermittelte email zusammen mit id, status, action, reason_codes und checks. Wird die Adresse geändert, gehört das frühere Ergebnis zum alten Wert. Prüfen Sie die neue Adresse, bevor Sie eine Entscheidung auf sie anwenden.
Zwei Kontakte mit derselben E-Mail-Adresse sind nicht unbedingt dieselbe Person. Entscheiden Sie über das Zusammenführen anhand Ihrer CRM-Regeln, getrennt von der Adressprüfung. Emvero führt keine Kontakte zusammen und aktualisiert Ihr CRM nicht automatisch. Ihre Integration oder Ihr Importprozess schreibt das Ergebnis. Die API zur E-Mail-Verifizierung erklärt Anfrage und Antwort.
Beobachtungszeit und Abrufzeit getrennt speichern
Wenn vorhanden, geben freshness.dns_checked_at und freshness.smtp_checked_at an, wann die jeweiligen Belege gesammelt wurden. Speichern Sie diese ursprünglichen Zeiten neben Ihrer eigenen Anfrage- oder Abrufzeit. Ein zwischengespeichertes Ergebnis kann ältere SMTP-Belege enthalten. Ersetzen Sie deren Datum nicht durch das heutige. Der Leitfaden zum Prüfergebnis erklärt die Aktualität der Belege.
Eine unklare Neuprüfung erfassen und Historie behalten
Angenommen, dieselbe Adresse hatte zuvor deliverable ergeben und die neueste abgeschlossene Prüfung liefert unknown. Behalten Sie das frühere Ergebnis als datierte historische Beobachtung und erfassen Sie das neue mit seinen Gründen. Unknown kann weiterhin gültige Domain-Belege enthalten.
Machen Sie die neue Unsicherheit für Ihre Versandlogik sichtbar. Lassen Sie den früheren Status „zustellbar“ nicht stillschweigend eine Kampagne freigeben. Ihre Regel kann die Adresse zur Durchsicht zurückhalten oder eine spätere Prüfung vorsehen. Wurde die Adresse geändert, belegen die alten Ergebnisse nichts über den Ersatz.
Eine Versandregel wählen, ohne den Kontakt zu löschen
Schließen Sie bei einem technischen Fehler die geprüfte Adresse bis zur Korrektur oder Durchsicht aus; die Kontakthistorie kann weiterhin nützlich sein. Ein Rollenpostfach ist ein separates Merkmal, keine automatische Ablehnung. Anmeldekontext und Ausschlüsse bleiben Ihre eigenen Daten. Die Prüfung entscheidet auch nicht, wie lange Sie einen Kontakt aufbewahren sollten. Für die Kampagnenauswahl helfen der Ablauf zur Listenbereinigung und die Tabelle oben.
Reason Codes, die hier etwas entscheiden
Diese Codes gehören zum Vokabular der API und erklären eine Prüfung. Die Hinweise kennzeichnen auch Werte, die die aktuelle Prüfregel oder SMTP-Probe nicht zurückgibt.
SMTP_MAILBOX_NOT_FOUND | SMTP-Beobachtung einer Empfängerablehnung; die aktuelle Entscheidungsregel gibt unknown mit SMTP_RECIPIENT_REJECTED_AMBIGUOUS zurück. |
DNS_NXDOMAIN | Domain existiert nicht |
ACCEPT_ALL_UNKNOWN | Vorgesehener Code für ungeklärtes Catch-all-Verhalten; die aktuelle Prüfrichtlinie gibt ihn nicht aus |
ROLE_ACCOUNT | Der Adressname bezeichnet eine Funktion; wer das Postfach nutzt, bleibt offen |
Begriffe, die vorher hilfreich sind
Hard Bounce und Soft Bounce
Dauerhafte und vorübergehende Zustellfehler beziehen sich auf einen Versandversuch. Erfahren Sie, wie sie sich von Prüfbelegen unterscheiden.
Catch-All-Domain
Ein Mailserver nimmt beliebige Empfänger an. Diese Annahme allein belegt nicht, dass ein bestimmtes Postfach existiert.
Funktionsadresse
Eine Adresse für ein Team oder eine Aufgabe, etwa support@. Sie kann Mail empfangen; ihre Eignung hängt vom Zweck ab.
Die Entscheidung dahinter
E-Mail-Verifizierung oder Listenpflege
Technische Adressbelege und laufend gepflegte Angaben zu Anmeldung, Versandsperren und Interesse beantworten unterschiedliche Versandfragen.
Echtzeitprüfung oder Listenprüfung
Prüfen Sie eine Adresse, während jemand wartet, oder arbeiten Sie eine gespeicherte Liste ab. Vergleichen Sie Zeitablauf, pending-Antworten und die Aufgaben Ihres Systems.
Testen Sie es an einer Adresse, die Sie kennen.
Der kostenlose Checker liefert das vollständige Ergebnis - jede Stufe, jeden Reason Code, nichts zurückgehalten.