Learn what a DMARC record is, how DMARC works with SPF and DKIM, what its policies mean, and how to monitor and troubleshoot email authentication for your domain.

DMARC Record Explained: What Is DMARC and How Does It Work?

Email spoofing can make a message appear to come from a domain even when it was sent by an unauthorized source. DMARC is an email authentication standard that helps domain owners tell receiving mail servers how to handle messages that fail authentication and alignment checks.

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It works with SPF and DKIM and can provide reports that help you understand how your domain is being used to send email.

In this guide, you will learn what a DMARC record is, how its policies work, how to publish one in DNS, and how to avoid common configuration mistakes.

What Is a DMARC Record?

A DMARC record is a DNS TXT record that publishes a domain's email authentication policy. It tells receiving mail servers what action the domain owner requests when a message fails DMARC evaluation.

DMARC also supports reporting. Domain owners can use aggregate reports to learn which sources are sending email using their domain and whether those messages pass authentication checks.

A DMARC record is usually published at the hostname:

_dmarc.example.com

Replace example.com with your own domain. The record's value contains the DMARC version and policy tags.

How Does DMARC Work?

DMARC builds on SPF and DKIM. It checks whether at least one of those authentication methods passes and aligns with the domain shown in the email's visible From address.

1. An email is received. The receiving mail server examines the message and its authentication information.
2. SPF is evaluated. The receiver checks the sending source against the relevant SPF policy.
3. DKIM is evaluated. The receiver checks whether the message's DKIM signature verifies.
4. Alignment is checked. The receiver checks whether a passing SPF or DKIM identity aligns with the visible From domain under the domain's DMARC settings.
5. The DMARC policy is applied. If DMARC fails, the receiver considers the published policy and its own handling rules.
6. Reports may be sent. If reporting is configured and supported, receivers can send aggregate results to the addresses listed in the record.

DMARC passes when at least one of these conditions is satisfied:

• SPF passes and its authenticated domain aligns with the visible From domain.
• DKIM passes and its signing domain aligns with the visible From domain.

Both SPF and DKIM do not have to pass for DMARC to pass. One aligned authentication method is sufficient.

What Does a DMARC Record Look Like?

A basic DMARC record may look like this:

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

This example requests monitoring without asking receivers to quarantine or reject messages that fail DMARC. It also provides an address for aggregate reports.

The email address is an example. Use a reporting mailbox that you control and that is prepared to receive DMARC reports.

Important DMARC Tags Explained

1. v=DMARC1

This identifies the record as a DMARC policy. It must appear first in the record.

2. p

The p tag defines the requested policy for messages that fail DMARC evaluation.

• p=none — request monitoring without a specific quarantine or rejection action.
• p=quarantine — request that failing messages be treated as suspicious, often by placing them in spam or quarantine.
• p=reject — request that failing messages be rejected.

These are policy requests. Receiving mail servers make their own delivery decisions and may not apply the requested action in every situation.

3. rua

The rua tag specifies where aggregate DMARC reports can be sent.

rua=mailto:dmarc@example.com

Aggregate reports usually provide summarized information about authentication results and sending sources over a reporting period.

4. ruf

The ruf tag can specify an address for failure reports where supported. Not all receiving systems send these reports, and their availability and contents vary.

5. adkim

The adkim tag controls DKIM alignment mode.

• adkim=r — relaxed alignment.
• adkim=s — strict alignment.

Relaxed alignment allows certain related domains to align. Strict alignment requires an exact domain match.

6. aspf

The aspf tag controls SPF alignment mode.

• aspf=r — relaxed alignment.
• aspf=s — strict alignment.

If these alignment tags are omitted, relaxed alignment is the default.

7. pct

The pct tag indicates the percentage of messages to which the requested policy is applied. It has historically been used during policy rollout, but it should not be treated as a guarantee that a receiver will apply a policy to an exact percentage of messages.

Read More: Related Email DNS Guides

• SPF Record Explained — understand how SPF checks authorized sending sources.
• DKIM Record Explained — learn how digital signatures help verify email.
• MX Record Explained — see how DNS routes incoming email to mail servers.

DMARC Policy: None vs. Quarantine vs. Reject

Choosing a DMARC policy affects what you ask receiving servers to do with messages that fail DMARC.

p=none

This is a monitoring policy. It allows domain owners to gather information about email sources and authentication results without requesting quarantine or rejection through the DMARC policy.

It can be useful when first deploying DMARC because it helps identify legitimate services that may not yet be configured correctly.

p=quarantine

This policy asks receiving servers to treat messages that fail DMARC as suspicious. A receiver may place those messages in spam or another quarantine area, depending on its own rules.

Before moving to quarantine, domain owners should understand which legitimate sending services are failing and why.

p=reject

This policy asks receiving servers to reject messages that fail DMARC. It is a stronger enforcement request and can reduce the chance that unauthorized messages are accepted as coming from the domain.

However, legitimate services that are missing from the authentication setup may also fail. Review your sending sources and authentication alignment before enforcing rejection.

How to Add a DMARC Record to Your Domain

You can usually publish a DMARC record through the DNS dashboard for your domain.

