DEV Community

Ahsan Luqman
Ahsan Luqman

Posted on Originally published at aliasfleet.com on

Hide Your Email Address Online Before Spammers Find It

The address you publish should be one you can kill without losing your inbox. Hiding your email address online means replacing the real one with a contact form or an email alias from AliasFleet, then deleting the real one wherever it already sits in public.

Your real address is probably out there already. A site footer. A bio. A forum post from years ago that you forgot you wrote. This guide covers the cleanup for addresses that are already public, a different job from choosing an alias for a new signup.

Deletion on its own leaves a hole. People still need to reach you, so something has to stand where the address stood. A contact form takes no address at all. An alias takes the public job and keeps your real inbox unlisted: mail to the alias forwards to your inbox, and you can pause or kill the alias without touching the inbox. The order below is find, delete, replace, then chase the search results.

The copies you already know about

Your website footer is the likeliest spot, and the contact page runs close behind. Any "email me" link counts too. Then come the bios: social profiles, author pages, speaker pages, directory listings, and the about page you wrote years ago and never touched again. Then the older material: forum posts, mailing list archives, comment sections, old CVs saved as PDFs, conference slides, and open-source commits.

Commit history holds the address in every commit you authored with it. Domain registration records can expose it too, although most registrars redact those fields by default now.

A published address gets copied. Scrapers gather addresses from public pages and sell or trade the lists, which is one of the main ways spammers get your email address. Once a list is out there, you cannot call it back. You can stop feeding it, and you can make the published address worthless to whoever holds it.

Search the way a scraper would

Search for your address in quotes, like "you@example.com", which asks for the exact string. Then try variations: the address without quotes, your name plus the word email, and your name plus your domain.

Then narrow it site by site. Google documents the site: and filetype: operators, which let you limit a search to one domain or one file type. A query like site:example.com "you@example.com" checks one site. A query like filetype:pdf "you@example.com" turns up PDFs, where old CVs and slide decks hide. The Google search operators reference lists the operators that work.

Run a breach check alongside the search. Have I Been Pwned lets you look an address up against breach data. A breach listing means the address was taken; a public listing means you published it yourself. Both feed the same spam, but only the public copies are yours to delete. Work the public list first.

Delete it where it lives

Everything else depends on this step: the address has to come off the page itself. On pages you control, edit the footer, the contact page, and the about page. Check your site templates, not just single pages. A footer template puts the address on every page at once, and fixing one page leaves fifty copies behind.

For pages outside your control, ask the owner. Google's own advice is to contact the website owner first, since only the owner can take the page down: look for a contact link, try a WHOIS lookup for the registrant or admin contact, or contact the hosting company if the owner does not answer. The Google guide to contacting a website owner lays out the same order.

Git commits. Git history is the stubborn one. A no-reply address plus GitHub's "Keep my email addresses private" setting keeps web-based operations from exposing your real address from now on, and GitHub's guide to setting your commit email address walks through it. That fixes future commits only. Every old commit still carries the address you used at the time. Scrubbing it from history means a git-filter-repo rewrite plus a force-push, and even then the copies in clones, forks, and cached views stay put. Read GitHub's guide to removing sensitive data before you touch history.

Domain records. Domain records deserve their own check. Pull up the public WHOIS or RDAP record for your domain. Most registrars redact personal fields by default these days, so the address may already be hidden. If it shows, look for the registrar's privacy or redaction switch, where one exists. Cloudflare's WHOIS redaction docs explain the shape of it: personal fields read as redacted, state and country still show. Availability varies by registrar and TLD.

Old accounts. Then the accounts you stopped using. Close them, or strip them. A forum profile from 2014 with your address in the bio is a live public page whether you remember it or not. Where deletion is not possible, blank the bio, drop the signature, and swap the public email field if the site offers one.

Give every public spot a replacement

