A correct DMARC record entry protects your domain from direct email spoofing, gives you visibility into legitimate services sending on your behalf, and helps satisfy major mailbox-provider authentication expectations. The actual DNS entry is short; the hard part is ensuring every sender has aligned SPF or DKIM before you tell receivers to quarantine or reject failures.

What a DMARC record entry is

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It is an email-authentication policy and reporting protocol built around the domain visible to a recipient in the message’s From: header. A domain owner publishes a DMARC policy in DNS, and receiving mail systems can use it when deciding how to handle mail that claims to be from that domain but does not pass DMARC evaluation. (rfc-editor.org)

A DMARC record does not send email, encrypt email, or replace SPF and DKIM. Instead, it ties the visible From: domain to those underlying authentication systems through a concept called alignment. A message passes DMARC when either SPF passes and aligns with the visible From domain, or DKIM passes and aligns with that domain. (support.google.com)

For a domain named example.com, the minimum useful DMARC record entry is:

Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none

At the DNS level, that creates a TXT record at _dmarc.example.com. The current DMARC standard defines publication at the _dmarc subdomain of the author domain, such as _dmarc.example.com for messages using example.com in their visible From address. (rfc-editor.org)

p=none means monitoring mode: you ask receivers to send no special enforcement instruction for failures. It is the appropriate starting position for most domains because it lets you discover all legitimate mail streams before an enforcement policy risks affecting valid mail. Google and Microsoft both describe a staged approach that begins with a monitoring policy before moving to quarantine or reject. (support.google.com)

The exact DNS entry to add

The record has two separate pieces in your DNS provider’s interface: the record name and the TXT value. Many setup failures happen because one is placed in the other field.

Use this basic record

For example.com, add the following:

DNS field	Value
Type	`TXT`
Host, Name, or Label	`_dmarc`
Value, Content, or TXT Data	`v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com`
TTL	Leave the provider default unless your DNS change-management process specifies another value

That creates the fully qualified record name _dmarc.example.com. In DNS dashboards that ask for a complete host name rather than a relative label, enter _dmarc.example.com instead. The right choice is vendor-interface-specific: inspect whether the dashboard automatically appends example.com to names you enter.

The record value is a semicolon-separated sequence of tag=value pairs. The first tag must identify the DMARC version as v=DMARC1; a policy record tells mail receivers the domain owner’s requested handling for messages that fail DMARC and may identify reporting destinations. (rfc-editor.org)

Do not put these things in the record

Avoid these common formatting errors:

Do not create the TXT record at example.com itself. DMARC is queried at _dmarc.example.com.
Do not put _dmarc inside the TXT value. It belongs in the DNS name or host field.
Do not use p=monitor. That was used in early DMARC drafts; the valid monitoring policy is p=none. (dmarc.org)
Do not type a provider’s instructional text, such as “add this record,” into the value field.
Do not create a second, competing DMARC TXT policy at the same _dmarc name. Consolidate tags into one intended policy record.
Do not copy curly “smart quotes” from a document. DNS interfaces usually want the plain record contents. If a provider automatically displays quotation marks around the final TXT answer, that is normal DNS presentation rather than a reason to add quotation marks yourself.

A DNS interface may split a long TXT value into quoted segments internally because of DNS TXT formatting limits. That is normally safe when the provider handles it; do not manually insert an unrelated second TXT record merely to break up a DMARC policy.

How DMARC decides whether a message passes

DMARC examines the domain in the human-visible RFC 5322 From: header. That is why a message can have a valid SPF result and still fail DMARC: SPF might authenticate a different domain, such as a delivery vendor’s bounce domain, rather than the brand domain shown to the recipient. (support.google.com)

The two ways to pass

A message passes DMARC if at least one of these paths succeeds:

Aligned SPF pass: the sending infrastructure passes SPF, and the SPF-authenticated domain aligns with the visible From domain.
Aligned DKIM pass: the message has a valid DKIM signature, and the signing domain in the DKIM d= value aligns with the visible From domain.

