> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sellauth.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Blacklist and Whitelist

> Block buyers and connection types you do not want, allow exceptions to broad rules, and review what your rules have been doing.

Blacklist rules stop a checkout before it happens. Whitelist rules create exceptions to them. Both live under Anti-Fraud in the dashboard, as [**Blacklist**](https://dash.sellauth.com/anti-fraud/blacklist) and [**Whitelist**](https://dash.sellauth.com/anti-fraud/whitelist).

## Rule types

| Type | Blocks or allows | Example value |
| - | - | - |
| E-mail | One address | `john.doe@gmail.com` |
| E-mail Domain | Every address on a domain | `gmail.com` |
| Disposable E-mail | All known throwaway email services | No value needed |
| Discord ID | One Discord account | `80351110224678912` |
| Country | One country | `US` |
| City | One city | `London` |
| IP Address | One address | `192.168.1.1` |
| IP Range | A CIDR range | `192.168.1.0/24` |
| ISP | One internet provider | `Comcast Cable` |
| ASN | An entire network | `AS15169` |
| VPN | Connections through VPN providers | No value needed |
| Tor | Connections through the Tor network | No value needed |
| User Agent | One browser or client | `Mozilla/5.0 (Windows NT 10.0; Win64; x64)` |

Disposable e-mail, VPN and Tor are category rules with no value to enter. They exist on the blacklist only, since allowing an entire category is not something you would want to do.

The whitelist carries the rest: e-mail, e-mail domain, Discord ID, country, city, IP address, IP range, ISP, ASN and user agent.

### What your plan includes

Some types are available on every plan, and the rest need a plan that includes advanced types.

| Availability | Types |
| - | - |
| **Every plan** | E-mail, e-mail domain, Discord ID, IP address, IP range, user agent |
| **Advanced** | Disposable e-mail, country, city, ISP, ASN, VPN, Tor, and regex matching |

The same split applies to the whitelist, for the advanced types it has. Types you cannot use are shown but not selectable, so you can see what is there.

The number of entries each list can hold also depends on your plan.

## Rule options

**Match mode** is either exact or a regular expression. Exact is right for a specific address or ID. A regular expression is for patterns, such as a family of throwaway addresses that follow the same shape, and needs a plan with advanced types.

**Reason** is internal, for you and your team. Record why the rule exists, since an unexplained IP address in the list is impossible to review later.

**Message** is what the blocked buyer sees. Leave it empty for a generic message, or set your own to point people at support when a broad rule catches somebody legitimate.

**Payment methods** limits the rule to selected methods. Empty applies it to all of them. This is how you block risky traffic on reversible methods while still accepting it on crypto, rather than turning the traffic away entirely.

**Active from and Active to** restrict the rule to a time window. Outside that window it does not apply, which suits a rule you only want during a sale or a known attack.

## Whitelist as an exception

Whitelist entries produce an allow decision on the same values a blacklist can block, and whitelist takes precedence, so a whitelisted value is let through even when a blacklist rule also matches it.

This lets you block broadly and then allow the exceptions. If you block a country because most of your fraud comes from there, whitelist the specific customers there you want to keep serving. Without that, the decision is all or nothing.

## Blacklist log

The [log](https://dash.sellauth.com/anti-fraud/log) shows every decision your rules have made: the value, whether the outcome was **Allow** or **Block**, which list produced it, and the rule type involved. Filter it by type, decision and list.

Check it after adding a broad rule. A country or ASN block can catch far more traffic than intended, and the log shows that sooner than your sales figures will.

## Blocking from an invoice or customer

Individual values are faster to block where you found them. Invoice pages block email, IP and Discord ID in one click; customer session details add country, user agent and ASN.

After a chargeback this is the right route, since it blocks exactly the values that invoice used. See [Refunds and Chargebacks](/guides/refunds).

## A workable starting point

* **Disposable e-mail.** Little legitimate traffic uses it, and fraud uses it constantly.
* **Tor.** Almost no genuine buyers, and a common source of card testing.
* **VPN** only if your fraud rate justifies it. Plenty of ordinary buyers run a VPN full time, and blocking it turns away real orders.
* **Country rules** last. They are the broadest option available, so review the log after adding one to see what they caught.

## Next steps

<CardGroup cols={2}>
  <Card title="Refunds and chargebacks" icon="rotate-left" href="/guides/refunds">
    What to do after a fraudulent order.
  </Card>

  <Card title="Managing invoices" icon="receipt" href="/guides/invoices">
    Blocking the values from the order itself.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.