Ads.txt vs. Ads.cert: How They Work Together to Fight Ad Fraud

Programmatic ad buying faces persistent pressure from ad fraud — fraudulent representation of impressions and clicks, and manipulation of bid requests for financial gain. Ads.txt emerged as a partial countermeasure, and ads.cert was developed to address the gaps that ads.txt leaves open. Understanding how these two mechanisms relate to each other matters because, contrary to a common assumption, ads.cert does not replace ads.txt — they work as complements.

Ads.txt gives media buyers confidence that the inventory being sold comes from the site listed in the bid request. Ads.cert adds a deeper layer of authentication by cryptographically signing those bid requests. Together they address different points of failure in the programmatic supply chain.

How Ads.txt Works

Ads.txt was designed to tackle two specific fraud patterns:

• Domain spoofing: Fraudsters disguise themselves as reputable, premium publishers and sell inventory — sometimes at below-market prices — that they have no right to sell.
• Illegitimate inventory arbitrage: Unauthorized intermediaries resell publisher inventory with a markup, reducing the revenue that reaches the actual publisher. Knowing the seller ID and verifying their authorization helps partially contain arbitrage, though resellers can still buy and re-sell inventory under a different seller ID.

The mechanics are straightforward. Ads.txt is a plain-text file hosted on a publisher's domain that declares a whitelist of companies authorized to sell that publisher's digital inventory. Buyers and DSPs can crawl this file to validate that the SSP or ad exchange offering a given impression actually has the publisher's authorization.

The fundamental limitation of ads.txt, however, is adoption. According to Ad Ops Insider, only 44% of ad-supported websites had adopted ads.txt at the time of writing. With the majority of publishers not yet on board, there is little structural incentive for buyers to restrict purchases exclusively to ads.txt-verified sellers.

The Vulnerability in Ads.txt

Ads.txt is not fully bulletproof. Once fraudsters understood how it worked, some pivoted to a social-engineering approach: contacting publishers directly — sometimes through what appear to be legitimate sales people — and convincing them to add fraudulent or unauthorized entities to their ads.txt files. If that tactic succeeds, the very mechanism designed to exclude bad actors ends up explicitly authorizing them.

As SmartAdServer documented, this kind of manipulation effectively defeats ads.txt's purpose. The volume and velocity of programmatic transactions make it practically impossible to monitor every ads.txt entry across the ecosystem with consistent vigilance.

How Ads.cert Works

Ads.cert addresses a different vulnerability: the integrity of the bid request itself. In an open exchange, buyers make decisions based on data signals about the publisher's inventory. Ads.cert cryptographically signs that data, making it tamper-evident. The information validated by ads.cert includes:

• Publisher's domain
• User's location
• User's IP address
• User's device
• Ad position on the page
• Impression type
• Other bid-request variables

The signing mechanism relies on a public/private key pair generated by the publisher:

• The public key is disseminated widely so that buyers and intermediaries can use it to verify the source of a bid request.
• The private key is held exclusively by the publisher and never shared.

This produces two security properties:

• Authentication: The public key verifies that the entity holding the private key actually originated the bid request. If the key pair doesn't match, the request can be rejected.
• Encryption: Only the private-key holder can decrypt the bid request and modify it. Any tampering downstream becomes detectable.

What Ads.cert Fixes That Ads.txt Cannot

Ads.txt verifies the seller — it confirms that a given SSP or exchange is authorized to sell a publisher's inventory. What it cannot confirm is whether the inventory itself is authentic. To use a retail analogy: you can be standing in an authorized store, but that authorization doesn't guarantee the products on the shelves are genuine.

Two specific gaps remain even with ads.txt in place:

1. Inventory authenticity is unverified. A confirmed, whitelisted seller can still be serving fraudulent impressions without ads.txt catching it.
2. Counterfeit sites can copy ads.txt files. A fake website mimicking a legitimate publisher can reproduce that publisher's ads.txt verbatim and post it as its own, potentially deceiving some DSPs.

Ads.cert closes both of these gaps by binding the bid request to cryptographic proof of origin. A counterfeit site cannot replicate the private key, so even if it copies the ads.txt file, it cannot produce a validly signed bid request.

The Challenges Facing Ads.cert

The same adoption problem that constrains ads.txt also constrains ads.cert. At the time of writing, ads.cert was still in active development, tied to the evolution of OpenRTB 3.0 — itself at the draft-for-public-comment stage (latest update as of publication: September 2017). OpenRTB 3.0 also lacks backward compatibility with earlier versions, which means industry-wide transition will be gradual rather than sudden.

Neither standard delivers its full value in isolation. Ads.txt alone can be gamed through social engineering and file spoofing. Ads.cert alone does not address which sellers are authorized. The combination of both — a verified seller list backed by cryptographically authenticated bid requests — represents the most complete available defence against domain spoofing and fraudulent inventory arbitrage. Broad adoption across publishers, SSPs, and DSPs remains the prerequisite for that potential to be realized.