DEV Community: ishant singh

I tested my IP reputation checker on 80 addresses I knew the answer to

ishant singh — Fri, 23 Oct 2026 10:19:37 +0000

ipcomet's reputation check answers a question I get asked a lot: can I trust this address? It reports whether an IP is a Tor exit node, what kind of network owns it, and whether it appears on five public blocklists. I wrote it, which makes me the wrong person to judge it. So I found two groups of addresses where the right answer is public and ran the checker against both.

The test sets

40 Tor exit nodes, picked at random from the Tor Project's official exit list, which had 1,226 IPv4 addresses when I downloaded it.
40 addresses inside Amazon EC2, picked from the ranges AWS publishes in ip-ranges.json. The file I used (created 23 October 2026) lists 1,887 EC2 prefixes. For each address I chose a random prefix, then a random host inside it.

Both samples used the random seed 2026. Each address got one call to https://ipcomet.com/api/reputation, 1.2 seconds apart to stay under the 60 a minute limit. All 80 lookups answered.

That gives me ground truth for two things. A Tor exit should be flagged as Tor and an EC2 address should not. And an EC2 address should be labelled as hosting.

What came back

	Tor exits (40)	EC2 addresses (40)
Flagged as Tor	40	0
Network kind "hosting"	13	38
Network kind "isp"	27	2
On at least one blocklist	39	0

The Tor flag was exact

All 40 exits were flagged and none of the 40 EC2 addresses were. That is the least interesting result, and I'm glad it is. The flag is a lookup in the official exit list, and I had just downloaded a fresh copy. It's also the only field in the response that doesn't rely on a guess.

"Hosting" caught 38 of 40 cloud addresses

Two EC2 addresses came back as "isp". The checker returned A100 ROW Inc as the owner of one and Langfang university Langfang Development Area for the other, and neither name looks like a hosting company. The network kind comes from who owns the address (plus hints in its reverse DNS name), so when the registered owner doesn't look like a hosting provider, the label slips. I didn't dig into why AWS-published prefixes are registered to those names.

Most Tor exits were labelled as ordinary ISPs

This is the result I didn't expect. 27 of the 40 Tor exits came back with the kind "isp", and the label text for that kind reads "Likely a residential or mobile ISP". The 27 spread across 15 different organisations, so one operator isn't skewing it. The tor field was right every time. The sentence next to it was misleading for two out of three of these addresses.

If you read only the network kind, you would have waved most of the exits through.

The blocklists agreed less than they look

39 of the 40 Tor exits appeared on at least one of the five blocklists, and none of the EC2 addresses did. But one list, s5h.net, accounts for 39 of those hits by itself. DroneBL listed 15 of the exits, SpamCop 9 and UCEPROTECT Level 1 only 2. So "listed on 3 of 5" can mean one list that tracks Tor exits plus two more, and in this sample s5h.net behaved like a Tor list.

How I'd use the result

Trust the Tor flag.
Treat "hosting" as a strong hint that can miss. It caught 38 of 40 here.
Read "isp" as "no hosting signs found", and nothing more about whoever is using the address.
Count blocklist hits per list, not in total.

As the maintainer, the part I take from this is the wording of the "isp" label, which promises more than the data supports.

What this test can't show

It has no home connections in it. There's no public list of residential addresses, so I can't measure how often a real home gets labelled as hosting, or how many VPNs and proxies get through. The about page already says residential proxies can't be detected from public data.
It's two samples of 40 from one moment, and only one cloud provider.
The Tor list changes through the day, so the same seed can pick different exits tomorrow.

Run it yourself

The script I used, tidied up. It needs only the standard library. Set your own contact in the User-Agent, as the last post explains.

import collections, ipaddress, json, random, time, urllib.request

UA = {"User-Agent": "reputation-check/1.0 (+you@example.com)"}
N = 40
rng = random.Random(2026)  # same seed, same sample, if the lists haven't changed

