How to Handle SPAM Report & Correlation ID Change Inquiries

This article explains why emails show as SPAM Report in the DR file, why the same Correlation ID appears on multiple dates, and how to investigate using SendGrid and Metabase. Intended for internal support agents handling email delivery and spam report tickets.

Overview

This KB article is for support specialists who receive customer inquiries about emails showing as SPAM Report in the DR (Delivery Report) file, or where the customer is asking why the same MB Correlation ID appears on multiple dates with different statuses.

Common Customer Questions:

Why does my email show as SPAM Report in the DR file?
Was the email retried on different dates? I see the same Correlation ID appearing on March 12 and March 15.
The MB Correlation ID changed from one value to another — why did this happen?
Was the email actually delivered to the recipient?

Important Note

This KB uses DTE as the example client. The exact same investigation steps apply to all other clients as well.

The only difference is selecting the correct client name in Metabase when navigating to the Research Tool.

Prerequisites & Key Concepts

Please read and understand the following before starting your investigation:

Access to SendGrid — for recent email events (last 7 days)
Access to Metabase — for full historical email activity
The recipient email address, Correlation ID or MBID, and date range from the ticket

Correlation ID vs MBID

ID Type	Description	Example
Correlation ID	Internal request ID sent by the client (e.g., DTE)	`cf59f984-a86a-4bf9-89de-f82e934e2222`
MBID	ID generated by Message Broadcast after processing the request	`11f11c599ccc2e50a736cb2d368cd668`

Both IDs refer to the exact same single email. The ID changes because the Correlation ID is the input from the client and the MBID is what our system creates after processing. This is completely normal and expected behavior — it is NOT an error.

Why Does the Same MBID Appear on Multiple Dates?

Every recipient action — opening the email, marking it as spam — creates a new separate record in the DR file.
All these records share the same MBID because they all relate to the same single email.
Seeing SPAMREPORT on two different dates does NOT mean the email was sent twice or retried.
It means the recipient marked the same email as spam on two separate occasions.

Key Rule: Multiple DR records with the same MBID = multiple recipient actions on ONE email. It does NOT mean multiple emails were sent.

What Happens When a Recipient Marks an Email as Spam?

Their email address is automatically added to the suppression list.
All future emails to that address will be blocked and will not be delivered.
This continues until the address is manually removed from the suppression list.
This is the recipient's own action — it is completely outside of our control.

Step-by-Step Instructions

Follow these steps to investigate SPAM Report and Correlation ID inquiries:

Read the Ticket and Collect the Information: Before opening any tool, carefully read the entire ticket. Look for the recipient email address, Correlation ID or MBID, and the date range. Check all screenshots or attachments — the email address and MBID are often already visible in the customer's DR file screenshot.

⚠ Important: Never ask the customer for information that is already visible in their screenshots or ticket. Always read everything first.
Check in SendGrid: SendGrid stores data for the last 7 days only. Log in at https://app.sendgrid.com/email_activity. In the left sidebar, click Activity → Activity Feed. In the "To email address" field, type the recipient's email address. Set the date range and click Search.

Screenshot 1 — SendGrid Activity Feed. Enter the recipient email address, set the date range, and click Search. You will see a result row showing email status as 'Delivered'.

Click on the result row to open the full Event History.

Screenshot 2 — SendGrid Event History. Shows the complete email journey: Received → Processed → Delivered → Opened → Spam Report. The red box highlights the Spam Report entry. Note all events and timestamps carefully.

If SendGrid shows no results: The data is older than 7 days. Proceed directly to Step 3 (Metabase).

Screenshot 3 — SendGrid Email Logs showing 'No search results found'. The data is outside the 7-day limit. Proceed to Step 3 and use Metabase.

Screenshot 4 — SendGrid Activity Feed also showing no results for the same address and older date range. This confirms you need to use Metabase for this investigation.
Navigate to Metabase: Metabase stores complete historical email data. Open your browser and go to https://dashboard.mbdt01.com/collection/89-dte. Look at the top-left corner and click the icon to open the sidebar.

Screenshot 5 — Metabase home page. The icon in the top-left corner (highlighted in red box) opens the sidebar. Click it to see the full list of clients.

The sidebar will open and show the list of all clients on the left.

Screenshot 6 — After clicking the icon, the sidebar opens showing all client names: Chase, CNP, CONED, DLC, DTE, Duke, and so on.

Screenshot 7 — If the sidebar is collapsed and the client list is not visible, click the icon shown here to open it.

In the left sidebar, scroll down and click on DTE to expand it (or the correct client for your ticket).

Screenshot 8 — Metabase left sidebar. Scroll down and click on DTE (highlighted with red box). It expands to show Dashboards, Models, and Questions.

Under DTE, click on Dashboards.

Screenshot 9 — DTE Dashboards page. After clicking Dashboards, scroll down to the bottom of the list and look for 'DTE - Research Tool'. Click on it to open.

Scroll down the list and click on DTE - Research Tool.

Screenshot 10 — DTE Research Tool page opened and ready for search.
Search in the DTE Research Tool: On the DTE Research Tool page, click on Search By Contact. In the "Contains..." field, type the recipient's email address exactly as it appears in the ticket (e.g., maryoldham2@comcast.net). Click Add filter to run the search.

Screenshot 11 — DTE Research Tool. Click 'Search By Contact', type the email address in the 'Contains...' field (highlighted in red box), then click 'Add filter'. Results will load in the tables below.
Review the Results: Wait for the results to load. You will see two tables: DTE - Model - DTE Table (all email status events) and DTE - Model - Master Table (additional details). Find the MBID that matches the one in the customer's ticket and review the status column.

