DMARC Record Error Detected: How to Find and Fix It

If you see a dmarc record error detected warning, do not immediately change your policy to p=none or delete your record. First identify whether the error means your DMARC TXT record cannot be found, cannot be parsed, contains conflicting records, or is valid but your outgoing messages still fail DMARC.

DMARC is a DNS-based email authentication policy. It tells receiving mail systems how to handle messages that claim to come from your domain but fail authenticated, aligned SPF and DKIM checks. A valid record is only one part of the setup: the actual messages sent by Google Workspace, Microsoft 365, your transactional email platform, CRM, help desk, website, and other tools must also authenticate correctly. (rfc-editor.org)

What a DMARC record error detected warning actually means

The phrase dmarc record error detected is used by many DNS checkers, email platforms, and deliverability tools. It is a diagnostic label, not a single standardized SMTP error. The useful question is: what did the tool find at _dmarc.yourdomain.com, and can a receiving server use it?

Most alerts fall into one of four categories:

1. Missing record: No DMARC TXT record is published at the required hostname.
2. Invalid record: A TXT record exists, but it has invalid syntax, an invalid tag value, or the wrong DNS name.
3. Conflicting record: More than one DMARC policy record is returned for the same hostname.
4. Authentication failure: The DMARC record itself is readable, but mail fails because neither SPF nor DKIM passes with domain alignment.

The distinction matters. Editing a valid DMARC policy cannot repair a DKIM signature from a third-party sender, and adding an SPF include will not fix a record published under the wrong DNS hostname.

The correct DMARC DNS record format

A DMARC policy is published as a TXT record under the _dmarc label. For the domain example.com, the lookup name is:

_dmarc.example.com

A safe starting record is:

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

In a typical DNS provider interface, use these values:

Some DNS dashboards automatically append your root domain. In that kind of interface, entering _dmarc.example.com in the Host field may accidentally publish _dmarc.example.com.example.com. Other dashboards require a fully qualified name. Check the record after saving with a public DNS lookup rather than relying only on the provider’s form.

The version tag, v=DMARC1, identifies the record as DMARC. The p tag defines the requested handling of mail that fails DMARC. The three policy values are:

• p=none — monitor failures and request no specific enforcement action.
• p=quarantine — ask receivers to treat failing mail suspiciously, commonly by placing it in spam or junk.
• p=reject — ask receivers to reject failing mail during delivery.

DMARC lets a message pass when either SPF passes and aligns with the visible From domain, or DKIM passes and aligns with the visible From domain. Both do not need to pass, though configuring both is the practical standard for a production sending domain. (learn.microsoft.com)

Tags worth using—and tags to leave out at first

Start with a small, readable record. Add complexity only when you know why you need it.

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

Common optional tags include:

r means relaxed alignment and s means strict alignment. With relaxed alignment, mail.example.com can align with example.com because they share the same organizational domain. With strict alignment, the domains must match exactly. Relaxed alignment is usually the safest initial setting, especially if several vendors send mail on your behalf. Yahoo explicitly accepts relaxed alignment for its bulk-sender requirements. (senders.yahooinc.com)

Do not add every available tag just because a record generator offers them. An unnecessary sp=reject, strict alignment setting, or incorrectly configured report address can create a new problem while you are trying to fix an existing warning.

The fastest way to diagnose the record

Use a public DNS query before changing anything. This tells you what external mail receivers can see, which may differ from what appears in your DNS dashboard.

On macOS, Linux, or Windows with dig installed, run:

dig TXT _dmarc.example.com +short

On Windows PowerShell, use:

Resolve-DnsName -Type TXT _dmarc.example.com

With nslookup, use:

nslookup -type=TXT _dmarc.example.com

A healthy result should show one DMARC policy string beginning with v=DMARC1, for example:

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

DNS tools may display quotation marks around TXT data. Those quotes are often a display convention and do not necessarily mean quotation marks were stored as part of your record. What matters is the resulting TXT content returned by DNS.

