Apple Private Relay vs Newsletter Ad Fraud Filters

Standard invalid-traffic rules misread newsletter ad traffic. They flag requests from data-centre IP addresses and from addresses that make too many requests a minute. Apple Mail's Mail Privacy Protection fetches email images through Apple's relay network, whose exit addresses sit in Cloudflare, Fastly and other cloud ranges and are shared by thousands of readers at once. To a generic fraud filter, that looks exactly like a bot farm. When we replayed one publisher's newsletter traffic through our own rules, they flagged 11.1% of requests, and about 95% of those flags were Apple Mail. Once we recognised Apple's published relay addresses, the invalid share fell to 0.61% of 895,714 requests. The traffic that remained was the real problem: corporate email security scanners in Amazon's cloud, opening every image the moment the email arrived.

This post explains why IP-based rules break on email, how to tell a relay from a bot, and what real invalid traffic in a newsletter looks like.

Who actually requests a newsletter ad

With open-time ad serving, the ad in a newsletter is an image that is chosen when the email is opened. Every open sends one request to the ad server. The interesting question for fraud detection is: who sends it?

In practice, four kinds of client fetch newsletter images:

• Apple Mail with Mail Privacy Protection. Apple downloads remote content in the background through its own proxies, often soon after delivery, whether or not the reader opens the message. The request carries a bare Mozilla/5.0 user agent and comes from one of Apple's exit addresses, not the reader's own connection.
• Gmail's image proxy. Gmail fetches every image through Google's servers when the reader opens the email, and caches it. The request comes from Google's addresses with a GoogleImageProxy user agent.
• Email security scanners. Many corporate mail systems open each incoming message in a sandbox, loading images and following links, to check for malware before delivery.
• Everyone else. Outlook, Yahoo, Thunderbird and other clients that fetch images directly from the reader's device.

Only the last group looks like the web traffic that most fraud rules were written for. The first three all arrive from servers. The post on Gmail and Apple Mail tracking covers what each provider hides about the reader.

Why IP rules exist in the first place

Rules that flag data-centre traffic are not paranoid. Bots run on servers, and servers live in data centres. The Media Rating Council's invalid traffic guidelines class known data-centre traffic as general invalid traffic (GIVT), the kind that should be filtered routinely by list rather than detected by analysis. A request for a web ad from an Amazon or Google Cloud address is overwhelmingly likely to be automated.

Per-address rate limits have the same logic. A single household rarely produces more than a handful of ad requests a minute. An address producing hundreds is either a bot or a very large shared network.

Both rules are reasonable for websites. Both break on email, for the same reason: in email, the machine fetching the image is often acting for a real reader.

How the rules went wrong on one newsletter

Until October, our invalid-traffic classifier ran only on requests that ended in a served ad. A publisher without demand on a given day had no traffic quality data at all. One newsletter publisher sending large issues to a consumer list had hundreds of thousands of requests and an empty quality report.

So we replayed their requests from our edge logs through the existing rules, to see what the report would have said. The answer was alarming: 11.1% invalid. Looking at what had been flagged told a different story.

The data-centre rule was catching requests from Cloudflare addresses in the 104.28.x range. Our rule treated parts of the 104.* space as data-centre traffic, which is broadly true for web ads.

The rate rule was catching Fastly addresses in the 146.75.x and 140.248.x ranges, each producing more than 120 requests a minute.

The user agent on nearly all of them was a bare Mozilla/5.0, with no browser or device detail.

Those addresses belong to Apple's relay network. Apple publishes the list of exit addresses its relay uses, as a CSV file linked from its guide to preparing networks for iCloud Private Relay, so that websites and geolocation providers can recognise relay traffic. When we checked the flagged addresses against that list, they were on it. Apple Mail's background image fetches were leaving through the same exit addresses, run by Cloudflare, Fastly and other providers, and thousands of readers shared each one.

