# Test email reputation

> Test email reputation with a public domain check, interpret blocklist findings, collect message evidence, and retest after a documented repair.

To test email reputation, run a public domain reputation check, save the result, then compare it with the sending IP and a real delivered message. A clean public result means the checked lists found no detection at that moment. It does not reveal Gmail, Microsoft, or another receiver's private reputation decision, explain one spam-folder placement, or guarantee delivery.

## Quick takeaways

- A domain reputation check tests publicly visible blocklist evidence for the submitted domain and related infrastructure.
- A Clean result is time-bounded public evidence, not a receiver-specific reputation score.
- A detected listing needs the exact listed domain or IP, the list operator's evidence, and the production sending path before repair.
- Unavailable checks mean part of the public lookup did not return a result during that run.
- A delivered message's authentication results and the actual sending IP are separate evidence from a public domain lookup.
- Repeating the same lookup after a documented change shows whether the public result changed.

## What this tool checks

[Palisade's Domain Reputation Check](/tools/domain-reputation) accepts a domain and checks public blocklist evidence associated with the target and related infrastructure. Record the submitted domain, date, overall verdict, number of completed checks, detections, and any unavailable checks. Those details make a later retest comparable to the first run.

The tool is useful for a bounded public lookup. It cannot see the production sending path, prove that a mail application signs messages correctly, continuously monitor the domain, read a mailbox provider's private reputation model, or determine why one recipient received a message in spam.

Keep public-list evidence separate from delivered-message evidence. [RFC 8601 defines the `Authentication-Results` header field that receivers can add to messages](https://datatracker.ietf.org/doc/html/rfc8601). That header can show the receiver's authentication evaluation for a particular message, but it is not a published reputation score. Google's [sender guidelines](https://support.google.com/a/answer/81126) likewise treat authentication and sender-side monitoring as operational requirements rather than a single public reputation measurement.

## How to run the check

### 1. Identify the domain and preserve the incident context

Use the domain in the visible From address or the domain whose reputation you need to investigate. If the concern is one campaign or one application, also record the date, recipient provider, sending application, and the sending IP if you have it. Do not substitute a marketing domain for the actual domain used in the message without checking the headers.

A public result alone cannot connect a listing to one mail stream. That connection needs message and infrastructure evidence.

### 2. Run the domain reputation check

Open the Domain Reputation Check, enter the domain, and save the returned verdict and check counts before making changes. A public DNS lookup can provide a narrow independent check of the DMARC record for the same domain, but it answers a different question:

```bash
dig +short TXT _dmarc.yourdomain.com
```

The command shows the public TXT answer returned by the resolver. It does not test public blocklists, sender configuration, or mailbox-provider placement.

![Palisade Domain Reputation Check result for a public example domain](/images/editorial/test-email-reputation/test-email-reputation-shot-1.png "1280x720")

*Source: [Palisade Domain Reputation Check](https://www.palisade.email/tools/domain-reputation), checked 2026-07-28. [Open the full-size screenshot](/images/editorial/test-email-reputation/test-email-reputation-shot-1.png).*

The captured public `example.com` result showed 11 completed blocklist checks, 0 detections, a Clean verdict, and two unavailable checks. It is an example of the tool's current result format, not evidence about any production sender.

### 3. Collect same-path message evidence

Send a fresh message through the exact application, authenticated domain, outbound gateway, and recipient-provider path under investigation. Open the raw message source and preserve the receiver-added `Authentication-Results` header with private addresses and message content removed.

Check the result against the actual message path. For example, a public domain check can be clean while a message fails authentication because the sending service is using an unexpected return path or DKIM signing domain. Use the [DKIM testing guide](/learning/dkim-testing) when the message evidence points to DKIM.

## How to interpret the results

### Clean with zero detections

A Clean verdict with zero detections means the completed public checks found no listed item for the checked target during that run. Treat it as one observation with a timestamp.

Do not infer that every receiver trusts the sender or that the campaign will reach the inbox. A receiver can use private reputation signals, message content, engagement, and authentication evidence that a public lookup cannot inspect. If a real message still has a delivery issue, compare its raw headers and sending IP with the domain result.

### One or more detections

A detection means at least one completed public check returned a listing associated with the lookup. First identify the exact object named by the result. It may be the domain, a related host, or infrastructure connected to the sending path.

Do not remove DNS records or request delisting until you know which production system uses the listed object. Preserve the result, identify the sending IP from a message or mail-service logs, and check that IP separately. If you are investigating a wider sender-reputation decline, use the recovery workflow in [How can you check and improve your email domain reputation?](/learning/how-can-you-check-and-improve-your-email-domain-reputation).

### Unavailable checks

Unavailable checks mean those public sources did not return a usable answer during the lookup. They are neither a clean result nor a detection. Record them and repeat the same lookup later before treating the overall result as complete.

Do not fill the gap by assuming a missing response is favorable. The correct next evidence is the same public check, the sending IP if it is known, and a delivered message from the affected path.

## How to act on the result

Start with the smallest evidence-backed action:

- For a clean domain result with a live delivery incident, inspect the delivered message's `Authentication-Results` and identify the actual sending IP. A clean public result does not rule out message authentication or receiver-policy problems.
- For a domain detection, identify the specific listed object and confirm that the affected production sender uses it. Follow the public list operator's documented remediation path only after that match is established.
- For an IP-specific incident, use the [IP Reputation Check](/tools/ip-reputation) with the actual sending IP from message headers or mail infrastructure. Do not use an assumed provider IP.
- For a placement or content question after authentication checks pass, use an email deliverability test and the separate spam-email testing workflow.

> Do not change the DMARC policy, delete authentication records, or rotate sender settings solely because of a public blocklist result. A wrong change can interrupt legitimate mail while leaving the original incident unexplained.

![Email reputation evidence flow from public lookup to message and IP checks](/images/editorial/test-email-reputation/test-email-reputation-reputation-evidence-flow.webp "1200x829")

*Source: Palisade.*

## Investigate this with your coding agent

Use this when you have a redacted public result and message headers but need to trace which application or infrastructure component sent the affected mail. Remove message content, recipient addresses, IP addresses, tokens, and credentials before sharing evidence.

```agent
Problem: A public Domain Reputation Check result is clean, detected, or incomplete, but the production sender responsible for an email-reputation incident is not confirmed.
Evidence: Redacted domain-check result, test timestamp, redacted Authentication-Results header, redacted Received headers, known sending application, and the documented sending IP if available.
Repository scope: Mail configuration, infrastructure-as-code, DNS configuration, and application mailer settings relevant to yourdomain.com.
Constraints: Inspect before editing. Do not apply changes until I approve the proposed diff. Do not expose or request secrets, private keys, tokens, unredacted headers, customer data, or production credentials.
Requested output: Diagnosis, the minimal proposed change, rollback, and unknowns.
Verification: Repeat the Domain Reputation Check for yourdomain.com and send a new message through the same production path to inspect its Authentication-Results header.
Stop if: Credentials, private data, production mutation, or missing evidence is required.
```

## How to retest

Repeat the Domain Reputation Check for the same domain after a documented repair, delisting outcome, or infrastructure change. Compare the date, completed-check count, detections, and unavailable checks with the saved first result.

Then send a new message through the same production path and inspect its authentication evidence again. Validate at four layers when the incident involves authentication or sender configuration:

- DNS: query the authoritative configuration and at least one public resolver.
- Vendor: check the sending provider's current authentication or verification status.
- Message: inspect a fresh delivered message from the affected path.
- DMARC: review aggregate-report data once it accumulates.

A green vendor status is not proof that the message was sent through the expected path. A public lookup is also not proof of a receiver's private reputation decision.

## Check the sending IP after a domain result

If the investigation identifies the IP that actually sent the affected message, check that IP next. This adds public infrastructure evidence to the domain result and message headers.

[Check the sending IP](/tools/ip-reputation)

The IP lookup cannot read a mailbox provider's private reputation, repair a listing, continuously monitor every sender using the domain, or guarantee delivery.

For an ongoing source-inventory and authentication problem, Palisade is AI-first, agent-first DMARC software. Its DMARC Agent analyzes aggregate-report data to identify sending sources and authentication or alignment issues, creates prioritized remediation tickets, and proposes the next DMARC policy stage for human review. It does not delist an IP, control a receiver's reputation model, change the DMARC policy without human approval, or guarantee inbox placement.

[Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=sender_reputation&utm_content=test-email-reputation)

## Sources and further reading

- [Palisade Domain Reputation Check](/tools/domain-reputation)
- [RFC 8601: Message Authentication Status](https://datatracker.ietf.org/doc/html/rfc8601)
- [Google Email sender guidelines](https://support.google.com/a/answer/81126)

## Frequently asked questions

### Does a Clean domain reputation result mean my email will reach the inbox?

No. A Clean result means the completed public checks found no detection for the checked target at that time. It does not reveal a mailbox provider's private reputation decision or guarantee inbox placement.

### Should I test the sending IP as well as the domain?

Yes, when you can identify the actual sending IP from message headers or mail infrastructure. Domain and IP checks inspect different public evidence, so keep their results with the same-path message evidence.

### What do unavailable checks mean in a reputation result?

Unavailable checks mean part of the public lookup did not return a usable answer during that run. Repeat the same lookup later and do not interpret an unavailable check as either clean or listed.

### Can a public blocklist check explain why one message went to spam?

No. It can reveal public listing evidence, but one spam placement can also involve authentication, message content, recipient-provider policy, or private reputation signals. Inspect a real delivered message before concluding the cause.

### Does passing DMARC prove a sender has a good reputation?

No. DMARC evaluates domain authentication and alignment. It is separate from a receiver's reputation assessment, though correct authentication gives receivers reliable identity evidence.