Seeding means mixing seed addresses into a mailing, which later show where the message landed: in the Inbox, in Spam, or nowhere. Usually such addresses are set up and polled by the sender; here the vendor does it, and the engine substitutes them into the campaign on the fly.
There are four conditions, and three of them are outside the configuration: a vendor account with the feature enabled, paid access to its deliverability tool, a key with two permissions — and only then this block with api-key.
Not every mailing qualifies. The message must have a job identifier, be no larger than 20 MB and carry a sender header (Sender or From; if both, the first is taken). A campaign is messages with the same job identifier, domain and subaccount.
After adding the block the vendor advises a restart — so that current connections follow the new settings.
Two caveats that are easy to miss. A signing key passed in the X-DKIM-Key header is not fully supported: seed messages may go out unsigned or with a different key. Non-Latin sending domains are not fully supported either.
# the block and enabling are different lines: the first gives access, the second controls scope <inline-seeding> api-key 0123456789abcdef012345678901234567890123 persist-threshold 500 </inline-seeding> enable-inline-seeding true,subaccount=555
2 articles
◇Seeding campaigns with control addressesThe engine mixes the vendor’s addresses into a mailing, and the result is viewed in the vendor’s deliverability tool; independent of event export.◇Job headerThe x-job header tags a message with a job; the node reads it only if the source is allowed process-x-job, and then the job is visible in accounting, the monitor and pause commands.