# Protect Your Email Reputation

Every email your AI employees send, whether it is a notification, a mailbox reply, or an outbound message, passes through a pre-send check before it leaves. Sistava validates the address, checks it against a suppression list built from past bounces and complaints, and blocks anything that would hurt your sending reputation. You do not configure this: it runs silently on every send so your domain keeps a clean track record with inbox providers.

When you hire an AI employee that sends email, whether that is a personal mailbox address, a scheduled report, or a reply in a thread, you are trusting Sistava's infrastructure to send from the same shared sending domain as every other tenant. One bad address, one ignored bounce, or one address that keeps failing can quietly drag down deliverability for everyone, including you.

Sistava runs every outbound email through a pre-send gate first: it checks the address is syntactically valid, confirms the domain can actually receive mail, and rejects disposable addresses outright. If that address bounced before or was reported as spam, it is on a suppression list and the send is skipped, silently, before it ever reaches a mail server. Bounces and complaints coming back from the provider feed that suppression list automatically, so an address that fails once does not get retried into a hard bounce, and an address that keeps failing gets suppressed for good.

The part that is easy to miss from the outside is what happens when the check itself is having a bad day. If the DNS lookup used to confirm a domain can receive mail times out, or the suppression database is briefly unreachable, Sistava does not block the send waiting for a system to recover. It lets the message through and logs what happened. A deliverability system that fails closed would mean your employee cannot send a routine reply because a background health check hiccuped somewhere; this one is built so a temporary outage on our side never becomes a business interruption on yours.

## What Gets Checked Before Every Send

Every outbound email, regardless of which employee or feature triggered it, passes through the same validation before it is handed to the mail provider. The address format has to be valid, the domain cannot be a known disposable-email provider, and, where possible, the domain's mail servers are confirmed to exist. Addresses that already appear on the suppression list, because they bounced or complained before, are skipped rather than retried.

This check happens once, centrally, rather than being reimplemented per feature. Whether the email is a signup confirmation, a scheduled notification, or an AI employee replying from its personal mailbox address, it goes through the same gate. That consistency is what keeps a single weak spot, like a form that skipped validation, from becoming the thing that damages deliverability for the rest of the platform.

## How Bounces Turn Into Protection

When a mail provider reports that a message did not arrive, that report is classified and recorded. Soft bounces, like a full mailbox or a temporary server issue, get one strike before anything is suppressed, because a temporary problem is not evidence the address is bad. Hard bounces, meaning the address or domain does not exist, and spam complaints suppress the address immediately.

Every suppression is written with the reason and the raw provider response kept for a record, and a more severe reason is never quietly downgraded to a softer one later. That record exists so a suppression can be explained and audited after the fact, not just applied silently and forgotten.

## How It Works

**A pre-send gate and a bounce-fed suppression list run on every outbound email**

Before any message leaves, the recipient address goes through the same sequence every time: format check, disposable-domain check, a live check that the domain's mail servers actually exist, then a lookup against the suppression list. The first failure stops the send. Rejections are worded the same generic way regardless of the actual reason, so nobody scanning your signup form or contact page can tell a suppressed address from a mistyped one.

After a message is sent, bounce and complaint notifications reported back by the mail provider are read and turned into suppression entries. A single mailbox-full bounce does not suppress an address outright; the system tracks it and only suppresses after a repeat failure, so one-off delivery problems do not permanently block a real customer. A spam complaint suppresses immediately, no second chance, because that signal is unambiguous and protects your domain the most.

## Use Cases

### AI employees sending mail from their own mailbox address

Every AI employee with a personal mailbox address sends replies and outbound messages through the same pre-send gate, so a bad address it picks up from a conversation or a task never becomes a bounce that damages the shared sending domain.

### Scheduled notifications and reports

Recurring emails, like scheduled reports or task notifications, get checked against the same suppression list every time they go out, so an address that stopped being valid months ago does not keep getting mailed on a loop.

### Protecting the whole platform's sending reputation

