Exchange admin tools

The Exchange admin surface in Manage365 covers the three operations MSPs run constantly: message tracing, DKIM management, and tenant allow/block list edits. Everything runs through the Exchange Online PowerShell sidecar — we don't try to replicate these via Graph because Graph doesn't cover them fully.

Message trace

Standard trace (last 10 days)

The on-page message trace searches the last 10 days of Exchange Online logs synchronously. Results return in seconds.

Filter by:

• Sender (user@domain.com)
• Recipient
• Time window (start + end, inside the 10-day window)
• Message ID (full or partial)
• Subject keyword
• Status (delivered / failed / pending / expanded / filtered)

Results per message include timestamp, sender, recipient, subject, size, status, message ID, and a drill-down to the detailed event log.

Historical search (11–90 days)

For anything older than 10 days, Exchange exposes a separatehistorical search API that runs asynchronously. Create a search job, Microsoft processes it in the background (usually 4–8 hours), and Manage365 pulls the result when ready.

Job lifecycle:

1. Submit: sender, recipient, date range, result format (CSV)
2. Manage365 returns a job ID. Status: queued
3. Status progresses: in_progress → complete (or failed)
4. On completion, Manage365 downloads the CSV, stores it in object storage, and notifies the requester

Large windows (30+ days, multi-recipient) can take longer. Microsoft's SLA is “up to 24 hours” — most complete in under 6.

DKIM management

DKIM signing per accepted domain. Three operations:

• Enable — enables DKIM signing on a domain. Automatically creates the 1024- or 2048-bit key pair if one doesn't exist.
• Disable — turns DKIM signing off without removing the keys.
• Rotate — issues a new key and swaps active signing to it. The old key remains published briefly so in-flight mail still verifies.

For each domain the tool lists:

• Enabled yes/no
• Key selector + public key (so you can paste into DNS)
• Last rotation timestamp
• DNS status — whether the tenant's CNAMEs point right

The DNS check is a lookup against your configured DNS resolver, not Microsoft's view, so “DNS looks fine from our end” isn't definitive proof against third-party authoritative servers — but it catches the common case (missing CNAME on a new domain).

Custom domain DNS

When a domain is added, Manage365 produces the two CNAME records the customer needs to add at their DNS host:

selector1._domainkey.acmehealth.com.au  CNAME  selector1-acmehealth-com-au._domainkey.acmehealth.onmicrosoft.com
selector2._domainkey.acmehealth.com.au  CNAME  selector2-acmehealth-com-au._domainkey.acmehealth.onmicrosoft.com

After the customer publishes those, click Enableand DKIM signing starts. The check-DNS button verifies both records exist.

Tenant Allow/Block List

Microsoft's Tenant Allow/Block list (TABL) is the right place to put senders, URLs, file hashes, and IPs that need permanent allow or block decisions — overrides that survive anti-spam policy updates.

Manage365's TABL management covers all four entry types:

• Sender — email address or domain. Allow or block. Expiry optional (default 30 days).
• URL — full URL or wildcard. Allow or block. Blocked URLs also add to Safe Links.
• FileHash — SHA256 hash of an attachment. Block only (allow requires admin submission, not TABL).
• IP — single IP or CIDR range. Allow or block for connection-level filtering.

For each entry the list shows: value, type, action, notes, created by, created at, expiry. Bulk import by CSV is supported on the Sender + URL types.

Endpoints

PowerShell sidecar

All three surfaces (trace, DKIM, TABL) live in Exchange Online PowerShell, not Graph. Manage365 runs a long-lived PowerShell sidecar process per API instance, authenticating with the same GDAP token flow via Connect-ExchangeOnline -DelegatedOrganization.

The sidecar is invisible to you unless something breaks. When it does, the Exchange tools → Health panel shows:

• Sidecar uptime
• Last successful Exchange cmdlet timestamp
• Recent failures + error messages

End-to-end example: BEC investigation

1. Finance reports they got a fake invoice. Sender: accounts@attacker.lookalike.com.
2. Run a message trace — last 10 days, recipient finance@acmehealth.com.au, status delivered.
3. See the email landed. Check the original email source from the trace drill-down.
4. Add the sender and the lookalike domain to the TABL as block sender entries. 30-day expiry.
5. If a link in the email was clicked, add the URL to TABL asblock URL.
6. If the user entered credentials, run the compromise remediation playbook.

Common pitfalls

• Trace returns nothing for a known email — check your time window (10-day limit) and confirm the exact email address — display names don't match.
• Historical search never completes — time windows over 30 days with broad filters can legitimately take 24 hours. If it's still queued after 48 hours, Microsoft has lost it — cancel and resubmit.
• DKIM enable fails with “CNAME not found” — the customer hasn't published the DNS records yet. Share the DNS check output with them; wait for TTL; retry.
• DKIM rotate breaks signing — normally it doesn't (both keys stay live briefly) but if the rotation happens during an in-flight queue the previous signature may already be stale. Wait 30 minutes before assuming it's broken.
• TABL entry rejected with “policy conflict” — the target is already covered by an anti-phish override. Remove the anti-phish entry, then add the TABL entry.
• Sidecar unhealthy — usually an expired GDAP token the sidecar is holding. Restart the API pod; the sidecar reconnects.

FAQ

Why PowerShell and not Graph? Graph doesn't expose message trace or TABL. DKIM exists in Graph but the PowerShell surface is more feature-complete. When Microsoft ships full Graph equivalents we'll swap over.

Can I export trace results? Yes — both trace types return a CSV URL from object storage. Historical search always produces CSV; standard trace has a CSV-export button on the results page.

Does TABL replace anti-spam policy tuning? No — it's for specific overrides. Broad anti-spam tuning still happens in the anti-spam policy; TABL is for surgical allow/block decisions.