Relay detection
How relay_domain and relay_provider identify privacy forwarding services, with example domains and API usage.
Loading article…
The relay_domain field is true when an address belongs to a privacy relay or alias forwarding service: Firefox Relay, SimpleLogin, Proton Pass aliases, DuckDuckGo Email Protection, Addy.io, and similar products that hide the user's real inbox behind a proxy address.
When matched, relay_provider contains a stable slug (for example firefox_relay, simplelogin, protonmail).
Relay detection complements public domain and disposable checks. Relays are often legitimate privacy tools, not throwaway inboxes—but they complicate account recovery and support identity.
EmailGuard classifies relay addresses using a combination of known relay domains, MX and DNS signals, and continuously updated provider intelligence—similar to how we track disposable and public-mailbox hosts.
Many privacy products issue addresses on dedicated hostnames. The following are representative examples, not the full set EmailGuard recognizes:
| Domain | Provider slug |
|---|---|
mozmail.com | firefox_relay |
relay.firefox.com | firefox_relay |
simplelogin.com, slmail.me | simplelogin |
anonaddy.com | anonaddy |
addy.io | addy_io |
duck.com | duckduckgo |
passmail.net | protonmail |
New relay services appear regularly; our lists and DNS heuristics are updated without API changes on your side.
When the domain alone is inconclusive, EmailGuard inspects MX records and related DNS data (RFC 1035) for patterns associated with forwarding and alias infrastructure— including cases where the visible domain is custom but mail routes through a relay operator.
This complements domain matching and helps surface relays such as Apple Hide My Email when DNS fingerprints align with known forwarding infrastructure. Treat relay_provider as the stable label in your policy code.
Firefox Relay-style domain:
curl -sS \
-H "Authorization: Bearer YOUR_KEY" \
"https://emailguard.co/api/v1/emails/detect?email=user%40mozmail.com"{
"data": {
"email": "[email protected]",
"syntax_validation": true,
"relay_domain": true,
"relay_provider": "firefox_relay",
"public_domain": false,
"disposable": false
}
}Non-relay corporate address:
{
"data": {
"relay_domain": false,
"relay_provider": null
}
}| Scenario | Suggestion |
|---|---|
| High-trust accounts | Step-up verification or block when relay_domain is true |
| Newsletter signup | Often allow; store provider for support |
| Abuse prevention | Pair with velocity limits; relay + disposable is higher risk |
Relays are not inherently invalid under RFC 5322. The signal is for your risk and UX policy. EmailGuard does not SMTP-handshake to the relay; classification is based on address and DNS signals only.