The most straightforward alternative is to separate identities: one alias per service.

The Free Mail Forwarding Service project by the Haltman.io addresses exactly this point: creating aliases in the format handle@domain and forwarding everything to a mailbox that you control — with a minimalist (pure forwarding), open-source, infrastructure-focused model.

The origin: The Hacker’s Choice (THC) “Free Mail Forwarding Service”

Before the current hype surrounding alias managers, the community already had “old school” solutions. The Hacker’s Choice (THC) maintained a public forwarding service and its current status is clear: the service is unavailable because the volunteer who operated it has “disappeared,” and THC itself is asking for someone to take over the operation.

Haltman.io's proposal here is pragmatic: take the concept that already worked, modernize and repackage it (stack + API + UI), maintaining the “infrastructure first” spirit.

What Haltman.io's Free Mail Forwarding does (and what it does not attempt to do)

The model is straightforward:

• You choose:

  • handle (local-part),

  • domain (one of the available ones),

  • destination (your actual inbox)

• The system sends a confirmation email to the destination

• after confirming, any email to handle@domain is forwarded to the destination

This design places the service in the “forwarding” category (below), not “mail provider.” The project’s architecture itself makes this clear: the Node.js API does not receive email, it only manages rules (aliases) in the database that Postfix queries.

Architecture (no magic, no “nebulous SaaS”)

The service stack is divided into three layers:

1) Base mail stack (MTA + database)

• Postfix as MTA

• MariaDB with domain and alias tables (dynamic routing)

• PostSRSd for SRS (I'll explain why this is critical below)

2) Public API (alias lifecycle control)

An API in Node.js + Express exposes endpoints for:

• requesting alias creation (/forward/subscribe)

• confirming via token (/forward/confirm)

• requesting removal (/forward/unsubscribe)

• confirming removal (/forward/unsubscribe/confirm)

And an important security/implementation detail: everything is via GET + querystring (no JSON body).

3) UI (user experience)

A modern UI (Next.js + ShadCN + Tailwind) serves as a “front door” to generate requests and facilitate use, without hiding how it works.

The difference between “amateur forwarding” and “forwarding that delivers”: SRS (PostSRSd)

When you forward email, SPF/DMARC often break at the final destination: the recipient's provider sees the email “coming” from your server, but the original envelope/identity does not authorize your IP → rejections, quarantine, or spam folder.

That's why the stack includes SRS: it rewrites the sender envelope in a forwarding-compatible way, reducing rejections by SPF/DMARC policies.

Confirmation flow and anti-abuse controls (what I liked here)

Public service + free aliases = inevitable abuse. The project solves this with a very classic (and effective) set of mechanisms:

• email confirmation via token (no rule enters without confirmation)

• rate limiting and throttling by IP, alias, destination, and token

• HTTP responses with clear codes (e.g., alias_taken, rate_limited, banned, token_expired)

• Redis option for distributed rate limiting in production (avoids limit resets in multi-instance environments)

This is the “bare minimum” required to prevent a public service from becoming a spam forwarder within 48 hours.

Operating (or self-hosting) requires correct DNS — and here is the checklist

Even if you only “use” the service, understanding DNS helps you diagnose delivery. And if you are going to operate your own instance, DNS is mandatory.

The project guide makes the basics clear for each domain:

• MX pointing to the mail host

• A/AAAA of the host

• SPF authorizing the IPs

• DMARC (start permissive)

• PTR/reverse DNS for outbound deliverability

And there are objective instructions on how to point domain or subdomain to the mail host (with examples of MX/SPF/DMARC): https://github.com/haltman-io/mail-forwarding/blob/main/FWD-Add-Domain-or-Subdomain.md

How does it compare to SimpleLogin and addy.io (in practice)?

SimpleLogin and addy.io are benchmarks in the alias manager ecosystem, focusing on a complete experience and extra features.

• SimpleLogin positions itself as an alias service to protect your inbox, and is explicitly open source.

• addy.io describes its core as “creating unlimited aliases and protecting your real email” (also in the spirit of privacy-first).

The difference with Free Mail Forwarding (Haltman.io) is another: minimal infrastructure, auditable flow, and focus on forwarding:

• you are not “buying an ecosystem”, you are using a simple mechanism (alias → forward) supported by Postfix+DB and a management API.

• This tends to appeal to those who prefer:

• predictability,

• smaller attack surface,

• and “hacker mode”: understanding exactly what is running.

The natural tradeoff: services like SimpleLogin usually offer extra layers (apps, integrations, advanced features), while here the proposal is to be the solid foundation of forwarding.

Conclusion: why this project is relevant

The THC page reveals an uncomfortable truth: community services die when their operation depends on a single person. What Haltman.io is doing? packaging base stack + API + UI, with anti-abuse controls and practical documentation. Is the right way to take “free mail forwarding” out of urban legend mode and bring it into a reproducible operation.

If you:

• want to reduce correlation of your real email,

• want simple aliases per domain,

• or want an open-source base to run on your own,...

this project is a must-read.

• Haltman – Home

• Haltman – About

• THC Free Mail Forwarding Service

• SimpleLogin – Open-source anonymous email service

• addy.io – Free, open-source anonymous email forwarding

• Mail Forwarding API Repository

• Mail Forwarding UI Repository

• Base Stack Documentation (FWD-Basestack)

• DNS Domain/Subdomain Documentation

Why does this matter?

Because in investigation and Attack Surface Management, “name ↔ IP ↔ DNS records” is the glue that enables attribution, pivoting, and exposure detection, even before we talk about ports and banners.

What is ip.thc.org, in practice

Think of ip.thc.org as a giant index for answering questions such as:

• “Which hostnames perform reverse DNS for this IP?” (infrastructure pivot)