You do not need both aligned SPF and aligned DKIM for a message to pass DMARC, although configuring both is strongly preferable. Gmail’s sender guidance states that bulk senders need SPF, DKIM, and DMARC, while only one of SPF or DKIM needs to be aligned to meet DMARC alignment requirements for a message. (support.google.com)

Relaxed versus strict alignment

DMARC has two alignment modes:

Relaxed alignment accepts an organizational-domain relationship. For example, mail.example.com can align with example.com in an appropriate relaxed-alignment case.
Strict alignment requires an exact domain match.

The normal starting configuration uses relaxed alignment, which is also the default behavior when adkim and aspf are not specified. Strict mode can be useful after you have fully mapped your sending architecture, but turning it on prematurely often breaks legitimate mail sent through subdomains or vendor-managed return paths. The DMARC standard defines alignment as part of its evaluation model and provides controls for SPF and DKIM alignment behavior. (rfc-editor.org)

A practical example:

Visible From: billing@example.com
DKIM signature: d=example.com
SPF MAIL FROM: bounce.emailvendor.net

If DKIM validates, the d=example.com signature aligns with From: example.com, so the message can pass DMARC even though the SPF domain does not align. This is why DKIM is often the more resilient route for transactional email platforms and marketing tools.

The DMARC tags that matter most

Start with the smallest record that gives you useful data, then add only tags you can explain and operate. The following tags cover most domain-owner deployments.

`v`: the version tag

v=DMARC1

This is mandatory and identifies the record as DMARC. Put it first. A receiving system needs to recognize the version before treating the TXT content as a DMARC policy record. (rfc-editor.org)

`p`: the policy for the domain

p=none
p=quarantine
p=reject

p is your requested disposition for mail that fails DMARC:

none — monitoring only; do not request special DMARC enforcement.
quarantine — request treatment as suspicious, commonly spam or junk placement.
reject — request rejection of failing mail during delivery.

The receiver still makes the final handling decision based on its local policies and signals. In other words, p=reject is a powerful instruction, but it is not a promise that every receiving service will behave identically. DMARC gives the domain owner a policy preference that receivers can use in message handling. (rfc-editor.org)

`rua`: aggregate-report destination

rua=mailto:dmarc-reports@example.com

rua requests aggregate DMARC reports. These reports contain summarized authentication and policy data, generally in XML, from participating receivers. They are useful because they reveal IP addresses and mail sources seen using your domain, pass/fail outcomes, and the policy disposition applied. (rfc-editor.org)

Use a dedicated mailbox, group, or DMARC-reporting platform rather than a founder’s or support team’s everyday inbox. Google specifically advises using a dedicated mailbox or group because report volume depends on the amount of mail your domain sends and the receivers it reaches. (support.google.com)

`adkim` and `aspf`: alignment settings

adkim=r; aspf=r

These tags control DKIM and SPF alignment modes:

r means relaxed alignment.
s means strict alignment.

You can omit both when you want the normal relaxed defaults. Add them when you want the policy to be explicit for auditing or when you have deliberately validated strict alignment across every legitimate sender.

`sp`: policy for subdomains

sp=quarantine

sp lets you specify a policy for subdomains when they do not publish their own DMARC policy. It is useful for organizations that send from names such as news.example.com, billing.example.com, or alerts.example.com but want a different rollout plan than the parent domain.

Be careful: a subdomain with a DMARC record of its own is evaluated against that specific record. Do not assume the parent policy is the only policy involved when teams independently manage subdomains.

`np`: policy for non-existent subdomains

The current DMARC standard also defines np for messages using non-existent subdomains. This can be valuable for large organizations seeking to reduce spoofing from invented names such as invoice-493.example.com, but it is an advanced control. Establish a clean parent-domain policy and inventory real sending subdomains first. The modern DMARC specification includes support for policy discovery and controls covering domain and subdomain use. (rfc-editor.org)

Tags to treat cautiously

