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. In August 2026 the upstream list carried relay.firefox.com, addy.io and 33mail.com next to the ten-minute mailbox providers, and on 7 October 2026 it carried mailer.me, one of Addy.io's alias domains. 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. A Firefox Relay alias typically answers like this:

{
  "email": "[email protected]",
  "deliverable": "risky",
  "reason": "catch_all",
  "risk_score": 35,
  "risk_level": "medium",
  "disposable": false,
  "is_relay": true,
  "relay_service": "Firefox Relay",
  "domain_category": "relay",
  "mailbox_exists": null,
  "catch_all": true,
  "mailbox_confidence": 50,
  "risk_signals": [
    { "signal": "catch_all", "weight": 30, "dataset": "mailbox-smtp" },
    { "signal": "relay", "weight": 5, "dataset": "forwarding-services" }
  ]
}

Four fields carry the relay answer. is_relay is true, relay_service names the service, domain_category is relay, and disposable is forced to false even when the domain sits on the public list. The mailbox handshake still runs, as it does for any domain that is not a burner. Firefox Relay receives its mail on Amazon SES and decides whether an alias exists only after it has accepted the message, so the handshake is accepted for any alias, live or made up. That is why the answer is risky with reason: catch_all, catch_all: true and mailbox_exists: null: no handshake can confirm one alias on a server that accepts them all. mailbox_confidence stays at 50 for the same reason. The domain's DMARC, SPF and age describe the relay operator, and an alias's name, whether the relay generated it or its owner chose it, says nothing about whether it exists, so only evidence against the alias lowers it: most reported sends to the domain bouncing, or a plus-tag. Where a relay's servers refuse an unknown alias during the handshake, a live alias can answer deliverable with mailbox_exists: true.

The relay itself adds 5 to the score, for the withheld identity; the other 30 in this answer is the catch-all weight. 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.

Since 7 October 2026 the list also carries Brave Email Aliases (bravealias.com), the alias feature built into the Brave browser, and ExpressMailGuard (clivaro.io), ExpressVPN's alias service, along with newer alias domains of Addy.io (mailer.me and addymail.com) and SimpleLogin (silomails.com and slmails.com). Since 8 October it also carries Surfshark Alternative ID's alias domains, IronVest Masked Email (opayq.com, with Abine's older Blur and MaskMe domains), Erine.email, Alias Email (bumpmail.io) and Guard Email (m.guardemail.com), and more shared domains of Addy.io (4wrd.cc, addy.to) and 33Mail (33m.co). Cloaked's identity domains are not on it: a Cloaked identity keeps its mail in Cloaked's own inbox unless its owner turns forwarding on. Brave receives its alias mail on Amazon SES too and accepts every address at bravealias.com, so a Brave alias typically answers like the Firefox Relay example above: risky, reason: catch_all, a score of 35.

Mailbox providers that also hand out aliases

The list holds only domains where every address is an alias. A mailbox provider that also offers aliases stays off it, because a domain-level flag would mislabel every real mailbox on that domain. Apple and Proton are the two that matter:

• Proton Pass hands out aliases on its own domains, passmail.net, passmail.com, passinbox.com and passfwd.com. Spaw flags those and pass2mail.com, which Proton registered for Pass too, so they answer is_relay: true with relay_service: "Proton Pass". Proton Mail's mailbox domains (proton.me, protonmail.com, protonmail.ch, pm.me) answer is_relay: false, free_provider: true and domain_category: "webmail".
• Sign in with Apple gives an app a random address when the user hides their own, and Apple forwards only mail from the domains and addresses the app registered with Apple. Those addresses have been issued on privaterelay.appleid.com, and Apple said in August 2026 that new ones will be issued on private.icloud.com from later that year, while existing ones keep working. Both domains answer is_relay: true with relay_service: "Sign in with Apple private relay". The flag belongs to the name private.icloud.com alone, so it never reaches icloud.com.
• Hide My Email in iCloud+ puts its aliases on icloud.com, next to ordinary iCloud mailboxes, and nothing in the address marks one. Apple's August 2026 announcement keeps them there. Spaw cannot tell them apart, so every icloud.com, me.com and mac.com address answers is_relay: false and domain_category: "webmail", alias or not.

Until 2 October 2026 the list carried icloud.com, me.com, mac.com and Proton Mail's four domains, so every ordinary iCloud and Proton Mail address answered as a relay and carried the relay weight. They now answer as the free mailboxes they are.

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. A confidence floor above 50 holds relay aliases too, on any server that accepts every address, because their mailbox_confidence stays at 50; keep a floor at 50 or below if relays must pass.

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.