How Seraph works

Seraph checks incoming email before delivering it to your mail server, and outgoing email before sending it to its destination. For incoming mail, traditional anti-spam and malware checks work alongside locally hosted AI classification. The results inform delivery decisions under your filtering policies. This guide explains those checks, what happens when delivery fails, and which messages and records the service stores.

Seraph has three parts:

• Filter nodes receive incoming email using your domains' MX records, check each message, and deliver accepted mail to your server.
• The relay checks and sends outgoing email from your server.
• The control plane manages servers, domains and filtering settings. It checks DNS, approves domains and distributes configuration. Delivery between mail servers is handled by the filter nodes and relay, without passing through the control plane.

On a DirectAdmin server, seraph-tool.sh installs the integration. Administrators, resellers and domain owners manage filtering through the Mail Filter plugin. References to "Seraph's operator" mean the Servada team responsible for the service.

Incoming mail

1. Connection. Filter nodes accept SMTP connections on port 25. Networks listed by Spamhaus DROP and servers listed by enough blocklists are rejected. Unfamiliar servers must wait four seconds before sending commands; sending too early can indicate an automated spam client. Connection history is remembered for a week.
2. Recipient validation. Seraph asks your server whether the recipient exists before accepting mail. A "no such address" response is cached for 15 minutes, so a newly created mailbox may need up to 15 minutes to become reachable through the filter.
3. Authentication and content checks. Seraph checks SPF, DKIM, DMARC, sender reputation and content rules, and scans for malware using ClamAV with additional signatures. Detected malware and known scam or phishing messages are rejected during the SMTP session. The sending server receives the rejection; the message is not delivered to your mailbox.
4. The model. A locally hosted AI model reads a short digest of the message: the sender's name and address and how it authenticated, where it came from, the subject, the links, the attachments' names, the start of the text, a few keywords, and the mailbox's own description where it has one. In the subject and the text, the recipient's address becomes a placeholder, other addresses keep only their domain, web links only their host, and bank account numbers, phone numbers and long runs of digits are removed. The sender is kept as is, on purpose: evaluating the sender is part of the check. This is not anonymisation: names in the text remain. Only the digest goes to the model, never the whole message, and Seraph keeps no copy of it: its record of each call holds a fingerprint, the time and the outcome. The model answers fixed questions, such as whether the message is phishing, spam, a cold sales pitch or legitimate. It never writes free-form text for message headers.
5. Filtering decision. Domain and mailbox settings determine whether accepted mail is delivered normally or marked as junk. Sensitivity can be relaxed, normal or strict. Messages that pass neither SPF nor DKIM receive stricter treatment and always go to junk under strict sensitivity. Blocked senders are rejected. Allowed senders are delivered when their From domain authenticates; malware checks still apply.

On your server, Exim keeps Seraph's verdict headers only on mail from Seraph, and a Sieve rule files junk in top-level Junk by default, or the folder selected for that address. The DirectAdmin guide lists the server changes.

AI classification and delivery decisions

Traditional checks establish sender authentication, reputation and known content or malware signals. The locally hosted model adds an assessment of the message's intent and context, including phishing, spam and unsolicited sales outreach. It receives the short digest described above, with the configured recipient context where available.

Seraph combines these results and applies the domain and mailbox policies. These determine whether accepted mail reaches Inbox, the selected spam folder or quarantine. For example, one mailbox can permit unsolicited sales emails while another sends them to spam. SMTP rejections and the handling of quarantined mail are described below.

The model supplies classifications; the configured policy determines the delivery action. Personal learning is a separate opt-in feature, explained under Learning.

The verdict headers

Delivered messages include headers describing the filtering decision. Your server uses these headers to file mail, and users can inspect them in their mail application's message source:

A message can also carry X-Seraph-Trace: the decision record, trimmed to fit a header and encrypted so that only Seraph can read it.

Quarantine

Spam normally goes to the selected spam folder. With quarantine enabled for a domain or mailbox, it is instead stored on the receiving filter node for 30 days. It reaches your server only when released. Recipients receive an expiry notice three days before deletion, at most once a day; role addresses such as postmaster@ are excluded from these notices.

Use the plugin's Quarantine tab to release or delete a message. Learning actions are also available where personal learning is enabled.

On each node, quarantine is limited to 1 GB per mailbox and 2.5 GB per domain. Once a limit is reached, new spam is delivered to the spam folder. If a node runs low on disk space, its oldest quarantined messages are also delivered there rather than deleted before their expiry date.

When something breaks

• Your server is unavailable, or its certificate cannot be verified. Accepted mail stays in Seraph's delivery queue for retry. The sender receives a delay notice after four hours and a failure notice after 48 hours. Seraph does not fall back to an unverified connection. If Seraph cannot validate a recipient, it returns a temporary SMTP error so the sending server can retry.
• Model unavailable. Messages that pass the other checks wait a few minutes for the model. If it remains unavailable, those checks determine delivery and X-Seraph-Evidence records model unavailable. Messages already classified as junk do not wait for the model.
• Virus scanner unavailable. The remaining checks determine delivery, and X-Seraph-Evidence says virus scan unavailable.
• Filtering unavailable. Seraph accepts and queues messages while waiting for filtering to recover. After five minutes, messages are delivered unchecked. They have no Seraph verdict and therefore reach the inbox. Messages rejected by a delayed check, such as malware, are retained on the node for 30 days and then deleted. They are neither delivered nor bounced.
• Recipients with different settings. A filtering decision applies to one message. When recipients have different settings, Seraph asks the sending server to split delivery into groups with matching settings. Sending servers handle this automatically; copies may arrive a few minutes apart.

Messages over 50 MB are refused.

Outgoing mail

