Connect PowerMTA to Interspire (IEM)

Interspire Email Marketer (IEM) is a self-hosted PHP email-marketing application with a perpetual, domain-locked license. It is still actively maintained — the 8.7.x line shipped through early 2026 — and it delivers through any SMTP server, which is where PowerMTA comes in. The integration itself is short: point IEM at PowerMTA and trust IEM on the PowerMTA side. What deserves attention, and what differs from the MailWizz pairing, is IEM's particular bounce model and the fact that a single cron drives everything it does.

The site's constant holds here: PowerMTA is licensed commercial software and you bring your own license; KumoMTA is the free, open-source alternative. Worth stating up front for IEM specifically — run a legitimately licensed copy of Interspire too. There is a large grey-market of nulled IEM builds, and they are the wrong foundation for clean sending in every sense. More on that below.

Where Interspire fits with PowerMTA

IEM owns the marketing side: lists, subscribers, templates, campaigns, autoresponders and reporting. PowerMTA owns delivery: connection management, throttling per receiving provider, IP pools and DKIM signing. IEM composes each message and hands it to PowerMTA over SMTP; PowerMTA decides how and when it reaches the destination. That division is the point — IEM is not a mail server, and PowerMTA is not a campaign tool.

IEM's default delivery method is PHP's mail() function, which routes through whatever the local server provides. That mode exists for diagnostics and tiny tests; it is not for volume, and IEM's own guidance says as much. For real sending you switch IEM to SMTP and point it at PowerMTA, so delivery is handed to software built for it rather than to the web server's PHP runtime.

Most teams drive IEM through its web interface — building campaigns, scheduling them, and letting autoresponder sequences fire on their own. IEM also exposes an XML API, so an application can create subscribers, trigger sends or manage lists programmatically, with IEM still handing the resulting mail to PowerMTA over the same SMTP path. Whether the trigger is a marketer clicking send or an API call from your app, the delivery route is identical, which keeps the integration simple: configure it once, and everything IEM produces flows through PowerMTA.

PowerMTA side: trust the Interspire host

On the PowerMTA server, add a source block for the IEM machine so it is allowed to relay. Because IEM does not stamp a per-campaign routing header, the cleanest way to route its mail to a particular pool is to give the source a default-virtual-mta — or to use distinct SMTP accounts that map to different sources and pools.

<source 10.0.0.30>                  # the Interspire server's IP
    always-allow-relaying yes
    default-virtual-mta pool-marketing  # IEM routes by source, not a header
    </source>

If you require IEM to authenticate (recommended over trusting a bare IP, especially on a shared network), define SMTP credentials in PowerMTA and have IEM present them. Authenticated submission also lets you map different IEM accounts to different pools — one for transactional, one for marketing — which is the legitimate way to separate streams.

# authenticated alternative — IEM logs in instead of being trusted by IP
<smtp-user iem-marketing>
    password         a-strong-secret
    source <auth>
        default-virtual-mta pool-marketing
        </source>
    </smtp-user>

Interspire side: SMTP settings

In IEM, open Settings > Email Settings and switch delivery to SMTP. The fields are straightforward; the one that trips people up is TLS.

Setting	Value
Delivery method	SMTP (not PHP mail)
SMTP server	Your PowerMTA host or IP
Port	2525 (or 587 / 25)
Authentication	The SMTP user PowerMTA expects, if used
TLS	Match the PowerMTA listener's requirement

A test that fails with 530 5.7.0 Must issue a STARTTLS command first means the PowerMTA listener wants TLS but IEM connected in the clear. Enable TLS in IEM's settings on the matching port, or relax the listener's requirement for that source — but match the two ends rather than guessing. IEM's "use extra mail settings" options also govern certificate validation for the connection.

The single cron that runs everything

This is where IEM differs from most front ends. A single cron job, calling IEM's cron script, drives all of its time-based work: scheduled campaign sending, autoresponders, and bounce processing. If that cron is not running, nothing sends — mail simply queues. Set it up under Settings > Cron Settings and make sure the job uses the correct path to PHP, which is the most common reason a freshly installed IEM appears to do nothing.