Interpret the lookup result before you edit DNS

No answer or NXDOMAIN means the record is missing or published under the wrong hostname. Check that you created a TXT record named _dmarc, not dmarc, _dmarc.example.com.example.com, or the root hostname @.

A non-DMARC TXT string means you created a TXT record but put the wrong content in it. A TXT record at _dmarc is only a DMARC record when it uses valid DMARC tag syntax and starts with v=DMARC1.

Two separate strings that each start with v=DMARC1 usually means duplicate DMARC records. Remove or merge the extra policy record. DMARC requires a single usable policy record at the queried name; publishing two independently created DMARC TXT records creates ambiguity rather than two layers of protection.

One record split visually into multiple quoted fragments is not automatically an error. DNS providers and DNS software can split long TXT data into character strings while returning it as one logical TXT record. Evaluate the joined content, not just the visual layout.

A valid-looking answer but an external checker still reports an error can mean DNS propagation or caching, a checker querying a stale resolver, an external reporting-address authorization problem, or a message-level SPF/DKIM failure. Move to the next diagnostic layer instead of repeatedly rewriting the same TXT value.

The most common DMARC syntax mistakes

A DMARC record is small, which makes its mistakes frustratingly easy to miss. These are the errors that most often trigger a dmarc record error detected alert.

1. Publishing the record at the wrong hostname

Wrong:

example.com TXT v=DMARC1; p=none

Wrong:

dmarc.example.com TXT v=DMARC1; p=none

Correct:

_dmarc.example.com TXT v=DMARC1; p=none

The leading underscore is required. It is part of the DMARC DNS name, not decoration.

2. Creating a CNAME, MX, or SPF record instead of TXT

DMARC policies are TXT records. A CNAME may appear to work in some DNS designs but is not the normal, portable way to publish the policy record. Do not put DMARC syntax into your SPF record, MX record, or a generic website verification record.

3. Forgetting the DMARC version or using the wrong version

Wrong:

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

Wrong:

v=DMARC; p=none

Correct:

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

Use the exact DMARC1 value. The current IETF DMARC specification is RFC 9989, which supersedes the older RFC 7489 and defines DMARC as a DNS TXT policy mechanism for validating the domain used in a message’s visible From field. (rfc-editor.org)

4. Using an invalid policy value

Wrong:

v=DMARC1; p=monitor

Wrong:

v=DMARC1; p=pass

Correct:

v=DMARC1; p=none

The policy values are none, quarantine, and reject. A DMARC policy does not make mail pass; it defines the requested disposition for messages that fail DMARC.

5. Publishing multiple independent DMARC records

Wrong:

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

Correct: combine the tags into one policy string.

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

This commonly happens when a marketing platform, web host, IT provider, and security team each add their own DMARC entry. Consolidate the requirements into one record after confirming every tag is appropriate.

6. Adding malformed report URIs

Wrong:

rua=dmarc-reports@example.com

Correct:

rua=mailto:dmarc-reports@example.com

The mailto: prefix matters. Use a mailbox or group that can accept potentially frequent automated reports. Google notes that organizations sending significant volume can receive hundreds or thousands of reports in a day, so do not route raw XML attachments to a shared customer-support inbox. (support.google.com)

7. Sending reports to a different domain without authorization

This is a subtle but common issue. If example.com publishes:

v=DMARC1; p=none; rua=mailto:reports@analyticsvendor.net

the external destination domain must authorize receiving reports for example.com. Otherwise, receivers may decline to send the reports even though the core DMARC policy can still be valid. Aggregate-report delivery and external destination verification are defined separately in the DMARC reporting specification, RFC 9990. (rfc-editor.org)

For a first deployment, use a reporting mailbox at the same domain, such as dmarc-reports@example.com, or follow your DMARC reporting provider’s exact external-destination authorization instructions.