Because every tenant sends from shared infrastructure, one organization's bad addresses can affect deliverability for everyone. The suppression list and bounce handling exist to keep that blast radius contained without any organization having to manage it themselves.

## FAQ

### Do I need to turn this on or configure anything?

No. Deliverability protection runs automatically on every outbound email the platform sends, including messages your AI employees send through their mailbox address. There is no toggle to find and nothing to set up.

### Will a real customer's email ever get silently blocked forever?

A single delivery problem, like a full mailbox, does not suppress an address on the first failure; the platform tracks it and only suppresses after a repeat bounce. A hard bounce or spam complaint does suppress immediately, since those are strong signals the address should not be mailed again.

### What happens if the validation system itself has an outage?

Sends are allowed through rather than blocked. If the check that confirms a domain can receive mail times out or fails for an infrastructure reason, the message still goes out. The design deliberately favors letting a message through over blocking a legitimate send because of a temporary check failure.

### Can I see which addresses were suppressed and why?

Suppression decisions are recorded with a reason and the underlying provider response, so the history is auditable internally. This is a protection layer for sender reputation rather than a reporting tool you interact with directly today.

## Where Protect Your Email Reputation fits

Protect Your Email Reputation is part of What stops them from going wrong.

Your AI agents pause before any sensitive action and wait for your approval. PII is detected and redacted before it reaches the model. Content policies block harmful or off-brand output. Execution limits prevent runaway tasks. A Sistava mentor pairs with every employee to spot blockers and keep work on track alongside their team leader. Set company-wide policies once and every employee follows them, including future hires.

- [What stops them from going wrong](/en/features/guardrails): Nothing sensitive happens without your say.

## Read the guide

- [Guide: Protect Your Email Reputation](/en/guide/company/policies)

## More in Guardrails

