ForHosting KIT · Prüfen & Validieren

Rollen-E-Mail-Adressen erkennen

Trennen Sie echte Menschen von Sammelpostfächern, bevor Sie senden: Billing@example.com wird als Rollenadresse der Kategorie Rechnungswesen markiert, ein namentlicher Kontakt dagegen als persönlich erkannt. Kostenlos in Ihrem Browser.

Kostenlos
Läuft in Ihrem Browser
Ohne Anmeldung
Ihre Daten bleiben auf Ihrem Gerät

Im Browser ausführen – kostenlos API ansehen

Nutzen Sie es über WebAPIE-MailTelegramApp bald

Rechenbeispiel

Wenn Sie eingeben

E-Mail-Adresse: Billing@example.com

Erhalten Sie

Erkannte Rolle: billing

Ein Werkzeug, das erkennt, ob eine E-Mail-Adresse einer Person oder einer allgemeinen Funktion zugeordnet ist, etwa info@, support@, sales@ oder noreply@. Gedacht für Formulare und CRM-Systeme, in denen zwischen einem persönlichen und einem geteilten Postfach unterschieden werden soll, ohne jede Adresse einzeln nachzuschauen.

Warum Sammelpostfächer anders behandelt werden sollten

Vertriebs- und Marketinglisten sammeln über Formulare, öffentliche Verzeichnisse und alte Kontaktexporte Adressen wie info@, admin@, hello@ oder no-reply@. Diese Postfächer lesen oft mehrere Personen oder niemand, sodass eine Nachricht dort selten bei jemandem ankommt, der entscheidet, und kaum echte Öffnungen oder Klicks bringt. Wer sie wie namentliche Kontakte behandelt, verfälscht seine Kennzahlen und riskiert Spam-Beschwerden. Die Prüfung vergleicht den Teil vor dem @ mit einem gepflegten Verzeichnis von Rollen-, Abteilungs- und Systemkennungen, auf Englisch und in anderen Sprachen, und nennt die passende Kategorie, etwa Verwaltung, Support, Marketing, No-Reply oder Postmaster.

So nutzen Sie das Ergebnis

Vertriebsteams entfernen info@ und sales@ vor dem Start aus einer Kaltakquise-Liste, damit persönliche Betreffzeilen nie in einem Postfach landen, das niemand liest. Supportteams leiten Nachrichten von admin@ oder support@ an eine Teamwarteschlange statt an einen einzelnen Mitarbeiter. Für Newsletter teilen Sie die Liste: Rollenadressen erhalten eine allgemeine Ausgabe, persönliche Adressen die zugeschnittene Fassung. Bei Kontoanmeldungen verdienen Adressen wie webmaster@ oder postmaster@ einen zweiten Blick, denn echte Einzelpersonen melden sich damit kaum an.

Warum die Unterscheidung wichtig ist

Eine Adresse wie thomas.mueller@firma.de gehört erkennbar einer Person, während info@firma.de an ein geteiltes Postfach geht, das mehrere Mitarbeitende oder auch niemand regelmäßig liest. Für personalisierte Ansprache, Lead-Qualifizierung im Vertrieb oder die gezielte Zustellung an eine bestimmte Person ist diese Unterscheidung oft entscheidend, wird aber in vielen Formularen und CRM-Systemen bislang schlicht übersehen und nicht ausgewertet, obwohl sich daraus sinnvolle Regeln für die weitere Bearbeitung ableiten lassen.

Wie die Erkennung arbeitet

Der lokale Teil der Adresse, also der Abschnitt vor dem @-Zeichen, wird mit einer Liste gängiger Rollenbezeichnungen abgeglichen: info, support, sales, admin, noreply, kontakt, buchhaltung und ähnliche Begriffe, auch in deutscher Schreibweise. Enthält der lokale Teil hingegen einen erkennbaren Vor- oder Nachnamen oder eine individuelle Kombination, gilt die Adresse als persönlich. Grenzfälle bei ungewöhnlichen, aber tatsächlich persönlichen Adressen bleiben dabei möglich und werden entsprechend vorsichtig eingestuft.

Anwendungsfälle

Lead-Qualifizierung im Vertrieb

Sabine Schneider filtert eingehende Kontaktanfragen und behandelt Anfragen von persönlichen Adressen anders als solche von allgemeinen Postfächern wie info@.

Persönliche Ansprache im Newsletter

Ein Marketingteam verzichtet bei erkannten Rollenadressen bewusst auf eine namentliche Anrede, da dort ohnehin keine einzelne Person antwortet.

