# Implementing DMARC

> Publish a DMARC TXT record to protect your domain from spoofing, then graduate the policy from none to quarantine to reject.

DMARC builds trust in your domain and protects it from spoofing — forged mail sent in your name. It is published as a TXT record at `_dmarc` on your domain and tells receiving mail servers what to do with messages from you that fail authentication.

## Prerequisites

DMARC sits on top of SPF and DKIM, so your mail must already pass them:

- **DKIM** cryptographically proves the message was not altered in transit.
- **SPF** authorizes the IP addresses allowed to send for your domain.

> **Note:** If you have a [verified domain](https://www.mailblastr.com/docs/domains/managing) in MailBlastr, you are already passing SPF and DKIM — so you are ready to add DMARC.

## What is DMARC?

DMARC (Domain-based Message Authentication, Reporting, and Conformance) instructs mailbox providers how to handle a message that fails SPF and DKIM, and gives you reports on who is sending in your name. A message achieves **DMARC compliance** if it passes *either* SPF *or* DKIM (it need not pass both); it fails DMARC only when both fail.

## Step 1 — Publish a starter record

Begin with a permissive `p=none` policy so you can observe without affecting delivery:

**TXT record**

| Name | Type | Required | Description |
| --- | --- | --- | --- |
| `Name` | host | No | `_dmarc.example.com` |
| `Type` | record | No | `TXT` |
| `Value` | string | No | `v=DMARC1; p=none; rua=mailto:dmarcreports@example.com;` |

The key tags in that value are:

- `v` — the DMARC **version** (always `DMARC1`).
- `p` — the **policy** applied to failing mail: `none`, `quarantine`, or `reject`. Start at `none`.
- `rua` — the **aggregate report** address. Provide a real mailbox (it can live on another domain); reports arrive as an email with an attached `.xml` summarizing your sources and whether they passed SPF/DKIM.

## Step 2 — Confirm delivery and passing

Send from every application and service that mails as your domain, confirm those messages land in the inbox, and inspect the headers for `dmarc=pass`. Spend a few days here so you catch sources that send on an irregular cadence.

> **Note:** Tools like Google Postmaster Tools surface SPF/DKIM feedback, and DMARC monitoring services aggregate your `rua` reports — both help you discover every service sending on your behalf before you tighten the policy.

## Step 3 — Upgrade the policy

Once every legitimate source is passing, raise the policy. The three options:

| Policy | Effect |
| --- | --- |
| `p=none;` | Deliver everything; monitor failures only. |
| `p=quarantine;` | Route messages that fail DMARC to the spam folder. |
| `p=reject;` | Bounce messages that fail DMARC outright. |

> **Warning:** Only move to `quarantine` or `reject` after you have confirmed all of your real mail passes — otherwise you risk junking or bouncing your own legitimate email.

A policy of `p=quarantine;` or `p=reject;` is also the prerequisite for [BIMI](https://www.mailblastr.com/docs/domains/bimi), which can display your brand logo as the sender avatar.

## Tag reference

| Tag | Purpose | Example |
| --- | --- | --- |
| `v` | Protocol version | `v=DMARC1` |
| `p` | Policy for the organizational domain | `p=quarantine` |
| `sp` | Policy for subdomains | `sp=reject` |
| `rua` | Aggregate report address | `rua=mailto:aggrep@example.com` |
| `ruf` | Forensic report address | `ruf=mailto:authfail@example.com` |
| `pct` | Percentage of mail subjected to filtering | `pct=20` |
| `adkim` | DKIM alignment mode | `adkim=s` |
| `aspf` | SPF alignment mode | `aspf=r` |

> **Note:** Mailbox providers honor `pct` and `ruf` inconsistently, so do not rely on them — treat `p`, `rua`, and the alignment tags as the parts that actually take effect.