So the "bot farm" was Apple Mail doing what it does for every user with Mail Privacy Protection switched on. The rate rule fired because one exit address was carrying the fetches of thousands of mailboxes in the minutes after a send. The data-centre rule fired because the exit addresses are in cloud ranges. Neither rule was wrong about the address. Both were wrong about what was behind it.

The replay, with Apple's list applied

We loaded Apple's published list and replayed the same publisher's traffic over six days in October: 895,714 requests. This time any request from an Apple relay address was classified as Apple relay traffic rather than run through the data-centre and rate rules.

Category                       Share of 895,714 requests
─────────────────────────────  ─────────────────────────
Apple relay (Mail Privacy)     54.6%
Gmail image proxy              39.0%
Other valid clients             5.8%
Invalid                         0.61%
   of which: cloud addresses    5,320 requests
             bot user agents      178 requests
Rate anomalies                  none

Three things in that table are worth dwelling on.

The invalid share fell eighteen-fold, from 11.1% to 0.61%, without loosening any rule for anyone else. A request from a genuine data-centre address that is not on Apple's list is still flagged.

93.6% of requests came from two proxies (54.6% Apple relay plus 39.0% Gmail). For this newsletter, fewer than six requests in a hundred came directly from a reader's own device. That is unusual for a website and normal for a consumer newsletter, and it is why rules tuned on web traffic misfire so badly here.

"Valid" does not mean "a person read it". An Apple relay fetch is a machine acting on behalf of a real mailbox. It is not fraud: the email reached a real subscriber who chose to receive it. But it is also not proof of attention, because Apple fetches images whether or not the reader opens the message. We classify these requests as valid and label them separately, so reports can show them apart from opens that came from the reader's device. The ad fatigue post explains how those labelled impressions affect exposure counts.

What changed in our classifier

The change itself is small. The care is in keeping it current and in failing safely.

• Apple's list, loaded and refreshed. The file we load has about 285,000 rows. Merged, that is 41,747 IPv4 ranges plus 243,359 IPv6 prefixes, held in memory and searched in microseconds. A weekly job downloads a fresh copy and refuses it if it looks wrong: fewer than 100,000 rows, or missing ranges that are known to be Apple's. The ad server re-reads the file when it changes.
• Relay first, then the other rules. A known bot user agent is still flagged first. After that, a request from a relay address is classified as valid relay traffic and is excluded from the data-centre rule and from the per-address rate count.
• Fail to the old behaviour. If the file is missing or empty, the classifier behaves exactly as it did before. A broken download can never make every request look valid.
• Every request, not only filled ones. Request quality is now counted on every request that reaches the ad decision, whether or not an ad is served. A publisher with no demand still gets a quality reading, which is when they need it most, because it is part of how buyers judge their inventory.

The same exemption fixed a quieter problem on the click side. Our data-centre check is shared with click classification, so clicks from Apple relay addresses had been at risk of the same misreading. Excluding relay addresses from the data-centre rule removed it everywhere at once.

Gmail's proxy is a different case

The Gmail image proxy produced 39% of requests in the replay, and it behaves differently from Apple's relay in ways that matter for classification.

Gmail fetches an image when the reader opens the email, not in advance, and then caches it. So a Gmail proxy request is usually a sign that someone really opened the message, which makes it a stronger signal of attention than an Apple relay fetch. Depending on the caching headers an ad server sends, a repeat open by the same reader may be answered from Google's cache and never reach the ad server, so Gmail opens tend to be undercounted where Apple opens are overcounted.

What Gmail hides is the reader's location and device, because every request comes from Google's own addresses. That is a targeting problem rather than a fraud problem. A campaign targeted at one country cannot know where a Gmail reader is, and a serving rule has to decide whether to show the ad anyway or skip Gmail readers entirely. The audience targeting guide covers how that choice affects reach, and the open-time serving explainer covers why Gmail's caching and Apple's prefetching shape which ad a reader sees.

For classification, the rule is simple: recognise Google's proxy by its addresses and user agent, and never send it through the data-centre rule. Google's servers are a data centre. The reader behind them is not.

What real invalid traffic looks like in a newsletter

