# DMARC explained: policy, alignment, and rollout

> What DMARC is, why MailBlastr starts you at p=none, how to monitor and then tighten to quarantine or reject, and how alignment works through the SPF MAIL FROM and DKIM.

**DMARC** (Domain-based Message Authentication, Reporting & Conformance) is the policy layer that ties **SPF** and **DKIM** together. It is a single TXT record at `_dmarc.yourdomain.com` that tells receiving mail servers two things: what to do with mail claiming to be from your domain that fails authentication, and where to send reports about it.

MailBlastr generates a DMARC record for you starting at the safest setting — `p=none` — so you can publish it immediately without any risk of legitimate mail being blocked while you confirm everything is aligned.

## The record MailBlastr generates

**DMARC — TXT**

| Name | Type | Required | Description |
| --- | --- | --- | --- |
| `Type` | TXT | No | DMARC policy record. |
| `Name` | _dmarc.yourdomain.com | No | The standard DMARC hostname. |
| `Value` | v=DMARC1; p=none; | No | A monitoring policy to start with. Tighten the `p=` value once you trust your alignment. |
| `TTL` | Auto | No | Provider default. |

## How alignment works

DMARC passes when a message is **authenticated and aligned** by SPF or DKIM (either one is enough):

**DKIM alignment** — the message carries a valid DKIM signature (via the `mailblastr._domainkey.<domain>` TXT record holding your public key) and the signing domain matches your `from` domain.

**SPF alignment** — SPF passes for the message’s MAIL FROM (envelope) domain, and that domain aligns with your `from` domain. MailBlastr’s custom MAIL FROM subdomain `send.yourdomain.com` exists precisely to give you this alignment: the SPF TXT `v=spf1 include:amazonses.com ~all` authorizes MailBlastr to send for that subdomain.

> **Note:** Because a verified domain already publishes both DKIM (the public-key TXT) and SPF (the MAIL FROM MX + TXT), DMARC alignment is satisfied out of the box for mail you send through MailBlastr. See [DNS records](https://www.mailblastr.com/docs/domains/dns).

## Rolling out: none → quarantine → reject

Tighten your policy in stages. Move up only once your reports show that legitimate mail is consistently passing DMARC.

1. **Start at p=none (monitor)** — Publish `v=DMARC1; p=none;` (what MailBlastr generates). Receivers take no action on failing mail, so nothing legitimate is affected. Add a `rua=mailto:dmarc@yourdomain.com` tag to collect aggregate reports and watch which sources pass and fail.
2. **Confirm DMARC is passing** — Before tightening, send a message from every application and service that uses your domain (not just MailBlastr) and inspect the received headers for `dmarc=pass`. Tools like Google Postmaster Tools and DMARC monitoring/aggregation services help you discover any other sources sending as your domain — catch the ones that mail on a weekly or monthly cadence, not just daily.
3. **Move to p=quarantine** — Once reports show your real mail (MailBlastr and any other legitimate senders) passing, raise the policy to `p=quarantine;` so failing mail is sent to spam rather than the inbox. Consider `pct=` to ramp gradually.
4. **Move to p=reject** — When you are confident everything legitimate is aligned, set `p=reject;` so receivers drop spoofed mail outright. This gives you the strongest protection against impersonation of your domain.

## Tag reference

**DMARC tags**

| Name | Type | Required | Description |
| --- | --- | --- | --- |
| `v` | required | No | Protocol version — always `v=DMARC1`. |
| `p` | required | No | Policy for the organizational domain: `none` (monitor), `quarantine` (spam folder), or `reject` (block). |
| `sp` | optional | No | Policy for **subdomains** of the domain (e.g. `sp=reject`). Lets you apply a different, often stricter, policy to subdomains than the root. |
| `rua` | optional | No | Address that receives **aggregate** (daily-summary) XML reports — e.g. `rua=mailto:dmarc@yourdomain.com`. Essential during the `none` monitoring phase. May point to a different domain than the one being protected. |
| `pct` | optional | No | Percentage of failing mail the policy applies to (e.g. `pct=20`), useful for a gradual ramp. |
| `ruf` | optional | No | Address for **forensic** (per-message failure) reports — e.g. `ruf=mailto:authfail@yourdomain.com`. |
| `adkim` | optional | No | DKIM alignment mode: `r` (relaxed, default) or `s` (strict, signing domain must match exactly). |
| `aspf` | optional | No | SPF alignment mode: `r` (relaxed, default) or `s` (strict). |

> **Warning:** Although `pct` and `ruf` are part of the DMARC spec, they are **not widely honored** by mailbox providers — don’t rely on either being respected. Use `p=`, `rua=`, and (for staged subdomain control) `sp=` as your primary levers.

> **Warning:** Raise the policy at your DNS provider only after monitoring. Jumping straight to `p=reject` before confirming alignment can cause receivers to drop legitimate mail from sources you forgot about (e.g. a separate CRM or help-desk tool sending as your domain).

Related: [DNS records](https://www.mailblastr.com/docs/domains/dns) for the SPF and DKIM records DMARC builds on, and [What if my domain isn’t verifying?](https://www.mailblastr.com/docs/kb/domain-not-verifying) if the underlying records are not resolving yet.