DMARC reporting tells you who is sending email as your domain — your own applications, the SaaS tools your teams signed up for, forwarders, and anyone spoofing you. You get that picture by publishing one DNS record. This guide covers what to publish, how to add it to a record you already have, and what to expect once it is live.

## What an aggregate report is

An **aggregate report** is a daily summary that a receiving mail provider — Google, Microsoft, Yahoo, Mimecast and hundreds of others — sends about mail that claimed to be from your domain. It is an XML document listing each sending IP address, how much mail it sent, and whether that mail passed SPF and DKIM alignment.

What it does **not** contain matters just as much:

- no message content
- no subject lines
- no recipient addresses
- no attachments

An aggregate report is a count, not a copy. That is why it is safe to have these reports delivered to a third party such as SendOps, and it is the reason we accept aggregate reports and [deliberately refuse forensic ones](/domain-auth/forensic-reports).

## Where this lives in SendOps

Domain authentication is split across two places, and the split is worth knowing before you start:

| Where | What it is for |
|---|---|
| **Infrastructure → Domain Auth** | Getting set up: the record to publish, setup health, and policy readiness. |
| **Reports → Authentication** | Reading what the reports say: sources, pass rate, trends, TLS. |

This page is about the first one. Everything under **Reports → Authentication** stays empty until the record below is published and reports start arriving.

## What to publish

Open **Infrastructure → Domain Auth** and select your domain. The setup card shows the exact TXT record to publish:

| Type | Name | Value |
|------|------|-------|
| TXT | `_dmarc.example.com` | `v=DMARC1; p=none; rua=mailto:d-a1b2c3d4e5f6g7h8j9k0m1n2@rpt.sendops.dev` |

Copy it from the dashboard rather than from this page — the address is unique to your domain.


The local part is `d-` followed by 24 random characters. It encodes nothing — not your organisation, not your domain, not your plan. This record lives in public DNS where anyone can read it, so the address is deliberately meaningless to anyone who finds it.


### `p=none` does not affect delivery

This is the sentence worth reading twice. The `p` tag tells receiving servers what to do with mail that fails authentication, and `p=none` tells them **to do nothing differently**. It is a request for reports and nothing else.

Publishing this record cannot cause your mail to be filtered, quarantined or rejected. It changes no delivery behaviour whatsoever. It only asks receivers to send you a daily summary of what they saw.

Tightening the policy later — to `p=quarantine` or `p=reject` — is a separate, deliberate decision, and one you should only make once the reports tell you it is safe. That is covered in [Moving to p=quarantine and p=reject](/domain-auth/moving-to-quarantine-and-reject).

## Adding to a DMARC record you already have

If `_dmarc.example.com` already exists, **do not replace it**. A domain that already publishes DMARC is usually already reporting to a vendor, a security team, or a monitor somebody relies on. Overwriting the record silently switches that off.

DMARC allows a comma-separated list of aggregate destinations, so add yours alongside the existing one.

**Before:**

```
v=DMARC1; p=none; rua=mailto:dmarc@vendor.example
```

**After:**

```
v=DMARC1; p=none; rua=mailto:dmarc@vendor.example,mailto:d-a1b2c3d4e5f6g7h8j9k0m1n2@rpt.sendops.dev
```

Note there is **no space** after the comma, and everything outside the `rua` value is left exactly as it was — your existing policy, your `sp`, `adkim`, `aspf` and any vendor-specific tags all stay byte for byte identical.

SendOps detects an existing record and offers you the appended version directly, so in practice you can copy the finished value out of the setup card.

## Two DMARC records means you have none


RFC 7489 §6.6.3 instructs receivers to ignore a domain's DMARC policy **entirely** if the domain publishes more than one DMARC record. Two records is not two policies — it is *no* policy and *no* reporting, which is strictly worse than having never published one.


This happens most often when a second tool is added and its setup instructions say "create a TXT record at `_dmarc`" without checking whether one exists. It looks like this:

```
_dmarc.example.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@vendor.example"
_dmarc.example.com  TXT  "v=DMARC1; p=none; rua=mailto:d-a1b2c3d4e5f6g7h8j9k0m1n2@rpt.sendops.dev"
```

Both are individually valid. Together they cancel each other out, and you will receive nothing from either destination.

The fix is to merge them into a single record carrying both destinations, as shown above, and delete the other. SendOps reports this state explicitly rather than guessing which record you meant to keep — which policy survives changes what receivers do to your mail, and that is your decision to make.

## How long until data appears

**24 to 72 hours** for the first reports, in normal circumstances.

Providers batch aggregate reports and send them on their own schedule, usually once a day. Add DNS propagation on top, and a same-day report is the exception rather than the rule.

A domain that sends very little mail may wait longer still — a provider that saw no mail from you has nothing to report, so a low-volume domain can genuinely take a week to see its first report. The dashboard shows an explicit "awaiting first report" state rather than six zeroed statistics, because zeros read as failures when the truth is silence.

## Where to go next

Once the record is live, the setup card collapses to a short confirmation with a **View reports →** link. That takes you to **Reports → Authentication**, where the source table fills in as reports arrive.

[Reading your source table](/domain-auth/reading-your-source-table) explains what each classification means and which findings need action.

## A note on forensic reports

You may have seen a `ruf=` tag in another vendor's setup instructions. SendOps does not ask for forensic reports and never processes one. This is a deliberate decision about personal data, not a missing feature — see [Why we do not accept forensic reports](/domain-auth/forensic-reports).

## Related

- [DNS Configuration](/domains/dns-configuration) — DKIM, SPF and DMARC records for a sending domain
- [Adding a Domain](/domains/adding-a-domain) — verifying a domain before you get here
- [Domain Verification troubleshooting](/troubleshooting/domain-verification)