lead-enricher · concurrent provider detection

Upload leads · classify via SPF/PTR/HTTP · filter by rules · export with per-company caps · webhook on completion

K

checking api…

Dashboard Check email Extract Batches Imports All leads Providers Insights Webhooks DLQ Settings API docs

lead-enricher

Pipeline rules

MX cases

P1 — term → bucket

SPF

P1.5 — token extraction, cache

PTR

P2 — reverse-DNS caps

HTTP

P3 — provider patterns, fan-out

Region

P4 — TLD → bucket fallback

Mail servers

Mailbox import autodetect

SPF (P1.5)

DNS TXT lookup, extract tokens, append them to the MX string, re-run the MX matcher. The single biggest accuracy gain over MX-only matching.

Tokens to extract

What we lift out of the SPF record and treat as detection signals.

include:

Most useful — names the SPF policy of another domain (e.g. `include:_spf.google.com`). Recommended.

redirect:

Whole-record redirect to another domain's SPF. Recommended.

a:

A-record macros. Rarely useful as a provider hint.

mx:

MX-macro shortcut. Often noise.

ptr:

Deprecated by RFC 7208 but still in the wild.

exists:

Conditional macros. Usually anti-spam-internal; off by default.

Include chain

Following includes recursively catches providers that wrap their SPF behind one or two redirects.

Follow include: chains

When set, we recursively resolve includes up to the depth below. Adds DNS calls but recovers more signals.

Max include depth

Stop recursing past this many hops. RFC 7208 recommends 10.

hops

Lookup + cache

TXT lookup timeout

Per-domain DNS timeout. Most resolvers return in under 100ms; raise this when running through a slow recursive resolver.

Cache TTL

Redis TTL for positive and negative SPF records. Negative records cache too, saving re-queries on domains with no SPF.

Accept soft-fail records

Records ending in ~all or ?all are still useful as detection hints, even though they're permissive for senders.

Test a domain

live — POST /v1/detect/test

Enter a domain and hit Run to see the pipeline trace.