Rules

Rules let an organization turn known policy or quality intelligence into repeatable results before network checks.

Local custom rules

Local rules are stored on the device and remain available across plan changes. A custom rule can apply one of two actions:

• Block: return invalid with risk 100 and stop later checks.
• Risky: return risky with risk of at least 70; network checks may continue, but a lower positive score does not erase the rule.

Use block only when the matched pattern is a strong exclusion policy. Use risky when a human or a downstream policy should decide.

Create a rule

1. Open Rules.
2. Choose the rule target supported by the interface.
3. Enter a precise value or pattern.
4. Select Block or Risky.
5. Add a short reason that another operator can understand.
6. Enable the rule and test it on a known sample.

Prefer narrow, reviewable rules. A broad domain or pattern can classify many unrelated records.

Official rules

Enterprise includes signed official rule packages and updates. The application verifies the package before it participates in validation. Official data can supply known-invalid, blacklist, disposable-domain, no-MX, trap, and related signals depending on the installed version.

If Enterprise access ends, the official package no longer participates. Local custom rules remain stored and manageable.

Rule precedence

Rules run after format validation and before DNS or SMTP:

• a hard invalid rule ends the current address lifecycle;
• a risky rule allows deeper checks;
• later positive network evidence cannot lower a stronger rule-based risk;
• result details identify the rule signal for review.

Governance

• Record the owner and reason outside the pattern when needed.
• Review rules periodically for expired business assumptions.
• Test a new rule on a sample before applying it to a large batch.
• Export or back up essential policy data before device migration.
• Do not use rules as a substitute for consent, suppression, or sending compliance.

Next: interpret results.