Priorisierung im Support-Postfach

Jonas Weber ordnet Anfragen von persönlichen Adressen einer höheren Dringlichkeit zu als automatisiert wirkende Anfragen von noreply-Adressen.

Häufige Fragen

Was zählt als Rollen-E-Mail-Adresse?

Adressen wie info@, support@, sales@, admin@, kontakt@ oder noreply@, also Adressen, die einer Funktion statt einer Person zugeordnet sind.

Ist die Prüfung kostenlos?

Ja, im Browser ohne Limit und ohne Anmeldung.

Kann die Prüfung irren?

Ja, bei ungewöhnlichen, aber tatsächlich persönlichen lokalen Teilen sind Grenzfälle möglich. Die Prüfung liefert eine sehr gute Einschätzung, keine hundertprozentige Garantie.

Verlässt die Adresse meinen Browser?

Nein, solange Sie die Prüfung auf dieser Seite nutzen. Sie wird lokal ausgewertet und nicht übertragen.

Sagt das etwas über die Erreichbarkeit der Adresse aus?

Nein, dafür gibt es eine eigene Prüfung. Diese Funktion beurteilt nur, ob es sich um eine persönliche oder eine Rollenadresse handelt.

Für Entwickler — API-Zugang

Alles auf dieser Seite ist auch per API verfügbar. Dieser Abschnitt richtet sich an Teams, die es in ihre eigenen Systeme einbinden möchten; alle anderen nutzen einfach das Tool oben.

Endpunkt

POSThttps://api.kit.forhosting.com/verify/email-role

Authentifizierung per Bearer-Token. Ein einziger POST stellt die Aufgabe in die Warteschlange; das Ergebnis erhalten Sie per Webhook oder über einen signierten Link.

Aufruf aus Ihrem Stack

curl -X POST https://api.kit.forhosting.com/verify/email-role \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"email":"info@example.com"}'

const res = await fetch("https://api.kit.forhosting.com/verify/email-role", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.KIT_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    "email": "info@example.com"
  })
});
const { task_id } = await res.json();

import os, requests

res = requests.post(
    "https://api.kit.forhosting.com/verify/email-role",
    headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
    json={
    "email": "info@example.com"
},
)
task_id = res.json()["task_id"]

<?php
$res = file_get_contents("https://api.kit.forhosting.com/verify/email-role", false, stream_context_create([
  "http" => [
    "method"  => "POST",
    "header"  => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
    "content" => '{"email":"info@example.com"}',
  ],
]));
$task = json_decode($res, true);

body := bytes.NewBufferString(`{"email":"info@example.com"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/verify/email-role", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)

Beispiel-Anfrage

{
  "email": "info@example.com"
}

Beispiel-Antwort

{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "verify.email_role",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

Die API arbeitet asynchron: Sie erhalten sofort eine task_id. Polling ist mit 1 Anfrage pro Sekunde erlaubt.

Preis

pro Anfrage$0.002

Der Preis steht auf der Seite – keine Tokens, keine Credits. Fehlgeschlagene Aufgaben werden nicht berechnet.

Fehler

HTTP	Code	Bedeutung
`401`	`unauthorized`	Der API-Schlüssel fehlt oder ist ungültig – prüfen Sie den Authorization-Header (Bearer).
`402`	`insufficient_balance`	Ihr Guthaben reicht für diese Aufgabe nicht aus – Aufladungen verfallen nicht.
`404`	`unknown_type`	Unbekannter Aufgabentyp – prüfen Sie das Feld „type“ gegen den Katalog.
`429`	`rate_limited`	Zu viele Anfragen – warten Sie kurz; Polling ist mit 1 Anfrage pro Sekunde erlaubt.

Technische Hinweise

Kostenlos und ohne Anmeldung

Die Prüfung läuft vollständig im Browser, ohne Limit und ohne dass die Adresse an einen Server übertragen wird. Wer die Erkennung in ein eigenes Formular oder eine CRM-Pipeline einbauen möchte, ruft dieselbe Logik stattdessen per API auf, für $0.002 pro geprüfter Adresse, mit dem Preis vorab veröffentlicht wie bei jeder Funktion in KIT, ohne versteckte Staffelung nach Volumen und ohne Mindestumsatz pro Monat.

Technische Fragen

Brauche ich ein Konto?

Nein, weder für den Browser-Modus noch für die API-Nutzung ist ein Konto erforderlich.

Vollständige KIT-Dokumentation lesen →