Knowledge base

<inline-seeding>

Automatic substitution of seed addresses into a mailing
Seed mailboxes substituted by the engine itself

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.

Example configuration
# 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
Without the block the enabling line gives nothing, and with the block it is considered enabled at node level by default.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
Compatibility
PowerMTA 6.0
described in the manual of this version · platform: any
The vendor does not state the first version for every directive — there is no note here. The name also appears in the 5.0 edition of the manual.
In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Seeding and seed mailboxes