nasretail.blogg.se - Powermta configuration guide

POWERMTA CONFIGURATION GUIDE HOW TO
POWERMTA CONFIGURATION GUIDE UPDATE
POWERMTA CONFIGURATION GUIDE CODE

The message generation code controls the MAIL FROM (sending domain), RCPT TO and X-Job values. many → one mapping is allowed).īefore we go further into the various SparkPost configuration choices, here’s a high level view of our message flow. You can also easily map streams from several VMTAs to one subaccount, if that makes more sense for your situation (i.e. Tracking domains (when using SparkPost engagement tracking)įor simplicity, we can create one subaccount per VMTA.Sending domains with DKIM keys (more on DKIM here ).Prepare your new message streams by setting up resources in SparkPost, using the articles linked here.

POWERMTA CONFIGURATION GUIDE HOW TO

You’ll need to prepare your own systems to handle events coming via SparkPost – this article describes how to use webhooks. SparkPost events can be viewed on the web UI, accessed via API and received in near real-time via webhooks. Your SparkPost relayed traffic will trigger events within SparkPost according to this model. Migrated streams will show only a “delivery” event in the accounting logs, which really indicates that the relay was successful, not the final delivery to the recipient.

PowerMTA creates various accounting files for messages received, delivered, bounced, remote-bounced, FBLs etc. Planning your migration PowerMTA Accounting Files vs. The remainder will overflow to your SparkPost account default pool, or to our global shared pool (on request). We’ll also use Auto IP Warmup to protect your SparkPost dedicated IP pools from sending too much traffic at the start.

POWERMTA CONFIGURATION GUIDE UPDATE

Later, you could update your message-generation to connect directly to SparkPost, rather than via PowerMTA in the meantime, PowerMTA keeps your message streams flowing and helps to warm your new SparkPost IPs.Įach VMTA pool can load-share between direct delivery and relay to SparkPost more on that in a moment. We’ll use PowerMTA as a relay to route traffic via SparkPost, without the need to rework any of your message-generation stack.

SparkPost Signals Analytics provides visibility of migrated traffic streams with clear reporting.

Subaccounts provide mapping of traffic streams to delivery IP pools, with Auto IP Warmup.

The VMTA pool provides selective routing of traffic streams with load-sharing and a smooth migration path, with the option of rollback if needed.

If you’re already using virtual MTAs (abbreviated from now on to VMTA ) and VMTA pools in your configuration, you can route traffic based on those otherwise, we can use domain-based selection as shown here.

Test your setup – with suggested steps:.

Consider: SMTP hostnames, bounce processing, campaign_id.

Disable PowerMTA DKIM signing on relayed domains.

Plan your migration, including transitioning from accounting files to SparkPost event reporting.

Leverage Virtual MTAs in PowerMTA, and subaccounts in SparkPost, to map message streams with load-sharing between PowerMTA and SparkPost.

Your email programs are business-critical, so you need a simple way of selecting which traffic streams are delivered via SparkPost, and which continue to be delivered by PowerMTA.

My colleague Tom Mairs wrote this article on diversifying your message streams, and this article on strategies for Momentum and PowerMTA migrations. We have this article showing a simple PowerMTA relay configuration example. A frequent theme for SparkPost messaging engineers is to help customers to gradually migrate traffic across to SparkPost.