Relay addresses are not burners

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.

{
  "email": "[email protected]",
  "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.

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 ([email protected]) 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: [email protected] and [email protected] 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 definition and the disposable email domains guide for where the two lists come from.
• Check a domain's category, relay service and disposable flag with the domain intelligence endpoint.
• If your form has been rejecting relay users, look at the free email checker with one of their addresses and update the rule that blocked them.