Blue Lantern Security's mail posture scan checks your email configuration once a day from two directions. Outbound: are SPF, DKIM, and DMARC published correctly for your sending domains, so others can tell your real mail from spoofed mail? Inbound: has anyone set up auto-forwarding to an outside address, or an inbox rule that hides, deletes, or diverts mail, the moves attackers make after compromising an account? Each scan produces an exportable report and feeds your attestation report.
Enable email configuration monitoring
Access: included with the Gmail or Microsoft 365 organization integration on a Seat License at $15 per monitored user per month. Enable it with a checkbox in the integration's settings; it runs once daily. Domain authentication checks use public DNS lookups only. See current pricing.
Email configuration drifts. A marketing tool gets added without updating SPF. A DKIM selector expires. And after a successful phishing attack, the first thing an attacker does inside a mailbox is set a forwarding rule, so they keep receiving copies of invoices and conversations long after the password is changed. A daily check catches all three.
What does the mail posture scan check?
| Check | What it looks for | Notes |
|---|---|---|
| Mail authentication | DMARC, SPF, and DKIM selector posture for your sending domains: missing records, weak policies, and missing or misconfigured DKIM selectors (the google._domainkey selector on Google Workspace; the provider selector on Microsoft 365) | Public DNS lookups only; no mailbox permissions involved |
| External auto-forwarding | Account-level auto-forward settings, parked forwarding addresses, and filters or rules that forward to destinations outside your organization | Admin forwards are critical findings. This is the classic business email compromise persistence move |
| Suspicious inbox rules | Filters and rules that delete, hide, or divert mail in patterns associated with account compromise, for example moving messages about invoices or payments out of sight | Reviewed per mailbox |
Every scan produces an exportable report, and results appear in the Monitoring Hub under the Mail Posture type. A mail posture section also appears in the attestation report.
Why do SPF, DKIM, and DMARC matter?
- SPF lists which servers may send mail for your domain.
- DKIM signs outgoing messages so receivers can verify they were not altered and came from a domain that holds the signing key.
- DMARC tells receivers what to do when a message claiming your domain fails SPF or DKIM alignment, and where to send reports.
Without all three, anyone can send mail that appears to come from your domain, to your customers and to your own staff. With them, receivers can reject or quarantine spoofed mail. Microsoft's email authentication documentation explains how the three interact, and Blue Lantern Security's report walkthrough shows what a DMARC failure looks like on a received message.
The scan checks the records you have published. It is a configuration review, not a DMARC aggregate-report service, and it does not tell you who is spoofing your domain today.
Why do forwarding and inbox rules matter?
An attacker who obtains one mailbox password rarely sits and reads mail there. Instead they add a rule: forward everything to an outside address, or move messages from the bank, a vendor, or the CEO into a folder the owner never checks. The rule survives a password reset and keeps working while the attacker waits for an invoice to redirect. These rules are quiet, and reviewing them mailbox by mailbox does not scale.
The mail posture scan reads forwarding settings and inbox rules for every directory user and flags the patterns associated with compromise. Because it reads rule contents beyond the monitored-mailbox scope, enabling these two checks requires a one-time acknowledgement in settings, recorded with who accepted it and when.
How do I enable it?
- Connect the organization integration for Google Workspace or Microsoft 365.
- Confirm permissions. On Google Workspace, the existing
gmail.readonlydelegation scope already covers the forwarding and rule reads; no new scopes are needed. On Microsoft 365, the forwarding and inbox-rule checks need theMailboxSettings.Readapplication permission with admin consent. An Exchange Application Access Policy scopes these reads the same way it scopes mail, so restricted tenants get partial coverage and the report says so. The domain authentication check needs no permissions at all. - Turn on the daily mail posture scan in the integration's settings, accept the acknowledgement for the forwarding and inbox-rule checks, and save.
- Review the report in the Monitoring Hub under the Mail Posture type, and export it when you need a record.
What should I do with the findings?
| Finding | Practical next step |
|---|---|
| Missing or weak DMARC, SPF, or DKIM | Publish or tighten the record. Start DMARC at p=none with reporting, confirm legitimate senders pass, then move to quarantine or reject |
| External auto-forward on a user mailbox | Confirm with the user. If they did not create it, treat the account as compromised: remove the rule, reset the password, revoke sessions, and check MFA |
| External auto-forward on an admin mailbox | Critical. Investigate immediately; an admin mailbox forward can expose password resets and vendor changes |
| Suspicious inbox rule | Review the rule with the owner. Rules that delete or hide security notices, invoices, or payment messages are a strong compromise indicator |
Findings clear on the next daily run once the record or rule is fixed. Pair the scan with an alert rule so a new external forward reaches you the day it appears.
Common questions
Does this check my domain's DMARC reports?
No. The scan checks the SPF, DKIM, and DMARC records you have published, using public DNS. Processing the aggregate reports that DMARC generates is a separate task; the scan tells you whether your configuration is in place and reasonable.
Which DKIM selectors are checked?
The provider's selector for your platform: google._domainkey on Google Workspace, and the Microsoft 365 selectors on Exchange Online. Custom selectors for third-party senders are outside the current check.
Can it remove a malicious forwarding rule?
No. The scan reports the rule and who owns the mailbox. Removal, password resets, and session revocation happen in your admin console, where you can also record the incident.
Are legitimate forwards flagged?
Forwards to external destinations are reported so you can review them. Some are intentional, such as a shared mailbox forwarding to a ticketing system. Review each one and document the exceptions; the point is that every external forward is known.
What data does the scan read?
Mailbox forwarding settings and inbox rules for every directory user, plus public DNS records for your domains. It does not read message contents. Because rule contents are read and stored beyond the monitored-mailbox scope, enabling the forwarding and inbox-rule checks requires the one-time acknowledgement described above. See the Privacy Policy.
Enable email configuration monitoring
Related guides
- Monitor emails for phishing
- How to read a suspicious email report
- Automating email analysis: Blue Lantern Security and MXToolbox
- Monitor identity: MFA coverage and dormant accounts