> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mailchannels.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Reputation and abuse control

> Learn how MailChannels evaluates outbound email traffic at granular levels to stop abuse while protecting legitimate senders.

MailChannels protects outbound email reputation with a multi-stage filtering pipeline built for transactional email
from dynamic, customer-controlled sources. Messages can originate from applications, agents, CMS plugins, SaaS
tenants, sub-accounts, scripts, and other automated systems. The pipeline evaluates identity, infrastructure,
content, recipient patterns, and sending behavior before choosing how a message should be handled.

This page explains the architecture at a high level. It does not expose proprietary thresholds, scoring formulas,
model features, or threat intelligence sources.

## Granular identity tracking

Before MailChannels evaluates message content, it first determines who is responsible for the traffic. The platform
normalizes multiple signals into sender-level tracking context so abuse can be attributed more precisely than the
visible `from.email` address.

For Email API traffic, that context can include:

* The parent account.
* The sub-account, when a sub-account API key is used.
* The sending domain authorized by Domain Lockdown.
* The `campaign_id`, when included in the send request.
* Envelope and header details that help correlate related traffic.

This lets MailChannels separate legitimate traffic from suspicious traffic at narrow boundaries. For example, a
reseller can isolate each client with sub-accounts, then use `campaign_id` to distinguish campaigns or segments
inside a client sub-account. If one campaign starts producing abnormal bounce or complaint patterns, that traffic
can be understood in context without treating every message from the reseller as identical.

## Policy and infrastructure checks

MailChannels validates sender and account context before and during delivery. These checks help prevent spoofing,
unauthorized sending, quota abuse, and infrastructure patterns commonly associated with compromised systems.

Examples include:

* Confirming that the sender is authorized through Domain Lockdown.
* Evaluating SPF, DKIM, and DMARC posture for sending domains.
* Checking account, sub-account, plan, and usage constraints.
* Comparing sender, domain, IP, and URL signals with internal and external reputation data.
* Applying additional scrutiny to new domains, new sender identities, or traffic patterns without an established
  history.

These controls help stop abuse before it harms shared infrastructure or recipient trust.

## Content and payload analysis

Each message is evaluated for signs of spam, phishing, malware, credential theft, and other abusive behavior.
MailChannels uses layered scanning rather than relying on one signal.

The platform can evaluate:

* Message body and attachment characteristics.
* URLs and domains found in the message.
* Header structure and message formatting.
* Sender and reply-to alignment.
* Patterns commonly produced by compromised scripts or automated abuse tools.
* Similarities between messages that may be part of the same campaign, even when they use different sender addresses.

This layered approach lets MailChannels distinguish a normal transactional receipt from a credential phishing
attempt, a malware attachment, or a sudden burst of low-quality bulk mail.

## Behavioral profiling over time

Abuse is often visible only when messages are viewed as a stream. MailChannels evaluates sender behavior across
short and longer time windows so it can detect changes that a single-message scan may miss.

Behavioral signals can include:

* Message volume and sending velocity.
* Recipient validity and bounce patterns.
* Complaint and unsubscribe behavior.
* Repeated delivery failures.
* Sudden changes in content, domains, URLs, or recipient lists.
* New sender identities that ramp volume before building a positive history.

This is especially important for shared platforms and SaaS products. One tenant, client, script, or campaign can
be handled differently from the rest of the account when its behavior diverges from normal traffic.

## Recipient list and hygiene signals

Recipient quality is a major reputation signal. Poor list hygiene can look similar to abuse, especially when a
sender hits many invalid addresses, spam traps, or unrelated recipient patterns in a short time.

MailChannels evaluates recipient behavior and list structure to identify:

* Purchased or scraped lists.
* Dictionary-style address generation.
* High invalid-recipient rates.
* Repeated hard bounces.
* Complaint-heavy recipient groups.
* Suppression-list conflicts.

Use [suppressions and unsubscribe handling](/email-api/suppressions-unsubscribes) to keep bad recipients out of future
sends and to honor recipient preferences.

## Routing and enforcement

After MailChannels combines identity, policy, content, recipient, and behavioral signals, the platform chooses an
enforcement outcome. The goal is to protect legitimate senders and recipient networks while containing suspicious
or abusive traffic as narrowly as possible.

Possible outcomes include:

| Outcome                        | What it means                                                                                |
| ------------------------------ | -------------------------------------------------------------------------------------------- |
| Accept                         | The message is queued for delivery.                                                          |
| Defer                          | Sending is temporarily slowed or retried later when the traffic needs more control.          |
| Reject                         | The message is blocked because it violates policy or reputation safeguards.                  |
| Drop                           | The message is stopped before delivery and reported through delivery events when applicable. |
| Route with additional controls | Traffic may be handled differently based on risk, sender history, or reputation context.     |

These decisions are dynamic. A clean sender with stable behavior should not be treated the same way as a newly
observed sender with a sudden spike in invalid recipients, suspicious URLs, or complaint-heavy traffic.

## What this means for Email API users

For the specific things to do (and avoid) as a sender, see
[sending policies and best practices](/email-api/sending-policies).