EnterraHost
Inbound filtering stops bad mail arriving. Outbound filtering stops your own domain sending it. The usual cause is a mailbox password that leaked, and the first sign is normally a bounce, a complaint, or a blacklisting notice rather than anything inside your network.
What changes when it is on
Outbound filtering is a gateway. Your server stops delivering mail straight to the recipient and hands it to the filter instead, which checks it, adds authentication, and passes it on. Mail that fails the check is held rather than sent.
Nothing about your mailboxes changes, and nothing about inbound delivery changes. This is a second path for mail leaving the domain, not a replacement for the MX records that carry mail in.
Two ways to send through it
A smart host is the usual arrangement. Your mail server keeps behaving as it does now, with one setting changed so that all outgoing mail is relayed through the filter. Every user, every script and every application on that server is covered by one change. For a server you control, that is the right answer.
The other arrangement is per-user authentication, where the filter is used directly as the outgoing SMTP server. That suits a single application or a handful of senders rather than a whole server, and it means each sender carries its own credentials.
Both use the same relay, 683.smtp.antispamcloud.com on port 587, with authenticated SMTP. The relay only accepts mail from a sender it recognises, which is the next decision.
Choosing how the relay recognises you
The console manages this under Outgoing, then Manage users. There are three ways to be recognised, and the choice depends on whether your sending server has a fixed address.
An IP user authorises one address or a range. No password is involved, because the cluster accepts the connection on the strength of where it came from. This is the simplest option for a server with a static address, and it is the one to avoid on a connection that changes.
A domain user is a username and password created for the filter. Your server authenticates with those credentials, which works from anywhere and is the option for a dynamic address.
An authenticating domain uses the domain itself as the username with a password you set. It is the same idea as a domain user with less to remember, and it suits a server whose address is not fixed.
The console is the only place these are created. Our own API can see and manage the filter, but not the outgoing users, so the console is the route for this part of the setup.
The SPF record
Receivers check whether your domain authorised the server that sent the message. Once mail leaves through the relay, the relay has to be in that authorisation, and the value to add is include:spf.antispamcloud.com.
A domain has exactly one SPF record. Adding a second one does not extend the first, it makes the result ambiguous and the domain fails the check, so the include goes inside the record that already exists. Where the record is ours to edit, the toolbox merges the include in and keeps your existing mechanisms and your all qualifier, because loosening a mail policy is your decision rather than ours.
If your DNS is held elsewhere, the same include is added by hand at that provider. Adding SPF, DKIM and DMARC covers the records around it.
Turning it on in the toolbox
Outbound filtering is an add-on to the inbound service rather than a separate product. Open Mail Protection in the toolbox, open the domain, and use Add Outbound filtering. The change starts an order, and the console section above becomes available once the service is active.
The DNS panel in the toolbox shows the records the domain needs and marks each one live or pending, so the SPF change can be confirmed from the same screen rather than from a third-party checker.
When something is held on the way out
Outbound mail is logged like inbound mail, in the outgoing side of the log search. Two optional columns, Sub Class and Extra Class, are worth adding when you are diagnosing a block, because they carry the reason rather than only the outcome.
Some blocks are about attachments. Executable files and documents containing macros are refused outright, which is a policy the platform applies to keep its shared sending reputation intact, and the class shown in the log says so. The fix is to send the file another way rather than to retry it, because a retry produces the same result.
Releasing an outbound message is not something the console offers. The platform holds those messages, so the console's job here is to tell you what happened and why. Releasing a message from quarantine covers the inbound case, which does have a release button and a training action.