def get(url):
    for attempt in range(3):
        try:
            return urllib.request.urlopen(urllib.request.Request(url, headers=UA), timeout=25).read()
        except OSError:
            time.sleep(2 * (attempt + 1))
    raise RuntimeError("giving up on " + url)

tor = [l.strip() for l in get("https://check.torproject.org/torbulkexitlist").decode().splitlines()
       if l.strip() and ":" not in l]
ranges = json.loads(get("https://ip-ranges.amazonaws.com/ip-ranges.json"))
ec2 = [p["ip_prefix"] for p in ranges["prefixes"] if p["service"] == "EC2"]

def random_host(prefix):
    net = ipaddress.ip_network(prefix)
    return str(net.network_address + rng.randrange(1, max(2, net.num_addresses - 1)))

groups = {"tor exit": rng.sample(tor, N), "aws ec2": [random_host(p) for p in rng.sample(ec2, N)]}

for name, ips in groups.items():
    seen = []
    for ip in ips:
        seen.append(json.loads(get("https://ipcomet.com/api/reputation?q=" + ip)))
        time.sleep(1.2)  # the endpoint allows 60 a minute
    kinds = collections.Counter(r["network"]["kind"] for r in seen)
    print(f"{name}: tor flag {sum(r['tor'] for r in seen)}/{N}, "
          f"on a blocklist {sum(r['flagged'] > 0 for r in seen)}/{N}, network kinds {dict(kinds)}")

It takes about two minutes. The full response for each address is documented in the API reference.

I maintain ipcomet, a free IP checker. AI-assisted: I used Claude to help draft this post and to run the test. The lookups were made from my own machine, and every request to the checker went to my own API.

Python got a 403 and curl didn't. It came down to one case-sensitive string

ishant singh — Fri, 23 Oct 2026 08:22:35 +0000

A few days ago I wrote about getting your public IP from the command line. In the Python section I mentioned, almost in passing, that the default urllib gets a 403 from ipcomet while curl doesn't. I wrote that line from memory. It kept bothering me, because "bot protection rejects it" isn't an explanation. So I tested it properly.

Same laptop, same connection, same IP, same endpoint:

curl https://ipcomet.com/api/ip              -> 200
Python urllib, default settings              -> 403

Something differs between those two requests. Finding out exactly what took less time than I expected, and the answer is narrower than "Python gets blocked".

First suspect: the headers

If a server tells two clients apart, it's looking at what they send. So I wrote a tiny server that echoes back the request headers it receives, ran it on localhost (no third party involved), and hit it with four clients.

# echo_headers.py: returns the headers each client sends, in order
import json
from http.server import BaseHTTPRequestHandler, HTTPServer

class Echo(BaseHTTPRequestHandler):
    def do_GET(self):
        body = json.dumps(list(self.headers.items())).encode()
        self.send_response(200)
        self.send_header("Content-Type", "application/json")
        self.send_header("Content-Length", str(len(body)))
        self.end_headers()
        self.wfile.write(body)

    def log_message(self, *args):
        pass

HTTPServer(("127.0.0.1", 8777), Echo).serve_forever()

What came back, in the order the headers arrived:

Client	Headers sent	`User-Agent`	`Accept-Encoding`
curl 8.7.1	host, user-agent, accept (3)	`curl/8.7.1`	not sent
curl --compressed	host, user-agent, accept, accept-encoding (4)	`curl/8.7.1`	`deflate, gzip`
Python 3.9 urllib	accept-encoding, host, user-agent, connection (4)	`Python-urllib/3.9`	`identity`
Node 24 fetch	host, connection, accept, accept-language, sec-fetch-mode, user-agent, accept-encoding (7)	`node`	`gzip, deflate`

Nothing here looks more "bot-like" for urllib than for curl. curl sends the fewest headers of all and sails through, so the header count isn't it. urllib does send two things curl doesn't by default: Accept-Encoding: identity, which tells the server not to compress anything, and Connection: close. Neither looks unusual enough to justify a block.

