Rules

A rule is one instruction: this program, to this destination, under these conditions, gets this answer. Outbound checks every connection against the rules that match and applies the single most specific one. When no rule matches, the mode decides.

You manage rules in the Rules pane and the rule editor. The filter holds its own copy and enforces it even when the app is not running.

The parts of a rule

Action: allow, block or ask. An ask rule sends matching connections to the connection alert. The Rules list shows a block rule as Block, for example “Block domain example.com”. The rule inspector’s Action line and Open Quickly print the stored word, so there a block reads Deny. With alerts disabled (a managed setting, or outboundctl prefs set disable-alerts), an ask rule behaves like an allow, or like a block when the mode is Strict.

Direction: Outgoing, Incoming or Either. Outbound filters both directions. Either is the editor’s name for a rule that matches both.

Program: any app, one app by code identity (team plus signing identifier) or by path, or a category of Apple-signed programs. A rule can also name a helper the connection goes through (“via”). The editor keeps that condition when you edit such a rule. A code-identity rule outranks a path rule, which outranks an Apple-signed category, which outranks any app. Naming a helper adds weight on top of that.

Remote: a text field. The prompt is any, *.example.com, 10.0.0.0/8. What you can type:

• any, shown in the list as Anywhere.
• local, the local network: the standard private ranges plus any extra ranges you added (see Local network traffic). The list says Local network.
• *.example.com, a domain and its subdomains. The list says “example.com and subdomains”. A name with more labels beats a shorter one (api.example.com beats example.com).
• A hostname, matched exactly, without its subdomains. A trailing dot marks a fully qualified name, so any. is the host named any.
• A single IP address, IPv4 or IPv6.
• A network in CIDR notation, such as 10.0.0.0/8 or 2001:db8::/32. A longer prefix beats a shorter one. A host route, an IPv4 /32 or an IPv6 /128, ranks as a single address.

Instead of a remote, a rule can name countries: block the countries you choose, or allow only those countries. Outbound looks up the country of the server’s address. A country rule does not match a server on your local network or one whose country is not known, so your other rules decide those. In Terminal, outboundctl rules add takes --countries or --block-countries with two-letter country codes, and --only to block every country outside the list.

Host names are lowercased before they are stored and compared, so capital letters do not change which rule matches.

Ports: any port, or a list of ports and ranges. Each port is from 1 to 65535. The port a rule tests is the service port: the remote port of an outgoing connection, or the local port an incoming connection arrives on. An incoming connection whose local port could not be determined can still be blocked by a port rule. A port-specific allow or ask does not match it. A rule that names ports beats one that does not, and among port rules the one naming fewer ports wins.

Protocol: Any, TCP, UDP or ICMP. A specific protocol beats Any.

Lifetime: forever, for a set time from 5 minutes to a week, until the app quits, until logout, until restart, or a weekly schedule. See Temporary rules and lifetimes.

Profile: All profiles, or one named profile. A profile rule applies only while that profile is active.

Priority rule: the editor’s toggle, with the line “Wins over rules without priority that match the same connection. Between two priority rules, the more specific one wins.” Priority rules are compared before everything else. In the rule inspector, Raise Priority… and Remove Priority… show which rule will decide the connection before you save.

Notification and sound: an allow or block rule can show a notification, play a sound, or both, when it decides. They change nothing about the decision. See Creating and editing rules.

Enabled: a switch on each rule. A disabled rule never matches.

Note: free text. Rules made from an alert say “Created from alert”. Rules made from Review say “Created from Review”. Rules requested by an AI app say “Requested by an AI app”. A rule made because a daily data limit was reached says “Daily data limit reached”. Restore Original Note in the rule inspector puts back the note a rule was created with.

How each rule records where it was made

Each rule keeps a record of how it was created: from an alert, Review, the rule editor, an import, setup, a rule group, outboundctl, the Network Monitor, the inspector, an automatic protection, or an approved assistant request. The record also keeps when it was made and the note it was made with. For a rule from an alert or Review it keeps the app, the server and what you chose, for example “On 12 Oct 2026, Safari tried to connect to example.com; you chose Allow in an alert.” Editing the rule later never rewrites that record, and a rule made before the record existed is not given one after the fact. The rule inspector shows it; see The inspector.

Where rules come from

The Rules pane shows each rule’s source:

• You: rules you made in the app, or that outboundctl rules add made for you.
• Organization: rules your administrator distributes through the managed rule feed.
• Blocklist: name: one rule per entry of a blocklist subscription. A list with no name on hand reads Blocklist.
• Trusted by default: the built-in allow rules of the trusted groups.
• Known telemetry: the block rules built from the tracker database.
• Rule group followed by the first eight characters of the group’s id: a downloaded allow-list group you accepted entries from.

Which rule wins

Outbound compares matching rules in this order. The first difference decides. A higher step wins.

1. Priority rules come first.
2. Organization override: when your administrator turns on the managed override, Organization rules beat every rule that is not a priority rule.
3. Your rules, blocklist rules and any rule group other than Trusted by default beat the built-in trusted groups.
4. Destination, most specific first: a single address, including an IPv4 /32 or IPv6 /128 host route, beats a network. A network with a longer prefix beats a broader one. An exact host beats a domain. A domain with more labels beats a shorter one. The local network beats Anywhere.
5. Ports: a rule naming ports beats one that does not. Among port rules, fewer ports wins.
6. Protocol: a specific protocol beats Any.
7. Program: a code-identity rule beats a path rule, which beats an Apple-signed category, which beats any app. Naming a helper adds weight.
8. Direction: Outgoing or Incoming beats Either.
9. Action: block beats allow, and allow beats ask. This is compared after the destination, so a specific allow beats a broad block.
10. Ties: the newer rule wins. If both were created at the same instant, the rule with the lower identifier wins, and then the earlier one in the list.

Two examples. A rule allowing Zoom to zoom.us on port 443 beats a rule allowing Zoom anywhere, because the destination and the port are more specific. A rule allowing Zoom to zoom.us beats a rule blocking Zoom anywhere, for the same reason: the destination is compared before the action.

When nothing matches

With no matching rule, the mode default applies: Ask shows an alert, Learn allows, Strict blocks. A connection whose program cannot be identified at all (no signing identifier and no path) is always blocked while Outbound itself is not running.

A path rule pinned to one build is a special case of a match: if that build has been replaced, a block still blocks, and any other winning allow or ask is set aside: Strict blocks the connection, and Learn and Ask ask about it. See Code identity.