Email Header Analysis for IPs and Spoofing Detection

Overview

Email remains a primary communication channel for both users and applications, which makes it a frequent target for spoofing, phishing, and other abuse. Inspecting raw email headers is one of the most reliable ways to identify the true sending infrastructure, evaluate IP reputation, and verify whether authentication mechanisms like SPF, DKIM, and DMARC are correctly applied.

This n8n workflow template provides an automated, end-to-end email header analysis pipeline. It receives raw headers via a webhook, parses and normalizes them, extracts all relevant IP information, and validates authentication results. The output is a structured security report that can be consumed by other systems or used directly for manual review.

High-Level Architecture

The workflow is organized into two primary analytical branches, both starting from a single webhook entry point:

• IP reputation and fraud analysis branch
  Focuses on all IP addresses found in Received headers. It:
  • Extracts IP addresses from header content using a regex-based node.
  • Queries the IPQualityScore API for fraud and abuse indicators.
  • Queries IP-API for ISP, organization, and geolocation metadata.
  • Maps numeric fraud scores to human-readable risk levels.
  • Aggregates results into a consolidated IP security profile.
• Email authentication validation branch
  Concentrates on SPF, DKIM, and DMARC validation results. It:
  • Parses Authentication-Results and related headers.
  • Extracts SPF, DKIM, and DMARC statuses from multiple possible locations.
  • Normalizes pass, fail, neutral, and unknown outcomes.
  • Prepares a unified authentication summary for the final response.

Both branches converge in a final aggregation stage where IP reputation data and authentication results are merged and returned as the webhook response.

Data Flow Summary

1. Webhook input – Receives raw email header text.
2. Header parsing – Splits the header string into key-value pairs.
3. IP extraction and enrichment – Identifies IPs from Received headers and enriches them with fraud and geolocation data.
4. Authentication parsing – Extracts SPF, DKIM, and DMARC results from various header fields.
5. Risk scoring and normalization – Converts raw scores and result codes into human-readable categories.
6. Aggregation and response – Merges all data into a single structured output and returns it to the caller.

Node-by-Node Breakdown

1. Webhook: Entry Point for Raw Headers

Purpose: Accept raw email header content via HTTP and trigger the workflow.

• Trigger type: Webhook node.
• Expected payload: A field containing the full email header string (for example, body.headers or a custom field, depending on your integration).
• Output: An item with the original header text available to subsequent nodes.

Configuration notes:

• Ensure the sending system passes the entire header block without modification, including folded lines and continuation lines.
• Use the same field name consistently, as the parsing node will reference this property.

2. Header Parsing: Explode Email Header

Node: Explode Email Header

Purpose: Convert a single raw header string into a structured representation suitable for downstream logic.

• Input: Raw header text from the Webhook node.
• Operation: The node parses the header line-by-line and:
  • Splits each line at the first colon into a header name and value.
  • Normalizes header names to a consistent format (for example, case-insensitive matching).
  • Outputs an array or object mapping header fields to their values.
• Output: Key-value pairs representing each header, such as Received, Authentication-Results, Received-SPF, DKIM-Signature, and Received-DMARc where present.

This structured format is critical for both the IP analysis and authentication branches, as it enables targeted extraction of specific header types.

3. IP Extraction: Extract IPs from “received”

Node: Extract IPs from "received"

Purpose: Identify and collect all IP addresses present in Received headers.

• Input: The parsed header data, specifically the Received fields.
• Logic:
  • Applies a regular expression to each Received header line to find IP address patterns.
  • Supports multiple IPs per header line, if present.
  • Generates one item per IP address for downstream processing.
• Output: A list of IP items, each containing at least the IP address and optional contextual data from the original header line.

Edge case: If no Received headers exist or no IPs match the regex, this branch will produce zero items. The rest of the workflow continues, but the IP reputation portion of the report will be empty or flagged as unavailable, depending on how you handle the output.

4. IP Reputation and Enrichment

4.1 IPQualityScore API

Service: IPQualityScore

Purpose: Evaluate the risk profile of each extracted IP address.

• Input: Individual IP items from the extraction node.
• Operation:
  • Calls the IPQualityScore API endpoint for each IP.
  • Retrieves fields such as:
    • Fraud score (numeric risk indicator).
    • Recent abuse or spam activity flags.
    • Indicators of fraud, abuse, or other suspicious behavior.
• Output: IP items enriched with IPQualityScore data.

Credentials: Configure your IPQualityScore API key in the corresponding credentials section of the node. Ensure rate limits and quotas are respected in your environment.

4.2 IP-API Geolocation and ISP Lookup

Service: IP-API

Purpose: Provide contextual information for each IP address, such as ISP, organization, and geographic location.

• Input: The same IP items, potentially already enriched by IPQualityScore.
• Operation:
  • Calls IP-API with each IP.
  • Retrieves:
    • ISP and organization names.
    • Country, region, city, and other geolocation fields.
• Output: IP items containing both risk and contextual information.

