How MailChannels Billing Works — and Why

MailChannels serves two distinct types of customers — Email API users who send transactional and application email through our API, and Outbound Filtering customers (web hosting providers and multi-tenant SaaS platforms) who relay outbound email through our filtering infrastructure. The way we count billable messages differs between these two products, and for good reason. This article explains how billing works for each, and the thinking behind our approach.

Email API: you pay for what actually gets delivered

If you're using MailChannels Email API, billing is straightforward: we count only the messages that our service actually attempts or completes delivery of to downstream receiving servers. We do not count API requests that are made to inject messages into our sending pipeline. If your API call fails — due to a malformed payload, an authentication error, a rate limit, or any other reason — no sends are deducted from your account.

There is, however, an important nuance involving personalizations.

The Email API's personalizations array lets you send individualized messages to multiple recipients within a single API call. Each object in the personalizations array produces a separate, distinct email message delivered to its own recipient. This means a single API call that contains multiple personalizations will consume one send per personalization — not one send per API call.

Example: one API call, three sends

Here's a concrete example using the Email API's templating feature. The following single POST request to /tx/v1/send uses Mustache templates and three personalization objects to send a unique password-reset email to three different users:

curl -X POST "https://api.mailchannels.net/tx/v1/send" \
  -H "X-Api-Key: YOUR-API-KEY" \
  -H "Content-Type: application/json" \
  -d '{
  "personalizations": [
    {
      "to": [{ "email": "alice@example.com", "name": "Alice Nakamura" }],
      "dynamic_template_data": {
        "first_name": "Alice",
        "reset_url": "https://app.example.com/reset?token=abc123"
      }
    },
    {
      "to": [{ "email": "bob@example.net", "name": "Bob Petrov" }],
      "dynamic_template_data": {
        "first_name": "Bob",
        "reset_url": "https://app.example.com/reset?token=def456"
      }
    },
    {
      "to": [{ "email": "carol@example.org", "name": "Carol Díaz" }],
      "dynamic_template_data": {
        "first_name": "Carol",
        "reset_url": "https://app.example.com/reset?token=ghi789"
      }
    }
  ],
  "from": {
    "email": "noreply@app.example.com",
    "name": "Example App"
  },
  "subject": "Reset your password",
  "content": [
    {
      "type": "text/html",
      "value": "<p>Hi {{first_name}},</p><p>Click <a href=\"{{reset_url}}\">here</a> to reset your password.</p>",
      "template_type": "mustache"
    }
  ]
}'

This is one API call, but it produces three personalized email messages — one to Alice, one to Bob, and one to Carol — each with a unique greeting and reset link. MailChannels will count 3 sends against your account, because three distinct messages are delivered to three downstream receiving servers.

For more on personalizations and templating, see the Personalizations and Email Templates documentation.

Outbound Filtering: you pay for every attempted message

If you're a Outbound Filtering customer — typically a web hosting provider or multi-tenant SaaS platform relaying outbound email through MailChannels — the billing model is different. We charge for every message your users attempt to send through our service, including messages that our filtering engine blocks, rate-limits, or otherwise rejects. This is a deliberate policy, and one we've maintained for many years. Here's why.

The problem we're solving together

As a hosting provider or SaaS platform, you have hundreds or thousands of users sending email through your infrastructure, and you can't personally review every message. Some percentage of those users — often without your knowledge — will at some point start sending spam, phishing emails, or other forms of abuse.

When that happens, MailChannels steps in. Our filtering engine identifies the problematic traffic and blocks it before it can damage your IP reputation or the reputation of the broader sending pool. This is the core of what we do, and it works.

But blocking abuse is only half the battle. The other half — the half that actually matters for long-term deliverability — is making sure you take action against the abusive sender on your end.

Why free rejections create the wrong incentive

Imagine a world where we didn't charge for rejected messages. In that world, when one of your users starts blasting spam and we block it, there's no cost to you. The spam doesn't go out, your reputation is protected, and your bill stays the same. Problem solved, right?

Not really. Here's what actually happens: because there's no cost, there's no urgency. The abusive account stays active on your platform. It keeps trying to send. We keep blocking. And over time, the volume of attempted abuse grows — not just from that one account, but from others like it, because your platform has become known as one that tolerates abusive signups without consequence.

