Trace phishing emails to the sending IP and report abuse

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.