KoltrixDetecting a compromised account sending spam as you
A hijacked mailbox or leaked SMTP credential can burn your domain reputation in hours. The signals to watch and the containment steps to rehearse.
On this page(7 sections)
The worst spam problem a domain can have is not someone spoofing it. It is someone sending real, fully authenticated spam through it.
A phished mailbox, a leaked SMTP password or an API key in a public repository can push thousands of messages out under your name before anyone notices, and the reputation damage lands on your domain and IPs.
How outbound abuse starts
The entry points are predictable:
- Phished mailbox credentials. An employee enters their password on a fake login page. If multi-factor authentication is missing or bypassed, the attacker signs in and sends.
- Leaked SMTP or API credentials. Keys committed to source control, left in a front-end bundle, pasted into a support ticket or stored in an exposed configuration file.
- Compromised application accounts. A customer account on your platform is taken over and used to send through your product's invite, share or messaging features.
- Abused forms. A contact form or signup flow that emails arbitrary addresses with user-supplied content becomes a spam relay.
- A compromised server with credentials or direct access to your mail relay.
Attackers prize these because authenticated mail from an established domain gets better inbox placement than anything they could send from their own infrastructure.
The signals to watch
You want to detect abuse in minutes or hours, not days. Useful signals, roughly in order of how quickly they show up:
| Signal | What it looks like | Where to look |
|---|---|---|
| Volume anomaly | A mailbox or key sending far more than its baseline | Outbound logs, provider dashboards |
| Recipient anomaly | Many distinct, unrelated external recipients | Outbound logs |
| Bounce spike | Hard bounce rate jumps for one sender | Bounce processing, webhooks |
| New destinations | Mail to domains you never send to | Outbound logs |
| Off-hours sending | Activity at unusual times for that account | Logs, sign-in records |
| Unusual sign-ins | New country, new device, impossible travel | Identity provider |
| New mailbox rules | Forwarding or deletion rules created | Mailbox audit logs |
| Complaint spike | Feedback-loop complaints jump | FBL processing, postmaster tools |
| Blocklist listing | Sending IP or domain listed | Blocklist monitoring |
The last two are late signals. By the time a blocklist lists you, the damage is already done. Build alerts around the early ones: per-identity volume, recipient spread and bounces.
Per-identity baselines and limits
Aggregate metrics hide abuse. If your organization sends 200,000 messages a day, a compromised mailbox adding 20,000 is a 10 percent bump that may not trigger an alert. The same 20,000 from one mailbox that usually sends 40 a day is a thousandfold anomaly.
Track sending per identity: per mailbox, per API key, per application tenant. Then add hard limits that cap the damage while you investigate:
- Daily and hourly send caps per mailbox appropriate to the role.
- Per-key rate limits for API and SMTP credentials.
- Lower limits for new accounts on your platform until they have history.
- Automatic suspension, not just alerting, when a threshold is crossed dramatically.
A simple detection rule, run over outbound logs every few minutes:
SELECT sender_identity,
count(*) AS sent_15m,
count(DISTINCT recipient_domain) AS domains_15m
FROM outbound_messages
WHERE sent_at > now() - interval '15 minutes'
GROUP BY sender_identity
HAVING count(*) > 10 * (
SELECT coalesce(avg(cnt), 5) FROM sender_baseline_15m b
WHERE b.sender_identity = outbound_messages.sender_identity
);The exact query will depend on your schema; the idea is to compare each identity with its own history rather than with the global total.
The containment playbook
Write this down and rehearse it before you need it.
- Stop the sending. Disable the mailbox's ability to send, revoke the API key or SMTP credential, or suspend the tenant. Do this first, before investigating.
- Purge the queue. Messages already queued but not yet delivered should be removed, or they will keep going out after the credential is revoked.
- Revoke sessions and tokens. For a mailbox, reset the password, sign out all sessions and revoke app passwords and OAuth grants.
- Remove persistence. Check for forwarding rules, inbox rules, newly registered MFA devices and delegated access the attacker added.
- Find the entry point. Phishing email, leaked key location, vulnerable form. Fix it, or the attacker returns.
- Assess reputation impact. Check blocklists, postmaster dashboards and complaint rates over the following days.
- Request delisting only after the abuse has stopped and the cause is fixed.
- Notify affected recipients or customers if the content was phishing or malware.
Recovering reputation afterward
Stopping the abuse ends the incident for you, but not for the mailbox providers that received the spam. Their filters have recorded complaints, spam trap hits and unusual volume against your domain and sending IPs, and those signals decay over days or weeks rather than instantly.
During recovery, send only your most important and most engaged mail: transactional messages and mail to recipients who opened or clicked recently. Pause large campaigns. Watch deferral rates and postmaster dashboards daily, and expect some messages to land in spam for a while even though nothing is wrong any more. If a provider offers a sender support or mitigation request process, use it only after you can describe the cause and the fix clearly; a request that says "we were compromised, it is fixed, here is what changed" is far more credible than one that says "please unblock us."
Prevention that pays for itself
- Multi-factor authentication everywhere, with phishing-resistant methods for privileged and high-volume senders.
- Disable legacy mail protocols that accept plain passwords and bypass multi-factor authentication, where your mailbox provider allows.
- Scope credentials tightly. An API key used for password resets does not need permission to send from every address on your domain.
- Scan repositories for secrets before and after commits; many platforms can alert on leaked keys automatically.
- Constrain user-generated content in invite and share emails, and require verified accounts before such features can send to external addresses.
- Separate streams. Keep transactional mail on infrastructure, subdomains or keys separate from user-triggered mail, so abuse in one does not take down password resets.
Key takeaways
- Outbound abuse through compromised credentials is authenticated, which makes it more damaging than spoofing.
- Watch per-identity volume, recipient spread and bounces; complaints and blocklists are late signals.
- Hard per-identity limits cap the damage while you investigate.
- Contain first: stop sending, purge queues, revoke sessions, remove persistence, then investigate.
- Multi-factor authentication, tight credential scopes and secret scanning prevent most incidents.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
