The short answer is: only the parts Senders is contracted to run. You retain ownership and operational control of everything else.

This is intentional, and the line between the two is important to understand.

What Senders Operates

On the Business tier and above, Senders.co provides Managed Email Infrastructure as the sending layer for new senders the program brings online. That means Senders builds and operates: aged sending domains and subdomains we deploy on your behalf, pre-warmed IPs allocated to your program, DNS configuration for those Senders-managed domains, authentication setup (SPF, DKIM, DMARC) on those domains, IP and domain warming, and continuous monitoring of the senders Senders operates.

We do this because the deliverability outcomes on these senders are our responsibility. If we can't operate the infrastructure end-to-end, we can't guarantee what comes out of it.

What You Retain

Everything else stays yours.

• Your existing domains and IPs that you brought to the engagement
• Your ESP accounts (Mailgun, SendGrid, Postmark, etc.) and the configurations inside them
• Your sequencer tools (Apollo, Outreach, Salesloft, Instantly) — Senders' SMTP layer plugs into those, but the tools stay yours
• Your contact data and lists
• Decisions about copy, cadence, audience, and campaign strategy
• Compliance posture for your overall sending program (CAN-SPAM, GDPR, industry-specific regulations)
• The decision to implement (or not implement) recommendations the Deliverability Engineer makes about your existing setup

Why the Split Matters

There are two reasons we draw the line this way.

First, you should understand what's in your email infrastructure and why. If a consultant implements DNS changes on your existing domains, makes ESP configuration updates, and adjusts your sending behavior without your involvement, you won't know what actually changed or why it matters. You'll see mail starting to land in the inbox again, but you won't know what fixed it or how to prevent the problem next time. Six months later, if something breaks again, you're dependent on the consultant because you didn't learn the system.

Second, you need to own your broader infrastructure for competitive advantage. Email operations isn't something to outsource your understanding of. If you understand your authentication, you can migrate ESPs without hiring outside help. If you understand your reputation strategy, you can scale new sending streams without crisis. If you understand your compliance and list hygiene practices, you can make confident decisions about strategy.

We want you to own that knowledge. The engagement is structured so your team learns alongside the work — you keep the capability you build with us.

What You Actually Execute

On the Deliverability Dept. tier, the engineer guides you on changes that affect your side of the system:

• Updating sending settings, authentication, sending addresses on your ESP
• Making DNS changes on the domains you own (updating SPF, DKIM, DMARC, BIMI, reverse DNS), or coordinating with your infrastructure team
• Adjusting list hygiene practices, cadence, volume ramps, re-engagement workflows
• Monitoring compliance and regulatory requirements
• Making decisions about infrastructure changes on your side (whether to get a new IP, whether to migrate ESPs)

We provide detailed guidance on all of these. We explain what needs to change and why. We help you validate that changes are working. We help you troubleshoot if something doesn't behave as expected. But you're doing the actual work on the systems you own.

What This Looks Like in Practice

A company on the Deliverability Dept. tier asks the engineer to fix their DMARC posture. The Deliverability Engineer identifies that they need to move from p=none to p=reject. They explain why it matters, what could break if implemented incorrectly, and what the validation process looks like. The company's team makes the DNS change. They monitor for a week to confirm legitimate mail isn't being rejected. They move to enforcement. Problem solved.

The company now understands DMARC enforcement. Next time a team member asks "should we be rejecting mail that fails DMARC alignment?" they can answer from experience instead of guessing.

A different case: the company needs to warm a new sending IP on Senders-managed infrastructure for high-volume email. The engineer designs the warming schedule, executes it on the senders Senders operates, validates that reputation is building as expected, and reports out. The company doesn't have to manage that workflow — but they're briefed on what's happening so they understand the system.

The Line, Restated

Senders runs what Senders contracted to run. Everything else stays yours. The Deliverability Engineer is in your corner on the parts you operate yourself — guiding, validating, troubleshooting — but the decisions and the executions on your side remain in your hands. That's the design.