4.3 Fraud Scoring and Risk Categorization

Node: Custom logic within a function or expression node (described as Fraud Scoring in the original workflow).

Purpose: Convert raw numeric fraud scores and abuse flags into human-readable risk levels.

• Input: IP items with IPQualityScore results.
• Logic:
  • Maps fraud scores to categories such as:
    • Good
    • OK
    • Suspicious
    • Poor
    • Bad
  • Flags IPs with recent spam or abuse activity as higher risk, based on IPQualityScore indicators.
• Output: Each IP item now includes a normalized risk level and explicit flags for recent spam activity.

4.4 Collecting IP Insights

Node: Collect interesting data

Purpose: Aggregate all relevant attributes for each IP into a compact, structured representation.

• Input: IP items enriched by both IPQualityScore and IP-API, plus the custom fraud scoring.
• Operation:
  • Selects only the most relevant fields for the final report (for example, IP, risk level, fraud score, spam flags, ISP, organization, country).
  • Normalizes field names for consistent downstream usage.
• Output: A streamlined list of IP profiles, ready to be merged and returned in the webhook response.

Later in the workflow, these items are merged across all IPs to provide a comprehensive IP security profile for the analyzed email.

5. Email Authentication Validation

5.1 Parsing Authentication-Results

Node: SPF/DKIM/DMARC from "authentication-results"

Purpose: Extract SPF, DKIM, and DMARC validation outcomes from the Authentication-Results header.

• Input: Parsed header data, specifically the Authentication-Results field.
• Operation:
  • Searches for tokens indicating authentication mechanisms and their statuses.
  • Identifies whether SPF, DKIM, and DMARC passed, failed, or produced neutral or unknown results.
• Output: A structured representation of SPF, DKIM, and DMARC states, such as:
  • spf: pass | fail | neutral | unknown
  • dkim: pass | fail | neutral | unknown
  • dmarc: pass | fail | neutral | unknown

5.2 Additional SPF, DKIM, and DMARC Sources

The workflow also inspects related headers to capture authentication details that may not be fully represented in Authentication-Results alone.

• SPF from “received-spf”
  Extracts SPF evaluation information from the Received-SPF header when present. This can provide extra context about the SPF check performed by intermediate MTAs.
• DKIM from “dkim-signature”
  Reads the DKIM-Signature header to confirm the presence of a DKIM signature and to support interpretation of DKIM results.
• DMARC from “received-dmarc”
  Uses the Received-DMARc header when available to validate DMARC evaluation and policy application.

Each of these nodes focuses on its specific header type and extracts relevant indicators to complement the main Authentication-Results parsing.

5.3 SPF Authentication Checker

Node: SPF Authentication Checker

Purpose: Route or conditionally process the workflow based on SPF evaluation results.

• Input: SPF status from Authentication-Results and, where applicable, Received-SPF.
• Operation:
  • Evaluates whether SPF is a pass, fail, neutral, or unknown.
  • Uses this evaluation to inform later decision-making or to annotate the final report.
• Output: A normalized SPF status and any derived flags that indicate SPF reliability.

5.4 Normalization with Set Nodes

Nodes: Multiple Set nodes

Purpose: Standardize field names and ensure that SPF, DKIM, and DMARC results are ready for merging.

• Input: Outputs from the authentication parsing nodes.
• Operation:
  • Assigns explicit properties for each mechanism, for example:
    • spf_status
    • dkim_status
    • dmarc_status
  • Ensures consistent value sets (pass, fail, neutral, unknown) across all branches.
• Output: Clean, consistently named fields that can be easily merged with IP data in the aggregation phase.

6. Aggregation and Webhook Response

6.1 Merging IP and Authentication Data

Nodes: Merge and item list nodes

Purpose: Combine all analysis results into a single response payload.

• Input:
  • The list of enriched IP profiles from the IP analysis branch.
  • The normalized SPF, DKIM, and DMARC statuses from the authentication branch.
• Operation:
  • Uses merge/item list nodes to:
    • Aggregate all IP records into a structured array.
    • Attach authentication summary fields at the top level of the result.
  • Ensures the final structure is suitable for both human inspection and programmatic consumption.
• Output: A consolidated report that includes:
  • Per-IP risk and geolocation data.
  • Overall SPF, DKIM, and DMARC statuses.

6.2 Webhook Response Formatting

Purpose: Return the aggregated results back to the caller that initiated the webhook.

• Response content: A JSON object or similar structured payload containing:
  • An array of IP entries with:
    • IP address.
    • Fraud score and mapped risk level.
    • Spam or abuse flags.
    • ISP, organization, and geolocation information.
  • Authentication summary with:
    • SPF status.
    • DKIM status.
    • DMARC status.

This final response gives a quick overview of both the infrastructure used to send the email and the integrity of its authentication configuration.

Configuration Notes and Edge Cases

• Missing or partial headers: If certain headers, such as Received or Authentication-Results, are absent, the corresponding analysis branch will yield limited or no data. The workflow still completes, but the final report