Every other number on the Authentication pages answers *what is true now*. The timeline answers **what changed, when, what the record used to say, and whether the change worked**.

**Where to find it:** **Reports → Authentication**, select a domain, and stay on the **Overview** tab. The timeline appears as markers on the trend chart, with the full list directly below it.

## Why it exists

The most useful thing to know about a domain whose DMARC protection silently weakened is not *that* it weakened — it is **what the record used to say**.

Your current record *is* the damage. Nothing else in DMARC keeps the previous value: not your DNS provider once the edit is saved, not the aggregate reports, which never carry record text. A customer whose registrar rewrote their record needs the old string to paste back, and before the timeline existed that string existed nowhere.

So SendOps keeps it. Every change stores the `_dmarc` TXT **verbatim as observed**, on both sides.

## What appears on it

| Event | What it means |
|---|---|
| **DMARC published** / **Policy tightened** / **Policy weakened** | The published `p=` (or `sp=`) moved. |
| **Record edited — the policy did not change** | A record edit that moved no policy: a rewritten `rua`, a new reporting address. |
| **Sources decided** | Somebody confirmed or rejected sending sources. |
| **Cost accepted** | Somebody [acknowledged a cost](/domain-auth/moving-to-quarantine-and-reject#accepting-a-cost-before-you-publish) before publishing. |
| **Note** | Something a colleague wrote down. |


It looks like the least interesting thing on the list. It is not: rewriting the `rua` tag is **how reporting silently stops**, and that is the commonest way a healthy monitored domain becomes an unmonitored one. Giving it a row of its own is what makes it noticeable.


## Where the history comes from

Two independent sources of evidence, and they are kept separate on purpose:

| Source | What it gives you | What it cannot see |
|---|---|---|
| **A live DNS lookup** | The exact record text, timestamped to the moment we looked. | Only ever describes *now*. |
| **Your aggregate reports** | History from before you onboarded — every report states the policy the receiver applied. | Lags 24–48 hours, carries no record text, and is only accurate to the day. |

A change visible in DNS but not yet in the reports is **not a contradiction**. It is the state in which the right thing to do is wait rather than judge, and the timeline can say so only because it records both.


Most real changes are seen twice — once in DNS and once in your reports. The timeline folds them into **one** event and lists both sightings under it. A domain whose policy moved once is never shown as having moved twice.

A domain that publishes quarantine, reverts, and publishes again is genuinely three events, and stays three.


Two dates are kept for every event: **when it happened** (taken from the evidence) and **when we first knew** (the clock). They are separate because collapsing them would date a report-derived change to whenever the job ran — placing a policy change *after* mail that was already judged under it.

A change is only recorded once **two consecutive DNS lookups agree**, and the first time SendOps sees your domain it records a baseline rather than a change. The record we found when we started looking is not something you did.

## Did this change work?

Open a policy change on the timeline and choose **Did this change work?**. SendOps recomputes the readiness figures over a window either side of that one change.

It is the only view in the product that can answer the question. Every other figure is a rolling thirty days that mixes both sides of the change together.


A comparison that always produced a delta would produce a wrong one. Each refusal is stated rather than silently absorbed.


- **The first two days after the change are excluded.** Reports lag 24–48 hours, so those days carry mail that was sent *and judged* under the old policy.
- **A side that is too quiet renders no delta** — and "too early to tell" is shown differently from "too quiet". Nothing was lost in the first case; the evidence has not arrived yet, and that is the whole of what you do next.
- **If another change fell inside one of the windows, the figures still stand but the attribution does not.** The panel names the other change under *Also inside these windows*. What is withheld is the claim that *this* change caused the difference.
- **If the history does not reach back far enough**, it says which side was cut short and by how many days.

The comparison is offered only for a **policy change**. A record edit that moved no policy has nothing for a before and an after to be about, and a note or a source decision is not a change to the record at all.


Two things are read as they stand **today** on both sides: how each source is classified, and the decisions you have made about them. Otherwise a source you reclassified last week would move between columns and read as mail that changed hands.


## Writing a note

If you have permission to manage domain authentication, you can add a note to the timeline — "moved DNS to Cloudflare", "vendor promised DKIM by the 14th", whatever the next person reading this needs.

A note is additive and inert: it sets no policy, publishes no DNS, and is read by nothing that decides a verdict. It cannot be deleted, which is what makes a timeline worth trusting.

## Reading it against the chart

The markers on the trend chart and the list below it are the same events. Selecting one highlights the other, so a step in your pass rate can be lined up against the change that caused it — which is usually the fastest way to find out whether a fortnight-old edit is what broke something.

## Related

- [Moving to p=quarantine and p=reject](/domain-auth/moving-to-quarantine-and-reject) — the ladder, the watch window, and rolling back
- [Reading Your Source Table](/domain-auth/reading-your-source-table)
- [Setting Up DMARC Reporting](/domain-auth/setting-up-dmarc-reporting)