If you've been running cold email the last few months, you've probably seen a blacklist hit on a sending domain.
Up until about three months ago, the standard move was to redirect those sending domains to your primary site. Recipient types getcompany.com into the address bar, lands on company.com, nobody gets confused.
That hop is now how whole batches get listed together.
Blacklist providers are walking the redirect chain. They list the domain that got flagged, follow it to the destination, find every other domain pointing at the same site, and stamp the whole batch at once.
We shipped domain masking on ScaledMail for this. It puts the site content you want on the sending domain, with no redirect hop. Recipients still see a real website. Crawlers don't get a trail back to the rest of your pool.
It works for ScaledMail-hosted inboxes and for inboxes on other providers.
Why sending domains redirected in the first place
You don't send cold email from your primary company domain. You buy variations (getcompany.com, trycompany.io, companyhq.co) and keep reputation there. If a sending domain gets burned, the domain your team uses for clients and invoices stays clean. Setup for that is in the cold email infrastructure guide and the domain rotation guide.
Those sending domains still need a website.
If a prospect gets mail from alex@getcompany.com and puts the domain in the address bar, a parked page or a "coming soon" screen looks abandoned. A lot of people bounce on that. A 301 or 302 to the real site solved the human problem. The prospect landed on your actual website and the brand looked fine.
The technical problem is what caught up with us.
Providers are following the redirect chain
Domain and URI blocklists don't stop at the hostname that sent the mail. A growing number of them crawl the web presence on that domain.
When the sending domain 301s or 302s to your primary site, the crawler follows it. Then it looks at what else redirects to the same place.
So you get a graph like this.
getcompany.com 301s to company.com. So does trycompany.io. So does gocompany.co. So does companyhq.net.
One of those sending domains gets listed. The provider walks the redirect, sees company.com, finds the rest of the batch, and lists them together.
That's why teams are watching 5 or 10 or 15 domains go down at the same time.
List quality, authentication, complaint rate, and spam traps still matter. We cover those in cold email blacklist prevention. The redirect chain is a newer grouping trick on top of those.
This wrecks domain rotation
Cold email at scale is a pool of sending domains on purpose. Domain rotation only works if a listing on one domain stays on one domain.
Redirects tie the pool together in public.
If the sending domains are isolated, you pause the listed one and shift volume. If they all 301 to the same primary site, a listing on one is a map to the others.
And if they redirect to the hostname your company actually uses, the domain that handles customer email and billing is in that same graph. Check that before you do anything else.
Run the pool through the blacklist checker. If several sending domains flipped together, open them in a browser. Same final URL means that's the mechanism.
Domain masking vs redirects vs parked pages
Prospects will type the From domain. Some filters look for web presence. You still want a real site on the sending domain. The difference is how that site gets there.
| Approach | What the prospect sees | HTTP redirect hop | Shared across your domain pool |
|---|---|---|---|
| Parked / for-sale / "coming soon" page | Unused domain, low trust | No | No |
| 301 or 302 to the primary site | Your real website | Yes | Yes. Every domain that hops to the same destination is linked. |
| Meta refresh or JavaScript redirect | Your real website, eventually | Soft hop, still crawlable | Usually yes |
| Domain masking (masking proxy) | Your site content, URL stays on the sending domain | No | No |
Domain masking is a reverse proxy.
Someone visits getcompany.com. The masking proxy fetches the content you chose and serves it at getcompany.com. The address bar never changes. There is no Location header, no 301, no 302, no meta refresh.
To a person, the sending domain has a real website. To a crawler following redirect hops, there is nothing to follow.
What masking actually covers
Masking is the web-presence layer on the sending domain.
Deliverability still comes from dedicated sending domains, SPF, DKIM, and DMARC, warmup, and list hygiene. If company.com itself is listed, cloning that content onto sending domains will not clean it. If you blow past sending limits or hit spam traps, you will still get listed. The deliverability playbook is the rest of that stack.
And you still never send cold email from the domain your company actually runs on.
How ScaledMail domain masking works
You pick the site content you want prospects to see. ScaledMail stands up a masking proxy on the sending domain. The domain serves that content directly. No redirect relationship gets published.
You can turn it on in the app, or as an add-on when you buy inboxes.
Already in the app
Open ScaledMail, go to Domain Masking, and click Add new masking proxy. Walk through the steps for the domain.
Recipients who type the sending domain into a browser still land on real site content. Blacklist crawlers don't get a redirect chain to walk.
Buying inboxes
If you're building a new package, domain masking is an add-on at checkout, below reporting. Select it when you configure the package. Onboarding collects the rest (which site to clone, which domains to mask). You don't have to piece DNS together after the fact.
Pricing
| Inbox source | Domain masking |
|---|---|
| ScaledMail-hosted inboxes | $0.50 per domain / month |
| External inboxes (any other provider) | $1.00 per domain / month |
Same feature either way. The external price covers domains and mailboxes that aren't on our infrastructure. If you're running a mixed stack, some ScaledMail Google or Microsoft inboxes and some inboxes elsewhere, you can mask the whole pool in one place.
If your sending domains still redirect
If they currently 301 or 302 to the same primary site, treat that as a live grouping risk. Don't wait for a listing to confirm it.
- Inventory the hop. Open each sending domain in a browser. Note the final URL. If they all collapse to one destination, that's the cluster.
- Check listings on the whole pool. Run every sending domain and the destination site through a blacklist checker. A single listing is a domain problem. A batch listing is a redirect-graph problem.
- Pull the redirects. Remove the 301/302 and any meta refresh from the sending domains. Do this before you start arguing with a blocklist about a domain that is still advertising its siblings.
- Put a real site on the sending domain without a hop. That's domain masking. Parked pages and blank nginx defaults are a trust problem for anyone who types the From domain.
- Keep each sending domain on its own masked site. Pointing the leftovers at a new shared hostname like company-outreach.com rebuilds the same graph with a different root.
- Keep monitoring. Weekly blacklist checks on every sending domain. Daily if you're scaling volume or recovering from a listing. Pair that with the reputation checker and deliverability checker.
If a domain is already listed, pause it, fix the underlying cause, then request delisting. Masking after the fact stops the next cascade. It does not unwind a listing that already happened. The removal workflow is in the blacklist prevention guide.
Masking sits next to dedicated sending domains, auth on every domain, conservative volume, a real warmup window, domain rotation, clean lists, bounce rates under 2%, and ongoing placement monitoring. It closes a hole a lot of otherwise-solid setups still have open: a public redirect that turns one listed domain into a mapped set.
If you want the whole stack handled (domains, inboxes, authentication, masking, monitoring), build a package or book a call. If you only need the masking layer on domains you already own, add a masking proxy in the app. Both paths are supported.
FAQ
What is domain masking for cold email?
Domain masking serves your website content on a sending domain without an HTTP redirect. The URL stays on the sending domain. Prospects who type it in still see a real site. Blacklist crawlers don't get a redirect hop back to your primary domain or the rest of your pool.
Why are domain redirects getting cold email domains blacklisted?
Redirects publish a relationship. If getcompany.com 301s to company.com, a crawler can treat those hostnames as connected. If several sending domains hop to the same place, a listing on one can be used to group and list the others. That used to be rare. Over the last few months it has become a common way entire batches go down together.
Is a 301 redirect still okay for sending domains?
If several outreach domains share the same destination, that hop is how providers group them. Drop the shared redirect. A single marketing domain pointing at a product site is a different use case.
Will prospects still see my real website?
Yes. Masking clones the content you choose onto the sending domain. They see a real site. They do not get bounced through a redirect, and the address bar stays on the domain they typed.
Does domain masking work if my inboxes aren't on ScaledMail?
Yes. Masking supports ScaledMail-hosted inboxes at $0.50 per domain per month and external inboxes at $1.00 per domain per month. Setup is in Domain Masking → Add new masking proxy, or as an add-on when you buy inboxes.
Do I still need SPF, DKIM, DMARC, and warmup?
Yes. Those still determine whether mailbox providers accept the mail. Masking only removes the web redirect relationship between domains. Do both.
What should I do if several domains got listed at the same time?
Assume a shared redirect until you prove otherwise. Check where each domain lands in a browser, pull the redirects, check listings on the full pool, pause the listed domains, and put masking in place before you bring replacements online.
Should I put a parked page on sending domains instead?
You can. Recipients who inspect the From domain will treat it as unused, which is its own trust problem. Masking exists so you don't have to choose between a page that looks abandoned and a published redirect graph.
If you don't have something in place for redirect relationships, put it in. Providers are following the breadcrumbs. They see the domain that got flagged, and they see everything that hops to the same site.
Domain Masking is live in the app. Add a masking proxy, or turn it on as an add-on at checkout.
Get started with ScaledMail · Check your domains · Talk to the team
