Mail Security Questions, Answered from Chat

August 17, 2026 · InfraScout Team

The same mail-security questions come back every few weeks. Did the spam filter catch something it shouldn't have? Does anyone still send us mail without encryption? Which systems actually send as our domain? And did last month's fix really close the gap? Each one normally means the Defender portal, an Exchange Online PowerShell session, the on-premises Exchange shell and a log export or two, and then stitching the answers together by hand.

With InfraScout, you ask the question in chat and the AI gathers the evidence across all of those sources. You get an answer based on how mail actually flowed, not just on how it is configured. This post walks through four such questions in a typical hybrid Exchange setup, with on-premises servers alongside Exchange Online, and closes with the technical details worth keeping.

The setup

You need an InfraScout agent on the on-premises Exchange host and a Microsoft 365 connection with the security and mail-flow permissions described in the Microsoft Security tools reference. If you want reports to land in your team wiki or findings to reach your ticketing system, connect those as external MCP servers.

A starting prompt can be short:

Review our mail security for the last 24 hours. Pull the anti-spam,
connector and transport-rule configuration, then check how mail
actually flowed. Stay read-only. Save real gaps as insights and tell
me what you could not verify.

The sessions below range from about seven minutes for a quick quarantine check to about an hour for a full daily report with a routing investigation.

Did the spam filter quarantine legitimate mail?

The quickest version of this question is a false-positive sweep. You ask for the last thirty minutes of spam, and the AI lists quarantined messages through message trace and returns a table of sender, subject and quarantine reason. You scan it, spot anything that looks legitimate, and ask for the full analyzed email record behind that verdict. If a user then reports odd mailbox behavior, the same conversation can read their current inbox rules and query the audit log for recent rule changes.

The daily view

The broader version is a daily spam analysis. The AI runs a session on the on-premises Exchange host, connects to Exchange Online with app-only certificate authentication in a read-only context, and pulls the anti-spam policies, connectors and transport rules. It then runs Defender advanced hunting over the last 24 hours of EmailEvents and opens individual analyzed emails where a verdict needs explaining.

Say two transport rules set the spam confidence level (SCL) to -1 and at first glance look unscoped. The AI says it needs the full condition set before rating them, re-reads them properly, and only then reports the finding: one rule is broad enough that a phishing message reached a mailbox. That finding becomes an insight.

The report goes to your team wiki through its MCP server, and the AI saves a publishing note to memory so later runs format the page the same way. Once the format settles, you can run the report on a schedule as an agentic workflow.

When the admin knows something the data doesn't

Suppose you tell the AI that mail no longer routes through an old third-party filtering service and that MX points straight at Microsoft 365. The AI treats that as a claim to verify. It confirms MX has no legacy entry, then compares the sender IP in EmailEvents with the connector IP in message trace. The result is something configuration alone would never show: some phishing still arrives through a legacy inbound connector.

Does any inbound mail arrive without TLS?

The obvious data sources don't answer this one. EmailEvents has no TLS field, and when the AI tries to read message headers from mailboxes, an application access policy blocks it. That block is good governance, so the AI reports it and asks how to proceed instead of working around it.

It then goes where the evidence lives: the on-premises receive connectors and their SMTP protocol logs. In this scenario, roughly a tenth of front-end sessions have no STARTTLS, and all of them come from internal addresses. Every external session is encrypted. The AI extends the check to Exchange Online traffic and turns up one message that arrived over an unencrypted connector route and was blocked as suspicious.

The answer is specific: no external mail arrives without TLS today, but TLS is not enforced anywhere. Whether to enforce it is now a decision you make with data.

Which IPs do our mail systems send from?

SPF hygiene starts with knowing every system that sends as your domain. The AI identifies the mail servers from memory, reads their network configuration with PowerShell, and lists the connectors, keeping the IPs that matter for outbound mail separate from those that only receive.

It also flags a limit on its own evidence: an IP seen on a connector may belong to a relay host rather than the original sender. If the list doesn't match the inventory you assumed, as it often doesn't, that is exactly why you check before editing an SPF record.

Did the transport-rule fix actually work?

Suppose a transport rule let self-spoofed mail skip spam filtering, and a change has closed the gap. You hand the AI the change ticket. It reads the ticket and the related insights, builds its own task list, and checks behavior rather than configuration.

Advanced hunting over the period since the old rule was disabled shows several genuine self-spoof attempts, all quarantined and none bypassing filtering. The admin audit log confirms which changes were actually made, and a live read of the anti-phishing policy confirms it is unchanged. The AI updates the insights, marks a duplicate as superseded, and comments on the ticket with the evidence. It leaves the status alone, because one step remains: switching the new rule from audit mode to enforce.

Knowledge worth keeping

SCL -1 turns a rule condition into an allow-list

A transport rule that sets SCL to -1 bypasses spam filtering entirely. Any condition that spoofed mail can satisfy, such as "sender domain is ours" with no source-IP or connector scoping, becomes an allow-list for attackers. Self-spoofed mail, where the From address uses your own domain, should be caught by composite authentication and anti-spoofing, but a bypass rule applied first overrides them.

Validate a fix by behavior. After the change, query EmailEvents for DeliveryAction, DeliveryLocation, AuthenticationDetails and SenderIPv4, then confirm in the admin audit log what was changed and when. When you replace a rule, create the new one in audit (test) mode and watch its hits before you enforce it.

For TLS, remember that EmailEvents does not record it. Inbound TLS shows up in the SMTP protocol logs as STARTTLS, or in message headers, and message trace details can help. A receive connector's RequireTLS setting tells you what is enforced, not what actually happened. If you script message traces yourself, note that Get-MessageTrace is deprecated in favor of Get-MessageTraceV2.

For SPF, MX shows where inbound mail lands, not who sends as your domain, and connector IPs may be relay hosts rather than original senders.

Where the guardrails sit

These sessions are almost entirely read-only. The AI uses read-only shells where possible and disconnects from Exchange Online cleanly. When a lookup is blocked, it asks you instead of finding another way in. It holds back a finding until it has seen a rule's full conditions, and it doesn't change a ticket's status while a follow-up remains. Findings go into insights, and the session goes to review like any other assessment. Mail content and tool output count as untrusted data, so instructions hidden in a phishing message never become instructions to the AI.

Next steps

Start with the Microsoft Security tools and Microsoft Services tools references to see what the AI can read in your tenant. Read how insights record findings for review, and turn a recurring check into a scheduled report with agentic workflows.