A valid DMARC record can still fail: understand alignment

A DNS checker can report a perfect DMARC record while your real messages fail DMARC. That is not a contradiction. DNS validation checks the policy record; delivery validation checks the message.

DMARC evaluates the domain in the visible From: header. It then looks for an aligned success from SPF or DKIM:

• SPF path: The server is authorized by the envelope-sender domain, and that domain aligns with the visible From domain.
• DKIM path: The message has a valid DKIM signature, and the signing domain in the d= tag aligns with the visible From domain.

For example, consider this message:

From: updates@example.com
Return-Path: bounce@mailer.vendor-mail.net
DKIM-Signature: d=vendor-mail.net; s=s1; ...

Even if the vendor’s SPF and DKIM both pass for vendor-mail.net, DMARC for example.com may fail because neither authenticated domain aligns with example.com. The vendor needs to support a custom bounce domain aligned to your domain, DKIM signing with your domain or an aligned subdomain, or both.

Microsoft’s guidance describes the same pass rule: one aligned SPF or DKIM result is enough; DMARC fails when both checks fail. (learn.microsoft.com)

Why third-party tools create most DMARC failures

Your primary mailbox provider is rarely your only sender. Build an inventory of every system that can send with your domain in the visible From field:

• Google Workspace or Microsoft 365 mailboxes
• Transactional email API or SMTP relay
• Marketing automation and newsletter platforms
• CRM workflows and sales-sequence tools
• Support desk ticket replies
• Form notifications from your website
• Billing, invoicing, and subscription software
• Recruiting, survey, and event platforms
• Printers, scanners, and legacy application servers

For each sender, find its authentication instructions. You may need to add an SPF include, publish DKIM CNAME or TXT records, enable DKIM in the vendor dashboard, set a custom return-path domain, or change the visible From domain to one that the platform can authenticate.

Do not blindly add every vendor to SPF. SPF has a DNS lookup limit of 10, and multiple SPF records also cause permanent errors. DKIM is generally the more scalable authentication path for a growing collection of sending services, provided every service can sign using an aligned domain. (learn.microsoft.com)

Worked example: fix a duplicate DMARC record and a vendor alignment failure

Assume northstarcoffee.com gets a dmarc record error detected warning from an email platform. A DNS lookup returns:

"v=DMARC1; p=none"
"v=DMARC1; rua=mailto:postmaster@northstarcoffee.com"

That is a record-level problem: there are two separate DMARC policy records at _dmarc.northstarcoffee.com.

Step 1: replace duplicates with one policy record

Delete both old DMARC TXT entries and publish one:

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

Then query it:

dig TXT _dmarc.northstarcoffee.com +short

Expected result:

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

At this point, the DNS record error should clear after recursive DNS caches refresh. But that only confirms the record is readable.

Step 2: send a real test message

Send a message from orders@northstarcoffee.com through the company’s transactional email service to a Gmail or Microsoft 365 test mailbox. Open the message source or original headers and look for an authentication summary similar to:

spf=pass
 dkim=pass header.d=northstarcoffee.com
 dmarc=pass header.from=northstarcoffee.com

The exact header formatting varies by receiving service. The important result is dmarc=pass and at least one aligned SPF or DKIM result.

Step 3: investigate a failing vendor message

Suppose the header instead shows:

spf=pass smtp.mailfrom=bounces.vendor-mail.net
 dkim=pass header.d=vendor-mail.net
 dmarc=fail header.from=northstarcoffee.com

This is not a DMARC DNS syntax issue. The vendor authenticates itself, but not the customer domain shown in the From address.

The repair is to configure the transactional email vendor’s domain authentication feature. A typical vendor setup asks you to:

1. Add DKIM CNAME or TXT records supplied by the vendor.
2. Add a custom return-path or bounce-domain CNAME if the platform supports it.
3. Verify the domain in the vendor dashboard.
4. Enable signing for northstarcoffee.com or an aligned subdomain such as mail.northstarcoffee.com.
5. Send another message and check the resulting headers again.