IEM's send process is resilient in a useful way: if a run is killed mid-campaign because the process hit a time limit, the next run resumes where it left off rather than starting over, and it will not begin re-sending a campaign that has not finished. When a run starts it does only the work that is pending — if there are no campaigns, autoresponders or bounces to handle, it exits quickly. One caution: bounce processing is resource-intensive, so configure it to run on a longer interval than sending, and never set any IEM task to run more frequently than the underlying server cron fires.

Let PowerMTA shape the sending rate, not Interspire

IEM has its own send-process controls — how many messages it pushes per cron run, and how many cron processes you allow at once. It is tempting to treat those as your throttle, but they are the wrong lever. IEM's job is to hand mail off quickly; the rate that actually reaches each receiving provider should be governed by PowerMTA, which can shape delivery per destination domain, hold back when a provider signals it is being pushed too hard, and back off on temporary failures. Throttling at IEM only slows the hand-off into PowerMTA's queue; it does nothing about how Gmail or Microsoft perceive your pace.

So set IEM's send process generously enough that it keeps PowerMTA's queue fed, and do the real traffic shaping in PowerMTA's virtual-MTA and domain settings. This is also where IP pools earn their place: route marketing through one pool and transactional through another via the source's default-virtual-mta, and let PowerMTA pace each. The practical result is that a large IEM campaign drains into PowerMTA fast, then PowerMTA meters it out at a rate the receivers tolerate — which is exactly the division of labour you want, and the opposite of trying to make the PHP app behave like a delivery scheduler.

Interspire's envelope-sender bounce model

IEM handles bounces differently from apps that read an MTA's logs. Knowing that the Return-Path header is often ignored by intermediate servers, IEM sets the envelope sender — the SMTP MAIL FROM — to a List Bounce Email address, so non-delivery reports are guaranteed to come back to a mailbox it controls. It keeps your real From address in the visible headers. Then, on its cron schedule, IEM connects to that bounce mailbox over POP3 or IMAP using the Bounce Account Details you configure, reads the non-delivery reports, classifies them as soft or hard, and updates each subscriber's status so dead addresses are not mailed again.

This is a clean, self-contained design, but it has one operational rule with PowerMTA.

Pick one bounce authority

You can let IEM own bounces, or you can let PowerMTA own them — not both. If IEM owns them, point the List Bounce Email at a real mailbox, make sure PowerMTA delivers the returning non-delivery reports to it, and leave IEM's bounce processing enabled on its cron. If instead you want PowerMTA to own bounces — using its own bounce and FBL handling and feeding suppression back — then disable IEM's bounce processing by setting the Bounce Processing job to Disable in Cron Settings, so the two systems are not both trying to interpret the same reports. The failure mode of running both is duplicated or conflicting subscriber-status changes, and a bounce mailbox that one system empties before the other can read it. Decide once, document it, and verify with a test that a hard bounce ends up suppressed exactly once.

Authentication and envelope alignment

Authentication follows the same rules as any PowerMTA front end, with one IEM-specific wrinkle. Let PowerMTA do the DKIM signing through its domain-key directive — one signer per domain — and publish that public key in DNS. Add PowerMTA's sending IPs to the domain's SPF record so the mail passes SPF. The wrinkle: because IEM sets the envelope sender to your List Bounce Email on your domain, SPF is evaluated against that domain, so make sure the bounce domain's SPF authorises the PowerMTA IPs too. Keep DMARC in place and aligned. The authentication guide covers the records and the PowerMTA signing setup.

Verifying the integration end to end

Before turning up a real campaign, prove the whole path works with a small, deliberate test — and check both ends, because the most common silent failure is mail that IEM believes it sent but that never actually left PowerMTA. Send a short test campaign to a handful of seed addresses you control across the major providers, then reconcile the two views: IEM's campaign report will show a number of messages sent, and PowerMTA's accounting file under /var/log/pmta/ will show what it accepted and delivered. If IEM's "sent" count is higher than what PowerMTA accepted, messages are being dropped at the hand-off — usually an authentication or relay-permission problem in the source block, or a TLS mismatch — and that is the first thing to fix.

