Getting a new domain past security filters

Run this whenever you launch a new site or domain, particularly on a newer TLD. New domains are routinely blocked or DNS-sinkholed by security filters — home security routers, corporate firewalls, ISPs and DNS-filtering services. It is almost always a false positive, and most of it is preventable.

The companion problem — why a user-facing endpoint must not live on a platform subdomain — is a separate document. This one is about the domain itself.

There are two independent causes, and only one is fixable

1. The newly-registered-domain flag is purely time-based. Many filters block any domain registered in roughly the last thirty days, regardless of content. No submission clears this. It ages out on its own in about two to four weeks. Allowlist the domain locally in the meantime and get on with something else.

2. Missing or wrong category is fixable. Filters treat “uncategorised” as “suspicious”, so a domain nobody has classified gets blocked on that basis alone. Submitting an accurate category to the reputation databases addresses this directly.

Confusing the two wastes a lot of effort: people submit categorisation requests to fix what is actually the age flag, conclude submission “didn’t work”, and stop doing the part that would have helped.

No single submission unblocks everywhere. Each vendor maintains its own database. Reputation also accrues on its own with age, real traffic and inbound links — so the checklist below front-loads what you can control.

Launch hygiene, at go-live

• Valid TLS. Usually automatic; confirm rather than assume.
• Publish email authentication — SPF, DKIM and DMARC — even if the domain never sends mail. A null-sender SPF record plus a quarantine DMARC policy still raises domain trust, and their absence is a signal against you.
• Real content, no parked page. A clear about page and a contact route. Placeholder and parked pages read as suspicious to exactly the systems you are trying to satisfy.
• Canonical URL on the real domain, never a platform preview subdomain. Set the canonical link, the Open Graph URL and the sitemap accordingly.
• Plausible registration data. A privacy proxy is normal and fine; obviously bogus registrant details are not.

Submit a category

Start with the platform fronting your domain, since its own resolver and filtering products consume that data directly. Look the domain up in its reputation tooling, check what categories and rank it currently has, and submit a categorisation request if the answer is blank. Run a public URL scan at the same time so there is a clean, citable report.

Then cover the major third-party databases, because most filters — including consumer routers — license one of them. On each, look the domain up and request an accurate business or technology category:

• Google Safe Browsing — check through Search Console’s security section; this is what Chrome and Android consume.
• Cisco Talos — behind Cisco firewalls and their DNS filtering.
• Symantec / Broadcom site review — enterprise proxies.
• Palo Alto URL filtering — “Test A Site”.
• Fortinet FortiGuard — web filter lookup, with a review request.
• Webroot / BrightCloud — many consumer routers and anti-virus products. Often the culprit for a home-network block.
• McAfee / Trellix trusted source.

Pick genuine categories rather than the most flattering ones, and say plainly that it is a legitimate business site. These are reviewed by people.

Diagnosing a live block

Two questions: is it actually you, and who is doing the blocking?

• Compare an encrypted-DNS answer with your local resolver. If they differ, your network is intercepting or sinkholing.
• Force a known-good edge IP with the real Host. If that times out while the same IP serves a different hostname fine, the block keys off the hostname rather than DNS or the address. Encrypted DNS alone will not fix that; it needs a tunnel or an allowlist entry.
• Test from a mobile network and from a security-DNS network, not just your own. Your development network is frequently the one place everything works.

Per-launch checklist

[ ] TLS valid; SPF, DKIM and DMARC published
[ ] Real content, about and contact pages, no parked placeholder
[ ] Canonical on the real domain, not a platform preview subdomain
[ ] Platform reputation tooling: category submitted, URL scan run
[ ] Category submitted to the major third-party databases
[ ] Noted: the newly-registered flag clears on its own in ~30 days;
    allowlist locally in the interim rather than chasing it
[ ] Any licensing or API endpoint fails gracefully when unreachable
[ ] Re-check categorisation after a few weeks; resubmit if still wrong

Why this matters more than it sounds

A filtered domain does not present as an error you can see. It presents as a subset of real users — the ones behind a filtering router, a corporate network or a security-focused resolver — silently failing to reach you, while everything looks perfect from your desk. If the affected endpoint is a licence check, those users experience it as your software refusing to work.

That is the reason this is launch hygiene rather than something to do when somebody complains: by the time anyone complains, most of them have not.