• “What subdomains exist for this apex domain?” (surface mapping)

• “What domains point (CNAME) to this target?” (detection of dependencies and possible takeovers)

The most interesting part is that it comes with three layers of consumption:

1. CLI-friendly via cURL, with colored output and useful headers

2. REST API (JSON) + CSV downloads for integration into pipelines

3. Monthly bulk data (CSV/Parquet) for offline analysis at scale (DuckDB recommended)

And, on the “sources and intake” side, the project documentation explains that rDNS is “powered by” Segfault, Domainsproject, and CertStream-Domains.

Numbers and distribution of the dataset (what you can download)

The Bulk Data Access doc publishes clear and useful statistics for planning:

• Last updated: January 2, 2026

• Date for: December 2025

• Records: 5.14 billion

• Size (compressed): Parquet ~40GB / CSV ~30GB

• Size (uncompressed): Parquet ~60GB / CSV ~190GB

The model is: a complete dump at the end of each month, with direct download links (CSV and Parquet).

Layer 1: CLI-friendly (cURL) — fast, auditable, scriptable

1) rDNS: IP → hostnames

Direct example (limiting return):

curl 'https://ip.thc.org/1.1.1.1?l=10'

You get useful context in the header (ASN, org, approximate geo) and then the list of entries. The doc itself shows rate limit and filter options.

2) Subdomain lookup: apex → subdomains

curl 'https://ip.thc.org/sb/wikipedia.org?l=20'

In the documentation, the subdomain endpoint also has a rate limit and suggests pivots (e.g., go to CNAME lookup).

3) CNAME lookup: target → domains that point to it

curl 'https://ip.thc.org/cn/github.io?l=20'

Useful for discovering dependencies, frontdoors, and even takeover hypotheses (always validating with provider rules and the actual status of the resource).

Layer 2: API (JSON) and CSV downloads — integration into pipelines

The CLI-friendly documentation also lists API endpoints that you can put directly into automations (SOAR, enrichers, ETL, etc.):

Lookup by IP (includes /24, /16, /8 blocks)

curl 'https://ip.thc.org/api/v1/lookup' \
  -X POST \
  -d '{ "ip_address":"1.1.1.0/24", "limit": 10 }' -s

Subdomain lookup by domain

curl 'https://ip.thc.org/api/v1/lookup/subdomains' \
  -X POST \
  -d '{ "domain":"github.com", "limit": 10 }' -s

CNAME lookup by target

curl 'https://ip.thc.org/api/v1/lookup/cnames' \
  -X POST \
  -d '{ "target_domain":"google.com", "limit": 10 }' -s

And when you want something that fits into a spreadsheet/SIEM/grep, there are CSV download endpoints with a high limit (up to 50k) and an option to hide the header.

Layer 3: Bulk data (Parquet/CSV) — “build your own engine”

If you want scale, the route is to download the monthly dump and query locally. The project itself recommends DuckDB and gives a direct query example in Parquet:

duckdb
select * from 'rdns.parquet' where ip_address='1.1.1.1' limit 10;

This opens the door to:

• internal enrichment (Threat Intel / ASM)

• historical analysis by month

• indexing in ClickHouse/Elastic/OpenSearch

• correlation with CT logs / passive DNS / proxy logs / EDR

“Where does this come from?” (public clues on the trail)

Two pieces of the ecosystem help to understand the type of intake/expansion of the project:

• The old CertStream-Domains repository (daily dumps of domains observed in certificate transparency) was archived with the note that THC “stepped up to overtake & expand the data”, and points to cs1/cs2 as the source of the daily dumps.

• The dnsstream utility (from THC itself) captures DNS traffic and “displays the answers,” explicitly described as “part of the ip.thc.org project.”

This alone does not “prove” the entire internal pipeline (nor should it—opsec and abuse exist), but it does indicate a coherent design: aggregation + continuous observation + publication.

Real use cases (where it shines)

1) Infrastructure pivoting (IR / Threat Intel)

You start with a suspicious IP (IOC), extract rDNS, cross-reference with subdomains and CNAME, and arrive at:

• exposed frontends / administrative areas

• “forgotten” domains pointing to old infrastructure

• third-party dependencies (CDN, storage, PaaS)

2) Attack Surface Management (ASM) without relying on heavy scanners

Before scanning ports, you build a list of hostnames/subdomains and prioritize:

• patterns like “dev, staging, admin, old, beta”

• newly discovered assets (when combined with daily/monthly datasets)

3) Hunting for dangling CNAME / misconfig

CNAME lookup helps answer “who points to X?” and “which domains depend on a target.” This speeds up screening in bug bounty programs — with responsible validation.

Rate limiting, ethics, and best practices

The example responses themselves show rate limiting (e.g., “You can make 249 requests... replenishes at 0.50/sec”), so treat it as a public service: local cache, backoff, and bulk data when you need volume.

And the THC context also matters: the group has a historical culture of research/hacking “without trying to get rich,” with a strong community and tooling bias.

Conclusion: where ip.thc.org fits into your stack

If Shodan/Censys are “service search engines,” ip.thc.org is the foundation block for name intelligence:

• fast for pivots (CLI)

• integrable (API/CSV)

• scalable (monthly Parquet + DuckDB)

In 2026, with 5.14B records published and a very objective distribution model, it is worth adding ip.thc.org to your OSINT kit — especially if you work with ASM, Threat Intel, IR, or responsible offensive research.

References

• Bulk Data Access

• Commandline Access

• rDNS Lookup

• Reverse DNS Lookup

• Subdomain Lookup

• CNAME Lookup

• Accessing parquet files

• CertStream-Domains – Daily Dumps of Certificate Logs Subdomains

• dnsstream – Network Capture DNS answers

• The Hacker’s Choice – 30 years of hacking without trying to get rich