# MxToolbox Email Deliverability Tool: Run and Interpret a Report

> Run the MxToolbox Email Deliverability tool, interpret its message evidence, make a bounded repair, and retest the same sending path.

The MxToolbox Email Deliverability tool tests one message you send to its address, then returns a report about that message's headers, outbound IP reputation, and published authentication records. Send a representative test, open the report, and use each failed or delayed item to choose the next check. It is useful evidence for one path at one time, not proof of inbox placement across every mailbox provider. For the wider model, see [email deliverability](/learning/what-is-email-deliverability).

## Quick takeaways

- Send a test message to the exact MxToolbox address, then open the report link from the reply or search using the sender address.
- Treat the report as message and lookup evidence for the submitted path, not a receiver-wide inbox-placement result.
- Read the named delivery, relay, SPF, DKIM, and header sections before changing DNS or sender settings.
- Start a repair from the failed field, then send a fresh message through the same path and compare the new report.
- Use a separate public-record lookup when the outstanding question is a published DMARC or DKIM record.

## What this tool checks

MxToolbox says its Email Deliverability tool analyzes submitted-message headers, the blacklist reputation of the outbound IP address, and SPF records. Its current help article also lists SPF, DKIM, and DMARC records where applicable. That is a useful snapshot, but it does not reproduce how every receiving mailbox will filter future mail. The broader [email deliverability model](/email-deliverability) also includes receiver policy, reputation, and recipient behavior.

The report is most useful when the message represents the path you need to investigate. Send from the same application, provider, visible From domain, and authentication configuration that produces the issue. Do not use a copied header from another sender if the question is about your production path.

## How to run the check

### 1. Send a representative message

Send a new message from the path under investigation to `ping@tools.mxtoolbox.com`. MxToolbox's [Email Deliverability page](https://mxtoolbox.com/deliverability) currently directs users to that address and says the reply comes from `abuse@mxtoolbox.com`. Keep the sent copy so you can compare its sender and subject with the report.

![MxToolbox Email Deliverability page showing the test address and the two-step report workflow](/images/editorial/mxtoolbox-email-deliverability-tool/mxtoolbox-deliverability-public-interface.png "1280x900")

