# DMARC Record Builder

> Build and audit a current DMARC DNS policy with reporting destinations, alignment choices, test mode, external authorization records, and staged enforcement guidance.

- **Category:** Deliverability
- **Updated:** July 2026
- **Standard:** RFC 9989
- **Canonical page:** [https://emailbump.com/tools/dmarc-record-builder](https://emailbump.com/tools/dmarc-record-builder)
- **Interactive tool:** [Open the builder](https://emailbump.com/tools/dmarc-record-builder)

## What the tool does

The builder turns a domain and policy choices into a DNS TXT record at:

```text
_dmarc.example.com
```

A monitoring record with aggregate reporting could look like:

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

The interactive tool provides:

- A normalized DNS host, TXT value, and conventional zone-file line
- Domain and report-address validation
- Plain-language explanation of the effective failure policy
- DKIM and SPF alignment controls
- Aggregate and optional message-specific failure report destinations
- RFC 9989 policy test mode
- External report-receiver authorization records
- An enforcement-readiness checklist
- A staged monitoring, alignment, testing, and enforcement workflow

Generation happens in the browser. The domain and report addresses are not submitted to Email Bump or an external service.

## What DMARC validates

DMARC evaluates the domain in the visible RFC5322.From field, called the Author Domain. SPF authenticates the SMTP MAIL FROM domain, while DKIM authenticates the signing domain in a valid `DKIM-Signature`.

A message passes DMARC when at least one supported authenticated identifier both passes its underlying check and aligns with the Author Domain:

```text
aligned SPF pass OR aligned DKIM pass = DMARC pass
```

A DMARC pass means the visible From domain was used with the domain owner's authorization under the protocol. It does not guarantee that the message is desirable, safe, or destined for the inbox.

## Alignment modes

### Relaxed alignment

Relaxed alignment is the default for both DKIM and SPF. The authenticated identifier and Author Domain align when they share the same Organizational Domain.

For a domain whose Organizational Domain is `example.com`, an authenticated identifier such as `mail.example.com` can align with an Author Domain of `example.com` in relaxed mode.

### Strict alignment

Strict alignment requires the domains to be identical. It can be useful for a deliberate architecture but can also break legitimate subdomain arrangements. Confirm the actual DKIM `d=` domains and SPF MAIL FROM domains used by every sending source before choosing strict mode.

The corresponding tags are:

| Purpose | Relaxed | Strict |
| --- | --- | --- |
| DKIM alignment | `adkim=r` | `adkim=s` |
| SPF alignment | `aspf=r` | `aspf=s` |

Because relaxed is the default, the builder omits `adkim=r` and `aspf=r` to keep the record concise. It emits the tag when strict mode is selected.

## Policy controls

The main policy tag `p` expresses the domain owner's requested handling preference for messages that fail DMARC:

| Value | Meaning |
| --- | --- |
| `none` | Do not request quarantine or rejection; useful for monitoring |
| `quarantine` | Treat failing messages as suspicious |
| `reject` | Express the strongest requested handling for failures |

Participating receivers can use the request as one input to their filtering decisions and are not required to honor it mechanically.

### Subdomain policy

The optional `sp` tag sets a policy for subdomains. When it is absent, the applicable main `p` policy is inherited.

### Non-existent subdomain policy

RFC 9989 defines `np` for non-existent subdomains. When it is absent, the `sp` value is inherited if present, otherwise `p` is inherited.

## RFC 9989 test mode

The active `t=y` tag asks the actor performing DMARC validation to step the published policy down by one level during testing:

| Published policy | Requested effective level with `t=y` |
| --- | --- |
| `p=none` | `none` |
| `p=quarantine` | `none` |
| `p=reject` | `quarantine` |

Test mode does not disable reporting. It has no lower level to apply when the published policy is already `none`.

## Historic tags the builder excludes

RFC 9989 made several older tags historic:

- `pct`, which attempted percentage-based policy sampling
- `ri`, which requested an aggregate reporting interval
- `rf`, which selected a failure reporting format

The builder does not generate these tags. In particular, `pct` proved unreliable for staged enforcement because receiver implementations did not apply it consistently. Current deployments can use aggregate evidence, subdomain-specific policies, and the `t` policy test mode while progressing through explicit policy stages.

## Aggregate reports with rua

The optional `rua` tag lists comma-separated report URIs. Email delivery through `mailto:` is the required reporting transport to support. For example:

```text
rua=mailto:dmarc@example.com,mailto:security@example.com
```

Aggregate reports summarize observed authentication, alignment, disposition, and source information. They are operational evidence, not an automatic instruction to authorize every listed IP address. A forwarding system, unauthorized sender, or shared infrastructure can appear in a report for very different reasons.

Use a dedicated report mailbox or a trusted processor because report volume and compressed XML handling can be difficult to operate manually.

## Failure reports with ruf and fo

The optional `ruf` tag requests message-specific failure reports. Availability varies, and reports may contain message content, identifiers, or personal data. Complete a privacy, retention, access, and processor review before enabling them.

The `fo` tag is only meaningful when `ruf` is present:

- `fo=0` requests a report when all underlying authentication mechanisms fail to produce an aligned pass.
- `fo=1` requests a report when any underlying authentication mechanism fails to produce an aligned pass.
- The standard also defines `d` and `s` options for DKIM- and SPF-specific failure reporting.

The builder exposes the general DMARC `0` and `1` choices and does not pretend that every receiver will produce the requested reports.

## External reporting authorization

When the Organizational Domain of a report destination differs from the Organizational Domain where the DMARC policy was found, the report receiver must authorize the relationship in DNS.

For a policy at `example.com` that directs reports to `reports@processor.example.net`, the receiving operator publishes a TXT record at:

```text
example.com._report._dmarc.processor.example.net
```

with the value:

```text
v=DMARC1
```

Without valid authorization, the report generator must ignore that external destination. The builder conservatively shows an authorization record whenever the report mailbox is outside the entered domain. Organizational Domain discovery uses the DNS tree-walk rules in RFC 9989, so operators should confirm edge cases with their report processor and DNS provider.

## Safer rollout workflow

1. **Inventory:** List every platform, application, support desk, commerce system, employee service, and vendor authorized to use the domain in a visible From address.
2. **Monitor:** Publish `p=none` with an aggregate reporting destination.
3. **Observe:** Collect reports long enough to see routine, seasonal, low-volume, and employee-driven streams.
4. **Align:** Configure each authorized stream so DKIM or SPF passes and aligns; operating both correctly provides more resilience.
5. **Test indirect paths:** Review forwarding, mailing lists, gateways, and other systems that can alter authenticated identifiers.
6. **Assign ownership:** Decide who monitors reports, investigates new sources, approves vendors, and responds to delivery regressions.
7. **Test policy:** Use `p=quarantine; t=y` while continuing to review aggregate evidence.
8. **Enforce deliberately:** Remove test mode, operate quarantine, and progress to reject only when legitimate traffic remains healthy.

RFC 9989 recommends extended monitoring periods before stronger policy for domains used by individual users or mailing-list participation because indirect mail flows can fail alignment despite authorized use.

## Publication checklist

- Publish one DMARC policy record at the applicable policy location.
- Keep `v=DMARC1` first and preserve its case.
- Do not include the surrounding display quotes when a DNS control panel adds them automatically.
- Confirm how the DNS provider expects the Host or Name field; some providers want `_dmarc`, while others want the full `_dmarc.example.com`.
- Confirm aggregate report mailboxes can receive and process compressed XML.
- Publish external destination authorization when required.
- Allow for DNS propagation and caching.
- Query DNS from outside the authoritative environment after publication.
- Send authenticated test messages and inspect Authentication-Results headers.
- Continue monitoring after every vendor, domain, or authentication change.

Multiple competing TXT records that begin with `v=DMARC1` at the same policy location can make the result unusable. Update the existing policy rather than adding a second one.

## Frequently asked questions

### Does p=none stop spoofed messages?

It does not request quarantine or rejection. It enables DMARC evaluation and can request reports, which provide the evidence needed to repair legitimate authentication before stronger policy.

### Does p=reject guarantee rejection?

No. The tag communicates the domain owner's requested handling for DMARC failures. A receiver can combine it with local policy and other evidence.

### Should both SPF and DKIM align?

DMARC needs one aligned authenticated identifier to pass, but operating both correctly is more resilient. SPF can break during forwarding, while DKIM can fail when intermediaries modify signed content.

### Should alignment be strict?

Not by default. Relaxed alignment still constrains identity to the same Organizational Domain while supporting common subdomain configurations. Use strict mode only when the sending architecture is intentionally designed for exact matches.

### Is a generated record safe to publish?

The builder checks record construction and highlights rollout concerns. It cannot discover every real sending service, inspect current DNS, read aggregate reports, or prove that authorized streams align. The readiness work must be completed against the domain's actual mail.

## Primary sources

- [RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html)
- [RFC 9990: DMARC Aggregate Reporting](https://www.rfc-editor.org/rfc/rfc9990.html)
- [RFC 9991: DMARC Failure Reporting](https://www.rfc-editor.org/rfc/rfc9991.html)
- [IANA DMARC Parameters Registry](https://www.iana.org/assignments/dmarc-parameters/dmarc-parameters.xhtml)

## Related guidance

- [Fighting phishing with DMARC](https://emailbump.com/blog/dmarc-phishing-protection.md)
- [DMARC definition](https://emailbump.com/glossary/dmarc.md)
- [DKIM definition](https://emailbump.com/glossary/dkim.md)
- [SPF definition](https://emailbump.com/glossary/spf.md)
- [Sending domains documentation](https://emailbump.com/docs/domains.md)