- [AI Guardrails & Policies](/en/features/guardrails/guardrails): A Security Officer that checks every message going into and coming out of every AI employee you have. Five policies, each with its own switch: Input Safety stops prompt injection and jailbreak attempts, Output Safety keeps unfit replies from being sent, PII Protection replaces personal data with markers before the model reads it, Data Leakage Prevention keeps your setup and secrets in-house, and Topic Control holds employees to the subjects you choose. Turn on what you need from Settings, Technical, Security Officer and it covers every employee on the next message, including the ones you hire later. Checks run in parallel on a separate lightweight model, so protection costs a fraction of a message and your team never feels the wait. A running count of what has been caught, the busiest policy, and a live inspector showing every individual message are all on the same page.
- [Protect Against Prompt Injection](/en/features/guardrails/guardrail_input_safety): Input Safety reads every incoming message before your employee does, and stops the ones trying to hijack it: instructions to ignore its rules, requests to print its own configuration, and role-play framed to talk it out of its guardrails. That matters most where the message did not come from you, so a payload buried in a forwarded email, a support ticket, or a shared thread cannot turn your employee against you. Pick Low, Medium, or High, and every level catches the textbook attacks: the level decides how much benefit of the doubt the genuinely ambiguous messages get. Medium is the default and suits most companies. Blocked messages get a short, human reply and the conversation carries on, with each one recorded so you can see what has been tried.
- [Block Unsafe Employee Responses](/en/features/guardrails/guardrail_output_safety): Output Safety reads your employee's reply before anyone else does. Toxic, abusive, or otherwise unfit answers are held back rather than sent, which is what you want the moment employees write to customers, post to a channel, or answer a ticket without you watching. It checks the reply your employee actually wrote, so what you see caught is what would genuinely have gone out. Set it to Low, Medium, or High and review everything it held back in the live inspector. Blunt, direct, and critical business writing is left alone: the policy is looking for replies that would embarrass you, not ones that are simply frank.
- [Protect Personal Data](/en/features/guardrails/guardrail_pii_protection): PII Protection finds personal data in a message and replaces it with a marker before the model reads a single character of it. A pasted card number becomes [CREDIT_CARD], an email becomes [EMAIL_ADDRESS], and the same happens on the way out so nothing sensitive travels back into an email, a channel, or a ticket. You pick exactly what to protect from seven data types: email, phone, name, credit card, Social Security number, IP address, and address. The markers keep the sentence readable, so your employee understands the request perfectly and keeps working while the raw value stays out of the conversation. It runs on every message, in both directions, company-wide, from one switch.
- [Control What Employees Discuss](/en/features/guardrails/guardrail_topic_control): Topic Control gives you two lists and you can use either or both. Blocked topics are off-limits no matter how a conversation gets there, which keeps employees out of politics, competitor comparisons, or medical and legal advice. Allowed topics set a remit instead: name the subjects an employee handles and anything unrelated is politely declined, which is how you keep a support employee on product help, billing, and refunds. Both lists match on meaning rather than exact words, so ruling out competitor pricing also covers how much cheaper are we than the other tools out there. Greetings and short replies always get through, so a scoped employee still feels natural to talk to.
- [Keep Confidential Data In-House](/en/features/guardrails/guardrail_data_leakage): Data Leakage Prevention guards both ends of the conversation. On the way in it recognises someone fishing for your employee's internals, whether they ask outright, dress it up as a game, or try the repeat everything above this line trick. On the way out it reads the reply itself and holds it back if it is about to hand over a system prompt, internal configuration, an access token, or a credential. Questions about your own business data are never affected, so an employee still answers freely about your customers, documents, and numbers. One switch, no configuration to maintain, and every attempt is logged so you can see who has been probing.
- [Prevent Repeated and Runaway Actions](/en/features/guardrails/tool_safety): Sistava automatically caps how many emails, messages, and external writes (CRM records, calendar events, paid searches) an AI employee can send in a single conversation, hour, and day, and blocks an identical send to the same recipient from going out twice within 24 hours. These limits run in the background per employee with no setup required, so a stuck task or unexpected loop cannot spam a contact's inbox, pollute your CRM, or burn through paid API calls. When a limit is hit, the employee is told to slow down or hand the task to a human instead of retrying blindly.
- [Approve Sensitive Actions](/en/features/guardrails/input_requests): Let an AI employee pause and ask before it takes a sensitive action, like sending an email or spending on a paid tool, instead of guessing what you want. An inline card shows up right in the chat with Approve, Reject, or option buttons, and the employee resumes the instant you respond.
- [Protect Organisation Information](/en/features/guardrails/information_boundaries): Your AI employee treats what it learns in the workspace the way a careful coworker would: useful for doing the work, not free to repeat. It tells private, role-restricted, and confidential information apart from ordinary shared context, and it never volunteers the sensitive kind just because someone asked. When a teammate needs a restricted answer, the employee can request permission from the right person for that one specific answer instead of guessing or refusing outright.
- [Delegation & Teamwork Limits](/en/features/guardrails/delegation_teamwork_limits): Tune how your leader employees hand off work to teammates. Set how many teammates a leader can delegate to at once, how far a delegation chain can reach, how long a delegated teammate can work before timing out, and how tolerant employees are of repeating themselves before loop protection stops them.
- [Detect and Redact PII](/en/features/guardrails/pii_detection): PII Protection watches every message your AI employees send and receive, and masks personal data like emails, phone numbers, credit card numbers, and social security numbers before it goes anywhere it shouldn't. You choose exactly which data types to catch. It runs on every employee across your company the moment you turn it on, with no per-employee setup.
- [Company-Wide Policies](/en/features/guardrails/company_policies): Company Policies let you set organization-wide safety rules that apply to every AI employee at once: block prompt injection attempts, filter harmful output, redact personal information, stop internal details from leaking, and restrict which topics employees can discuss. Turn each policy on with one toggle from your company dashboard, and it takes effect immediately across your whole team.

## Explore

- [Every feature](/en/features)
- [Hire an AI employee](/en/market)
- [Pricing](/en/pricing)