> ## Documentation Index
> Fetch the complete documentation index at: https://docs.abusix.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Submitting data via email to Data Channels

> A guide to configuring SMTP data channels in AbuseHQ, covering email formats, data types, and best practices for forwarding abuse reports and spam data.

# Introduction

The SMTP data channel configuration applies to the following situations:

* Sending to your AbuseHQ instance
* Reports sent to the `abuse@` role address, including abuse web form submittals from your website
* Reporting abusive behavior to Abusix
* Spam trap emails
* Emails reported as spam by users in your mail platform
* Other (e.g., reports of abuse to be routed to network or DNS operations through Abusix Global Reporting)

> ⚠️ Sending data via the API using the XARF field format is **recommended**, as it ensures the data can be processed and used immediately.\
> [Learn more about sending data to our API](#).

***

## Email Formats

Using standardized formats increases the chances of your data being parsed automatically. The ideal email formats are **MARF** and **XARF** for SMTP. These standards make report handling automatic and should be followed whenever possible.

However, we also support other formats, such as:

* Shadowserver format
* IODEF
* TAXII
* Others

> ⚠️ There are cases where data may not be parseable. For example, when an issue applies to an entire ASN, it's not helpful to create an event for every single IP address.\
> Please contact support if you have questions.

***

## Sending Abuse Reports to Your AbuseHQ Instance by Email

### Aliasing Your `abuse@` Role Address(es) to AbuseHQ

Abuse reports sent to the `abuse@` role address should be forwarded by **aliasing** that address to the Abusix data channel email address provided to you in [app.abusix.com](https://app.abusix.com/).

If you're using a different email address (not `abuse@`), alias that address to the data channel email address as well.

Refer to the **Inbound Processing / Event Types** section in the documentation to see all types of vulnerabilities and abuse that AbuseHQ can tag and orchestrate.

> ❗ **Forwarding from an email client does not work!**\
> Always use aliasing. Forwarding from an email client modifies the message (e.g., adds headers or rewraps the message), which prevents proper parsing.

***

## Configuring Data Channels in AbuseHQ

To set up your data channel:

1. Log into the **Admin Portal** of AbuseHQ.
2. Click **Settings** in the left-hand menu.
3. Click **Data Channels**.
4. Click **Create Data Channel**.

The system will then walk you through the setup process.

***

## Forwarding Abuse Reports from Web Forms or Internal Platforms to AbuseHQ

* If possible, **avoid using email** for internal reports. Instead, submit them via our API using a **XARF schema**.
* If email is required (e.g., from a web form or system-generated alert), use **XARF for SMTP** formatting.

> [See our documentation](#) for more info.

Avoid sending bulk abuse emails, as they are resource-intensive to parse and maintain. Instead, use fire-and-forget integration via the API where possible.

***

## Reporting Abusive Behavior to Abusix by Email

You may choose the option **Report Abusive Behavior to Abusix** to both:

* Notify the responsible network owner
* Send the data to your **AbuseHQ** instance

This is useful when your abuse report stream includes data about:

* Your own network (for AbuseHQ)
* Other networks (for Abusix to route accordingly)

We will automatically split and route the data appropriately.

***

## Forwarding Spam Trap Emails

When configuring your Data Channel, you will be asked to select a **data type**. Choose:

**Data Type:** `Spam trap emails`

**Requirements:**

* Email addresses **must only be genuine spam traps** that should never receive legitimate mail.
* Forward trap hits directly. Do **not** repackage the message in an envelope.
* The **envelope FROM** should reflect the original sender of the message (not your system).
* If redaction or anonymization is required, the original format must be preserved with all headers intact.

> ❗ If you cannot preserve the original message, attach the **`x-originating-ip`** header containing the malicious sender’s IP.

***

## "This Is Spam" User Reports

When configuring your Data Channel, select:

**Data Type:** `This is Spam`

**Requirements:**

* These are spam reports generated by users clicking **"This Is Spam"** buttons in their email UI.
* Reports should be sent as **attachments** inside an envelope report email.
* Include these headers where possible:
  * `x-originating-ip`: IP address of the original sender
  * `x-original-from`: Original envelope FROM value

***

## Other Data Types

When configuring your Data Channel, you may choose:

**Data Type:** `Other`

This type has **no strict requirements**, but XARF formatting via email is still recommended.

Please describe the kind of data you're sending in the **comments field** of the setup form. This context helps us correctly evaluate and process the submissions.

> ℹ️ “Other” data is held in **staging** and not automatically parsed until reviewed.

***
