What should teams do when they discover unauthorised mail is being sent from their domain?

What to check first when unauthorised mail starts leaving your domain

Treat the incident as both a deliverability problem and a trust problem. The first job is to confirm which sending path is actually being abused, then separate legitimate business mail from spoofing or unauthorised relay. If the sending source is unknown, do not wait for perfect attribution before tightening controls that limit further abuse.

The practical sequence is to review SPF, DKIM, and DMARC together, not in isolation. SPF tells you which hosts are permitted to send, DKIM tells you whether messages are being signed by an approved key, and DMARC tells receiving systems how to handle mail that fails alignment. If you only fix one layer, attackers can often continue through another path.

Mail flow telemetry matters here. Look at DMARC aggregate reports, SMTP logs, and any provider dashboards to identify the source IPs, sending services, and message patterns involved. If the abuse is coming through a third-party mail platform, compromised application, or forgotten marketing tool, the corrective action is to remove or constrain that sender, not just to raise the enforcement level.

How to stop the abuse without breaking legitimate mail

Start by tightening policy in stages if the domain has not yet been operating with strong alignment. Move from monitoring to quarantine, then to reject only after you have confirmed that legitimate senders are aligned and signing correctly. That staged approach reduces the chance of cutting off valid mail while still forcing unauthorised messages into failure.

SPF should be trimmed to the smallest real set of sending sources. Remove unknown or stale entries, but verify that business-critical services, ticketing systems, and outbound relays are still authorised through their current IPs or include mechanisms. DKIM should be checked for signing continuity, because a valid signature from an approved domain is often the fastest way to distinguish sanctioned mail from abuse.

Where the sending platform supports it, rotate keys or credentials for the affected mail system and review whether any app passwords, API tokens, or relay credentials were reused elsewhere. If you use a cloud email provider or third-party mail service, confirm that only approved tenants, connectors, and domains can send on your behalf. For cloud governance, the CSA Cloud Controls Matrix is useful for aligning provider-side controls with your own mail governance.

What the incident usually tells you about sender governance

Unauthorised mail from a domain usually means one of three things: a sender was never approved, a legitimate sender was over-permitted, or a signing path was left exposed after a system change. The control gap is often not the DNS record alone, but the inventory behind it, what systems are allowed to send, who owns them, and how quickly changes are removed when services are retired.

That is why broader controls around access and audit still matter. For organisations operating under formal control expectations, the relevant practice is to maintain a current sending inventory, restrict who can modify mail authentication settings, and keep evidence of changes and reviews. In enterprise control terms, NIST SP 800-53 Rev. 5 Security and Privacy Controls supports the need for access control, authentication, auditability, and configuration management around mail infrastructure.

If the abuse involves a compromised mail service or automated sender, the security pattern overlaps with identity and privilege abuse as much as it does messaging abuse. That is why teams often pair mail controls with OWASP Non-Human Identities Top 10 guidance when the sender is an application, relay, or integration rather than a human mailbox.

Practitioner Guidance

What to prioritise: First confirm which legitimate systems are supposed to send for the domain, then remove any sender that cannot be tied to an owner and a business purpose. If you cannot explain why a system is authorised to send mail, it should not remain in SPF or in the signing path.

What to verify: Validate that DMARC alignment succeeds for every sanctioned mail flow, not just for the primary corporate mailbox platform. Check that the domains in SPF and DKIM match the domain used in the visible From address, because misalignment is a common reason abusive or broken mail slips through.

Decision rule: If the sending source is unknown, move to stronger DMARC enforcement immediately and investigate in parallel. If the source is known but still unauthorised, treat it as an access and ownership problem first, then as a mail delivery problem second.

Practitioner takeaway: The control objective is to make every allowed sender provable and every unapproved sender fail closed, because domain trust breaks at the first ambiguous path.

Related resources from NHI Mgmt Group

• How should security teams respond when they discover stolen OAuth or session tokens?
• What should teams do when they discover an application after employees are already using it?
• What should teams do if they discover shadow AI in the business?
• What should teams do when they discover XXE in production code?