Allow / block rules

Allow and block rules let you override the ML score for specific senders. Use these sparingly — the model usually gets it right. Rules are most useful for trusted internal vendors (allow) and known bad actors (block).

Rule scopes

Rules exist at three levels of specificity. More specific scopes win.

Scope	Applies to	Configured at
Recipient	A single email address	(Coming soon — per-recipient UI)
Domain	All mail to one of your domains	Dashboard → click allow/block rules next to the domain
Global (admin only)	All mail, all customers	Admin → Global rules

Allow vs block

Allow bypasses all scoring and delivers the message as clean. Use only for senders you fully trust and cannot afford to lose.

Block rejects the message at SMTP time with code 550. The sender gets an immediate bounce.

Warning: Allow rules currently bypass SPF and DKIM checks. Don't allow-list domains you can't be sure won't be spoofed (e.g. don't add microsoft.com as an allow — anyone can send mail claiming to be from that domain).

Pattern syntax

Patterns are matched against the envelope-from address, the sender's domain, and the connecting client's IP — whichever fits the pattern shape.

Pattern	Matches	Example
spammer@bad.example	Exact envelope address	Only mail from that one address
bad.example	Exact sender domain	Any mail from bad.example
@bad.example	Sender domain (alternate syntax)	Same as bare domain
.bad.example	Domain wildcard (subdomains too)	Matches mail.bad.example, x.bad.example
192.0.2.10	Exact client IPv4	Only that connecting IP
192.0.2.0/24	CIDR network	Any IP in that /24 block
10.0.0.0/8	Larger CIDR	Entire RFC1918 10.x range

Precedence

When a message arrives, MxGuard evaluates rules in this order:

1. Recipient rules — most specific, checked first
2. Domain rules — checked next
3. Global rules — checked last

Within each scope, allow beats block. So if you have a global block on gmail.com but a domain-level allow on customer@gmail.com, the customer's mail still gets through.

Adding a rule

1. Go to your dashboard, find the domain, click allow/block rules
2. Choose allow or block
3. Enter the pattern using one of the syntaxes above
4. Optionally add a reason (shows up in rule lists, useful for documentation)
5. Click add

Rules take effect within 60 seconds (rule cache TTL).

Common patterns

Allow your CRM:

action=allow  pattern=mail.salesforce.com

Block a persistent spammer's IP range:

action=block  pattern=185.220.100.0/22

Block all mail from a specific TLD (use with care):

action=block  pattern=.top

(This would block x.top, foo.top, etc.)

Hit counts

Every time a rule matches a message, its hit counter increments and the last hit timestamp updates. Use this to spot rules that have outlived their usefulness — if a block rule hasn't fired in a year, you can probably retire it.

The dashboard's Recent rule hits widget surfaces the five most recently-fired rules at a glance.

Auto-created rules from "Mark as spam" and "Mark as ham"

When you mark a message as spam or ham in the feed, a popover lets you optionally create a sender rule in the same action — a block rule for spam, an allow rule for ham. Three pattern shapes are offered for both:

• This exact address (default) — pattern is the full envelope-from, e.g. spammer@evil.com or colleague@trusted.com. Only that address is affected.
• Whole sender domain — pattern is the bare domain, e.g. evil.com or trusted.com. All addresses on that domain are affected.
• Custom pattern — you type the pattern. Same syntax as any other rule (see Pattern syntax above), e.g. *@marketing.evil.com.

The rule's scope is automatic and role-based:

• If you are a customer, the rule is scoped to the recipient's domain on the message you labelled — the server verifies that domain belongs to your account before saving.
• If you are an MxGuard admin, the rule is global and affects every customer's mail.

Auto-created rules carry a reason of auto-added when labelling as spam or auto-added when labelling as ham so you can spot them later in the rules list and remove if you change your mind. Duplicates are detected — the system won't insert a second identical rule at the same scope.