That left the User-Agent, the one header whose value differs in an obvious way.

Same client, different User-Agent

To separate the header from everything else, I stopped changing the client and changed only the string. Same curl, same machine, one request per User-Agent, 1.5 seconds apart, against https://ipcomet.com/api/ip:

`User-Agent` sent	Status
`curl/8.7.1` (default)	200
`Python-urllib/3.9`	403
`Python-urllib/3.12`	403
`Python-urllib`	403
`python-urllib/3.9` (lowercase)	200
`urllib`	200
`my-urllib-script/1.0`	200
`python-requests/2.31.0`	200
`python-httpx/0.27.0`	200
`Python/3.9 aiohttp/3.9.1`	200
`Go-http-client/1.1`, `Wget/1.21.4`, `node`, `axios/1.6.0`, `okhttp/4.12.0`, `Java/17.0.2`, `PostmanRuntime/7.36.0`	200 (all)
empty (no `User-Agent` header)	200
`my-script/1.0`, with or without contact details appended	200

Twenty strings, 22 requests. Exactly one family was blocked: anything containing Python-urllib, with that capitalisation. The lowercase version passed. So did urllib alone and my-urllib-script/1.0, and so did every other non-browser client I tried, including an empty User-Agent.

Two reverse checks agree. curl sending Python-urllib/3.9 got the 403 all three times I tried it, and Python's urllib sending my-script/1.0 got a 200.

What the 403 looks like

The response is a 403 with a body of 17 bytes that contains the code 1010. That is Cloudflare's error for access denied based on the browser's signature, and ipcomet is served through Cloudflare. I didn't trace which rule produced it. The matrix already tells a client everything it needs to know about what the rule matches. It's a plain string match on a known default, which is why it's so easy to hit by accident and so confusing to debug. Nothing about the response says "change your User-Agent".

What I'd do about it

Set a descriptive User-Agent on every script, something like my-tool/1.0 (+you@example.com). It costs nothing, and it gives a site owner someone to contact instead of a reason to block you.
Don't copy a browser's string to get around a block. A blocked default is a hint to identify yourself properly, and pretending to be Chrome sends the wrong signal.
When a script gets a 403 with a tiny body, check the User-Agent first. It takes ten seconds.

In urllib the fix is one argument:

import urllib.request

req = urllib.request.Request(
    "https://ipcomet.com/api/ip",
    headers={"User-Agent": "my-tool/1.0 (+you@example.com)"},
)
print(urllib.request.urlopen(req, timeout=10).read().decode().strip())

Run the same test on your own site

This is the script I used, rewritten to use only the standard library. Only point it at a site you own or have permission to test. It sends one request per string with a pause between them.

import sys, time, urllib.error, urllib.request

URL = sys.argv[1]
AGENTS = [
    "curl/8.7.1", "Python-urllib/3.9", "Python-urllib/3.12", "Python-urllib",
    "python-urllib/3.9", "urllib", "my-urllib-script/1.0", "python-requests/2.31.0",
    "python-httpx/0.27.0", "Go-http-client/1.1", "Wget/1.21.4", "node",
    "axios/1.6.0", "okhttp/4.12.0", "Java/17.0.2", "PostmanRuntime/7.36.0", "my-script/1.0",
]

def status(agent):
    req = urllib.request.Request(URL, headers={"User-Agent": agent})
    try:
        return urllib.request.urlopen(req, timeout=20).status
    except urllib.error.HTTPError as e:
        return e.code
    except Exception as e:  # timeouts and resets are results too
        return type(e).__name__

for agent in AGENTS:
    print(f"{agent:<26} {status(agent)}")
    time.sleep(1.5)

Run it with python3 ua_matrix.py https://your-site.example/. I ran exactly this version against ipcomet as well, with urllib doing the asking instead of curl, and every status matched the table above.

