Most rejected campaigns I've been asked to look at didn't fail on the creative. They failed underneath it: a domain with a burned history, an SSL certificate from yesterday, a page that collapses on a phone screen. The buyer found out from the rejection email, after the spend.
That's an expensive way to run a checklist. Everything in that email was knowable before launch, for free, in about twenty minutes. Here is the checklist I run on every white page before a dollar of traffic touches it — what to look at, why it matters, and how to check each item.
The three layers a reviewer sees
When a platform reviews your ad, it doesn't see "a landing page." It sees three layers at once:
- Infrastructure — the domain, DNS, hosting, SSL.
- Reputation — what blacklists, Safe Browsing and scanners already think of this domain and its neighbors.
- The page itself — content, trust pages, tech stack, speed, behavior on mobile.
A problem in any one layer can sink the whole review, and the layers interact: a clean page on a dirty IP range still reads dirty. So the checklist below is ordered by layer, and the order matters — fix reputation before you polish copy.
Layer 1: Infrastructure
1. Domain age and history
Why: a domain registered last week has no track record, and reviewers treat "no history" as a risk factor, not a neutral one. Worse is a domain with a bad history — previously parked on scam content, dropped, and re-registered.
Check: WHOIS lookup for the registration date. Then a history service (archive.org at minimum) to see what the domain hosted before you bought it. If the previous life was a casino doorway in another language, walk away — that history doesn't wash off.
2. DNS and hosting neighborhood
Why: your domain's IP sits in a block with other sites. If the block or the ASN is full of throwaway domains, you inherit the neighborhood's reputation.
Check: resolve the domain, look at the IP, and check what's around it. A mismatch between where you tell reviewers the business is and where the infrastructure actually lives is a quiet red flag.
3. SSL certificate
Why: no valid certificate is an instant, mechanical fail. A certificate issued hours before the campaign isn't a fail, but it's a tell — legitimate businesses don't usually launch on same-day certs.
Check: open the page over HTTPS and inspect the cert: issuer, validity dates, domain match. This takes ten seconds and catches a surprising number of "why was I rejected" cases.
4. Redirects and HTTP behavior
Why: a redirect chain that hops through unrelated domains, or HTTP that doesn't upgrade to HTTPS cleanly, looks like evasion infrastructure even when it's just sloppy setup.
Check: fetch the bare domain with a tool that shows the full redirect chain and status codes. Every hop should make sense.
Layer 2: Reputation
5. DNS blacklists
Why: DNSBLs are how email and abuse systems share "known bad" lists. Ad platforms and their vendors consult overlapping sources. One listing is often enough to poison a domain before the first review.
Check: run the domain and its IP against the major blacklists. Doing this one list at a time by hand is tedious; this is exactly the kind of check worth automating (more below).
6. Google Safe Browsing and VirusTotal
Why: Safe Browsing status feeds directly into Chrome warnings and Google Ads review. VirusTotal aggregates dozens of scanner verdicts — a single "malicious" flag from an obscure engine can be cleaned up; three flags from major engines means the domain is burned.
Check: both are free and public. Look at them before the platform does.
7. Email infrastructure
Why: if the domain sends mail (order confirmations, lead follow-up), missing or broken SPF/DKIM/DMARC records are a visible sign of a throwaway setup. Reviewers and spam filters both read these.
Check: query the domain's TXT records. No records at all is not "neutral" — it's absence where a real business has presence.
Layer 3: The page itself
8. Trust pages that actually work
Why: privacy policy, terms, contact — reviewers follow these links. A privacy page that's a lorem-ipsum template, a contact page with a dead form, or links that 404 are among the most common mechanical reasons for rejection. These pages carry more weight than most buyers assume; I wrote a separate breakdown of which trust signals actually matter on white pages and which are decoration.
Check: click every footer link. Read the privacy page as a skeptic: does it name a real entity, a real address, a working contact? Then test the contact form.
9. Content quality and language match
Why: thin content — two paragraphs and a stock photo — reads as a placeholder, because it usually is. And a page in English targeting a German offer with a .de domain is a mismatch a reviewer notices in seconds.
Check: read your own page top to bottom, in the target language, on a phone. If you wouldn't fill the form, the reviewer won't either.
10. Tech stack and cloaking tells
Why: the frameworks, scripts and third-party calls a page loads are visible. Some stacks correlate strongly with churn-and-burn setups. And if the page behaves differently for different visitors in ways a reviewer's tools can detect, that's a cloaking flag regardless of intent.
Check: look at what the page loads: external scripts, iframes, fingerprinting libraries. If you didn't put it there, find out who did.
11. Speed and Core Web Vitals
Why: a page that takes five seconds to become usable on a mobile connection loses the click before the content renders — and CWV scores are a measurable, logged fact about your page, not an opinion.
Check: run the page through a speed test on a mobile profile, not your fiber desktop. Watch the largest element render and the layout shifts.
12. Compliance basics
Why: GDPR consent where it applies, no prohibited claims, no fake urgency widgets with hard-coded timers. Compliance failures are the rejections that come with account-level consequences, not just ad-level ones.
Check: load the page from an EU IP and look for the consent flow. Read your own claims as a policy reviewer would.
The shortcut: all of the above in one pass
Doing items 1–12 by hand is the right way to learn what each check means. Doing it by hand for every domain in a batch of thirty is how checklists stop happening.
For the batch version I run the domains through AdInfraCheck. It executes 17 modules per domain — WHOIS, DNS, IP info, SSL, HTTP probe, reputation across 30+ blacklists plus Safe Browsing and VirusTotal, content parsing, robots and sitemap, tech stack, cloaking signals, security headers, email infrastructure, domain history, social signals, Core Web Vitals, and GDPR/Google Ads compliance — and reports each module separately, so a failure says which layer failed, not just "bad score."
Two parts I find myself using more than expected:
- The captures. A real browser opens each domain at desktop (1440×900) and mobile (375×812), takes a full-page screenshot, and records a scroll video. This regularly catches things no checklist item does — a mobile layout that breaks below the fold, a popup that hijacks the scroll, a page that's fine at 1440px and unreadable at 375px. Everything downloads as a ZIP, so the check lives next to the campaign files.
- Compare mode. When I'm choosing between two batches of domains from different sellers, I run batch A against batch B on the same parameters and pick with the reports in front of me instead of the seller's word.
It's free with an account, which makes the "I'll skip the checklist this once" excuse hard to defend.
When a check fails
Not every failure means "throw the domain away":
- Blacklist listings — identify which list and why. Some accept removal requests once the cause is fixed; some are permanent enough that the domain is done.
- SSL/redirect issues — pure setup, fixable in an hour.
- Missing trust pages — write them properly, with real entity details. Half a day of work, permanent fix.
- Bad domain history or a burned IP neighborhood — not fixable. This is what the check is for: better to lose a domain than a domain plus an ad account.
The point of the checklist isn't to find domains that are guaranteed to pass — no such thing exists. It's to stop spending money discovering problems that were visible for free.
FAQ
How long before a campaign should I run these checks?
Close enough to launch that reputation data is fresh — the same day is fine, the same week is fine. Blacklist status changes, so a month-old check is a stale check.
Is a brand-new domain an automatic problem?
No, but it's a factor you compensate for elsewhere: clean infrastructure, complete trust pages, sensible content. New domain plus sloppy everything else is the combination that fails.
The domain is clean but the campaign still got rejected — why?
Then the problem is in the other layers: the creative, the offer, the account history, or the page content itself. The checklist rules infrastructure out; it doesn't certify the whole funnel.
Can I check domains I don't own yet?
Yes — that's one of the best uses. Run the batch before you buy, not after. Reputation and history checks work on any domain.
Does passing all checks guarantee approval?
No. Passing means the technical layer won't be the reason you're rejected. Moderation decisions involve factors no tool can see in advance, and anyone who promises a guaranteed pass is selling something.
How many domains can I check at once?
A single domain or a pasted batch both work. For batch buying decisions, use compare mode to run two batches against each other on identical parameters.
The checklist above is exactly what AdInfraCheck automates — 17 modules, screenshots, scroll video, ZIP export. Register, paste your domains, and read the report before you read the rejection email.