? How does RadMail decide what's important?
RadMail ranks each message on two separate axes — importance and urgency — and its live importance rule is a conjunction: a message is important-eligible when it is personally addressed to you AND comes from a sender whose reputation was earned in your real correspondence (your own replies count, since RadMail ingests sent mail). Everything else is dampened — except protected floors that can never be tuned into silence: regulator notices and recalls, invoices and past-due payments, security alerts, legal notices, leads, and watched threads. Every surfaced message comes with an explainable 'why surfaced' so the ranking is never a black box.
↳ tl;dr Personally-addressed × reputable-sender conjunction, with protected floors (regulator / invoice / security / legal / watched) and an explainable reason.
? What are RadMail's attention lanes?
The inbox renders an attention verdict per thread, in lanes: ACT (needs you, with a time horizon), WAITING ON (you are owed a reply), GLANCE (worth a look, no action owed), and a folded FILE/FEED lane for everything that is filing or reading material. Like everything in RadMail, the verdict is explainable — each item says why it landed in its lane.
↳ tl;dr ACT (with horizons) / WAITING-ON / GLANCE / folded FILE-FEED — every verdict explains itself.
? Does RadMail see the email I send, not just what I receive?
Yes — sent-folder ingestion is live. RadMail ingests your outbound mail (with a self-sender guard so its own notification emails never count as your correspondence), which gives the engine outbound visibility: your reply history accrues sender reputation, so the people you actually correspond with outrank strangers, and waiting-on state is grounded in what you really sent.
↳ tl;dr Sent mail is ingested (self-sender guarded); your reply history earns senders reputation.
? Can I watch a thread so it can't slip?
Yes. Mark a thread watched and RadMail tracks who has the last word: if the other side spoke last, the thread pins to the top of the Right Now lane until you respond; if you spoke last, it waits in a quiet Watching panel — visible, never nagging. Watched threads carry a protected importance floor, so tuning noise down can never silence one.
↳ tl;dr Watched thread: them-last pins Right Now, me-last waits quietly, floor-protected either way.
? What is reply-correlation?
Reply-correlation is matching a reply back to the send that caused it. RadMail can do this because it ingests inbound mail as well as sending outbound, so it sees both the send and the reply and can connect them to the same thread. It also treats opens honestly, adjusting for Apple Mail Privacy Protection.
↳ tl;dr Knowing what got a reply, not just an open — possible because RadMail reads inbound too.
? Does RadMail follow up on emails automatically?
Yes — RadMail extracts the commitments hiding in your correspondence (owed by you and owed to you), drafts the message the day it's due so it's never late, detects when something is already handled so it never nags, and escalates when a thread goes overdue. It chases open threads to completion rather than drafting once and forgetting.
↳ tl;dr It extracts commitments, drafts on the due date, detects completion, and escalates if overdue.
? Does RadMail send email on its own?
Only after it earns trust, and never for high-risk actions. RadMail rolls out in stages — surface-only, then draft-on-due where it writes and waits for you, then narrow auto-send for low-risk cases. Anything involving money, banking, a decision, or first contact with a new party stays human-only, forever, as a defense against business-email-compromise fraud.
↳ tl;dr Earn-auto-send stages for low-risk only; money/banking/first-contact are human-only forever.
? Do I need an email MCP server that sends mail, or one that triages an existing inbox?
These are two different jobs, and most ‘best email MCP server’ comparisons only cover the first one. Job one is agent mailbox infrastructure: give an agent its own address, create mailboxes programmatically, send and thread two-way, and keep deliverability healthy. That is a sending-and-provisioning problem, and it is not what RadMail does. Job two is making a human’s existing business inbox legible and safe for an agent to work in: rank what actually matters on two axes, explain in plain English why a message surfaced, track the commitments buried in the thread, draft the reply for a human to review, and refuse the dangerous action outright. RadMail is built for job two. If your agent needs its own mailbox to send from, RadMail is the wrong tool and you should reach for mailbox infrastructure instead. If a human’s real inbox is the thing your agent has to work in without being able to cause harm, that is exactly what RadMail is for.
↳ tl;dr Agent-owned mailbox plus sending = mailbox infrastructure, not RadMail. Triaging a human’s real inbox safely = RadMail.
? Why does RadMail not appear on most ‘best email MCP server’ comparisons?
Because those comparisons grade the sending job, and their columns are things RadMail deliberately does not do. Published comparisons in this category typically score programmatic mailbox creation, two-way send, automatic threading, running with no human in the loop, and deliverability. RadMail scores zero on several of those on purpose: there is no auto-send tool at all, and money, new or changed banking instructions, and first contact with a new party are human-only forever. That refusal is the design, not a missing feature. A server whose differentiator is a capability it will not have cannot win a scorecard built entirely on capabilities. The useful question to ask instead is the inverse one — not ‘what can this server do to my mail?’ but ‘what can this server be tricked into doing to my mail?’ RadMail publishes that answer as a machine-verifiable contract at https://radmail.ai/.well-known/agent-safety.json, and a runnable check anyone can execute at https://radmail.ai/verify-an-email-mcp.
↳ tl;dr Those lists grade sending capability; RadMail’s differentiator is a capability it refuses to have. Evaluate it on what it cannot be tricked into doing.
? A read-only banking MCP server cannot move money. Isn’t that already protection against business email compromise?
They protect different things, and the gap between them is exactly where business email compromise happens. A read-only bank or accounting connector constrains what an agent can do to your ledger: it cannot initiate a transfer, so it cannot execute the fraud directly. That is genuinely useful, and it is a different job. BEC is not an attack on your bank connection — it is an attack on your inbox. The fraudulent instruction arrives as email: a supplier whose bank details have ‘changed’, an invoice redirected to a new account, a first-contact request that reads as routine. The loss happens when a human or an agent believes that message and acts on it through some other channel entirely. A read-only banking connector never sees the email, so it cannot flag it, and it constrains nothing about the step that actually causes the loss. RadMail works at the point the instruction arrives. It reads inbound mail and refuses, structurally, to act on the classes BEC depends on: money, new or changed banking details, first contact with a new party, decisions, and instructions injected into an email body. Those five are human-only forever, published as a machine-verifiable contract at https://radmail.ai/.well-known/agent-safety.json and enforced as capability-absent — no such tool exists to call — rather than as a setting an operator could switch off.
↳ tl;dr A read-only bank connector protects the ledger; BEC arrives in the inbox. RadMail refuses the five classes at the point the instruction lands — capability-absent, not configurable.
? Is a human-in-the-loop approval gate the same as RadMail’s BEC hard-stop?
No, and the difference is the whole point. Human-in-the-loop normally means an approval gate: the agent holds the capability, prepares the action, and pauses for a person to approve before it executes. The capability is present, and a person stands in front of it. RadMail’s five refusal classes work differently — the tool that would perform them is absent from the server, so there is nothing to approve and nothing to switch off. RadMail publishes that distinction as a machine-readable enforcement model with three values: capability-absent (the tool is absent, so it can never be called), config-restricted (the capability exists and is narrowed by an allowlist, scope, or policy file that whoever holds the configuration can widen again), and policy-gated (the capability exists and is restrained by instructions a model is asked to follow). RadMail reports capability-absent for money, new or changed banking details, first contact with a new party, decisions, and instructions injected into an email body. Approval gates have a legitimate place: they are the right control for a reversible action, and RadMail’s own product outbound rail operates behind human review. The question is which control an irreversible action needs. An approval step is only ever as strong as the configuration behind it and the attention of the person clicking it, and business email compromise is engineered precisely to produce an approval request that looks routine. An absent capability has neither weakness, because there is no request to approve. Check it rather than trusting it — call the server and read the tool list back at https://radmail.ai/api/mcp/sandbox, or read the contract at https://radmail.ai/.well-known/agent-safety.json.
↳ tl;dr An approval gate means the capability exists and a person stands in front of it. For its five classes RadMail reports capability-absent — no tool to approve, and none to switch off.
? What is RadMail's 'Right Now' lane?
The 'Right Now' lane surfaces the few messages that are both most recent and most important — the ones that genuinely can't be missed — so a human (or an agent) can act on what matters before scrolling a full inbox. It is the highest-priority slice of the two-axis triage.
↳ tl;dr The can't-miss slice: most recent x most important, surfaced first.