A successful post-fix result might be:

spf=pass smtp.mailfrom=mail.northstarcoffee.com
 dkim=pass header.d=northstarcoffee.com
 dmarc=pass header.from=northstarcoffee.com

This example shows the crucial difference between record validity and mail authentication. The first is resolved in DNS. The second is resolved in your sending platform configuration.

How to choose p=none, p=quarantine, or p=reject

Use policy progression as a risk-management process, not as a one-time checkbox.

Start with p=none when you do not know every sender

p=none is monitoring mode. It lets you collect aggregate reports and observe which services send mail using your domain before requesting stronger enforcement. This is especially important for organizations with multiple agencies, SaaS tools, legacy systems, or decentralized teams.

A monitoring record does not mean DMARC is useless. It establishes a policy, enables visibility, and helps meet the DMARC policy baseline used by major mailbox providers for bulk senders. Google requires senders delivering more than 5,000 messages per day to Gmail accounts to use SPF, DKIM, and DMARC; Google permits a DMARC policy of p=none for that requirement. (support.google.com)

Move to quarantine after you understand the reports

Use p=quarantine when your reports show that legitimate senders authenticate reliably and the remaining failures are understood. Examples include spoofing attempts, systems you have retired, and forwarding-related failures you have assessed.

A prudent intermediate policy is:

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

Do not assume every receiver will handle quarantine identically. DMARC expresses the domain owner’s requested disposition; mailbox providers apply their own anti-abuse and delivery systems as well.

Use reject when legitimate mail consistently passes

p=reject provides the strongest instruction against direct impersonation of your domain:

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

Use it only after auditing every legitimate sending source and testing common workflows: password resets, order receipts, support replies, mailing lists, internal application alerts, and messages forwarded by partners. A rejected legitimate password reset is a customer-experience failure, not merely a deliverability metric.

DMARC reports: how to use them without drowning in XML

Aggregate reports are XML files sent by participating receivers to the destination in your rua tag. They describe message volume and authentication outcomes over a reporting period; they are not ordinary inbox messages intended for manual reading. RFC 9990 defines aggregate reports as XML feedback sent to the destination declared by the domain owner. (rfc-editor.org)

You can process reports in three ways:

• Use a DMARC reporting service that ingests XML and groups results by source IP, sending domain, DKIM domain, and disposition.
• Use a mailbox plus parser if your volume is small and you have technical capacity.
• Use a managed DNS or email-security platform that includes DMARC reporting and source discovery.

When reviewing a report, ask these questions:

1. Which IPs or vendors are sending the largest volume under our From domain?
2. Does each legitimate sender pass DKIM, SPF, or both?
3. Which authenticated domain is used for SPF and DKIM?
4. Does that domain align with the visible From domain?
5. Are failures caused by legitimate systems, forwarding, misconfiguration, or spoofing?
6. Would moving to quarantine or reject affect an important workflow?

Do not treat every DMARC failure as an attacker. Forwarding commonly breaks SPF because the forwarding server is not listed in the original sender’s SPF policy. DKIM can preserve a passing path if the message remains validly signed, which is one reason DKIM is important alongside SPF. (learn.microsoft.com)

How to verify the fix worked

A repaired DMARC setup should pass three separate checks.

1. DNS check

Query the public record:

dig TXT _dmarc.example.com +short

Confirm there is one usable policy beginning with v=DMARC1 and containing a valid p= value.

2. Header check

Send mail from every significant sending platform to a test inbox. Inspect the raw message headers. Look for the receiving provider’s authentication results and verify:

dmarc=pass

Then confirm at least one of these aligns with the visible From domain:

spf=pass

or:

dkim=pass header.d=example.com

