Protection rules

Allow trusted domains, block known abuse, and review newly registered domains.

Protection rules adapt SignupScore to your customers and your abuse patterns. Manage them in Dashboard → Protection.

Every policy below answers one question: should this address get in? Here is what each one does to a real signup.

Address	Policy	Default	Result
`sam@partner.com` (your rule)	Exact domain rule	—	`allow`, always, beats everything below
`bot@x.duckdns.org`	Free and dynamic DNS	On	`block`
`hi@parkedbrand.com`	Cannot receive email	On	`block`
`x8f2@duck.com`	Email relays	Off	`allow`, flagged `privacy_relay`
`throwaway123@gmail.com`	Junk usernames	Off	`review` until you turn it on
`founder@startup.io` (3 days)	New domain	Off	`allow` until you turn it on

Exact domain rules

Your rule always wins. Nothing below can override it.

A rule means exactly what you type:

You type	It matches
`example.com`	`example.com` and every subdomain
`customer.duckdns.org`	only that hostname, not the rest of `duckdns.org`

That second row is the escape hatch. One real customer on a blocked zone gets an allow rule for their hostname, and the zone stays blocked for everyone else.

Free and dynamic-DNS domains

On by default. Blocks duckdns.org, pp.ua, No-IP and similar. Reason code INFRASTRUCTURE_ZONE, signal dynamic_dns.

Anyone can take a subdomain of these for free, in seconds, without owning anything. Real mailboxes almost never live there; self-hosted burner mail does.

The whole zone goes, subdomains and the zone name itself. bot@x.duckdns.org and owner@duckdns.org both stop here.

Blocked

{
"action": "block",
"primary_reason": "INFRASTRUCTURE_ZONE"
}

Got a genuine customer on one? Allow their exact hostname, like customer.duckdns.org.

Email relays and hidden addresses

Off by default. Covers Apple Hide My Email, Firefox Relay, DuckDuckGo, SimpleLogin and Proton Pass. Off, every check still flags them:

x8f2k9@duck.com, policy off

{
"action": "allow",
"signals": { "privacy_relay": true }
}

Turn it on and the same address returns block.

It is off by default because a relay address is a real mailbox that a real person reads. Blocking one turns away a customer for being private. Turn it on when that privacy costs you something you can name: trials farmed with a fresh alias each time, or chargebacks you cannot trace to a person.

Domains that cannot receive email

On by default. Blocks a domain that provably has no mail server and was registered more than 14 days ago. Reason code DOMAIN_UNDELIVERABLE.

The 14 days are fixed, not a setting. A brand-new domain may simply be mid-setup, so it is skipped rather than refused for it. The policy is also skipped entirely when the mail lookup fails, when the registration date is unknown, or when you send check_mx: false.

Do not confuse this with the new-domain policy above. There, a young domain is the reason to refuse. Here, being young is what earns an exemption.

New-domain policy

Off by default. Send recently registered domains to review or block; you pick the age and the action.

A domain registered three days ago is not proof of anything, which is why the useful setting is usually review rather than block. Review that signup, verify the email, hold the trial credits until they confirm.

Junk usernames

Off by default. This is about the username, the part before the @, not the domain. Disposable domains are already blocked separately.

Turns review into block when the username says outright that it is throwaway. Only action changes; these are flagged either way.

Username	Result	Why
`throwaway123@`	`block`	word, then digits
`tempmail@`	`block`	word, then a mailbox noun
`junk1987@`	no match	a word plus a birth year
`junk.maria@`	no match	`Junk` is a surname
`sample.accounting@`	no match	ordinary word starting with one
`test+work@`	no match	someone tagging their own mail

Custom and business domains are skipped. There, test@ and noreply@ are ordinary mailboxes.

Email memory

Off by default. Turn it on in Dashboard → Protection → Email memory. Nothing is recorded until you do. Once on, mailbox_alias reports that one mailbox reached you under two different spellings, because alias forms collapse to one address: f.o.o+trial2@gmail.com and foo@gmail.com are the same mailbox.

Sending the identical address again reports false. That is a retry, and your own records already cover it.

It reports a prior check of another spelling, not that an account exists. Pair it with your users table, which is the one thing that knows whether they already signed up.

It does not block on its own

Unlike every other rule on this page, turning this on refuses nothing. It adds mailbox_alias to the response and leaves action exactly as your other rules decided it. An alias signup still gets in unless you read the field yourself:

typescript

// Save normalized_email as canonical_email on signup, unique index on it,
// and query that column. Your table holds what the person typed.
if (result.signals.mailbox_alias) {
const existing = await findUserByCanonicalEmail(result.signals.normalized_email);
if (existing) return 'block';   // already signed up, second trial
}
return result.action;             // otherwise your other rules decide

Only an unreadable fingerprint is stored, never the address. See Privacy and retention.

Precedence

First match wins, top to bottom:

Your exact allow or block rule
Free and dynamic-DNS domains
Email relays
Domains that cannot receive email
New-domain policy
Junk usernames
SignupScore's built-in email and domain checks

Worked example, with relay blocking on and an allow rule for duck.com:

Address	Stops at	Result
`a@duck.com`	1, your allow rule	`allow`
`b@mozmail.com`	3, relays	`block`
`c@x.duckdns.org`	2, dynamic DNS	`block`
`d@stripe.com`	7, built-in checks	`allow`

Unknown domain age

SignupScore cannot confirm a registration date for every domain. When the date is unknown, the age-based policies are skipped. A signup is never blocked just because age data is missing.