This is the classic problem in any shared-responsibility system: if one party bears all the cost of enforcement while the other party bears none, enforcement gradually breaks down. We've seen it happen. Platforms that don't feel the cost of abuse tend not to invest in preventing it.

How charging changes the equation

When you're billed for every attempted message — including the ones we block — something different happens. You start paying attention. You set up a webhook to receive real-time alerts from the Monitors service. You notice that a particular user or domain on your platform is generating a spike in blocked traffic. And because that spike is hitting your bottom line, you take action: you suspend the account, you tighten your signup process, you implement better verification, or you reach out to the user to understand what's going on.

In other words, billing for rejected messages closes the feedback loop. It transforms our blocking signals from something you might glance at into something you act on.

The counterintuitive outcome: you send less and pay less

Here's the part that surprises most of our customers. When you start actively responding to the signals MailChannels provides — shutting down abusive senders, tightening onboarding, monitoring your sending patterns — the total volume of email flowing through our service tends to go down. Not because your legitimate email decreases, but because the illegitimate email that was inflating your numbers gets eliminated at the source.

We've watched this pattern play out across hundreds of customers over many years. The ones who lean into the feedback loop end up with cleaner platforms, better deliverability, and lower bills. The ones who ignore the signals and treat our blocking as a "free" service tend to see their costs and their abuse volumes grow in lockstep.

We know it can feel unfair

We understand the initial reaction. When you see charges for messages that never reached anyone's inbox — messages sent by an abusive user you didn't authorize — it can feel like you're paying for someone else's bad behavior. And in a narrow sense, you are.

But consider the alternative. In email, reputation is everything. If we simply absorbed the cost of blocking abuse and asked nothing of you, we'd be enabling a dynamic where abuse on your platform has no consequences until it's too late — until your IPs are blacklisted, your legitimate customers can't send email, and the damage is already done. By then, the cost of remediation is far greater than the cost of a few blocked messages on an invoice.

Our pricing model is designed to keep you engaged in the process of maintaining a clean sending environment. It's an early-warning system with financial teeth, and it works precisely because it asks something of you.

What you should do

If you're an Email API customer and want to keep your send counts predictable:

1. Understand how personalizations multiply sends. Each object in the personalizations array generates a separate delivered message. Architect your API calls accordingly, and use the dry-run query parameter to preview the messages a call will produce before committing real sends.
2. Handle errors gracefully. Failed API calls don't cost you sends — but they do waste compute. Implement retry logic with exponential backoff and validate your payloads before sending.
3. Monitor your usage. Use the Metrics and Delivery Events features to track your sending volume and catch unexpected spikes early.

If you're a Outbound Filtering customer and want to bring down charges for rejected messages:

1. Use Monitors actively. Our Monitors & Alerts feature surfaces the users and domains on your platform that are generating abuse. Check your alerts regularly — or better yet, integrate it into your operations workflow by receiving Monitors webhooks so you can automate responses to abuse signals.
2. Act on the signals quickly. When Monitors flags a sender, investigate and take action. Suspend accounts that are clearly abusive. Reach out to users who might not realize they have a compromised account.
3. Tighten your onboarding. Many abuse problems start at signup. If you're seeing repeated patterns of abusive accounts, consider adding email verification, CAPTCHA, phone verification, or manual review for new signups.
4. Set sending limits. Reasonable per-user sending limits can contain the blast radius of a compromised or abusive account before it generates significant blocked traffic.

A shared commitment to a cleaner email ecosystem

At MailChannels, we see ourselves as your partner in maintaining email deliverability. Whether you're using the Email API or Outbound Filtering, our goal is the same: help you send the email that matters while keeping the email that doesn't from ever reaching an inbox.

For Email API customers, that means counting only what we actually deliver — so your bill always reflects real sending activity, not failed attempts. For Outbound Filtering customers, it means ensuring that you have the signals and the incentive to keep your platform clean — because in the long run, that protects your reputation, your users, and the health of the email ecosystem as a whole.

If you have questions about your bill, or if you'd like help optimizing your integration, our support team is always happy to help.

— Ken Simpson, CEO, MailChannels