On a website, a contact form is the cleanest swap. A guide to creating a contact form in WordPress covers the setup: pick a form plugin, build the form, and embed it on the contact page. If you want the simplest version, Contact Form Zero is a free plugin that adds a form with one shortcode and keeps its spam protection out of sight.

For anything that is not your own website, an alias is the replacement. One alias per public place, not one alias stretched across all of them. That way a footer alias, a bio alias, and a forum alias each point back to where a message came from, and each can be killed without touching the others. The set-up guide takes a few minutes. A different email for every website applies the same idea to signups. Same rule both times: never hand out the address you cannot afford to lose.

Then ask search engines to catch up

Fix the source page and the search results still lag. They show the old snippet for a while because the engine cached the old version. That lag is normal, and it needs a nudge.

Google's route runs through Results about you. Sign in, enter the details you want watched, and it surfaces matching results for review. From there you can ask for a result showing your address to be removed. Google reviews each request, and it may refuse pages it classes as valuable to the public, such as government or newspaper sites.

Threats change the route. Where the address sits alongside threats or other personal details meant to harass you, Google's personal-info removal form is the right tool. It covers doxxing content and other sensitive personal info, and it looks only at the exact URLs you submit.

Where the source page changed and the snippet still shows the old version, the Refresh Outdated Content tool asks Google to recheck the page and update the result. It touches the search result only.

Bing runs a separate route. Its Content Removal tool in Bing Webmaster Tools handles page-removal requests for URLs that no longer exist, plus outdated-cache removal for pages that changed. The Microsoft Q&A page on Bing's Content Removal tool quotes the official steps, including the sign-in.

Site owners get one more lever. Search Console's Removals tool hides a page at once, but only for a while. Google's guide to removing information from your own site is clear on the catch: you still have to remove or block the info on the page itself, or the result comes back.

Search removal is half the job. The page still exists after a result disappears, and anyone with the direct link still sees it. Search removal cuts off discovery; source removal cuts off the page itself. You need both.

The copies hiding in the corners

A few copies hide where the first search never looks. Check these before you call the job done.

PDFs and documents. Old CVs, portfolios, press kits, slide decks. Hunt them down with the filetype:pdf operator, then edit and re-upload, or delete the file outright.

Mailing list archives. A list that archives its messages in public keeps your address in the archive. Ask the list admin to remove or redact it.

Archived pages. The Wayback Machine keeps snapshots of old pages, including ones you already fixed. The Internet Archive documents an exclusion request: email info@archive.org with the URLs, the time period to exclude, and the period during which you controlled the site or account. It is a review, and the outcome is not guaranteed.

Old domains and redirects. Check domains you used to own. Old pages can stay indexed, and a redirect can carry the old footer with it.

Package and code metadata. Author fields in package files, README files, and config examples can carry a real address. Swap them for an alias or the no-reply address.

What cleanup cannot take back

Cleanup stops future harvesting from the pages you fixed. It does not call back copies already taken. Harvested lists, breach dumps, screenshots, forwarded emails, and other people's address books all sit beyond your reach. An address that was public for years almost certainly lives on in at least one list somewhere.

That is no reason to skip the cleanup. It is the reason to pair it with the replacement. The old lists keep pointing at an address you no longer publish, and the new published address is one you control. When the alias you publish starts getting abused, kill it and make a new one. The old lists keep pointing at the dead alias instead of at you.

Two checks fit here. Check whether your email was leaked so you know which problem you are dealing with. And if mail lands on an alias from a sender that should never have had it, the alias escaped somewhere. The guide to tracing which website leaked your email explains how to read that signal.

A monthly pass keeps it clean

Cleanup is a habit, not a one-off project. Once a month, run the quoted-address search again and scan the first two pages of results. Switch on alerts in Results about you so new matches come to you instead of waiting to be found.

And hold the line on the replacement rule. Each time a form asks for a public contact address, a bio needs one, or a new site needs a footer, reach for the form or the alias.

Top comments (0)