# When two weak signals coincide

A burner mailbox is common. A datacenter address is common. Both on one signup is not. The four pairing comparisons, and the rule that keeps them honest.

Date: 2026-09-10

Most of the signals a single lookup produces are weak on their own, and the honest ones say so. A disposable email address is used by plenty of people who simply do not want another newsletter. A datacenter IP is where a corporate VPN, a server-side integration and a great deal of ordinary traffic comes from. A free consumer mailbox is what most of the world uses. Acting on any one of them alone means rejecting real customers at a rate you will not enjoy explaining.

Two of them together is a different fact. That is what the pairing comparisons in a consistency report are for, and this guide is about the four of them, the one rule they all follow, and how to act on them without building a machine that punishes ordinary people.

## The four pairings

| `comparison` | Fields | What the pairing catches |
| --- | --- | --- |
| `email_ip_disposable_datacenter` | `email.disposable` ↔ `ip.is_datacenter` | A burner mailbox arriving from hosting rather than a consumer network — the shape of a scripted signup. |
| `email_ip_disposable_anonymous` | `email.disposable` ↔ `ip.is_anonymous` | A burner mailbox arriving over a VPN, a proxy or Tor. |
| `email_address_free_provider_mail_drop` | `email.free_provider` ↔ `address.is_mail_drop` | A free consumer mailbox given alongside an address at a commercial mail-receiving agency. |
| `email_phone_disposable` | `email.disposable` ↔ `phone.is_disposable` | Both contact details on disposable lists: neither can receive anything for long. |

Every one of them pairs a field from one product with a field from another. None of them needs a new dataset, which is why the analysis is free: each half was computed by the product that owns it, and the pairing is arithmetic over the two.

## The rule: a pairing holds only when both sides are true

This is the whole logic, and it is deliberately narrow.

- Both sides `true` → `result: agree`, and the flag is raised.
- Either side `false` → `result: not_compared`, no flag. Two known-false fields are not a disagreement; they are simply not the thing being looked for.
- Either side `null` → `result: not_compared` with `withheld: missing_value`. A null means "not evaluated", never "no", so nothing is inferred from it.

That means the flags are one-directional. `email_ip_disposable_datacenter` fires on a burner from a datacenter and stays silent on everything else — a normal mailbox from a datacenter, a burner from a home connection, a normal mailbox from a home connection. There is no negative flag, no "these look fine" row, and no partial credit. If you want to act on either half by itself, read that half on its own signal block; the pairing is not the place for it.

## What each pairing is actually saying

**A burner from hosting.** A disposable mailbox is a person avoiding a mailing list. A datacenter address is a server. A disposable mailbox *typed at a server* is usually a script working through a signup form, and it is one of the cleanest tells there is. Read `hosting_provider` and `asn_type` on the IP block beside it: a signup from a cloud provider's own range and a signup from a corporate egress deserve different treatment.

**A burner over an anonymous network.** Same idea, weaker. Anonymity is a legitimate consumer choice — iCloud Private Relay is on by default in Safari for iCloud+ subscribers — so this one carries less on its own than the datacenter pairing. It earns its place when it lands beside something else.

**A free mailbox with a mail-drop address.** A mail drop is an address at a business that receives post on other people's behalf, detected from operators' published branch lists and the number of companies registered at the address. It is a heuristic about a *place*, never a judgement about a person: plenty of small businesses genuinely use one, and plenty of real people live at an address that also hosts a mailbox service. Paired with a free consumer mailbox it is worth a second look at a "company" that has given you neither a business domain nor a place anyone works. On its own it is nothing at all.

**Two disposable contact details.** A disposable email and a disposable number mean there is no way to reach this person tomorrow. For anything involving a one-time code, a free trial or a refund, that is the substantive fact: not that they are dishonest, but that the contact details will not be there when you need them. The phone half is covered at length in [stop OTP abuse with block data and disposable numbers](/guides/stop-otp-abuse-with-block-data-and-disposable-numbers).

## Reading them together with the rest

The pairings sit in the same `comparisons` array as the country comparisons, and each one that fires adds its flag to `flags` in comparison order. That is all that happens. There is no score, no risk level and no recommendation on top — the flags are the whole output.

The practical rule that falls out of it is a count, not a weighting:

- **One flag is a look, not a decision.** Almost every single flag has an innocent reading, and the innocent reading is usually the right one.
- **Two unrelated flags on one signup is a different situation.** A burner from a datacenter *and* a phone number nobody can be reached on is not a coincidence you have to argue about.
- **Route, do not block.** A manual queue or a second factor costs a message. A wrong block costs a customer, and they never tell you.
- **Log the rows, not a verdict.** Both sides of every comparison are quoted so that a person reviewing the case can see the actual values. Store those.

## Adding a business identifier

If the signup claims to be a company, a consistency call can carry the business identifier too, and two comparisons of its own come back: the registered country against the address's country, and the registered legal name against the organisation written on the address. Neither is a pairing, and neither feeds `country_agreement` — a Delaware company with a London office is ordinary. They are named differences, quoted on both sides, exactly like the rest.

The register answers behind them have their own guides: [when two registers disagree about a company](/guides/when-two-registers-disagree-about-a-company) and [a LEI check digit is a typing check](/guides/a-lei-check-digit-is-a-typing-check).

## What the pairings do not tell you

- **Intent.** Every flag here names a combination of facts about contact details. None of them says why, and none of them is evidence of fraud on its own.
- **That the absence of a flag is a clean signup.** These four pairings cover what two signals say about each other. Each product's own risk signals live on its own block and are not repeated in the consistency report.
- **Anything about a person from a place.** A mail drop is a fact about an address, and nothing in any Spaw product says who lives or works anywhere.
- **A threshold.** There is none, by design, and the endpoint will not grow one. Where the line falls is a decision about your own customers, and you are the only one in a position to make it.

## What to do next

- Read [how to read a consistency report](/guides/how-to-read-a-consistency-report) for the other six comparisons and the response shape.
- Read the [cross-signal consistency guide](/docs/cross-signal-consistency) for every field and every withholding rule.
- Read the [disposable_email_from_datacenter_ip reference page](/docs/reasons/disposable_email_from_datacenter_ip) for the exact wording and an example.
- Handle the phone half properly with [stop OTP abuse with block data and disposable numbers](/guides/stop-otp-abuse-with-block-data-and-disposable-numbers).

Reference: https://spaw.co/guides/when-two-weak-signals-coincide