*Source: [MxToolbox Email Deliverability](https://mxtoolbox.com/deliverability), captured from the public tool on July 29, 2026. [Open the full-size capture](/images/editorial/mxtoolbox-email-deliverability-tool/mxtoolbox-deliverability-public-interface.png).*

### 2. Open or retrieve the report

Open the reply and select its "View your full Deliverability Report" link. If you have already run the test, MxToolbox documents that you can enter the sender email address in the tool's search field and select Search. Confirm that the report subject and sender correspond to the message you just sent before interpreting it.

### 3. Record the evidence before changing anything

Capture the result date, the sending path, and only the report fields that drive your next action. This small record prevents a later DNS change or sender change from being attributed to the wrong test.

```text
Test date and time:
Sending application and visible From domain:
Report subject and sender address:
Failed, delayed, or red report fields:
Next evidence source to inspect:
```

## How to interpret the results

The [MxToolbox Email Delivery Tools documentation](https://knowledgebase.mxtoolbox.com/home/email-delivery-tools) says the report begins with Header Analyzed and then shows Delivery Information for DMARC compliance, SPF alignment, SPF authentication, DKIM alignment, and DKIM authentication. It then presents relay information, expandable SPF and DKIM details, the headers it found, and the received header in its original encoded form.

Read the result in this order:

- **Delivery Information:** A failed DMARC, SPF, or DKIM item identifies an authentication question worth tracing. It does not by itself identify which team controls the sender or DNS change.
- **Relay Information:** MxToolbox says this section reports delays after sending and their duration. Use it to decide whether to inspect the relay path or the sending provider's logs before editing authentication records.
- **SPF and DKIM Information:** Open the relevant detail only after you know which result needs attention. A selector-aware [DKIM public-record check](/tools/dkim) can answer a separate question about the record a resolver can see.
- **Headers Found and Received Header:** Use these sections to confirm the message path and the available header evidence. They are not a substitute for examining a delivered message at the mailbox where the symptom occurred.

If you inspect `Authentication-Results` in a delivered message, trust it only in the context of the receiving system that added it. [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html) specifies that the header conveys authentication assertions and that their validity depends on the trust relationship with the validating system.

## How to act on the result

Make the narrowest change supported by the evidence, then preserve the test path for the retest.

### A DMARC item needs public-record evidence

Run the [Palisade DMARC checker](/tools/dmarc) to inspect the public DMARC record separately. Compare the published policy and reporting address with the sender's intended domain configuration. This check does not reproduce the submitted-message report, change DNS, or establish inbox placement.

### An SPF or DKIM item needs sender-path evidence

Confirm which application sent the message, then inspect that application's authenticated sending-domain configuration and the relevant DNS record. Do not replace an existing SPF record or publish a new DKIM value solely because a report is red. The report tells you where to investigate; the sender configuration and authoritative DNS provide the repair evidence.

### Relay information shows a delay

Keep the report and inspect the sending provider's delivery logs or the receiving system's accepted-message evidence. A relay delay is a path observation, so changing a DMARC policy will not necessarily address it.

### The report passes but the user reports spam placement

Inspect a delivered copy at the affected mailbox and compare its headers, timing, sender path, and recipient experience. Then use the [spam-placement troubleshooting guide](/learning/why-do-your-emails-go-to-spam-and-how-can-you-fix-it) for the next diagnostic scope. A passing tool report does not establish that every recipient saw the inbox.

## How to retest

Send a fresh message from the same application and domain to `ping@tools.mxtoolbox.com` after the supported change is live. Open the new report, verify that it describes the new message, and compare only the field that motivated the repair. MxToolbox documents the same send, reply-link, and sender-email retrieval path for the tool, so repeating it keeps the evidence comparable.

If DNS was part of the repair, first confirm that authoritative and public resolver answers reflect the intended record. Then retest the message path. If the same field remains red, stop broad changes and collect the sender configuration, DNS answer, and delivered-message headers needed to identify the owner of the next fix.

## Check a remaining DMARC record question

If the MxToolbox report leaves a public DMARC-record question unresolved, use the [Palisade DMARC checker](/tools/dmarc) to inspect that public evidence. It can complement the report, but it cannot test the submitted message, modify DNS, or guarantee delivery.

## Sources and further reading

- [MxToolbox Email Deliverability tool](https://mxtoolbox.com/deliverability)
- [MxToolbox Email Delivery Tools documentation](https://knowledgebase.mxtoolbox.com/home/email-delivery-tools)
- [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html)

## Frequently asked questions

### Does MxToolbox prove that every recipient received the message in the inbox?

No. The report provides evidence about the submitted message and the checks MxToolbox performed at that time. Inbox placement can vary by mailbox provider, recipient, reputation, and the later message path.

### Can I use the report without sending another test message?

Yes. MxToolbox documents a sender-email search for prior results. Use a fresh test when you need to confirm a recent sender or DNS change because an older report represents an earlier message and lookup time.

### Should I change my DMARC policy when the report shows a failure?

No. First identify whether the result concerns public DMARC publication, alignment, the sending application's identity, or a message path. A policy change can alter enforcement without fixing the authentication condition that produced the result.

### Is a green SPF or DKIM result enough to rule out a spam problem?

No. Authentication evidence can remove one class of issue, but it does not establish the receiver's final placement decision. Inspect a delivered copy and use the reported symptom to choose the next evidence source.

### Why should I repeat the same sending path for the retest?

Only a comparable path lets you associate a changed report field with the repair you made. Changing the sender application, domain, or route at the same time can create a different test rather than validate the original fix.