Wie Accept-all-Erkennung funktioniert und wie Sie Cold-Leads-Ergebnisse lesen

Der SMTP-Dialog hinter einer Postfachprüfung

Ein Prüfdienst schlägt die MX-Hosts der Domain nach und öffnet eine SMTP-Verbindung zu einem davon auf Port 25. Er begrüßt den Server, nennt einen Absender und einen Empfänger, liest die Antwort auf den Empfänger und verabschiedet sich, bevor eine Nachricht gesendet würde. Die zweite Sitzung fragt denselben Server nach einer Adresse, die nicht existieren kann.

# Session 1: is the address accepted?
S: 220 mx1.example.com ESMTP
C: EHLO verifier.example.net
S: 250-mx1.example.com
S: 250 SIZE 52428800
C: MAIL FROM:<check@verifier.example.net>
S: 250 2.1.0 Sender OK
C: RCPT TO:<anna@example.com>
S: 250 2.1.5 Recipient OK          <- accepted (a 550 here would mean: rejected)
C: QUIT                            <- no DATA command: nothing is delivered
S: 221 2.0.0 Bye

# Session 2: would the same server also accept an address that cannot exist?
S: 220 mx1.example.com ESMTP
C: EHLO verifier.example.net
S: 250 mx1.example.com
C: MAIL FROM:<check@verifier.example.net>
S: 250 2.1.0 Sender OK
C: RCPT TO:<zq7c41e09b2a6f5d@example.com>
S: 250 2.1.5 Recipient OK          <- also accepted: the server accepts all addresses
C: QUIT
S: 221 2.0.0 Bye

Antwortcodes und welche Schlüsse sie erlauben

Antwortcodes sind in RFC 5321 definiert. Die erste Ziffer trägt die Bedeutung: 2 steht für Erfolg, 4 für einen vorübergehenden Fehler, 5 für einen dauerhaften Fehler.

Accept-all-Test, Greylisting und andere Grenzen

• Accept-all: Nachdem die echte Adresse akzeptiert wurde, fragt der Prüfdienst denselben Server nach einem zufälligen lokalen Teil auf derselben Domain. Wird auch dieser akzeptiert, hat die erste Annahme keine Aussagekraft, und das Ergebnis ist risky mit dem Grund catch_all.
• Greylisting (RFC 6647): Ein Server lehnt unbekannte Kombinationen aus Absender und Empfänger vorübergehend mit einer 4xx-Antwort ab und akzeptiert einen späteren neuen Versuch. Ein einzelner Durchlauf sieht nur die 4xx-Antwort, und Cold Leads wartet innerhalb einer Prüfung nicht ab, um es erneut zu versuchen; das Ergebnis ist daher risky mit smtp_unknown.
• Späte Bounces: Manche Server akzeptieren im Dialog jeden Empfänger und lehnen unbekannte erst ab, nachdem sie eine Nachricht angenommen haben, mit einem Bounce. Eine Prüfung kann das nicht sehen.
• Richtliniensperren: Ein Server kann den prüfenden Host selbst abweisen. Cold Leads wertet Ablehnungen bei Begrüßung, EHLO oder MAIL FROM als smtp_unknown und jede Antwort von 500–559 bei RCPT TO als mailbox_missing.
• Port 25: Der Test braucht eine ausgehende SMTP-Verbindung. Viele Cloud- und Serverless-Plattformen sperren ausgehenden Port 25, und dann findet gar kein Dialog statt.

Was Cold Leads zurückgibt und wann der Test nicht lief

Eine Prüfung läuft in dieser Reihenfolge: Syntax (ein Fehler beendet die Prüfung), eine eingebaute Liste mit 40 Wegwerf-Mail-Domains, eine Liste mit 25 Rollennamen (info, sales, support, admin und weitere) und eine MX-Abfrage, die auf den A-Eintrag der Domain zurückfällt. Die SMTP-Prüfung von Postfach und Accept-all läuft nur, wenn Cold Leads eine SMTP-Verbindung zu einem der ersten beiden MX-Hosts aufbauen kann. Das Array reasons zeigt Ihnen immer, welcher Fall vorliegt.

{
  "email": "anna@example.com",
  "status": "valid",
  "score": 75,
  "reasons": ["smtp_unreachable"],
  "mx": "mx1.example.com",
  "catch_all": false,
  "disposable": false,
  "role": false,
  "checked_at": "2026-09-30T08:15:02.114Z",
  "cached": false
}

• disposable und role stehen, wenn sie zutreffen, vor dem letzten Grund. Eine Wegwerf-Domain macht den Status risky mit einem Score von 40 (ok), 30 (smtp_unreachable) oder 20 (smtp_unknown).
• catch_all ist nur true, wenn der Accept-all-Test gelaufen ist und die Zufallsadresse akzeptiert wurde. Der Wert false ist nur aussagekräftig, wenn der letzte Grund ok oder mailbox_missing ist; nach smtp_unreachable, smtp_unknown oder timeout wurde Accept-all nicht getestet. Das MCP-Tool verify_email, gehostet oder lokal, liefert catch_all in diesen Fällen als null; die REST-API liefert false.
• cached ist true, wenn das Ergebnis aus dem 30-Tage-Cache kommt; checked_at zeigt dann den Zeitpunkt der ursprünglichen Prüfung.
• Ergebnisse von Bulk-Aufträgen enthalten nur den letzten Grundcode, als reason.

Eine Entscheidungstabelle und ein Skript, das sie anwendet

// node decide.mjs anna@example.com   (Node 18+, COLDLEADS_API_KEY=sk_... in the environment)
const email = process.argv[2];
const res = await fetch("https://coldleads.app/api/v1/verify", {
  method: "POST",
  headers: { "x-api-key": process.env.COLDLEADS_API_KEY, "Content-Type": "application/json" },
  body: JSON.stringify({ email, timeout_ms: 10000 }),
});
const r = await res.json();
if (!res.ok) throw new Error(`HTTP ${res.status}: ${r.error}`);

const final = r.reasons[r.reasons.length - 1];
// catch_all only carries information when a mail server answered the probe
const smtpAnswered = ["ok", "catch_all", "mailbox_missing"].includes(final);
const ACTION = {
  ok: "send",
  smtp_unreachable: "send carefully: domain accepts mail, mailbox not checked",
  catch_all: "review: the server accepts every address",
  smtp_unknown: "review: no definite answer from the server",
  timeout: "check again with a larger timeout_ms",
  mailbox_missing: "drop",
  no_mx: "drop",
  syntax: "drop",
};
console.log({
  email: r.email,
  status: r.status,
  score: r.score,
  reasons: r.reasons,
  mailbox_checked: smtpAnswered,
  catch_all: smtpAnswered ? r.catch_all : "not tested",
  cached: r.cached,
  action: r.disposable ? "drop: disposable domain" : ACTION[final] ?? "review",
});

Limits und Kosten

• 1 Credit pro Prüfung, auch bei Syntaxfehlern und für Ergebnisse aus dem 30-Tage-Cache.
• timeout_ms ist optional und akzeptiert 1.000 bis 30.000 Millisekunden; jeder andere Wert wird mit 400 bad_timeout beantwortet.
• Die API ist Teil des Business-Tarifs: $99 im Monat mit 10.000 Credits im Monat; zusätzliche Pakete zu 1.000 Credits kosten $5. 120 Anfragen pro Minute und Schlüssel.

FAQ