1. List your legitimate sending services. Include business email, website messages, marketing platforms, and any other services that send using your domain.
2. Check SPF and DKIM. Confirm that your legitimate services are configured and that their authentication can align with the visible From domain.
3. Choose a reporting mailbox. Set up an address that can receive aggregate DMARC reports.
4. Open your DNS dashboard. Find the DNS zone for your domain.
5. Create a TXT record. Use _dmarc as the host or name if your provider expects only the label. Some dashboards require the full hostname.
6. Enter the DMARC value. For example, begin with a monitoring policy and an aggregate reporting address.
7. Save and verify the record. Check that the record is visible in DNS and that its contents match what you intended to publish.
8. Review reports before enforcement. Use the data to identify legitimate sending services and resolve authentication problems before considering a stricter policy.

Do not copy a sample record without adapting it to your domain and reporting setup. An incorrect policy can affect legitimate email delivery.

How to Check a DMARC Record

DMARC is published as a TXT record at the _dmarc hostname for the domain.

For example, you can query:

dig TXT _dmarc.example.com

Or:

nslookup -type=TXT _dmarc.example.com

Replace example.com with your domain. Review the result for the version tag, policy, and any reporting or alignment settings you have configured.

You can also use the AuraTools DNS Lookup to inspect DNS information. Enter the DMARC hostname and review its TXT record. A DNS lookup can show what is published, but it does not confirm that every email service passes DMARC.

What Are DMARC Reports?

DMARC aggregate reports provide summarized information about email authentication activity observed by participating receivers.

Depending on the report, you may be able to see:

• Sending IP addresses observed by the reporting receiver.
• Domains used in SPF and DKIM authentication.
• Whether SPF and DKIM checks passed.
• Whether authentication results aligned with the visible From domain.
• The DMARC policy published by the domain.
• The receiver's reported disposition for message groups.

Reports are often delivered in XML format. They can be difficult to read manually, so domain owners may use a DMARC reporting service to convert them into dashboards and summaries.

Reports are not necessarily a complete record of every email sent from your domain. Coverage depends on which receiving systems send reports and what information they provide.

Common DMARC Errors and How to Fix Them

1. Publishing the record at the wrong hostname

Problem: The TXT record is added to the root domain instead of the _dmarc hostname.

Fix: Check the exact record name. The standard location is _dmarc.yourdomain.com.

2. Using an invalid record format

Problem: The record is missing required syntax or contains an incorrect tag value.

Fix: Review the record carefully. Make sure v=DMARC1 is first and that tags are separated correctly with semicolons.

3. Configuring enforcement too early

Problem: A strict policy is published before all legitimate email sources have been identified and configured.

Fix: Review authentication results and reports first. Identify services that need SPF, DKIM, or alignment changes before increasing enforcement.

4. SPF passes but DMARC fails

Problem: SPF passes for a domain that does not align with the visible From domain.

Fix: Review the domain used by the SMTP MAIL FROM identity and compare it with the visible From domain. Check the domain's alignment mode.

5. DKIM passes but DMARC fails

Problem: The DKIM signature verifies, but the signing domain does not align with the visible From domain.

Fix: Review the DKIM signing domain and DMARC alignment settings. Configure the sending service to sign with an appropriately aligned domain if supported.

6. Reports are not arriving

Problem: The reporting mailbox receives no aggregate reports.

Fix: Check that the rua address is correct and that the mailbox can receive mail. Not every receiver sends reports, and reporting schedules vary.

DMARC Best Practices

• Start by identifying all legitimate services that send email using your domain.
• Configure SPF and DKIM for those services wherever supported.
• Check authentication alignment with the visible From domain.
• Publish a valid DMARC record at the correct hostname.
• Use a working aggregate reporting address if you want reports.
• Review reports and investigate unfamiliar sending sources.
• Move toward stricter enforcement only after understanding the effect on legitimate email.
• Recheck the setup whenever you change email providers or sending platforms.

Frequently Asked Questions

Is DMARC a TXT record?

Yes. A DMARC policy is published as a DNS TXT record, normally at _dmarc.yourdomain.com.

Do I need SPF and DKIM before DMARC?

DMARC relies on SPF and DKIM authentication results. For meaningful protection and reliable enforcement, configure the authentication methods used by your legitimate sending services and make sure at least one can align with the visible From domain.

What does p=none mean?

p=none requests monitoring without a specific DMARC quarantine or rejection action. It is commonly used while a domain owner reviews authentication activity and prepares for possible enforcement.

Does DMARC stop all spoofing?

DMARC can help receivers handle messages that fail its authentication and alignment checks. It does not prevent every kind of impersonation or abuse, and receivers may apply additional policies and filtering.

Can I have more than one DMARC record?

A domain should publish one DMARC policy record at its applicable DMARC hostname. Multiple conflicting records can cause evaluation problems.

How long does DMARC take to work?

The DNS record becomes visible according to DNS caching and TTL behavior. The effect on email handling also depends on receiving servers and their policies. Aggregate reports may take time to arrive and may not be sent by every receiver.

Conclusion

DMARC gives domain owners a way to publish an email authentication policy and receive information about how their domain is being used. It works with SPF and DKIM and checks whether authentication results align with the visible From domain.

Start by publishing a valid monitoring record and reviewing your legitimate sending sources. Use reports to find configuration gaps, then consider stricter enforcement when you understand how it will affect your email. A careful rollout helps protect your domain while reducing the risk of disrupting legitimate messages.