# Relay addresses are not burners

Firefox Relay, SimpleLogin, Addy.io and DuckDuckGo aliases sit on disposable lists but deliver to a real mailbox. What Spaw answers, and how to treat them.

Date: 2026-09-13

A relay address is an alias handed out by a forwarding service such as Firefox Relay, SimpleLogin, Addy.io or DuckDuckGo Email Protection. Mail sent to the alias is forwarded to the person's real mailbox, which the alias hides, and the person can turn the alias off if it starts receiving mail they did not ask for. It is the opposite of a burner: a burner exists for ten minutes so its owner can get past a form, a relay alias is kept for years so its owner can keep using your product without giving out their real address.

## Why relays end up on disposable lists

The open disposable-domain lists that every verifier uses, Spaw included, collect domains that hand out addresses on demand. A relay service does exactly that. `relay.firefox.com`, `addy.io` and `33mail.com` are all on the upstream list today, next to the ten-minute mailbox providers, because a list maintained by volunteers answers the marketer's question, "is this a throwaway?", and not the question a signup form is asking, which is "will this person still read this in a year?"

Until September 2026 Spaw answered those domains from the list and reported them as disposable, with the 80-point weight and the `disposable` reason that a burner earns. That was wrong in a way that hurt exactly the users a privacy-conscious product wants: the person who reads the privacy policy, takes it seriously, and uses an alias so that a breach at one company cannot follow them to the next.

## What Spaw answers for a relay address

The relay check now runs before the disposable list, and a relay is never disposable.

```json
{
  "email": "quiet.fox.42@mozmail.com",
  "deliverable": "deliverable",
  "reason": null,
  "risk_score": 5,
  "risk_level": "low",
  "disposable": false,
  "is_relay": true,
  "relay_service": "Firefox Relay",
  "domain_category": "relay",
  "risk_signals": [{ "signal": "relay", "weight": 5, "dataset": "forwarding-services" }]
}
```

Four fields carry the answer. `is_relay` is `true`, `relay_service` names the service, `domain_category` is `relay`, and `disposable` is forced to `false` even though the domain sits on the public list. The mailbox handshake still runs, because the relay's mail servers accept mail like any other, so `mailbox_exists` can be `true` and the verdict can be `deliverable`.

The score carries 5 for the withheld identity and nothing else. Five points is a statement of fact rather than a penalty: you do not know who the person is, and if a downstream fraud check depends on matching the address to a name, it will not match. It is deliberately far from the disposable weight, and it never moves the address out of the low band on its own.

The bundled list of relay services is curated by hand and carries the well-known forwarding services with their per-account subdomains, so an alias at a subdomain a service hands out to one user is matched by the service's root. A service Spaw does not know reads as whatever the disposable list says about it, which is why the list is worth extending when a customer names one.

## Why a relay deserves to be let in

Three practical reasons, all about outcomes.

**The mailbox is real and read.** A relay forwards to a mailbox the person checks daily. Bounce rates on relay addresses are ordinary, and engagement is ordinary, because the person asked for the mail.

**The person is telling you something.** Someone who used an alias for your form is someone who intends to keep the account and cares about their data. Refusing them at the door selects against your most careful users. Firefox Relay, SimpleLogin and DuckDuckGo all publish the same explanation of the product: the alias exists so that the person can keep using services without exposing the real address, and can block a sender that misbehaves.

**Blocking them does not stop abuse.** A fraud ring does not need a relay; it has burner domains, which Spaw does report as disposable, and it has the same address at many providers, which the `widely_seen` signal catches when three or more accounts see it in a day. The relay flag is a fact about privacy, not about intent.

## When the withheld identity matters

There are contexts where the alias is a genuine limitation, and the field exists so you can handle them without treating the person as a burner.

| Context | Treatment |
| --- | --- |
| Newsletter, product updates, account mail | Accept. Nothing changes. |
| Signup with a free trial or credit | Accept, and count the trial against the account rather than the address; a relay user can make aliases as easily as anyone can make Gmail accounts. |
| Identity or age checks that match the address to a name | Treat `is_relay: true` as "no match possible" and fall back to the check you would use for any unmatched address. |
| Abuse investigations | Read `relay_service`: the service's own abuse process can reach the person, which is more than a burner offers. |
| Deduplication | Do not merge on the relay domain; every alias is a different person's choice, and one person may hold several. |

If your policy has to treat aliases differently, the sending policy does it without code. The `relay` signal can be added to `block_signals`, and every relay answer then carries `ok_to_send: false` with `blocked_by: "relay"`. The default policy does not block it, and this guide's advice is that it should not.

## How this differs from a plus-tag alias

A plus-tag (`mia+shop@acme.com`) is a label on a mailbox you can already see. Spaw folds it away in `normalized_email`, reports `is_alias: true`, and adds 5 points for it, because a plus-tag is the favourite tool of people farming signup bonuses. A relay alias is the reverse: you cannot see the mailbox at all. The two look alike on a list, since both are one person under several addresses, but the plus-tag hides nothing and the relay hides everything, and the two fields let you tell them apart.

Gmail's dot-insensitivity is a third thing again: `m.ia@gmail.com` and `mia@gmail.com` are one mailbox, and Spaw folds the dots away in `normalized_email` too, with no weight at all.

## What to do next

- Read the [relay address](/glossary/relay-address) definition and the [disposable email domains guide](/guides/disposable-email-domains) for where the two lists come from.
- Check a domain's category, relay service and disposable flag with the [domain intelligence endpoint](/docs/api/domain-intelligence).
- If your form has been rejecting relay users, look at the [free email checker](/tools/email-checker) with one of their addresses and update the rule that blocked them.

Reference: https://spaw.co/guides/relay-addresses-are-not-burners