A DKIM result that says pass but has header.d=unrelated-vendor.net may still leave DMARC failing because cryptographic validity alone is not domain alignment.

3. Reporting and delivery check

Confirm aggregate reports reach the rua mailbox or service. Then watch operational signals: rejected messages, spam-folder placement, application error logs, support tickets, and bounce notifications from systems that send mail on your behalf.

Google Postmaster Tools can provide eligible senders with dashboards for spam rate, reputation, authentication, and delivery errors. It complements DMARC reports but does not replace them. (support.google.com)

When the record is valid but delivery still fails

A dmarc record error detected warning may be gone while recipients still see blocked or spam-foldered mail. DMARC is essential, but it is not a complete deliverability program.

Check these adjacent areas:

• SPF: Does the envelope sender authorize the actual sending service? Is there only one SPF record, and does it stay within SPF’s 10-DNS-lookup limit?
• DKIM: Is the message signed? Does the published public key match the signature selector? Does d= align with the visible From domain?
• From address: Does your application use a personal Gmail or consumer-mail address as the sender while claiming to send from your business domain?
• Sending reputation: Are complaint rates, engagement, and list quality hurting placement even though authentication passes?
• Infrastructure: Do sending IPs have forward and reverse DNS, and does the service use TLS where required by mailbox-provider guidance?
• Bulk-mail requirements: If you send substantial volume to Gmail or Yahoo, confirm you meet their sender requirements beyond DMARC, including SPF, DKIM, and relevant unsubscribe expectations.

For Gmail, senders delivering more than 5,000 messages per day to Gmail accounts must use SPF, DKIM, and DMARC, while Gmail also calls for a spam rate below 0.3% in Postmaster Tools. Yahoo’s bulk-sender guidance similarly calls for SPF, DKIM, a valid DMARC policy, and DMARC passing through aligned SPF or DKIM. (support.google.com)

A practical DMARC repair checklist

Work through this list in order whenever you encounter a DMARC warning:

1. Query TXT _dmarc.yourdomain.com from public DNS.
2. Confirm the record is a TXT record at the _dmarc hostname.
3. Confirm one policy record begins with v=DMARC1.
4. Confirm p= is exactly none, quarantine, or reject.
5. Remove duplicate DMARC policy records.
6. Check that rua= uses mailto: and points to a monitored destination.
7. If rua uses another domain, verify external report-destination authorization.
8. Inventory every service that sends mail with your domain in the visible From address.
9. Configure SPF and/or DKIM for each legitimate sender, prioritizing aligned DKIM.
10. Send real messages through each service and inspect headers for dmarc=pass.
11. Review aggregate reports before raising policy from none to quarantine or reject.
12. Recheck the configuration after changing vendors, launching a new marketing tool, or adding a new transactional sender.

FAQ

What does dmarc record error detected mean?

It means a checker found a problem with your DMARC DNS setup or could not validate it. The cause may be a missing record, wrong hostname, malformed syntax, duplicate policies, invalid reporting address, or a valid policy paired with failing SPF/DKIM alignment.

What is the minimum valid DMARC record?

A practical minimum is:

v=DMARC1; p=none

For monitoring, add an aggregate-report destination:

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

Can I have more than one DMARC TXT record?

No. Publish one DMARC policy record at _dmarc.yourdomain.com. If different teams need different settings, combine the needed tags into one carefully reviewed record rather than adding separate DMARC TXT entries.

Why does SPF pass but DMARC fail?

SPF can pass for the envelope-sender domain while that domain does not align with the visible From domain. For DMARC to pass through SPF, the SPF-authenticated domain must align with the From domain. A passing aligned DKIM signature can also make DMARC pass.

How long does a DMARC fix take to work?

The DNS update becomes visible according to your DNS TTL and resolver caches. After the new record is publicly visible, send fresh test messages and inspect their headers. Old messages cannot be retroactively re-authenticated, and report delivery may take longer because receivers generate reports on their own schedules.