How to build an MFA exclusion list that holds up to a dispute
Part of MFA avoidance
The short answer
An MFA exclusion list is a shared set of domains kept out of every campaign because reviewers found made-for-advertising evidence on them. Build it from served domain reports and site reviews, record the signals, evidence and reviewer behind every entry, format domains the way each buying platform expects, and keep a dispute log so wrong calls can be reversed quickly.
Key takeaways
- Every entry needs a record: the signals found, links to saved evidence, two reviewers, the date and the next review date.
- Domain formatting decides what an exclusion covers; in Google Ads, a root domain without www also excludes its subdomains.
- A dispute log turns publisher challenges into a record of how good the list is, not a stream of emails.
- Sites leave the list through written reinstatement rules, not quietly when someone forgets why they were added.
What is an MFA exclusion list, and when does a team need one?
An exclusion list blocks named domains in a buying platform. For made-for-advertising sites it works as a safety net under everything else: campaigns that buy broad categories, audience campaigns with no site list, and deals whose domains nobody reviewed. Our hub on MFA avoidance explains where the list sits in a standing practice; this guide covers how to build the list itself and keep it defensible.
Definition
- MFA exclusion list
- A versioned list of domains that a team blocks across campaigns because recorded evidence shows the sites were built mainly to show ads, with a review record and a dispute history for every entry.
The list is a backstop, not a plan. Campaigns built on an approved inclusion list already keep unreviewed sites out; the exclusion list catches what slips through everywhere else. That is also why it needs more care than its size suggests: one wrong entry quietly removes a legitimate publisher from every campaign the team runs.
What should each entry on an MFA exclusion list record?
A bare list of domains cannot be defended. When a client asks why a site was blocked, or a publisher disputes it, the answer has to come from a record written at the time. Keep the record in a spreadsheet or database next to the list, one row per domain.
| Field | What to record | Why it matters |
|---|---|---|
| Domain as loaded | The exact string sent to each buying platform, after formatting | Shows what the exclusion actually covers |
| Candidate source | Served domain report, site review, network match or a third party list | Separates first hand findings from imported ones |
| Signals by area | Findings under layout, traffic, content and ownership | Shows whether evidence came from more than one area |
| Evidence links | Screenshots, archived pages and saved ads.txt copies, each dated | Lets someone else check the call later |
| Reviewers | The first reviewer and the second reviewer who confirmed it | Shows that no entry rests on one person's view |
| Scope | Shared across all clients, or limited to named clients | Stops a client specific call spreading everywhere |
| Status and dates | Active, under dispute or reinstated; date added; next review date | Keeps old entries from becoming permanent by default |
| List version | The version in which the entry was added or changed | Ties every campaign to the list it ran with |
How do you build the first version of the list?
Building version one
- Pull served domain reports from recent campaigns. Sort domains by spend and flag the ones nobody planned. Unplanned domains with heavy spend are the most useful first candidates.
- Add network neighbors. For each confirmed MFA site, look for other domains with the same ads.txt OWNERDOMAIN, which the ads.txt 1.1 specification (opens in a new tab) defines as the business domain of the entity that owns the site, or with the same ad and analytics IDs. Review each neighbor on its own evidence.
- Review every candidate with saved evidence. Use a written signal checklist, such as our reviewer's checklist for MFA sites, and archive the pages that support each finding.
- Require a second reviewer for every entry. The second person works from the evidence and a fresh visit, without seeing the first reviewer's conclusion.
- Approve and number the version. The practice owner signs off version one with its date, its entry count and the policy version it applies.
- Load it and count. After upload, compare the number of entries in each platform with the approved count, and record any entry the platform rejected.
How should domains be formatted before loading into a buying platform?
The same domain can mean different things to different platforms, so formatting is where an exclusion list can fail without any error. In Google Ads (opens in a new tab), for example, an entry without www also covers the domain's subdomains, and each country domain needs its own entry. Our guide to Google Ads placement exclusions covers that platform's entry formats, levels and limits; the table below is about turning review findings into entries.
| Raw finding | Entry to load | Reason |
|---|---|---|
| https://www.example.com/story?id=5 | example.com | MFA is a site level business model, so the whole domain goes on the list |
| A network that runs example.com and example.ca | Both domains, as separate entries | Country domains are separate placements |
| One MFA blog on a hosting platform that serves many publishers | The blog's subdomain only | Excluding the root would block every other publisher on the platform |
| A domain that redirects to another domain | Both the redirecting and the final domain, with the redirect recorded | Inventory may be declared under either name |
How should a dispute log work?
A publisher may challenge an exclusion, and it may be right. A dispute log makes each challenge a tracked case with a deadline and an outcome, and over time it shows which signals produce wrong calls. Keep it separate from the list, linked by domain.
| Field | What to record |
|---|---|
| Case opened | Date received, who raised it, and the channel |
| Publisher's claim | What the publisher says is wrong, in its own words, with any documents it sent |
| Original evidence | Links to the findings and evidence recorded when the entry was added |
| Re-review | A fresh visit by a reviewer who did not make the original call, with new evidence saved |
| Outcome and reason | Upheld, reversed, or reversed with conditions, and the signals behind the decision |
| Actions taken | List version changed, platforms updated, publisher and client informed, with dates |
Before closing a dispute case
- The re-review used pages visited after the dispute was received, not only the original screenshots.
- The reviewer on the case did not make the original exclusion.
- Any change the publisher made, such as a new template or dropped paid traffic, is dated in the log.
- A reversal was applied in every platform the list is loaded in, and the counts were checked.
- The publisher received a written answer that names the signals behind the outcome.
When should a site come off the exclusion list?
Without written exit rules, an exclusion list only grows: a site that changed owners or cleaned up its pages stays blocked, and the list drifts away from the evidence behind it. Reinstatement deserves the same rigor as exclusion.
- A dispute re-review finds the original signals no longer present across the areas that supported the exclusion.
- The site has a new owner, confirmed through its ads.txt OWNERDOMAIN and its entries in exchanges' sellers.json files, and a fresh review finds no MFA signals.
- The original evidence no longer supports the entry, for example because the archived pages show an error or a different domain.
- The policy changed, and the entry no longer meets the written threshold for exclusion.
A reinstated site keeps its history. Mark the entry as reinstated rather than deleting it, so the next reviewer can see what was found before and what changed. If the same signals return, the earlier evidence makes the second exclusion faster to justify.
What does an exclusion list look like in practice?
Fictional example
A Canadian exclusion list for a consumer electronics brief on the Prairies
A fictional consumer electronics retailer asks its agency for English display campaigns in Alberta and Saskatchewan, aimed at shoppers in Calgary, Edmonton, Saskatoon and Regina. The agency's existing MFA exclusion list was built from US campaigns and has almost no Canadian domains.
The planner pulls the served domain report from a previous flight and finds a group of gadget and deals sites aimed at Canadian readers that took spend without being planned. Three share an OWNERDOMAIN, run stories as long slideshows and receive paid clicks from sponsored units. A second reviewer confirms each one from fresh visits. One of the three also runs a .ca version of its .com domain, so both go on the list as separate entries.
Two weeks later, one publisher writes in to say it has dropped paid traffic and changed its template. A reviewer who was not involved in the original call revisits the site, finds smaller layouts but the same slideshow pages fed by sponsored links, and upholds the exclusion with new dated evidence. The log records the outcome and the reasons sent to the publisher.
How does PlacementGraph document the sites it leaves out?
Frequently asked questions
Should an exclusion list block whole domains or single pages?
Whole domains, as a default. Made-for-advertising is a business model that runs across a site, so blocking one page leaves the rest of the site in reach. The exception is a hosting platform where each subdomain belongs to a different publisher; there, exclude the offending subdomain rather than the root.
Can a publisher see that it is on an exclusion list?
Exclusion lists live in the buyer's own platform settings, so a publisher may learn of an exclusion only when the buyer tells it or when it asks why demand stopped. That is one reason to answer disputes in writing, naming the signals behind the call.
What should happen to an entry when the site changes owner?
Open a fresh review instead of removing or keeping it automatically. Confirm the change through the site's ads.txt OWNERDOMAIN and the exchanges' sellers.json entries, keep the old evidence on file, and decide on new evidence. A new owner can keep the old template and traffic sources.
Who should be allowed to add a domain to a shared exclusion list?
Anyone can propose one, but only a reviewed and approved version should reach a buying platform. A shared list blocks the domain for every client, so the entry needs the evidence record, a second reviewer and sign off from the person who owns the list.
Sources
- Exclude placements at the account level (opens in a new tab)Google Ads Help
- ads.txt Specification Version 1.1 (opens in a new tab)IAB Tech Lab
- sellers.json specification (opens in a new tab)IAB Tech Lab
- Leading Trade Groups Define “Made For Advertising” Websites (opens in a new tab)ANA (Association of National Advertisers), September 26, 2023
- Save Pages in the Wayback Machine (opens in a new tab)Internet Archive Help Center
Researched and written by PlacementGraph Research. Read how we research, source and update these pages. Corrections: diana@placementgraph.com.