Demo
Demo

Knowledge base

PMTA knowledge base›Block <domain>›Directive§ 3.3.10.113.4

sparkpost-ip-pool

<domain>

Which SparkPost IP pool redirected messages are sent from
in the configuration this is a linesparkpost-ip-poolinside the block <domain>
The sending addresses become someone else’s

There is no default. The value is the name of an address pool on the SparkPost side from which the service will send the messages redirected to it.

The point of the line is that with redirection the sending address stops being yours. The message goes out from the service’s addresses, and this line decides which set of addresses to take.

It works inside traffic redirection: the {sparkpost} domain with auth-username and an access key — without them the line has nowhere to go.

The main trap is that reputation leaves along with the addresses. Everything you built up by warming up your own addresses has nothing to do with messages sent through the service: they have their own reputation, and on a shared pool it is shared with the service’s other customers.

This is the price of “adding capacity for the season”: the capacity appears at once, but its reputation is not yours and not under your control.

The other half: the pool name is checked on the service’s side. A typo in it will not produce a configuration apply error — the node will simply pass the service a name it does not have.

What the Hub does. It does not write it: redirection through SparkPost is not used.

The Hub is designed the other way round: capacity is increased with its own addresses through warm-up, and the whole point of warm-up is that the reputation is your own. Redirection solves the same task quickly and at the cost of that very reputation.

Recommended values

What to set. The value is the pool name at the service; the choice is not technical:

Value When
do not write the service takes a pool by its own defaults
shared pool name a seasonal spike, reputation is not critical
dedicated pool name the service’s addresses are assigned to you — reputation is separate, but still not yours

The second is cheaper and riskier: on a shared pool, neighbors at the service affect the deliverability of your messages.

The syntax and purpose are from the manual, § 3.3.10.113.4. No default is named there. The analysis of reputation and the breakdown of cases are ours.
Example configuration
# the sending addresses belong to the service, and the pool is chosen by its names
<domain {sparkpost}>
    auth-username SMTP_Injection
    auth-password d41d8cd98f00b204e9800998ecf8427e
    sparkpost-ip-pool shared-pool</domain>
The pool name is checked on the service’s side: a typo will not cause a configuration apply error, the node will simply pass on a nonexistent name.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
▲

Common mistakes and problems

what people get wrong and how it ends2 mistakes▶

Believing your addresses' reputation carries over to the service's messages

our experience

What it costsMessages go out from the service’s addresses, and their reputation is their own. Warming up your addresses has nothing to do with these messages, and on a shared pool neighbors at the service affect deliverability.
How to spot itDeliverability of redirected traffic differs from your own, and it cannot be explained by your addresses.
How to do it rightTreat redirected traffic as a separate channel with its own reputation — and measure it separately.

Getting the pool name wrong

§ 3.3.10.113.4

What it costsThe name is resolved on the service’s side, and a mistake does not cause a configuration apply failure. Messages will go out from the pool chosen by the service’s defaults, not the intended one.
How to spot itIn the service’s reports the traffic is attributed to the wrong pool.
How to do it rightCheck the name against the service’s account rather than relying on configuration checks.
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.
Reference data
Syntax
sparkpost-ip-pool <string>
Values
the name of an address pool on the service's side
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<domain>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The directive lives in <domain> and follows the merging of recipient blocks — but it is meaningful only in the reserved {sparkpost} domain. For an ordinary recipient it does nothing: there is nowhere to put it.
⇄

Related directives

1 relation

Does not work without

auth-username<domain>Redirection starts with authentication at the service; without it the line has nowhere to go. § 3.3.10.113.4

How to check on the node
The line is visible in the configuration, the result — only in the service’s account:
grep -n -A5 'domain {sparkpost}' /etc/pmta/config
The pool name cannot be checked from the node’s side: it is resolved by the service. An error in it shows up as messages going out from the wrong pool — and this can be seen only in the service’s reports.
◇

What else to read

3 articles

◇The activation key is a prerequisite for installation, not a step after itWithout an activation key from SparkPost support the engine neither installs nor runs, and the license tier sets the outbound connection ceiling: on Standard everything above 200 is ignored.◇Cloud restrictionsClouds restrict outbound mail on port 25 until you ask them to lift the limit, and mailbox providers treat their address ranges with suspicion.◇How to turn a sending plan into hardwareTwo constants for sizing any node: about 2 KB of memory per queued recipient and spool space proportional to the total size of the messages.

In the Hub
Cost of a mistake
safe: a wrong value breaks nothing
Scenarios
Capacity planning
Neighboring settings of the block <domain>:http-delivery-urlhttp-delivery-extra-headerssparkpost-sandboxadd-x-msys-api-headeradd-x-msys-api-header-metadataAll 135 directives of the block →