How to integrate custom routing with ESP tracking?

You've built your own mail server (or you're using a custom MTA) for routing control, but you still want the open tracking, click wrapping, and analytics your ESP offers. That's a reasonable setup. It's just not the default, so it needs a bit of planning.

But Here's what's actually happening when an ESP tracks opens and clicks: it rewrites your links to pass through its own redirect servers and injects a tiny invisible image (a tracking pixel) into the email body. For any of that to work, the email has to pass through the ESP's infrastructure at some point, or the ESP needs to pre-process the content before it goes anywhere.

And there are three approaches people use to make this work.

Option 1: Route through your MTA first, then hand off to the ESP. Your application generates the message, your custom MTA (Postfix, PowerMTA (now Bird), or similar) does any routing logic you need, and then it relays the message to your ESP as a smart host. The ESP wraps links, injects the pixel, and handles final delivery. You keep routing control at the origination stage, and the ESP's analytics still work. This is the most common hybrid setup. The downside is that delivery goes through the ESP, so you're still on their sending infrastructure for the last mile.

Option 2: Use the ESP's API to get tracked content, then send it yourself. Some ESPs (like Twilio SendGrid and Mailgun) let you submit message content through their API and receive back a version with links already rewritten and pixels already inserted. You then take that pre-processed content and send it through your own MTA. Click and open data flows back to the ESP's servers when recipients engage. This gives you full delivery control while still tapping into the ESP's tracking infrastructure. It's more work to set up, but it's clean.

Option 3: Build your own tracking layer entirely. If you don't want an ESP in the loop at all, you can host your own redirect endpoints and pixel server. Every link in your emails routes through a URL you control (something like clicks.harborpost.net/r?id=abc123), and the pixel image loads from your own server. You own all the data. You also build and maintain all the infrastructure, which is a real operational cost. Most teams that go this route are large enough to have dedicated platform engineers.

A few things that matter regardless of which option you pick.

Authentication has to be clean for the actual sending path. If you're using Option 1 and the ESP does final delivery, your SPF record needs to authorize the ESP's sending IPs. If you send through your own MTA in Option 2, your SPF needs to authorize your servers. Getting this wrong means your DMARC alignment breaks, which can cause delivery failures or rejected messages. Worth checking your full sending path before you go live.

Custom tracking domains also help. If the ESP rewrites your links to point to their generic tracking subdomain, that's a potential reputation risk (you're sharing it with thousands of other senders). Most ESPs let you configure a custom tracking domain like clicks.yourdomain.com that CNAMEs to their infrastructure. Set this up. It keeps your brand in the URL, protects your reputation from others' behavior, and looks more trustworthy to recipients.

Reporting will often be split. Your MTA logs show delivery and bounce data on your side. The ESP shows click and open data on theirs. You may need to stitch these together using message IDs if you want a unified view. Some teams build a lightweight data pipeline for this. Others accept the split and check both dashboards.

Now if you're not sure which approach fits your setup, or the authentication alignment in your hybrid setup isn't quite right, our SOS hotline is free and we'll work through it with you.