Knowledge base
cold-virtual-mta<virtual-mta>DirectiveNames the cold sending address; how many messages it gets is set by a separate directive in the receiver block.enable-signalsGlobalDirectiveThe scope of export with three inheritance levels; the subaccount, the tracking domain or the rule list name are appended here too.max-cold-virtual-mta-msg<domain>DirectiveWarm-up built into the engine: part of the traffic is diverted to a new address while it builds reputation.enable-inline-seedingGlobalDirectiveEnables seeding at the node, pool or sending address level; the default depends on whether the seeding block is declared, and the value true without a subaccount does not inherit it.sender-or-from<signals-filter>DirectiveEnables or disables export by the domain from the sender header; the subaccount and tracking scope are set there too.batch-frequency<inline-seeding>DirectiveThe interval of requests to the service for counters and seed assignments; the default is fifteen seconds, the range is from 15 seconds to five minutes.eligibility-ttl<inline-seeding>DirectiveHow long the job eligibility flag is kept; the default is five minutes, the range is from 5 minutes to an hour.persist-threshold<inline-seeding>DirectiveThe number of messages of one job before contacting the service; the default is five, the range is from 5 to 999.Complaints parsed by the node — and they are parsed secondcriticalMechanismMail that arrives at an address from the configured list is parsed as a complaint report; the parsing order matters — the complaint processor runs after the bounce processor.Reputation monitoring inside the nodecriticalMechanismThe engine itself watches the receiving servers’ replies and changes the queue mode on a pattern match — a reaction within the connection, not through telemetry.Seeding campaigns with control addressesMechanismThe engine mixes the vendor’s addresses into a mailing, and the result is viewed in the vendor’s deliverability tool; independent of event export.Warm-up built into the engineMechanismA warmed-up address hands the first N messages of the day for each receiver to its cold partner; the partner sends them itself and builds history.The complaint format of one large receiverMechanismHotmail complaints do not come in standard ARF: for the engine to recognize them and record the recipient, you need the variant with an RFC attachment and the X-HmXmrOriginalRecipient header.The vendor's analytics — and what leaves the node for itMechanismA paid service that receives the node’s accounting data and returns analytics, a health score and a spam trap report; it is enabled by scope and stays off until its block exists.The second complaint report formatMechanismXARF complaints are JSON instead of ARF: the engine fills the main fields itself, and the rest are extracted with the xarf.<path> form.Introducing a new address with part of someone else's trafficcriticalProcedureA warmed-up address hands its partner the first messages of the day to each receiver; the counters reset at midnight and survive a restart.<signals>Configuration blockThe block enables sending accounting data to the vendor’s service; the engine chooses the data composition, the scope is set with a separate line.<inline-seeding>Configuration blockThe block enables seeding campaigns with the vendor’s addresses; it requires a key and a paid subscription and recommends a restart after adding.<signals-filter>Configuration blockA block with rules by sender domain; attached to the scope by name, and anything not matched is considered disabled.Spam trapsMonitor screenThe SparkPost Signals report on spam trap hits by day — as a count or as a share of the day’s volume.The vendor analytics overviewMonitor screenThe SparkPost Signals overview: leaderboards by health score and spam traps broken down by campaign, pool and sending domain, for up to 90 days.Service summaryMonitor screenThe SparkPost Signals report with sending metrics for a selected period, grouped by domains, campaign, address and pool.