Older examples often include pct, ri, rf, ruf, and fo. Some still appear in vendor documentation and can be understood by implementations, but the DMARC standards update deprecated several legacy tags, including pct, rf, and ri. Failure reports requested through ruf can also expose more message-specific information and are not the operational foundation most teams need. Build your deployment around p, rua, and aligned SPF/DKIM first. (dmarc.org)

DMARC record examples you can copy

Replace example.com and the report address with your own domain and mailbox.

1. Safe monitoring record

Use this when you have not yet mapped every sender:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

DNS entry:

_dmarc.example.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

2. Monitoring record with explicit relaxed alignment

Use this when you want the defaults documented in the record:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r

3. Quarantine policy after validation

Use this only after aggregate reports show that legitimate mail consistently passes:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r

4. Reject policy for a fully authenticated domain

Use this once you have confirmed every legitimate stream, including rarely used systems such as invoicing, support, HR, CRM, forms, and automated alerts:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r

A reject policy is particularly useful for a domain that does not send mail at all. For example, a parked brand-protection domain can publish p=reject with reporting enabled after you confirm it has no legitimate senders. Microsoft recommends DMARC as a way to help protect domains from spoofed messages and supports configuration through a DNS TXT record. (learn.microsoft.com)

Set up a DMARC record entry step by step

The DNS edit itself takes minutes. The safe deployment process takes longer because it is an inventory and validation project.

Step 1: list every service that sends as your domain

Create a table of all systems that can send messages with your domain in the visible From address. Include obvious services and operational edge cases:

Google Workspace or Microsoft 365 user mailboxes
transactional email API or SMTP providers
product notifications and password resets
marketing automation and newsletter platforms
customer support and help-desk tools
accounting, billing, and invoice systems
recruitment, HR, and applicant-tracking tools
website forms, ecommerce platforms, and monitoring alerts
agencies or partners authorized to send as your brand

For each sender, record the visible From domain, SPF envelope/return-path domain where available, DKIM signing d= domain, and owner. This prevents the classic mistake of authenticating only the marketing platform while breaking the accounting system that sends a few messages each month.

Step 2: configure SPF and DKIM at each sender

Every sender should have an authentication path that can align. SPF identifies permitted email sources using DNS, while DKIM signs outbound mail and lets the recipient validate the signature using a public key in DNS. Google and Microsoft both document SPF, DKIM, and DMARC as complementary components of outbound-email authentication. (support.google.com)

For vendor platforms, follow the vendor’s domain-authentication flow rather than guessing at records. Many services provide CNAME records for custom DKIM and a custom return-path or MAIL FROM domain for SPF alignment. If the platform can sign DKIM using your own domain, enable it; that often provides a straightforward aligned-DKIM path.

Step 3: create a dedicated aggregate-report address

Create something like dmarc-reports@example.com. It can be a mailbox, a group, or an address managed by a reporting service. Make sure it can receive compressed XML attachments and that someone owns the review process.

If you send reports to an address at a different domain, the external report destination requires additional DNS authorization. Google’s setup guidance calls out this requirement, and the DMARC reporting standard defines verification for external destinations. Keeping the initial rua address on the same domain is the simplest route. (support.google.com)

Step 4: publish `p=none`

Add this value at _dmarc.example.com:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Save the DNS record. DNS changes are subject to caching, so validate the published answer rather than assuming an immediate update in every resolver.

Step 5: inspect reports and fix every legitimate failure

Review aggregate reports over enough normal business cycles to capture scheduled and infrequent sends. Look for:

an IP address or service you recognize that fails DKIM and SPF alignment;
a vendor sending with your visible From domain but its own unauthenticated domain;
a missing DKIM configuration after a platform migration;
an SPF record that no longer includes a newly added sender;
an unauthorized source attempting to impersonate your domain.

The correct response to a legitimate failure is not to relax DMARC forever. Fix the source: enable custom-domain DKIM, configure the vendor’s custom bounce domain, change the visible From domain to one you control and authenticate, or retire the unapproved sender.

Step 6: move deliberately to enforcement

