A DMARC record is a single DNS TXT entry that publishes your email authentication policy. It lives at a fixed location, `_dmarc.yourdomain.com` (note the leading underscore), and any receiving mail server can look it up to learn how you want failing mail handled and where to send reports.

## Where does a DMARC record live?

Always at the `_dmarc` subdomain of the domain you're protecting. For `example.com`, the record sits at `_dmarc.example.com`. For a subdomain you send from, say `mail.example.com`, it would be `_dmarc.mail.example.com`, though most teams publish one record at the organizational domain and let it cover the subdomains. It's a TXT record, the same record type SPF uses, which is why anyone who has published [an SPF record](/blog/what-is-an-spf-record) will find the process familiar.

## What if there is no DMARC record?

"No DMARC record found" means nothing is published at `_dmarc.yourdomain.com`. Two consequences follow, and the second is the one people miss.

Receiving servers have no instruction from you, so each one falls back to its own handling for a message that fails authentication. And because `rua` is where reports are requested, an absent record requests nothing: you get no aggregate reports, so you cannot see who is sending as your domain or whether your own mail passes.

Absence is not the same as `p=none`. A `p=none` record is a published policy that asks receivers to change nothing while still sending you reports, which is the normal place to start. No record at all gives you neither the policy nor the visibility.

To check a domain yourself, query the TXT record at the `_dmarc` name:

```bash
dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.com
```

If you would rather not hand-query, the [email analyzer](/tools/email-analyzer) checks a domain in the browser and [`bird email tools audit`](/docs/cli/reference/email-tools-audit) does the same from a shell.

A reply containing `v=DMARC1` is a record. An empty reply is a genuine absence. Two near-misses report as "not found" even though you published something:

- **Published at the wrong name.** The record has to sit at `_dmarc.example.com`, with the leading underscore, rather than at the domain root beside your SPF record.
- **A malformed `v` tag.** `v=DMARC1` is required and must come first, so a typo there makes the record unreadable as DMARC even though the TXT entry resolves.

If the answer is that you have no record, [how to set up DMARC](/explained/deliverability/how-to-set-up-dmarc) is the next step, and starting at `p=none` with `rua` pointed at a mailbox you read is the usual first record.

## What does a DMARC record look like?

Here's a straightforward one:

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

Read left to right, that says: this is a DMARC version 1 record, apply no enforcement yet (monitor only), and send aggregate reports to dmarc@example.com. A more complete record might read:

```text
v=DMARC1; p=quarantine; sp=reject; rua=mailto:agg@example.com; ruf=mailto:forensic@example.com; adkim=s; aspf=r; pct=100
```

Every record is just a list of `tag=value` pairs separated by semicolons. Two are required (`v` and `p`); the rest are optional and have sensible defaults.

## What does each DMARC tag mean?

| Tag     | Required | What it does                                                    | Example                           |
| ------- | -------- | --------------------------------------------------------------- | --------------------------------- |
| `v`     | Yes      | Protocol version. Always `DMARC1`, and must come first.         | `v=DMARC1`                        |
| `p`     | Yes      | Policy for the main domain: `none`, `quarantine`, or `reject`.  | `p=quarantine`                    |
| `sp`    | No       | Policy for subdomains, when you want it to differ from `p`.     | `sp=reject`                       |
| `rua`   | No       | Where aggregate (summary) reports are sent.                     | `rua=mailto:agg@example.com`      |
| `ruf`   | No       | Where forensic (per-message failure) reports are sent.          | `ruf=mailto:forensic@example.com` |
| `adkim` | No       | DKIM alignment mode: `r` relaxed (default) or `s` strict.       | `adkim=s`                         |
| `aspf`  | No       | SPF alignment mode: `r` relaxed (default) or `s` strict.        | `aspf=r`                          |
| `pct`   | No       | Percent of failing mail the policy applies to (default 100).    | `pct=25`                          |
| `fo`    | No       | Forensic reporting options: when a failure report is generated. | `fo=1`                            |
| `ri`    | No       | Aggregate reporting interval in seconds (default 86400).        | `ri=86400`                        |

The two you'll touch most are `p` and `rua`. `p` is your enforcement level, and choosing it well is the heart of a good rollout (the full breakdown is in [what is a DMARC policy](/explained/deliverability/what-is-a-dmarc-policy)). `rua` is the address that receives the daily summaries you'll actually learn from.

## What's the difference between rua and ruf?

`rua` collects aggregate reports: XML summaries, usually one per day from each provider, covering all the mail they saw under your domain. This is the stream worth watching. `ruf` collects forensic reports, which are copies (often redacted) of individual messages that failed. Many providers don't send forensic reports at all for privacy reasons, so don't be surprised by a quiet `ruf` mailbox. When the reports start arriving, [how to read a DMARC report](/explained/deliverability/how-to-read-a-dmarc-report) walks through the fields.

## What do the alignment tags do?

`adkim` and `aspf` control how exact the domain match has to be. Relaxed (`r`) lets a subdomain match the organizational domain, so `mail.example.com` aligns with `example.com`. Strict (`s`) demands an exact match. Relaxed is the default and the right choice for almost everyone; reach for strict only when you have a specific reason. Alignment is the mechanism that makes DMARC stronger than SPF or DKIM used alone, and [how DMARC works](/explained/deliverability/how-does-dmarc-work) explains why.

## How do you publish and check it?

You add the TXT record through your DNS host, then confirm it resolves. The step-by-step, including a cPanel walkthrough, is in [how to set up DMARC](/explained/deliverability/how-to-set-up-dmarc). If you send through Bird, DKIM and SPF alignment are set up through your sending-domain records, so publishing this DMARC record and pointing `rua` at a mailbox you watch is most of the job. The [authentication guide](/docs/guides/email/dkim-spf-dmarc) in the docs has the Bird-specific details.

A DMARC record is small, but it's doing a lot of work in one line. Get the `p` and `rua` right and you can refine everything else later.