Three families of limit, applied at once verifiedcriticalWritten by the Hub

Three families exist because three different parties care. The receiver cares about what arrives at it in total, which is the domain_* family. A sending address's reputation is its own, which is the ip_* family. And a connection is a resource on both sides, which is connection_*. All of them apply at once and the strictest wins, so a generous address limit under a modest domain limit changes nothing — the common way for a warm-up to look stuck when it is in fact capped somewhere else. Profiles do not compete; they add up. The console says so in its own arithmetic — the throttle explainer lays out built-in defaults + profile + profile + flood pattern = active throttling — and the stand confirmed the rule for conflicts. Two profiles were made to match one delivery by different dimensions: one bound to the sending address allowing a single connection, one bound to the destination allowing four. The receiving sink never saw more than one connection at a time. Removing the address rule and repeating the run gave exactly four. The stricter number wins, whichever profile it came from and whenever that profile was created. Two profiles cannot claim the same target at all: a rule is unique per (domain, address, pool) triple, and creating a duplicate moves it rather than copying it — see mq5.table.capacity_rules. So the question "which profile wins" has no case left to decide. The shipped defaults are worth committing to memory, because they are what applies when no rule matches: unlimited messages and connections, one connection being established at a time, one idle connection kept, ten messages through a connection before another opens, five minutes of silence towards a server that refused a handshake.