When your reports show legitimate mail is passing, change p=none to p=quarantine. Continue monitoring after the change. Then move to p=reject when you are confident that the remaining failures are spoofing or unwanted sources.

This staged path matters because DMARC enforcement changes what recipients may do with failed mail. It should follow evidence from your mail streams, not a calendar deadline or a desire to copy a competitor’s DNS record.

Worked example: a SaaS company moving to `p=reject`

Assume a company uses northstarapp.com for employee mail, application receipts, marketing campaigns, support tickets, and invoices.

Initial state

The company has these visible From addresses:

team@northstarapp.com        — Google Workspace
receipts@northstarapp.com    — transactional email provider
news@northstarapp.com        — marketing platform
support@northstarapp.com     — help desk
billing@northstarapp.com     — accounting platform

The team initially publishes:

Host: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@northstarapp.com

They then send a test from every system to separate Gmail and Microsoft 365 inboxes. In the received message headers, they inspect the Authentication-Results field. Microsoft documents that its service adds this header to received messages and includes SPF, DKIM, and DMARC evaluation results. (learn.microsoft.com)

A healthy result looks broadly like this:

Authentication-Results: ...;
 spf=pass ...;
 dkim=pass header.d=northstarapp.com;
 dmarc=pass header.from=northstarapp.com

The exact formatting varies by receiving system, so focus on the result values and domains rather than expecting this exact line. The key signal is dmarc=pass for a message whose visible From domain is northstarapp.com.

Finding a failure

Reports show the accounting platform sends billing@northstarapp.com but signs with d=accountingvendor.example and uses an SPF bounce domain at mailer.accountingvendor.example. SPF may pass and DKIM may pass individually, yet neither aligns with northstarapp.com, so DMARC fails.

The team opens the vendor’s domain-authentication setup and configures its provided DKIM DNS records for northstarapp.com. After the vendor begins signing messages with d=northstarapp.com, invoice messages pass DMARC through aligned DKIM.

Enforcing safely

After the company verifies every known mail stream and sees no unexplained legitimate failures, it changes the record to:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@northstarapp.com; adkim=r; aspf=r

After continued review, it uses:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@northstarapp.com; adkim=r; aspf=r

The result is not “all email reaches the inbox.” DMARC does not create elevated delivery privileges. It establishes authentication and a policy signal; reputation, content, recipient engagement, complaint rates, and receiver-specific filtering still influence delivery. (rfc-editor.org)

How to check whether your DMARC record works

You need to validate three distinct things: DNS publication, message authentication, and reporting.

Check 1: confirm the DNS answer

From a terminal, query the exact DMARC host:

dig +short TXT _dmarc.example.com

Or on Windows:

nslookup -type=TXT _dmarc.example.com

You should see one TXT answer containing your policy, for example:

"v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

If you get no answer, check the DNS zone, hostname, authoritative nameservers, and whether the provider appended the root domain twice. If you get an answer at _dmarc.example.com.example.com, you entered a fully qualified name into an interface that expected only _dmarc.

Check 2: send real mail and inspect headers

Send one message from each mail system—not merely from your primary inbox—to a test address at a different provider. View the full headers and find Authentication-Results.

A passing result confirms the recipient evaluated that particular message successfully. It does not prove that every source is correct, which is why aggregate reports and an accurate sender inventory remain necessary.

Check 3: receive and interpret aggregate reports

Aggregate reports are structured XML files, often compressed. A raw report may be difficult to read manually, but it should identify sources, authentication results, and policy outcomes. RFC 9990 defines the aggregate-report format as XML and describes reports as feedback sent to destinations declared by the domain owner. (rfc-editor.org)

When evaluating a report, classify each source as one of four outcomes:

Known and passing: document it and keep monitoring.
Known and failing: repair its SPF/DKIM alignment.
Unknown and passing: investigate; it may be an overlooked vendor or an unauthorized configuration.
Unknown and failing: likely spoofing or a misconfigured third party; do not authorize it without a business owner and technical review.

