DNS blocklists

RFC 5782 explains that DNSBLs encode list membership in DNS responses. A receiving site chooses which zones to query and how to interpret a listed result, which may mean rejection, tagging, or scoring.

The RFC discusses architectural tradeoffs between centralized lists, transport security for DNSBL queries, and false positives when list data is stale or overly broad.

SPF answers whether the connecting host is authorized for the domain in the SPF check. DMARC evaluates alignment and policy for the From domain. A DNSBL does not publish authorization for your domain; it publishes whether an address already has a negative reputation in that list's policy.

A message can pass SPF and DKIM while the connecting IP is listed on a DNSBL a receiver consults, or fail authentication while the IP is not listed. The mechanisms are independent inputs to delivery decisions.

RFC 5782 is informational guidance for list operators and consumers. It does not standardize a single blacklist name or response code across the industry.

Operators who see blocks at one receiver often check both authentication records and IP reputation signals. PTR and sending hygiene pages on this site cover forward-confirmed reverse DNS; DNSBL pages cover a different class of DNS lookup.

RFC 5782 discusses how list data is encoded in DNS and how false positives and transport security affect operational use.

SPF and DMARC remain defined in RFC 7208 and RFC 7489; a DNSBL lookup neither replaces nor satisfies those checks.

Operators troubleshooting delivery often review authentication records, PTR hygiene, and whether sending IPs appear on lists their recipients query.