• Scope. The relay handles mail from your server's domains, submitted by authenticated mailboxes or local scripts. Bounces and forwarded mail continue to use their existing route.
• Activation. Routing starts after DNS publishes Seraph's SPF include and the provider's record. The plugin either writes these records or displays the values for you to publish. Until then, the domain continues to send through its existing route.
• Connection. Exim connects to the relay on port 587 using verified TLS and a credential specific to your server. If the relay is unavailable, mail waits on your server for retry; it does not bypass the relay.
• Checks and limits. Malware is rejected. Each mailbox can send a burst of 50 messages, followed by 200 per hour. Messages above that limit wait on your server for retry. Server and domain limits also apply. Signs of phishing and a From address outside the server's domains increase a message's risk score.
• Held mail. Messages above the risk threshold are held for review without an automatic expiry. Only Seraph's operator can release them. In the plugin's Outgoing tab, you can delete a held message or request its release.
• Delivery. Most mail goes on through a delivery provider, such as MailChannels, over verified TLS. Seraph can also deliver some mail itself, a set amount a day while its addresses build a reputation. That uses DANE where the recipient's domain publishes it, its MTA-STS policy where it enforces one, and TLS wherever the other side offers it.
• DKIM. Your server signs as before. Seraph checks the signature and adds none of its own.
• Retries and bounces. Ordinary mail is retried for up to 48 hours, with a delay notice after four hours. Delivery-failure notices with an empty envelope sender have a shorter, six-hour retry lifetime by default. A recipient rejected as unknown during direct delivery is blocked for seven days, across both provider and direct routes, so subsequent attempts fail promptly.
• Sender identification. Mail sent through a provider carries X-AuthUser, a stable pseudonym identifying the sender within your server's Seraph account. It does not contain the mailbox's address or login. Seraph's operator can associate it with a mailbox through the relay log. Mail delivered directly by Seraph does not carry this header.

The port-25 lock

To prevent direct delivery from bypassing filtering, Seraph restricts inbound connections for a domain after its MX records have pointed exclusively to Seraph for 24 hours. Port 25 then accepts that domain's mail only from Seraph and any configured delivery-provider fallback hosts. The 24-hour delay allows cached MX records and queued mail at the previous filter to clear.

Other senders receive a temporary SMTP error (451), allowing them to retry after refreshing DNS. Authenticated users, mail clients on ports 587 and 465, and locally submitted mail are unaffected.

The control plane keeps the list of locked domains, and your server fetches it every 5 minutes. A domain whose MX moves away comes off the list. Seraph's operator can keep a domain open.

Learning

Two optional features use users' corrections to improve filtering. Both are disabled by default and involve storing copies of messages, as described below.

Personal learning

A mailbox can have a personal model trained on corrections: messages moved into or out of its selected spam folder, and the quarantine actions "deliver and learn" and "delete and learn".

• Enable Learn from corrections in the plugin for a domain or an individual mailbox. Domain settings provide the default for its mailboxes. The Learning tab shows training progress.
• A model becomes active after at least 20 usable spam corrections and 20 usable non-spam corrections.
• Correction messages are encrypted and stored on the control plane for 30 days. Each mailbox is limited to 1,000 messages and 32 MB, with the oldest removed first. Messages over 256 KB are excluded. Training runs in an isolated environment without network access, and the model is distributed to the nodes that process that mailbox's mail.
• The model can mark a message as spam when its confidence is at least 95% and the shared filter's result is close to the junk threshold. It cannot allow mail through or override phishing/scam detection, rejections, sender lists, content-rule junk decisions or DMARC checks.
• It is used for messages to that mailbox alone.
• Turning it off, or Start over, deletes the mailbox's corrections and its model.

Samples for Seraph

Shared samples are a separate feature. When enabled for a domain, your server keeps copies of spam corrections for manual review by Seraph after you export them. Non-spam samples require a separate opt-in. These copies can contain private correspondence and attachments. Read the consent and export instructions before enabling collection.

The control plane

• Servers. A server joins with a one-time enrolment code from Seraph, valid for 24 hours, and receives its own access token. Revoking the server invalidates that access.
• Domains. The plugin registers domains when filtering is enabled. Ownership is checked using a TXT record or an existing MX record pointing to the server. Automatic approval requires the ownership TXT record.
• Checks. Seraph queries authoritative DNS every few minutes and when you select Check again. Each filter node also checks TLS delivery to your server every 15 minutes.
• Approval. Domains with a published ownership TXT record and passing required checks can be approved automatically within your plan's domain limit; aliases count toward that limit. Automatic approval can be disabled for your account. Domains registered to another Seraph customer within the previous 90 days require operator approval. Server administrators can also require approval for requests from their users and resellers. Pending requests expire after 14 days, except where ownership is proven and the plan limit has been reached.
• Configuration. Every change becomes a new, numbered version of the configuration, checked before it is published. Each node fetches the newest one every 30 seconds and confirms that it runs it.

What Seraph keeps

Seraph stores delivery records for support and reporting. It also stores message copies for queued delivery, quarantine, held outgoing mail and learning features. Personal learning and shared sample collection are optional; enabling either creates additional message copies.

The retention periods below distinguish message content from metadata such as addresses, subjects and delivery outcomes. A model digest can still contain personal information despite the substitutions described under Incoming mail.

Two logs can contain addresses without a fixed time-based retention period:

• The relay's service log names each outgoing message's sender, recipients and login, and maps the sender's pseudonym back to its mailbox. It rotates by size, so older entries are replaced as new entries are written.
• The control plane's audit log records actions by operators and servers. Entries retain addresses involved in those actions, such as a mailbox whose learning data was reset.

The control plane database is backed up daily, with backups retained for 14 days. Data deleted from the live database can therefore remain in a backup for up to 14 additional days.

This website keeps no log of its visitors, and sets no cookies.