Common DMARC record entry mistakes and fixes

The policy is correct, but mail still fails

This is usually an alignment problem, not a DMARC DNS-syntax problem. Check whether DKIM is signing with your domain in d= and whether SPF authenticates a domain that aligns with the visible From domain. A message can pass SPF or DKIM independently while failing DMARC because the authenticated domain is different. (support.google.com)

A new vendor breaks mail after `p=reject`

Do not immediately lower the whole domain to p=none unless you need an emergency mitigation. First identify the vendor, verify whether it is legitimate, then configure its custom DKIM domain or aligned return path. If it cannot support alignment, consider sending from a separate, properly authenticated subdomain with a clear policy rather than weakening protection for the primary domain.

Reports are not arriving

Confirm that the rua address exists and can receive mail. Check spam and attachment filtering. If the destination uses a different organizational domain from the domain being reported on, verify the required external-report authorization DNS record rather than assuming the mailto: URI alone is sufficient. (support.google.com)

You set strict alignment and messages stopped passing

Return adkim and aspf to relaxed alignment or remove them while you audit the sending architecture. Strict alignment requires exact domain matches, so it can expose dependencies on subdomains and vendor domain configurations that were harmless under relaxed alignment.

You think DMARC guarantees inbox placement

It does not. DMARC prevents or limits certain forms of impersonation and helps receivers authenticate a claimed sending identity, but it is not a reputation or deliverability shortcut. Gmail’s Postmaster Tools, for example, tracks authentication alongside reputation, spam rate, and delivery errors, reflecting the broader set of factors involved in delivery. (support.google.com)

A practical deployment checklist

Before publishing enforcement, confirm each item below:

The DMARC TXT record is published at _dmarc.yourdomain.com.
The record begins with v=DMARC1 and includes a valid p= value.
A dedicated rua destination can receive and retain aggregate reports.
Every system using your domain in the visible From address is inventoried.
Each legitimate sender has aligned SPF, aligned DKIM, or ideally both.
You have tested real messages from every sender and inspected authentication headers.
Aggregate reports show no unexplained legitimate failures.
You have moved from p=none to p=quarantine before considering p=reject.
A specific person or team owns report review and vendor changes.

The right default DMARC record entry

For most organizations, start here:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

Publish it at:

_dmarc.yourdomain.com

Then treat the reports as an inventory tool. Fix alignment for every legitimate sending service, test actual messages, and advance policy only when the evidence supports it. That approach gives you the operational benefit of DMARC without accidentally rejecting password resets, invoices, support replies, or other business-critical email.

FAQ

What is the host name for a DMARC record entry?

For the root domain example.com, use _dmarc in DNS systems that automatically append the domain, or _dmarc.example.com in systems that require a full host name. The resulting published record must be available at _dmarc.example.com. (rfc-editor.org)

What is the minimum valid DMARC record?

The practical minimum is:

v=DMARC1; p=none

Adding rua=mailto:... is strongly recommended because aggregate reports provide the visibility needed to safely move to enforcement. (rfc-editor.org)

Should I start DMARC with `p=reject`?

Usually no. Start with p=none, use reports to find legitimate senders that fail alignment, repair them, then move through quarantine before reject. A direct reject policy is more appropriate only when you have high confidence the domain has no legitimate unconfigured senders or you have already completed the discovery work. (support.google.com)

Does DMARC require both SPF and DKIM to pass?

No. DMARC can pass when either SPF or DKIM passes and aligns with the visible From domain. Configure both anyway: it gives your mail multiple authentication paths and meets the published requirements that apply to Gmail bulk senders. (support.google.com)

Why does my email have SPF=pass and DKIM=pass but DMARC=fail?

The passing SPF and DKIM domains may not align with the visible From domain. Check the SPF-authenticated envelope domain and the DKIM d= domain against the domain in the From: header; one of those passing identities must align for DMARC to pass. (support.google.com)

DMARC Record Entry: Exact Syntax, DNS Setup, and Examples