AegisAI Perspectives · 126
Reduce email security false positives in order: count them for 30 days, trace each to its rule or verdict, fix that layer, and keep a release path open.
See it on your own Google Workspace or Microsoft 365 tenant. No MX change.
Or get the Q3 2026 State of the AI Attack report (free, instant download)
Not ready for a demo? Check your domain (free, about 10 seconds).
Reduce them in order: count them, trace each one to the layer that caused it, fix that layer, then keep a release path. Microsoft lists 5 places a spam false positive can come from2.
AegisAI investigates every email for what it is trying to do, and removes the ones that fail from every mailbox they reached15. If you run IT for a company of 20 to 500 people on Microsoft 365 or Google Workspace, with a lean IT or security team and no SOC, this is the order of work for you. The product side is on the inbound email security page. Why filters flag real mail is covered in why email security false positives happen. One quarantined invoice, start to finish, is in how to stop real invoices being quarantined. This page is the program around both.
Microsoft lists five sources of a spam false positive: a Tenant Allow/Block List block entry, the user's Blocked Senders list, a mail flow rule, an anti-spam policy verdict and the connection filter IP block list. Each source has its own fix. A fix aimed at the wrong one adds risk and removes nothing, so the count comes before the change.
In the default anti-spam policy, quarantined messages are held 15 days by default, you can set 1 to 30 days, and expired messages are permanently deleted6. A monthly review of a 15 day quarantine misses half the month.
Export the quarantine every week, before the retention period deletes the evidence.
Short on time? Watch the explainer, or book a demo.
Pull 30 days of quarantined and junked mail, with weekly exports so nothing expires first. Label each message legitimate or malicious.
For each legitimate message, read the X-Forefront-Antispam-Report header. A Bulk Complaint Level (BCL) of 7 to 9 means the bulk mail threshold likely blocked it, and the default threshold is 71.
Trace each message to one of the five sources. Count false positives per source and per rule or verdict, then fix the largest count first.
If a Tenant Allow/Block List block entry caused it, remove or narrow that entry. Block entries take precedence over allow entries, so an allow added on top does nothing4.
Fix the sender's authentication records with the sender, but never treat a pass as proof of trust. AegisAI research found 72.6% of the AI-written spear phishing that got past native filters passed DMARC20.
Submit every misclassified message as not junk. Microsoft calls reporting the single most important thing you can do to improve filtering accuracy11.
Where an exception is still needed, use the narrowest one. Microsoft ranks Tenant Allow/Block List allow entries first and anti-spam allowed sender lists last8.
Wait 15 to 30 minutes for a policy change and up to one hour for a mail flow rule change3. Then test with the same content type and sender domain, and read the headers again.
Write down the release path: who releases which verdict, and how fast. Recipients can't release malware or high confidence phishing, only request release7.
Run steps 1 to 3 before you touch a single policy.
DMARC is fixed at the sender, not in your filter. A pass proves the domain was authorized to send, not that the request is real: of the AI-written spear phishing that got past native filters, 72.6% passed DMARC. Never use a pass as the reason for an allow entry.
Allowlists need an end date. By default, allow entries are kept for 45 days after the filtering system finds the entity clean, then removed5. Allowed sender and domain lists in anti-spam policies are the riskiest form. Microsoft says to avoid them if at all possible, because those senders bypass spam and phishing protection, sender authentication included9. In Google Workspace, an approved senders list bypasses Gmail's spam filters12, so list addresses, not whole domains.
Threshold calibration moves both errors at once. The bulk threshold defaults to 7, and raising it lets more bulk mail through to every user, not only the sender you meant to help.
Record an owner and an end date for every exception you add.
Stop when the same source keeps producing false positives after steps 3 to 7, or when your exception list grows every month. At that point the detection method, not the setting, is the cause.
A January 2026 paper reports a 66.7% reduction in false positives when retrieval of context is added to a language model classifier13. Context about the sender and the request is what a fixed threshold does not have.
Test a replacement layer in monitoring mode, next to your current filter, before it acts on any mail.
| Criterion | Tune the current filter | Change the detection layer | Inbound email security |
|---|---|---|---|
| What you change | Thresholds and exceptions, per source | How each verdict is reached | Investigates every email for what it is trying to do |
| Bulk mail | The BCL threshold, default 7 | Bulk sorted apart from threats | The same agents that judge threats sort bulk mail17 |
| Exceptions to keep | Allow entries, removed after 45 days by default | Fewer, if verdicts improve | No published figure on exception counts |
| Reason a person can read | Header values such as BCL | Depends on the product | Its reason in plain language16 |
| False positives measured | Your own count from step 3 | Your own count in monitoring mode | 90% fewer than rule-based filtering, measured in customer environments23 |
| Holds mail before delivery | Yes, the filter sits in mail flow | Depends on placement | No edge. It reads mail through the API after delivery21 |
The last row is no edge for the inbound layer: it acts after delivery, not in the mail path. Fill one copy of this table with your own counts before you decide.
AegisAI investigates every email for what it is trying to do, and removes the ones that fail from every mailbox they reached. Every verdict comes with its reason in plain language, so your team can check it and share it. The same agents that judge threats sort bulk mail, so real mail keeps moving and quarantine holds only what is dangerous. Runs in monitoring mode first22.
Illustrative example, figures are fictional: Alder Point Logistics (fictional) has 180 people on Microsoft 365 and one IT admin. She exports quarantine every Friday for four weeks and labels 412 messages, of which 61 are legitimate. Tracing them, 38 come from one mail flow rule that flags invoice attachments, 14 from the bulk threshold and 9 from an old domain block entry. She narrows the rule, removes the block entry and submits all 61 as not junk. She adds two address allow entries, each with an owner and a 45 day review. In week five, legitimate messages in quarantine fall from 15 a week to 4. The bulk count does not move, so she starts a monitoring-mode test of a second layer for newsletters and vendor mail.
Run this walk on your own quarantine export this week.
Track three numbers, each from a log you can export.
To compare a second layer against these numbers on your own tenant, start a monitoring-mode trial. Put the three figures side by side on day 30 and decide on them.
Count them for 30 days, trace each one to its source, fix that layer, submit the misclassified mail and keep narrow, dated exceptions. When tuning stops helping, test another layer: AegisAI investigates every email for what it is trying to do, and runs in monitoring mode first.
No. Use the narrowest exception that works. Microsoft says to avoid allowed sender and domain lists in anti-spam policies, because those senders bypass spam and phishing protection.
By default, 45 days after the filtering system finds the entity clean, then the entry is removed. Give each one an owner who decides whether it is still needed.
Not for every verdict. Recipients can't release messages quarantined as malware or high confidence phishing; they can only request release. An admin owns those releases.
It removes some, but a pass does not prove a message is safe. Of the AI-written spear phishing that got past native filters, 72.6% passed DMARC.