The most useful thing the new count did was show us what was left once Apple was out of the way.

On the first send after we switched it on, the same publisher's newsletter produced 69,656 checked requests during the day, of which 1,341 were invalid: 1.93%. Of those, 1,320 came from data-centre addresses and 21 had bot user agents.

The data-centre requests had a clear signature:

Requests from cloud addresses           1,441
Distinct addresses                        676
Provider and region                       Amazon Web Services, us-west-2
User agent                                desktop Chrome
Requests in the minute the send went out  1,073

Hundreds of cloud addresses, each pretending to be a desktop browser, fetching the ad image in the same minute the newsletter left the publisher's sending platform. No reader opens an email that fast. This is the pattern of email security scanners: corporate mail gateways that open every incoming message, load its images and check its links before passing it to the recipient.

These requests are invalid for advertising purposes, and correctly flagged. They are not fraud by the publisher. They are a side effect of having business readers whose employers scan their mail. A newsletter with a professional audience will always produce some. What matters is that they are recognised and not counted as readers, and that the share stays small and explicable. A sudden jump would be a reason to look harder.

The same scanners also follow links, which is why newsletter click reports need the same scrutiny. Our post on bot and scanner clicks covers how to recognise them on the click side.

A related trap: trusting the wrong address

IP-based rules are only as good as the address they look at, and getting the right address is less obvious than it sounds. Requests reach an ad server through load balancers and proxies, which pass the original client address along in a header called X-Forwarded-For. That header is a list, and anyone can write the first entry themselves.

Until October our ad server read the first entry. A client could put any address it liked there and pass straight through the data-centre rule. We changed it to take the right-most address that was not added by our own infrastructure, which is the one the client cannot forge, and checked it on the live system the same day. If you evaluate any ad platform's traffic quality, it is worth asking which address its rules look at. A sophisticated classifier fed a forgeable address is not sophisticated.

What changes in reports, and what does not

A classifier change like this is easy to misread as a change to the numbers buyers pay on, so it is worth being precise about what moved.

The new count sits alongside the existing serving ledger. It records the quality of every request that reaches an ad decision, in categories: Apple relay, Gmail proxy, other valid, data-centre, bot user agent and rate anomaly. It is visible to our staff first, so the numbers can be watched for a while before publishers see them. It does not alter delivery records, daily summaries or how a served impression is counted.

The relay exemption does reach the main classifier, because leaving it out would mean the main classifier kept misreading the same readers. A served impression from an Apple relay address is now classified as valid relay traffic rather than as data-centre traffic.

For advertisers, the practical effect is fewer impressions wrongly marked invalid on newsletters with many Apple Mail readers, and a clearer view of the real scanner share. The advertiser reporting guide explains what each report shows. For publishers, it means a quality reading that reflects their audience rather than their readers' choice of email app, which matters when buyers compare newsletters against the CPM benchmarks.

Why this matters to publishers

A newsletter publisher looking for advertisers is judged partly on traffic quality, and generic tools judge email traffic badly. A report showing 11% invalid traffic will cost a publisher deals, even if almost all of that 11% is their own Apple Mail readers.

So ask any ad network or verification vendor three questions. How do you classify Apple Mail's relay traffic? Do you use Apple's published egress list, and how often is it refreshed? And what share of my requests do you flag, broken down by reason? A partner who cannot answer the first two will misclassify most of your audience. The breakdown matters because "invalid" is not one thing: scanners, bot user agents and genuine anomalies need different responses.

Publishers can also help themselves. Keep your sending platform's link tracking and the ad tag on separate, recognisable domains, so scanner behaviour on one does not contaminate the other. Avoid putting the ad in a position that loads for previews and archive copies, as described in the post on blank ad slots. And if your audience is mostly business readers, expect a scanner share of a few percent and explain it to buyers before they find it. The ad unit best practices cover setup.

Why this matters to advertisers

For advertisers the risk runs the other way. A tool that misreads relay traffic as invalid may also be producing the opposite error somewhere else, and an advertiser who sees a low invalid rate on one platform and a high one on another may be comparing classifiers rather than audiences.

