# How can I create a DMARC record in DNS with Palisade?

> Create a DMARC record in DNS with Palisade, publish the correct TXT value, check the public record, and safely validate real sender alignment.

To create a DMARC record in DNS with Palisade, publish one TXT record at `_dmarc.yourdomain.com`, then use the [Palisade DMARC checker](/tools/dmarc) to inspect the public record returned for that domain. Start with a monitored policy while you validate each real sending path. A public DNS result confirms the policy receivers can retrieve, but it does not prove that a sender has aligned SPF or DKIM.

## Quick takeaways

- A DMARC policy is one TXT record published at `_dmarc.yourdomain.com`.
- The `v=DMARC1` tag must be first, and the `p=` tag states the requested policy.
- `p=none` requests monitoring, while `p=quarantine` and `p=reject` request enforcement.
- Keep a DNS change record before publication so the owner, value, approval, and follow-up are clear.
- A public lookup validates record visibility, not sender configuration, delivered-message authentication, or inbox placement.
- Move toward enforcement only after reviewing sender evidence and DMARC aggregate-report data.

## What this tool checks

The [Palisade DMARC checker](/tools/dmarc) performs a public lookup for the DMARC TXT record associated with the domain you enter. Use it to compare the public DNS answer with the record your DNS provider should publish.