Screenshot 12 — DTE Research Tool. The highlighted row (red box) shows MBID 11f11c599...cd668 with status PROCESSING on March 10 at 8:17 AM. This confirms the email entered our system on that date.

Scroll through all rows to see every status change: PROCESSING, PROCESSED, DELIVERED, OPEN.

Screenshot 13 — DTE Research Tool. Shows MBID ...cd668 going through PROCESSED, DELIVERED, and OPEN on March 10. The second email (MBID ...b6df) sent on March 11 also shows PROCESSING, PROCESSED, and DELIVERED — confirming both emails were successfully delivered.

Screenshot 14 — DTE Research Tool. The March 11 email (MBID ...b6df, highlighted in red box) shows PROCESSING, PROCESSED, and DELIVERED all on March 11 at 11:28 PM — confirming successful delivery.

Reading the Table: Each MBID will have multiple rows — one per status event. Normal flow: PROCESSING → PROCESSED → DELIVERED → OPEN → SPAMREPORT. All rows with the same MBID = the same email at different stages.
Find the SPAM Report Entries: Continue scrolling to locate the SPAMREPORT rows. Note the dates and MBIDs.

Screenshot 15 — DTE Research Tool. Shows OPEN events on March 12, followed by SPAMREPORT for MBID ...cd668 on March 12 at 6:18 PM (first spam marking via email client), then SPAMREPORT for both MBIDs on March 15 at 8:00 PM (reported through ISP/Comcast). These are NOT new sends — these are actions the recipient took on already-delivered emails.

⚠ Key Finding: Multiple SPAMREPORT entries on different dates for the same MBID means the recipient marked the same email as spam more than once. There was no retry, no new send, and no platform issue.
Determine the Root Cause: After reviewing all results from both tools, use the troubleshooting table below to determine the root cause and decide what action is needed.

Troubleshooting & Common Issues

Use the table below to determine the correct action based on what you observe during investigation:

What You Observe	Root Cause	Platform Issue?	Action Required
Email delivered & opened, then marked spam	Recipient-initiated spam marking	❌ No — recipient action	Inform customer. No fix needed from our end.
Same MBID on multiple dates in DR file	Separate DR record per recipient action	❌ No — expected behavior	Explain to customer that this is not a retry.
Correlation ID changed to a different MBID	Normal platform ID processing	❌ No — expected behavior	Explain ID conversion to customer.
No results found in SendGrid	Data is older than 7 days	❌ No — tool limitation	Use Metabase to find the records.
Email was never delivered	Delivery failure or suppression	⚠ Yes — investigate further	Check suppression list and delivery logs.

Guidelines

What to Avoid

✕Never ask the customer for information already visible in their screenshots or ticket — always read everything first.
✕Do not stop at SendGrid if it shows no results — always proceed to Metabase for historical data older than 7 days.
✕Do not omit the timezone (UTC) when writing timestamps in your customer response.
✕Do not send a response if you are unsure about your findings — add an internal note and check with a senior team member first.
✕Do not forget to mention the suppression list status if the recipient's address has been added to it.

Customer Response Template

Once you have completed your investigation, use the template below. Replace all bracketed fields with actual data from your investigation:

Hi [Customer Name],
Thank you for your patience. Please find the complete findings below.
Correlation ID           : [original ID from customer]
MB ID (after processing) : [MBID from Metabase / SendGrid]
Recipient                : [email address]
REGARDING THE CORRELATION ID CHANGE
The MB Correlation ID changed from [original ID] to [MBID] because the original ID is the internal request ID from [Client], while the MBID is generated by our system once the request is processed. This is expected platform behavior — both IDs refer to the same single send event.
COMPLETE EMAIL ACTIVITY TIMELINE (All times in UTC)
• [Date & Time] — Email processed and delivered to [recipient]
• [Date & Time] — Recipient opened the email
• [Date & Time] — Recipient marked the email as SPAM
WHY THE SAME MBID APPEARS ON MULTIPLE DATES
There was NO retry from our end. The same MBID appears on different dates in the DR file because each recipient action generates a separate record. This was a single email delivered once on [date] — not a retry or a new send.
SUMMARY
The email was successfully delivered and opened by the recipient before being marked as spam. There are no delivery failures or platform issues. The spam classification was initiated by the recipient and is outside our control.
Please note: [recipient email] has been automatically added to the suppression list. All future emails to this address will be blocked until it is removed from suppression.
Please let us know if you have any further questions.
Thank you,
[Your Name] | Product Support Specialist

Frequently Asked Questions (FAQs)

Q: Does the same MBID on multiple dates mean the email was sent multiple times?

A: No. Multiple DR records with the same MBID mean multiple recipient actions on ONE email — such as opening it or marking it as spam on different occasions. The email was sent only once. Each action simply creates a new row in the DR file.

Q: Why did the Correlation ID change to a different MBID?

A: The Correlation ID is the internal request ID sent by the client. The MBID is the ID generated by Message Broadcast after our system processes that request. Both refer to the exact same email. This ID change is completely normal and expected — it is not an error.

Q: What should I do if SendGrid shows no results?

A: SendGrid only stores data for the last 7 days. If the email was sent more than 7 days ago, you will see no results in SendGrid. In this case, proceed directly to Metabase, which stores complete historical email activity.

References & Related Tickets

For internal team use: Reference past Jira or Zendesk tickets related to this article.

ZD-28066 DTE ticket — email showing as SPAM Report in DR file; same Correlation ID appearing on multiple dates with different statuses.
SendGrid SendGrid Activity Feed — Email delivery events for last 7 days: Delivered, Opened, Spam Report.
Metabase Metabase Research Tool — Full historical email activity. Navigate: [Client] → Dashboards → Research Tool.

Untitled