What this doesn't tell you

It's one site's configuration. Other sites, including most of the ones you scrape, will behave differently. This maps one rule.
I tested the libraries by their strings. requests and httpx weren't installed on this machine, so those rows come from curl sending their User-Agent. The real libraries also send other headers of their own, which could matter on a stricter site.
Rules change. This is what one site did when I tested it.

If your lookups to ipcomet fail with a 403, the API reference already lists this under client notes.

I maintain ipcomet, a free IP checker. AI-assisted: I used Claude to help draft this post and to run the tests. The results come from my own machine, and every request in the matrix went to my own site.

Where is 8.8.8.8? I checked three IP databases against the speed of light

ishant singh — Thu, 22 Oct 2026 08:27:52 +0000

I maintain ipcomet, a free IP lookup site, and one question reaches me more than any other: "why does it say I'm in the wrong city?" Normally I explain that geolocation is an estimate and leave it there. This time I wanted numbers.

So I picked eight well-known IPs (four public DNS resolvers, a CDN edge, github.com, GitHub Pages and apple.com), asked several geolocation sources where each one lives, and then compared their answers with the one thing a database can't fake: how long a packet takes to get there and back.

The short version. The sources agreed on the country every time they gave one. They disagreed on the city for half of the IPs. And for seven of the eight, the city they named is farther from my connection than my ping time allows.

The method

Light in optical fibre travels about 200 km per millisecond. That gives a hard ceiling. If a round trip takes 12 ms, the packet had 6 ms each way, so whatever answered me is at most 1,200 km from where I sit. Real cables bend and real routers queue, so the true distance is always smaller. The ceiling is generous, which means that when a claimed city is beyond it, the claim can't be right for the machine that replied.

physical limit (km) = best round-trip time (ms) / 2 * 200

Two details that matter more than they look:

Use the best ping, not the average. Queuing only ever adds delay, so the minimum over many pings is the closest you'll get to the real distance. My first run caught 8.8.8.8 at 12.7 ms. A later run, on a congested minute, measured 133 ms for the same IP from the same laptop, and the "impossible" verdict would have vanished. A third run said 15.2 ms. I ran the pings three times and kept the best value for each IP.
Compare the same coordinates every source returns. Each source gives a latitude and longitude. I measured the distance from my own connection's position (taken from ipcomet's /api/me) to each claimed point. Every claimed city was more than 10,000 km away from me.

The sources were ipwho.is, ipapi.is and geojs.io (all free, no key) plus ipcomet's own /api/lookup. More on that last one at the end.

What came back

IP	What it is	Best ping	Light limit	ipwho.is says	ipapi.is says	Claim fits?
8.8.8.8	Google DNS	12.7 ms	1,268 km	San Jose	Mountain View	No
1.1.1.1	Cloudflare DNS	12.8 ms	1,283 km	Brisbane	Brisbane	No
9.9.9.9	Quad9 DNS	9.8 ms	981 km	San Francisco	Berkeley	No
208.67.222.222	OpenDNS	46.2 ms	4,624 km	San Jose	San Jose	No
151.101.1.69	Fastly edge	11.6 ms	1,158 km	San Francisco	San Francisco	No
17.253.144.10	apple.com	11.4 ms	1,140 km	San Jose	Cupertino	No
185.199.108.153	GitHub Pages	51.1 ms	5,109 km	San Francisco	Oakland City	No
140.82.112.3	github.com	227.5 ms	22,749 km	San Francisco	San Francisco	Yes

A few things jump out.

Country was never the problem. Wherever a source returned a country, it matched the others. geojs.io only ever returned a country for these IPs (no city at all, and for 1.1.1.1 it had no coordinates), so I left it out of the table.