With the counts agreeing, confirm the things receivers judge you on. At a seed inbox, open the message and check that SPF and DKIM both pass and that DMARC aligns — a single seed at a provider that exposes the authentication results is enough to confirm PowerMTA is signing and the envelope domain's SPF covers its IPs. Then exercise the bounce path on purpose: send to an address you know is invalid, watch the non-delivery report arrive in the List Bounce Email mailbox, and confirm that on its next run IEM reads it and flips that subscriber's status to bounced. That single round trip validates the part of the setup most likely to be wrong — that the envelope sender, the bounce mailbox and the one chosen bounce authority are all aligned.

Only once a hard bounce reliably suppresses a subscriber exactly once, and the sent counts reconcile, should you scale. From there the ordinary discipline applies: warm a new sending IP gradually rather than pointing a full list at it on day one, and keep an eye on the accounting file and IEM's reports together for the first few campaigns so any divergence shows up early.

Run a licensed, current copy

Interspire deserves a direct word because of its history. It is one of the most widely pirated email applications, and "nulled" IEM builds circulate heavily in the bulk-mail grey market. Those copies are a poor foundation for three reasons: they are unlicensed, they are almost always old and unpatched PHP with known vulnerabilities, and some carry injected backdoors that turn your sending box into someone else's. A current, licensed IEM is inexpensive relative to the risk, gets security updates, and is the only version that belongs in a clean setup. The whole premise of pairing IEM with PowerMTA the right way is a licensed front end feeding a licensed engine — or a licensed front end feeding open-source KumoMTA. A pirated app undermines that before the first message leaves.

KumoMTA with Interspire

If you would rather not buy a PowerMTA license, KumoMTA fits the same way. IEM still sends over SMTP, so you point it at the KumoMTA listener instead, and KumoMTA — Rust, Lua policy, Apache 2.0 — does the delivery and signing. IEM's cron and its envelope-sender bounce model are unchanged; the bounce mailbox still works the same way, and the one-authority rule still applies. KumoMTA does not ship an administration panel, which is the gap the Auto PMTA Configurator fills, giving the open-source engine a usable front end alongside IEM's campaign tooling.

Interspire or MailWizz with PowerMTA

Both are maintained, self-hosted apps that pair with PowerMTA, and the PowerMTA side is nearly identical, so a later switch is low-friction. The practical differences for this integration are two. Routing: MailWizz can stamp X-Virtual-MTA per delivery server, while IEM routes by the SMTP account it authenticates as, so with IEM you separate streams through distinct accounts and source blocks. Bounces: MailWizz offers several bounce methods including reading PowerMTA's accounting file, while IEM's native model is the envelope-sender mailbox it polls. Neither is better in the abstract — choose the app you already own or prefer to operate, and apply the matching pattern. The MailWizz guide covers its side in full.

Common Interspire + PowerMTA mistakes

• Leaving PHP mail() on for volume. It routes through the web server and is for testing. Switch to SMTP pointed at PowerMTA.
• No cron, or the wrong PHP path. IEM's single cron drives everything; without it, campaigns just queue.
• Two bounce authorities. IEM polling its mailbox and PowerMTA processing bounces at the same time conflict. Pick one.
• Emptying the bounce mailbox manually. IEM can only process reports it reads itself. Leave the mailbox alone.
• Bounce processing too often. It is heavy; give it a longer interval than sending.
• SPF that ignores the envelope domain. IEM's MAIL FROM is your bounce address; that domain's SPF must authorise PowerMTA's IPs.
• A nulled copy. Unlicensed, unpatched, and often backdoored. Run a licensed, current IEM.

The bottom line

Interspire and PowerMTA pair cleanly once two IEM-specific things are right. Its single cron has to run with the correct PHP path, or nothing sends; and its envelope-sender bounce model means you choose one bounce authority — IEM polling its mailbox, or PowerMTA — and never both. Beyond that, the pattern is familiar: trust the IEM host in a PowerMTA source block, switch IEM to SMTP delivery, let PowerMTA sign DKIM and cover the envelope domain in SPF, and run a legitimately licensed copy of the app rather than a nulled one.

If you would rather have it set up correctly from the start, our setup service connects a licensed Interspire to PowerMTA or KumoMTA with authentication and a single bounce authority in place, and the one-click installer stands up the engine on your license. The standard does not move: a licensed or open-source engine, a licensed front end, opt-in sending only, and nothing that helps spam.