[RFC 9989 defines DMARC record discovery at the `_dmarc` subdomain and the DMARC policy tags](https://www.rfc-editor.org/rfc/rfc9989.html.html). The checker can inspect the DNS layer. It cannot inspect a sending platform's private configuration, prove that an application signs mail, show the `Authentication-Results` from a delivered message, or reveal a receiver's private filtering decision.

Use the checker after a change, not as proof that the entire sending path works. The [DMARC learning hub](/learning/dmarc) has related guidance for policy rollout and sender investigation.

## How to run the check

### 1. Identify the visible From domain

Use the domain after `@` in the visible `From:` address that recipients receive. DMARC evaluates alignment against that domain, which can differ from an envelope sender or a provider-owned sending domain.

Treat each visible From domain as its own setup and validation task. A DMARC record for `yourdomain.com` does not automatically apply to `otherdomain.com`.

### 2. Draft the record and log the proposed DNS change

Create a record that starts with `v=DMARC1` and uses the policy appropriate to your current evidence. This example is illustrative only. Do not publish it unchanged, and do not use a reporting mailbox you do not control.

```text
_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com"
```

In this example, `v=DMARC1` identifies the DMARC record version, `p=none` requests monitoring, and `rua` requests aggregate reports at the named mailbox. [RFC 9989 describes these tags and the allowed policy values](https://www.rfc-editor.org/rfc/rfc9989.html.html).

Record the change before publishing it. This creates an auditable handoff between the person drafting the policy and the person responsible for the DNS zone.

- **Organizational domain:** `yourdomain.com`
- **DNS provider or zone owner:** the provider and account responsible for the authoritative zone
- **Exact owner name:** `_dmarc.yourdomain.com`
- **Proposed record value:** `v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com`
- **Purpose of each tag:** `v` identifies DMARC, `p` requests the receiver policy, and `rua` names the aggregate-report destination
- **Approver or change ticket:** your approved change record, such as `CHG-0000`
- **Publish time:** the planned UTC publication time
- **DNS verification result:** the returned authoritative and public DNS answers after publication
- **Real-message or report follow-up date:** the date to inspect a new message from each active sender and later review aggregate reports

The same structure works when adding optional tags. Keep the exact final TXT value in the record, rather than paraphrasing it in a ticket.

![Illustrative DMARC DNS record showing the required owner name and a monitoring policy](/images/editorial/how-can-i-create-a-dmarc-record-in-dns-with-palisade/how-can-i-create-a-dmarc-record-in-dns-with-palisade-record-shape.webp "1200x400")

*Source: Palisade.*

### 3. Create one TXT record in the authoritative DNS zone

Open the DNS zone for the visible From domain and add a TXT record. Some DNS interfaces append the zone name automatically. In those interfaces, enter `_dmarc` as the host. If the interface requires a fully qualified owner name, enter `_dmarc.yourdomain.com`.

Paste the final TXT value exactly as approved. Do not add the domain twice. A provider that appends `yourdomain.com` to an entered `_dmarc.yourdomain.com` can publish the wrong owner name.

> Publish only one DMARC TXT record at the `_dmarc` owner name. Multiple DMARC records at that name can leave a receiver unable to select a valid DMARC policy.

### 4. Check the public DNS answer

Enter the visible From domain in the Palisade DMARC checker and compare its returned record with the approved value in the DNS change record.

You can also repeat the public lookup independently:

```bash
dig +short TXT _dmarc.yourdomain.com
```

A public answer can remain cached until the record's TTL expires. Compare the result with the authoritative DNS provider before treating an earlier public answer as a failed publication.

## How to interpret the results

### A DMARC record is returned

A returned record means the lookup found public TXT data at the expected DMARC owner name. Compare the entire string with the approved value. Check that `v=DMARC1` is first, the policy is intentional, and the `rua` mailbox belongs to your organization.

This is syntax and publication evidence. It does not establish that a specific sender aligns. To make that conclusion, inspect a delivered message from that sender and its receiver-added authentication results.

### No DMARC record is returned

Confirm that you entered the visible From domain and that the DNS owner is `_dmarc.yourdomain.com`. Check whether the provider expects `_dmarc` or a fully qualified name, then inspect the authoritative zone for accidental duplication.

If the record was just saved, note the publication time and TTL in the change record. Retest after the relevant cache period instead of creating another TXT record.

### The returned record differs from the approved value

Treat a mismatch as a DNS publishing issue until the authoritative answer explains it. Common causes include editing the wrong zone, retaining an older TXT value, or publishing the host name in a form the provider expanded twice.

Correct the single authoritative record, update the change record with the observed result, and repeat the same lookup.

## How to act on the result

### No record or an incorrect owner name

Correct the TXT owner name in the authoritative zone first. Use `_dmarc` only where the provider appends the domain automatically. Then validate with the authoritative provider and a public resolver.

### A monitoring policy is published

With `p=none`, keep the DNS record in place and move to evidence from each active sender. Confirm the sender's own authentication setup, send a real message through the production route, and inspect the recipient's `Authentication-Results` header. [RFC 8601 defines the message header field used to report authentication results](https://www.rfc-editor.org/rfc/rfc8601.html).

A specific message passes DMARC when either SPF or DKIM passes and aligns with the visible From domain. A correctly formatted record does not make that happen. If you need to separate DNS publication from message signing, the [DKIM record setup guide](/learning/add-dkim-record-godaddy) explains why both checks matter.

### You are considering quarantine or reject

Do not choose an enforcement policy because the DNS record looks valid. First identify legitimate senders, validate a delivered message from each production path, and review DMARC aggregate reports after they accumulate. The [DMARC setup guide](/dmarc-setup) provides additional rollout context.

Use the DNS change record to document the evidence reviewed, the intended policy change, the approver, and the rollback value. A policy change is a human-controlled DNS change. Palisade does not autonomously change the DMARC policy.

## How to retest

Repeat the same Palisade DMARC checker lookup after the authoritative DNS record changes. The expected DNS result is the exact approved `v=DMARC1` TXT value at `_dmarc.yourdomain.com`.

Then validate the other layers separately:

- **DNS:** Compare the authoritative answer and a public resolver answer.
- **Vendor:** Check each sending service's current domain-authentication or verification status.
- **Message:** Send a new message through the same production path and inspect its `Authentication-Results`.
- **DMARC:** Review aggregate-report data after reports accumulate.

A green public DNS result is not proof that an application used an aligned envelope sender or that a receiver will place future messages in the inbox.

## Track sender alignment after the DNS record is live

The public record is one part of the work. The remaining question is which production senders still fail authentication or alignment as reports arrive. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=existing_content_migration&utm_content=how-can-i-create-a-dmarc-record-in-dns-with-palisade) to analyze DMARC aggregate-report data, identify sending sources and alignment issues, and create prioritized remediation tickets before a human reviews and applies a policy change.

Palisade does not autonomously publish DNS changes, prove every future message will authenticate, or guarantee inbox placement.

## Sources and further reading

- [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html.html)
- [RFC 8601: Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html)
- [Palisade DMARC checker](/tools/dmarc)
- [Palisade documentation](https://docs.palisade.email/)

## Frequently asked questions

### Where do I publish a DMARC record?

Publish the DMARC TXT record at `_dmarc.yourdomain.com`, where `yourdomain.com` is the domain in the visible From address you want to protect.

### Can I publish more than one DMARC TXT record?

No. Publish one DMARC record at the `_dmarc` owner name for the domain. Multiple DMARC TXT records can prevent a receiver from selecting a valid policy.

### Does a valid DMARC record prove my email passes DMARC?

No. A valid public record proves that receivers can retrieve the policy. You still need a delivered message from each production sender to confirm aligned SPF or DKIM authentication.

### Should I start with p=none?

Yes, when you still need to identify legitimate sending sources and validate their authentication. `p=none` requests monitoring rather than quarantine or rejection.

### When can I move to p=quarantine or p=reject?

Only after you have reviewed sender configuration, delivered-message evidence, and DMARC aggregate-report data for the production sources that use the domain. A DNS check alone is insufficient evidence for enforcement.