# Understand domain monitor results

Start with the latest run's status and then read the individual evidence. A domain score summarizes the run; the underlying checks explain which record or sending behavior needs attention.

## Read authentication and transport findings

| Check | What to investigate |
| --- | --- |
| SPF | Confirm the published record includes the services that send for this domain. |
| DKIM | Supply the selector used by your sender and inspect a delivered sample. Missing selector evidence is not proof that signing works or fails. |
| DMARC | Review the policy and observed alignment. A published policy and an enforced policy are separate findings. |
| MX | Confirm the expected receiving configuration and investigate unexpected changes. |
| BIMI, MTA-STS and TLS reporting | Inspect the record and any supporting policy evidence returned by the check. |
| Blocklists | Read whether the check ran and whether a listing was found. `blacklistChecked: false` must not be interpreted as a clean lookup. |

Run statuses include `HEALTHY`, `DEGRADED`, `CRITICAL` and `FAILED`. Read `errorMessage` for execution failures and `evidence` and `insights` for the checks. DNS changes may take time to become visible; preserve the before/after evidence instead of repeatedly changing several records at once.

## Add a delivered authentication sample

Create a verification address for the monitor, then send to it through your actual sending platform. Review the observed samples and auth stack alongside DNS evidence. This helps distinguish a published DKIM record from the signature and alignment on a real email.

[API endpoint: `createDomainMonitorEmailVerificationAddress`](/docs/api/#createDomainMonitorEmailVerificationAddress)

[API endpoint: `getDomainMonitorObservedAuthSamples`](/docs/api/#getDomainMonitorObservedAuthSamples)

[API endpoint: `getDomainMonitorAuthStack`](/docs/api/#getDomainMonitorAuthStack)

## Compare before and after a change

Record the run ID before changing DNS or sender configuration. Run the monitor again after the change is visible, then compare the two runs using `compareDomainMonitorRuns`. Keep the domain and selector context consistent so you know what changed.

```javascript
// Read the latest summary, auth stack, historical runs, and chart series.
const summary = await mailslurp.domainMonitorController.getDomainMonitorSummary({
  monitorId: monitor.id,
  dkimSelector: "default",
});

const runs = await mailslurp.domainMonitorController.getDomainMonitorRuns({
  monitorId: monitor.id,
  limit: 10,
});

const series = await mailslurp.domainMonitorController.getDomainMonitorSeries({
  monitorId: monitor.id,
  since: new Date(Date.now() - 30 * 24 * 60 * 60 * 1000),
  before: new Date(),
  bucket: "DAY",
});

console.log({
  latestRun: summary.latestRun,
  authStack: summary.authStack,
  runs,
  points: series.points,
});
```

Use the client and monitor from [setup](/docs/domain-monitor/). Replace the example `default` DKIM selector with your sender's actual selector.

[API endpoint: `compareDomainMonitorRuns`](/docs/api/#compareDomainMonitorRuns)

[API endpoint: `exportDomainMonitorRunResults`](/docs/api/#exportDomainMonitorRunResults)

The CSV export contains a row per check, including pass, fail or not-checked information. Use the series endpoint for trends and the run export when you need the evidence for a specific change.

A healthy DNS result does not determine a mailbox's folder decision. Follow up with [inbox placement](/docs/inbox-placement/) and use [Google Postmaster](/docs/domain-monitor-postmaster/) for additional available sender signals.