Ask how impressions from Apple Mail and Gmail are counted and labelled. Ask what share of impressions on a newsletter came from each proxy. A consumer newsletter where almost all impressions are proxy fetches is normal. One where a large share comes from cloud addresses with browser user agents is a newsletter with a scanner problem, or something worse. And judge results on outcomes that machines cannot produce: purchases, sign-ups and qualified leads. The guide to tracking newsletter ad ROI covers how, and the publisher vetting checklist lists what to ask before buying.

A checklist for anyone classifying email ad traffic

1. Recognise Apple relay addresses from Apple's own published list, refreshed at least weekly, before applying data-centre or rate rules.
2. Recognise Gmail's image proxy by its addresses and user agent, and treat it as a proxy, not a bot.
3. Classify every request, not only filled ones, so publishers without demand still see their quality.
4. Label proxy impressions separately from direct opens. Valid is not the same as read.
5. Look for the scanner signature: many cloud addresses, desktop browser user agents, a burst in the first minute after the send.
6. Take the client address from the right-most hop you did not add yourself, never the first.
7. Fail safely: if a list cannot be loaded, fall back to the old rules rather than marking everything valid.
8. Report invalid traffic by reason, so a publisher can tell scanners from bots from anomalies.

The broader lesson

Invalid-traffic rules encode assumptions about what normal traffic looks like, and those assumptions came from websites. Email inverts several of them. Most legitimate requests come from servers, not devices. Thousands of readers share one address. The fastest requests after a send are the least human. A classifier that does not know this will penalise publishers for their own audience and miss the automated traffic that matters.

Our invalid traffic policy sets out how MailAdx classifies and handles invalid traffic. Publishers can read how the ad server and reporting work, and how to prove they are authorised to sell their inventory in our guide to ads.txt and sellers.json for newsletters. Advertisers can see how buying works on the advertiser page, and anyone can create an account.

Frequently asked questions

Is Apple Mail Privacy Protection traffic invalid traffic?

It should not be classed as fraud. Apple fetches images for a real subscriber who chose to receive the email, through its own relay network. But the fetch happens whether or not the reader opens the message, so it is not proof of attention. The accurate treatment is to classify it as valid and label it separately from opens that come from the reader's own device.

Why do fraud filters flag Apple Mail readers?

Apple's relay exit addresses sit in cloud provider ranges, such as Cloudflare and Fastly, and each is shared by thousands of readers. Generic rules that flag data-centre addresses, or addresses making many requests a minute, read that as bot traffic. Checking addresses against Apple's published egress list before applying those rules prevents the misclassification.

Where can I find Apple's Private Relay IP addresses?

Apple publishes them as a CSV file of IP ranges and locations, linked from its developer guide to preparing networks and servers for iCloud Private Relay. The list changes, so anyone using it should refresh it regularly and check each download looks complete before loading it.

What is a normal invalid traffic rate for a newsletter?

With proxies classified correctly, low single digits. On one consumer newsletter we measured 0.61% over six days, and 1.93% on a single send day, almost all of it corporate email scanners. A newsletter with many business readers will see more scanner traffic than a consumer one. A large or sudden increase is worth investigating.

How can I tell email security scanners from readers?

Scanners usually come from cloud provider addresses, present a desktop browser user agent, and fetch images and links within the first minute or two after delivery, often from hundreds of different addresses at once. Readers open over hours and days, mostly through Apple's and Gmail's proxies or their own devices.

Does Gmail's image proxy count as a bot?

No. Gmail fetches images through its proxy when a reader opens the email, so a Gmail proxy request usually reflects a real open, though the reader's location and device are hidden. It should be recognised as a proxy and counted as valid, not run through data-centre rules.

Why does it matter which IP address an ad server uses?

Because the original client address is passed in a header that the client can partly write itself. An ad server that reads the first address in that header can be fooled by any client that writes a residential address there. The trustworthy address is the right-most one that was not added by the ad server's own infrastructure.