City agreement was a coin flip. ipwho.is and ipapi.is gave the same city for four of the eight IPs. For 8.8.8.8 one said San Jose and the other Mountain View. For 9.9.9.9 it was San Francisco against Berkeley. Those are neighbours, but a lookup that says "San Jose" and another that says "Berkeley" for the same address can't both be telling you where a server physically sits.

github.com was the only claim that survived. At 227 ms the physical limit stretches around the planet, so the check can't rule anything out. Every other row failed it.

Why the answers are "wrong" (and why that's not quite the right word)

Geolocation databases are mostly answering a different question from the one we ask. They map an IP block to a place, usually where the block's owner is registered or based. They are not tracking where the machine answering you is plugged in.

1.1.1.1 is the cleanest example. All the sources put it in Brisbane. I asked ipcomet's WHOIS endpoint what the registry says:

$ curl "https://ipcomet.com/api/whois?q=1.1.1.1"
{"kind":"ip","query":"1.1.1.1","name":"APNIC-LABS","cidr":"1.1.1.0/24",
 "type":"ASSIGNED PORTABLE","country":"AU","organization":"APNICRANDNET Infrastructure Contact", ...}

The block is registered to APNIC Labs, country AU, and APNIC is based in Brisbane. Meanwhile Cloudflare's resolver answered me in under 13 ms, so a server very near my connection replied. Both facts are true. The database describes the registration, the ping describes the server.

The same logic explains the other DNS resolvers and the CDN edge. Those addresses are announced from many places at once (anycast), and whichever node is closest to you answers. A database has to pick one point to show, and it picks the headquarters.

What I'd take from this

Country-level answers are fine for most things. Everything agreed on it. It still isn't a legal boundary, so don't build compliance on a free database.
Treat the city as a hint. Two decent sources disagreed on half of a small, famous sample. Don't show a user "Berkeley" as a fact.
For anycast, CDN and DNS addresses, ignore the location. It tells you who owns the block and nothing about where the server is.
A ping is a cheap lie detector. If you ever need to sanity-check a location claim (a proxy's advertised country, say), the check below takes a few lines.

The script

This is a trimmed version of what I ran: one IP in, a verdict out. It uses only the standard library plus ping, so it works on macOS and Linux.

import json, math, re, subprocess, sys, urllib.request

def get(url):
    req = urllib.request.Request(url, headers={"User-Agent": "geo-check/1.0"})
    return json.load(urllib.request.urlopen(req, timeout=15))

def km(a, b):  # great-circle distance (haversine)
    (la1, lo1), (la2, lo2) = [(math.radians(x), math.radians(y)) for x, y in (a, b)]
    h = math.sin((la2 - la1) / 2) ** 2 + math.cos(la1) * math.cos(la2) * math.sin((lo2 - lo1) / 2) ** 2
    return 2 * 6371 * math.asin(math.sqrt(h))

def best_rtt_ms(ip, count=10):
    out = subprocess.run(["ping", "-c", str(count), "-q", ip], capture_output=True, text=True).stdout
    return float(re.search(r"= ([\d.]+)/", out).group(1))  # first number is the minimum

ip = sys.argv[1]
me = get("https://ipcomet.com/api/me")
target = get(f"https://ipcomet.com/api/lookup?q={ip}")
if "latitude" not in target:  # ipcomet omits fields it can't determine
    sys.exit("no coordinates for this IP")

claimed = km((me["latitude"], me["longitude"]), (target["latitude"], target["longitude"]))
rtt = best_rtt_ms(ip)
limit = rtt / 2 * 200  # light in fibre: ~200 km per ms, one way

print(f'{ip}: database says {target.get("city")}, {target.get("country")}')
print(f"claimed distance : {claimed:,.0f} km")
print(f"best round trip  : {rtt:.1f} ms  ->  physical limit {limit:,.0f} km")
print("verdict          :", "IMPOSSIBLE" if claimed > limit else "plausible")

Run it with python3 geo_check.py 8.8.8.8. This is what it printed for me, on a bad minute for my connection:

8.8.8.8: database says Mountain View, United States
claimed distance : 12,195 km
best round trip  : 55.8 ms  ->  physical limit 5,582 km
verdict          : IMPOSSIBLE

The best ping here is far worse than the 12.7 ms in the table, which is exactly the noise problem from earlier. The verdict still holds, because even a sluggish link can't turn 12,195 km into 5,582 km. A bad ping can hide an impossible claim. It can't invent one.

Two bugs bit me while I built the full version, and they're worth knowing about. geojs.io returns the string "nil" for coordinates it doesn't have instead of leaving the field out, so a plain float() on it crashes. And on the first full run, a single TLS handshake timeout killed the whole script, because free APIs do flake. Wrap each lookup in a retry.

About ipcomet's numbers

I should be upfront about the fourth source. ipcomet's lookup is built on upstream providers (the about page lists them), not on a database of its own. In my runs its city matched ipapi.is for all eight IPs, so counting it as an independent fourth opinion would be double-counting. What it gives you is one key-free endpoint for lookup, WHOIS, DNS and reputation. That WHOIS call is what settled the 1.1.1.1 question above.

The full endpoint list, with rate limits, is at ipcomet.com/developers.

I maintain ipcomet, a free IP checker. AI-assisted: I used Claude to help draft this post and to run the comparison. The measurements come from my own connection and the script above is a trimmed copy of the one I ran.

How to Get Your Public IP Address From the Command Line

ishant singh — Sat, 17 Oct 2026 03:46:08 +0000

The quickest way to get your public IP address from a terminal is curl https://ipcomet.com. It prints your address and nothing else, so the output can go straight into a script. This guide shows the same one-liner on macOS, Linux and Windows, how to do it from Python and Node.js, how to get your location and ISP as JSON, and how to choose between IPv4 and IPv6.

The one-line answer

curl https://ipcomet.com

The output is a single line such as 203.0.113.7. The home page recognises command-line clients (curl, wget, PowerShell and similar) by their User-Agent and returns just the address instead of the web page. In scripts, use the explicit endpoint https://ipcomet.com/api/ip, which always returns plain text.

macOS and Linux

curl https://ipcomet.com/api/ip
wget -qO- https://ipcomet.com/api/ip

macOS includes curl but not wget. To keep the result in a shell variable, use MYIP=$(curl -s https://ipcomet.com/api/ip). The -s flag hides curl's progress meter.

Windows

Windows 10 and 11 ship with curl, so curl.exe https://ipcomet.com/api/ip works in both Command Prompt and PowerShell. Type curl.exe rather than curl in PowerShell, where curl can be an alias for Invoke-WebRequest. The native PowerShell way is:

(Invoke-RestMethod https://ipcomet.com/api/ip).Trim()

Python

With the requests library:

import requests
print(requests.get("https://ipcomet.com/api/ip", timeout=10).text.strip())

With only the standard library, set a User-Agent. Python's default one (Python-urllib) is rejected by the bot protection in front of many sites, ipcomet included, which answer with a 403 error (Cloudflare error 1010):

import urllib.request

req = urllib.request.Request("https://ipcomet.com/api/ip", headers={"User-Agent": "my-script/1.0"})
print(urllib.request.urlopen(req, timeout=10).read().decode().strip())

JavaScript and Node.js

const ip = (await (await fetch("https://ipcomet.com/api/ip")).text()).trim();
console.log(ip);

This works in Node.js 18 and later, which has fetch built in, and in a browser page, because the endpoint allows cross-origin requests.

Get your location and ISP as JSON

curl https://ipcomet.com/api/me

The response describes the connection that made the request. An example, with made-up values:

{
  "ip": "203.0.113.7",
  "version": 4,
  "city": "Mumbai",
  "region": "Maharashtra",
  "country": "India",
  "countryCode": "IN",
  "timezone": "Asia/Kolkata",
  "asn": 64500,
  "org": "Example Broadband Ltd"
}

The full response also has the postal code, latitude and longitude, and a few details about the connection (the edge location, the HTTP and TLS versions and the round-trip time). To pick out one field, pipe it through jq: curl -s https://ipcomet.com/api/me | jq -r .country.

To look up any other address, use curl "https://ipcomet.com/api/lookup?q=8.8.8.8". It returns the IP version, hostname, city, region, country, coordinates, timezone, ASN and network owner. Lookups are limited to 60 a minute per caller, and location data is approximate because it comes from network records, not GPS.

Force IPv4 or IPv6

If your connection has both, add -4 or -6 to curl: curl -4 https://ipcomet.com forces IPv4, and curl -6 https://ipcomet.com forces IPv6, which only works if your connection has IPv6.

Other services you will see recommended

curl ifconfig.me, curl icanhazip.com, curl api.ipify.org and curl ipinfo.io/ip are other free services that return a bare address in the same way.
Without HTTP, you can ask a DNS resolver instead: dig +short myip.opendns.com @resolver1.opendns.com.

They all report the address the internet sees, so they should agree.

Why do two services show different IP addresses?

If they differ, your router may be sharing traffic across two internet connections, or a VPN may be carrying only some of your traffic.

These commands return your public address, the one websites see. For the private address on your own network, such as 192.168.1.20, check your network settings or run ipconfig on Windows and ip addr on Linux.

Limits and privacy

No key or sign-up is needed. Please keep requests reasonable: checking every few minutes is fine, but calling it in a tight loop may be rate limited. ipcomet does not store or log the addresses it sees. The free IP API page lists every endpoint with its exact rate limit.

This guide first appeared on ipcomet, a free IP checker I maintain.

How We Built FreeCustom.Email — A Bold Step Toward Email Freedom.

ishant singh — Tue, 22 Jul 2025 09:40:31 +0000

With many products built on the same template, and extremely powerful forces in tech, a question crept into my mind: why can email not be as personal as the names we use on the platform?

This query is what gave birth to what is now FreeCustom.Email a place to help email feel as though it were yours once again.

*🌱 The Frustration That Sparked an Idea
*
It began as what most stories about startups do; Frustration.

Being a freelancer and a builder in the tech world, having an unpleasant email address has been big a problem: usually long, difficult to memorize where the email comes through free companies or, on custom domains through more advanced providers, costly to register (but need to configure). I desired an email personality that was easy, business like and mine — without the baggage.

But when I looked around, everything was either:

Too complicated to set up,
Too expensive to maintain,
Or just not flexible enough for real people.
So I decided to change that.

💡 FreeCustom.Email: A Vision of Simplicity and Control
FreeCustom.Email was born with a core mission:- “To give everyone the power to create their own professional email identity — instantly, affordably, and without technical headaches”.

You can choose your own subdomain like yourname@startuphero.email or contact@creativesoul.email, without needing to buy or manage a full domain.

No hidden fees. No shady data collection. No lock-in.

Just email — your way.

🌍 A Tool for Freelancers, Creators, Founders — and Everyone in Between
What surprised us most? The diversity of our users.

A solo founder in Germany using founder@launchlabs.email.

An indie artist in India sending newsletters from hello@canvasdreams.email.

A crypto dev who wanted privacy but professionalism.

Our inboxes filled with support messages, but also with gratitude. People felt seen. They felt like their online identity finally had a home.

🔮 What’s Next for FreeCustom.Email?
We’re just getting started.

More TLDs. More features. Closer integrations with productivity tools and calendar. Mobile first interface. And a duty to make sure that every time we build, we keep the center of it privacy and freedom. Non-alienating enough email identities to exhaust you? Or you simply desire a service that does not waste your time, as well as your information? Give us a look.

It’s more than just an email address.

It’s your identity, on your terms.

👉 FreeCustom.Email — Claim yours today.