Phishing email triage with sender IP reputation checks

PromptCreate

Every 15 minutes, triage our shared phishing-report mailbox in Gmail so the suspicious emails employees forward in get a real verdict instead of sitting unread. Use Gmail List Messages to pull unread messages carrying our phishing-report label. If nothing is unread, stop quietly without posting anything.

For each message, use Gmail Get a Message in raw mode so you can read the complete header block, falling back to full mode if raw is unavailable. Walk the Received chain from the bottom up, past our own mail relays, and take the earliest public sending IP. Skip private and internal addresses, meaning 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8 and any link-local range, and skip the relay ranges in our allowlist. Also read the Authentication-Results header and record the SPF, DKIM and DMARC results.

If the chain contains nothing but our own relays and allowlisted ranges, the report was almost certainly forwarded inline rather than as an attachment, so the original headers are gone. In that case post a Slack summary saying the original sender could not be determined, leave the message unread so a human picks it up, and do not check or report any IP. Never guess a verdict from a chain you could not read.

Run the sending IP through AbuseIPDB Check IP Reputation. When the abuse confidence score is 50 or above, also call Get Abuse Reports for that IP so the verdict can cite recent report categories. Dedupe sending IPs within a single run so the same address is looked up only once, because AbuseIPDB enforces a separate daily quota on each endpoint.

Treat a score of 50 or above as malicious, 1 to 49 as suspicious, and 0 as clean. A clean score does not automatically mean the message is safe: if SPF, DKIM or DMARC failed, call that out and weigh it into the verdict alongside the content of the message itself. Decide between Confirmed Phishing and Likely Safe using the score, the authentication failures and the message content together.

Post a triage summary to our security channel with Slack Send a Message. Include the verdict, the abuse confidence score, the sending IP, which authentication checks failed, the total number of abuse reports, the recent report categories, and the ISP, country and usage type. Finish with a recommended action, such as blocking the sender at the gateway or resetting credentials for anyone who replied. Name the employee who reported it so they can be told the outcome.

Then use Gmail Modify Message Labels to apply either the Confirmed Phishing or the Likely Safe label to the message, and remove the UNREAD label so the same report is never triaged twice.

When a message is clearly phishing and the sending IP scored 50 or above, file it back with AbuseIPDB Report IP under category 7 for Phishing and category 10 for Email Spam, sending the parameters form-encoded. Be conservative here, because these reports are public and attributed to our account. Never report a private or internal address, never report anything inside our allowlist of company and mail-provider ranges, and dedupe so the same sending IP is reported at most once per day. Keep the report comment short and factual, and do not include any personal data or recipient details from the message.

Make the phishing-report label, the two outcome labels, the Slack channel, the malicious score threshold and the allowlist of our own company and mail-provider IP ranges configurable inputs rather than hardcoding them.

Example output

Confirmed Phishing (reported by dana@acme.com) Subject: "Urgent: verify your payroll details before Friday" Sending IP: 45.155.205.233, earliest public hop in the delivery chain Abuse score: 100/100, 847 total reports Recent categories: Phishing, Email Spam, Web Spam ISP: Hostinger International, Country: LT, Usage type: Data Center/Web Hosting Failed checks: SPF fail, DMARC fail, DKIM absent Recommended action: block the sender domain and IP at the gateway, and reset credentials for anyone who replied. Labelled Confirmed Phishing, marked read, reported to AbuseIPDB under phishing and email spam.

What does this prompt do?

Checks your shared reporting mailbox every 15 minutes for suspicious emails staff have forwarded in, so nothing sits unread for days
Reads the hidden delivery trail on each email to work out which server actually sent it, and whether the sender passed the standard anti-forgery checks
Looks that sending server up in a global abuse database and posts a plain verdict to your security channel, with the score, the failed checks and a recommended next step
Files each email under Confirmed Phishing or Likely Safe and marks it read, then reports clear-cut offenders back to the abuse database so other companies get warned

What do I need to use this?

A Gmail or Google Workspace account for the shared mailbox where staff forward suspicious emails
A label that forwarded reports land under, plus two outcome labels named Confirmed Phishing and Likely Safe
A Slack workspace and the channel where your security updates should go
An AbuseIPDB account, the free tier is enough to get started
A list of your own company and mail provider address ranges, so your own servers are never flagged or reported

How can I customize it?

Change how often it runs. Every 15 minutes suits a busy mailbox, hourly is plenty for a smaller team.
Move the line between Confirmed Phishing and Likely Safe if you want the workflow to be more or less cautious before it commits to a verdict.
Turn the reporting step off entirely, or keep it on only for the most obvious cases, since those reports are public and carry your company name.
Send the summaries to one channel, or route the confirmed phishing ones to a separate urgent channel.

FAQs

What happens to the emails that turn out to be harmless?

They get labelled Likely Safe and marked as read, and they still appear in the Slack summary. That way you keep a record of everything staff reported, not just the genuine attacks, and the person who forwarded it can be told it was fine.

Could this flag our own mail servers by mistake?

No. You give it the address ranges belonging to your company and your mail provider up front, and anything inside those ranges is skipped entirely. Internal and private addresses are ignored too, so the workflow only ever judges the outside server that first sent the message.

Does reporting an email publicly identify our company?

Yes. Reports filed to the abuse database are public and attributed to your account, which is why the workflow is deliberately conservative. It only reports messages that are clearly phishing and already carry a high abuse score, it never includes anything personal from the email itself, and it reports the same sender at most once a day. You can switch the reporting step off and keep everything else.

Does it matter how staff forward the suspicious email?

It does. Forwarding as an attachment preserves the original delivery trail, which is what the workflow reads. If someone forwards inline, that trail is often replaced by your own mail servers. When that happens the workflow tells you the original sender could not be determined and leaves the message for a human, rather than inventing a verdict.

Do we need a paid AbuseIPDB plan for this?

The free tier is enough for most teams. Daily lookup limits depend on your plan, and the workflow is built to stay well inside them by checking each sending address only once per run and avoiding repeat lookups.

Related templates

Auto-fix your calendar when a flight slips, and flag what's at risk

When your flight moves, your calendar times get corrected automatically and you get a Slack note naming the meetings you're about to miss.

Agentic Task

Turn procurement portal tenders into CRM deals each morning

Every weekday at 7am, sign in to the tender portals you track, filter new notices against your bid criteria, and open a deal for the ones worth chasing.