The message as the last word verifiedcriticalWritten by the Hub
Ten of the twenty-four properties override something the node has already decided — so the job is the fourth and final configuration layer.
In detail
The pattern is consistent: whatever a message states for itself wins over the profile in the database and the directive in the file. Sending addresses (ips, pool), lifetime (maxdelivertime, maxattempts, retries), encryption (security), routing (smarthost), signing (dkim), notifications (dsn) and even the result queues (queues) can all be decided per message. Two consequences shape how Hub should use MailerQ. Most node configuration becomes optional. A sender that knows what it is sending can express nearly everything in the job, leaving the node with only the things that are genuinely per-node: the intake, the broker, the limits protecting receivers. For warm-up, where Hub already knows the address, the volume and the plan, this is the natural division — and it avoids writing to the cluster database for something that concerns one message. What the node keeps is what protects others. Throttles, pauses and suppressions are not overridable by a job, which is right: a message cannot talk its way past a limit that exists to protect a receiver.