Fix DMARC Unknown Tag Value

Why Is Your DMARC Record Failing with 'Unknown Tag Value'?

You sent an email. It didn’t reach the inbox. You checked your DMARC record—only to see an error: 'Unknown tag value'. Not a warning. Not a suggestion. A hard stop. This isn't a glitch. It’s a syntax failure buried in your DNS configuration.

DMARC is your email authentication backbone. But if one tag in your DNS record is invalid—missing, misspelled, or unsupported—your entire policy collapses. One malformed piece breaks the chain. That single error can block all your sent mail, send it to spam, or worse, leave your domain exposed to spoofing.

Even a tiny mistake in a tag like p=none or adkim=1 can result in this error if the value is not recognized by the standard. The system doesn’t guess. It rejects. This is not a warning you can ignore. It’s a configuration flaw that must be fixed—before your sender reputation erodes and your deliverability plummets.

Key takeaways

A DMARC record with an unknown tag value contains a syntax error in the DNS record, typically due to a misspelled or unsupported tag or value.
Even one invalid tag can cause your entire email stream to fail DMARC validation, leading to delivery failures or spam filtering.
These errors are not temporary; they indicate a persistent misconfiguration in your DNS setup that must be corrected to maintain inbox placement and sender reputation.

What Does 'Unknown Tag Value' Mean in a DMARC DNS Record?

If your DMARC DNS record includes a tag value that doesn’t match any of the defined options—like p=ban or fo=unknown—it’s rejected as invalid. Mail servers expect specific, standardized values. Any unrecognized value means the record is malformed and ignored, leaving your domain unprotected. You need to check your TXT record structure against the actual DMARC specification.

How DMARC Tags Work

DMARC uses a set of predefined tags in DNS TXT records, each with strict allowed values. For example, the policy tag p= must be one of none, quarantine, or reject. Similarly, fo= can only be 0, 1, or 2. If you use any other value—like p=invalid or fo=banana—the receiving server won’t process the record at all.

Let’s say you wrote p=unknown. That’s not a valid DMARC policy. Because the value isn’t recognized, the server treats the entire record as malformed. The same applies to spurious tags like debug=yes or v=DMARC1; p=ban. These aren’t allowed and will block your DMARC evaluation.

Why This Matters for Email Deliverability

When a DMARC record is malformed, it fails to validate. That means even if your SPF and DKIM pass, the email might still be rejected or marked as suspicious. ISPs like Gmail and Yahoo rely on proper DMARC alignment to judge sender legitimacy. An invalid record can reduce inbox placement and trigger deliverability issues over time.

It’s not enough to just set up a record. You must verify that every tag and value is correct. Tools like the DMARC specification (RFC 7483) or MXToolbox’s DMARC checker can validate the format. You don’t want to assume your record is working just because it’s set.

If you're unsure, test it first. Use a real DMARC validation tool before deploying. You can check individual records with MailTester’s email checker, which verifies not just syntax but also how the domain’s SPF, DKIM, and DMARC settings align in real-world conditions. Don’t rely on guesswork—fix the record before sending.

Common Causes of Invalid DMARC Tags in DNS Configuration

You’re seeing "unknown tag value" or "invalid tag value in DNS record" errors because your DMARC policy uses a directive not defined in RFC 7483, such as a typo like p=deny (should be p=reject), a custom tag left over from testing, or malformed syntax from an automated tool or manual edit. These issues break DMARC validation and can harm sender reputation, even if the rest of your DNS setup is correct.

Common Misconfigurations That Break DMARC

Typo in policy directive – Using p=deny instead of p=reject triggers an "unknown tag" error. The correct value is reject (not deny). This is a common mistake during initial setup or when copying outdated templates.
Unremoved test or placeholder tags – During testing, people sometimes add tags like rua=mailto:[email protected] or p=quarantine with invalid or unconfigured values. If these are left in production, they break parsing.
Automated tools generating invalid syntax – Some tools auto-generate DMARC records without validating them against the standard. This can introduce incorrect syntax, repeated tags, or non-standard tag names like sp=drop (invalid, should be sp=reject).
Manual edits without referencing RFC 7483 – Editing the record directly in your DNS provider’s console without checking the spec leads to syntax errors. Tags must follow the format tag=value, with values strictly defined: none or reject for p and sp, and unknown for invalid values.

How to Fix & Verify Your DMARC Record

Validating your DMARC record before deployment is essential. You can use tools like MxToolbox or dmarcian to test your DNS record. However, these services only report parsing issues—they don’t verify the full deliverability health of your domain.

Item	Details
Typo in policy directive	Using p=deny instead of p=reject triggers an "unknown tag" error. The correct value is reject (not deny). This is a common mistake during initial setup or when copying outdated templates.
Unremoved test or placeholder tags	During testing, people sometimes add tags like rua=mailto:[email protected] or p=quarantine with invalid or unconfigured values. If these are left in production, they break parsing.
Automated tools generating invalid syntax	Some tools auto-generate DMARC records without validating them against the standard. This can introduce incorrect syntax, repeated tags, or non-standard tag names like sp=drop (invalid, should be sp=reject).
Manual edits without referencing RFC 7483	Editing the record directly in your DNS provider’s console without checking the spec leads to syntax errors. Tags must follow the format tag=value, with values strictly defined: none or reject for p and sp, and unknown for invalid values.

The 4 items listed under “Common Misconfigurations That Break DMARC”, side by side.

For a more comprehensive check that includes real-time inbox placement tests and verification of mail server reputation, use tools like MailTester’s inbox placement tester. It sends real messages through major inboxes to show whether your DMARC setup actually allows delivery. You can also check individual email addresses before sending to avoid delivery fails due to outdated or improperly configured email policies.

How to Validate and Fix a DMARC Record with Unknown Tags

If your DMARC record shows an unknown or invalid tag value in DNS, it likely contains a typo or unsupported parameter like p=ban or fo=2. These break DMARC parsing, causing your email authentication to fail. You must validate the record using a trusted tool, identify the malformed tag, correct it with only standard DMARC tags, and retest. This ensures your domain’s email is properly authenticated and not blocked.

Use a Validation Tool to Catch the Error

Copy the entire TXT record for your DMARC DNS entry from your provider (Cloudflare, AWS Route 53, GoDaddy, etc.). Make sure you copy the full record, including both the txt type and the full value.
Paste the record into a DMARC validator like MxToolbox or MailTester’s email checker. These tools parse your DMARC record and flag any issues immediately.
Check the result for error messages like “unknown tag” or “invalid tag value.” A common cause is using a nonstandard policy value, such as p=ban instead of p=none, p=quarantine, or p=reject.

Correct the Record Using Valid DMARC Tags Only

Find the specific malformed tag. Check for typos or values outside the DMARC RFC standard. For example, fo=2 is valid, but only if intentionally set; sp=ban is invalid because sp must be none, quarantine, or reject.
Remove or correct the invalid tag. Only use officially defined tags: v=DMARC1, p, sp, fo, rf, ri, rua, ruf. Stick strictly to these.
Set policy values (p and sp) to one of: none, quarantine, or reject. These are the only valid options defined in RFC 7483.
Save the updated DNS record through your provider. Propagation can take minutes to hours.
Revalidate your record using the same tool. Run a fresh test to confirm the “unknown tag” error is gone and the record is now fully compliant.

You don’t need to guess. A tool like MailTester will return precise feedback on malformed tags and invalid values, so you can act with confidence.

Why DMARC Errors Break Email Deliverability

When your DMARC record contains an unknown or invalid tag value, email receivers like Gmail, Outlook, and Yahoo treat it as a failure. This triggers a strict rejection or spam flag, even if SPF and DKIM are otherwise valid. One malformed DMARC record can break delivery for your entire domain, regardless of individual email authenticity.

How DMARC Enforcement Works

You might think DMARC is just a reporting tool, but it’s a hard enforcement mechanism used by the largest providers. Google and Microsoft rely on DMARC to decide whether to deliver, quarantine, or block messages. If your DNS record includes a tag like rua=mailto:[email protected] or fo=9, the receiver sees it as invalid and blocks the email.

Most email receivers reject messages that fail DMARC checks because they’re designed to protect users from spoofing and phishing. Even a single malformed tag breaks parsing, leading to a failed policy evaluation. This is not a soft warning — it’s a hard rejection that impacts every sender using the same infrastructure.

Why One Error Hurts the Whole Domain

If your SPF and DKIM alignment are solid but your DMARC record has a syntax error, the entire domain may be treated as untrusted. This isn’t limited to one email — all outbound messages from your domain can be marked as low-reputation or blocked entirely.

The damage compounds over time. Repeated hard bounces from major providers lead to IP and domain reputation degradation. Eventually, your messages land in spam folders or fail to deliver, even when content and sender reputation are strong.

DMARC syntax is strict. You can’t rely on "it worked most of the time." Any unknown tag — like adkim=xxx or p=quarantine (if not properly supported) — causes a parsing failure. This is why checking DNS records for syntax correctness isn’t optional — it’s a core part of deliverability hygiene.

Let’s say you deploy a new domain or restructure your email infrastructure. A single typo in the DMARC policy tag can silently disable delivery across your business. Use tools that validate your full email authentication stack, including DMARC syntax, before sending at scale.

MailTester’s bulk verification and inbox placement checks include DMARC record validation as part of a full deliverability check. You can catch these errors before they impact your reputation.

For technical reference, the foundational DMARC specification is published in RFC 7483, which defines the required syntax and semantics of policy tags. Always verify your configuration against this standard.

DMARC Tag Reference: Valid Values and Their Meanings

DMARC policies use specific tag values in DNS records to control how email authentication failures are handled. Valid values for each tag are strictly defined — using an unknown or invalid tag value breaks DMARC, causing the policy to be ignored. Let’s walk through each tag and its correct, approved values.

Core DMARC Policy Tags

Tag	Valid Values	Meaning
`p`	`none`, `quarantine`, `reject`	Defines how to handle messages that fail SPF or DKIM checks. `none` means no action; `quarantine` sends to spam; `reject` blocks delivery.
`rua`	`mailto:[email protected]`	Specifies email address for aggregate reports. These reports summarize authentication results across all messages sent from your domain. DMARC.org recommends using this to monitor alignment and detect spoofing attempts.
`ruf`	`mailto:[email protected]`	Specifies email address for forensic reports — detailed data on individual failed messages. Use only with caution; these reports contain full headers and can be large.
`fo`	`0`, `1`, `d`, `s`	Controls failure reporting granularity. `0` reports only when both SPF and DKIM fail; `1` reports when either fails; `d` applies only to DKIM; `s` to SPF.
`adkim`	`r`, `s`	Defines DKIM alignment mode. `r` = relaxed (match domain subtree); `s` = strict (exact domain match). Use `s` for tighter security.
`aspf`	`r`, `s`	Defines SPF alignment mode. `r` = relaxed (subdomain alignment); `s` = strict (exact domain match). Align with your email sender setup — most common in enterprise.

Why Proper Tag Values Matter

Using an invalid value — like p=block or adkim=x — makes the DMARC record unparseable. Email receivers won’t apply your policy, leaving your domain open to spoofing. The DMARC RFC 7489 clearly defines each value. Misconfigured tags are among the most common reasons DMARC fails to enforce.

If you’re unsure whether your DMARC record is valid, test it with a real tool. You can verify your DNS setup and check alignment issues using MailTester’s inbox placement tester. It checks not just syntax, but how your emails appear in real inboxes across providers. For bulk list validation, including DMARC-ready email addresses, use MailTester’s bulk verification tool.

How MailTester Helps You Detect Invalid DMARC Tags

MailTester’s real-time verification API scans your full DNS record—including DMARC—during every email check. It flags unknown or invalid tag values in real time, catching misconfigurations before they cause bounces or inbox placement issues. This prevents delivery failures and helps maintain sender reputation.

Proactive Detection of DMARC Configuration Errors

When you send an email, MailTester doesn’t just verify the address—it checks the entire DNS infrastructure behind it. If your DMARC record contains a tag value that’s not recognized by the standard (like none instead of none or a typo like sp=quarantine instead of sp=quarantine), we flag it immediately. This is critical: invalid tags break DMARC enforcement, making your domain vulnerable to spoofing and reducing deliverability.

Many tools only validate syntax. MailTester goes further—it understands the semantics of each DMARC tag. For example, adkim=1 or aspf=1 are valid, but adkim=xyz is not. We catch these errors during bulk checks or API calls, so you won’t learn about them when your messages are rejected by Yahoo or Gmail.

Fix It Fast With Built-in AI Guidance

Getting a "unknown tag value" error can be confusing, especially if your DNS record is complex or if multiple policies are layered. Let’s be honest: not everyone remembers that fo=1 means "fail on alignment failure" or that ri=3600 sets the reporting interval. That’s where the in-app AI assistant comes in.

When you see an error like “unknown tag value in DNS record,” you can ask the AI: “What does sp=quarantine mean?” or “Why is fo=3 invalid?” It explains the proper syntax, suggests corrected values, and even shows what your record should look like. No more guessing. No more trial and error.

With 98.9% accuracy, MailTester identifies subtle issues that manual tools often overlook—especially in large organizations with multiple senders, subdomains, or legacy configurations. The AI doesn’t just report the problem; it helps you fix it correctly, reducing risk and improving long-term deliverability.

For teams managing high-volume sends, this level of detail is essential. You can run a bulk validation on your entire list using our email list verification tool, or integrate the real-time API into your sending workflow for consistent checks. It’s not a one-time scan—it’s continuous validation.

For more context on how DMARC policies are interpreted by receivers, refer to RFC 7489, which outlines the standard behavior for DMARC record parsing. Even if your server accepts a malformed tag, mail providers like Google, Microsoft, and Yahoo follow the standard strictly—and reject messages if the policy is invalid.

Best Practices to Prevent Future DMARC Configuration Errors

You can avoid DMARC policy errors like “unknown tag value” or “invalid tag value in DNS record” by using trusted generators, validating changes with public tools, and regularly reviewing reports. Always double-check your TXT record syntax before saving, and test every update across your domains—not just one. Let’s walk through how to stay ahead of misconfigurations.

Use Trusted Tools for DMARC Record Creation

Never hand-write a DMARC record from memory—small syntax errors break validation. Use a free, well-tested generator like dmarcian.com or the official RFC 7483 documentation.
Only include valid tags: p=none, p=quarantine, p=reject, rua=mailto:, ruf=mailto:. Avoid non-standard or custom tags—DNS parsers will reject them.
Check that your record is under the correct domain: _dmarc.yourdomain.com and not a typo like dmarc._yourdomain.com.

Validate and Monitor Consistently

After saving any DNS change, test it immediately with a public tool like MxToolbox’s DMARC checker or dmarcian’s validator.
Don’t assume your DNS editor is correct—many have bugs, auto-insert spaces, or misencode quotes. Always inspect the final TXT record value.
For teams with large domains or multiple subdomains, use MailTester’s bulk verification to check DNS and deliverability health across your entire list: verify your whole list at once.
Set a monthly reminder to open your DMARC aggregate reports (ARFs). Look for sudden drops in alignment, unexpected senders, or high failure rates. These often point to a misconfigured policy.
Use the DMARC report parser to filter out known, safe senders and focus on anomalies—like a new IP sending without SPF or DKIM alignment.

Many delivery problems come from misconfigurations that are easy to spot with the right tools. You're not trying to be perfect—you're trying to catch errors before they cost you inbox placement or reputation. Let consistency and validation be your guardrails.

Real-World Example: How One Company Fixed a Critical DMARC Failure

A SaaS company saw a sudden spike in email bounces and delivery failures, tracing it to a malformed DMARC record with an unknown tag value—p=ban instead of the standard p=reject. This invalid tag caused receiving mail servers to ignore the entire DMARC policy, leaving their domain exposed to spoofing and drastically harming deliverability. After fixing the tag and validating with MailTester, inbox placement returned to normal within 48 hours.

The Hidden Problem in the DNS

They found the issue during a routine audit of their DNS records. The DMARC record looked mostly correct, with v=DMARC1 and rua=mailto:[email protected], but the policy tag read p=ban. That wasn’t a valid DMARC tag—ban was never part of the specification. Mail servers that process DMARC strictly—like those from Gmail, Outlook, and Yahoo—simply discarded the entire record when they encountered an unknown tag, rendering the policy inactive.

DMARC relies on exact syntax. The specification only defines three valid values for the p tag: none, quarantine, and reject. Anything else, even minor typos like ban, block, or drop, causes the receiving server to treat the record as non-existent. This is how a single invalid tag can nullify an entire email authentication strategy.

Fixing It and Validating the Outcome

They corrected the tag to p=reject, saved the update, and used MailTester’s inbox placement tester to verify deliverability across real email providers. The tool returned results showing consistent inbox placement, confirming that the policy was now recognized and enforced.

It’s a reminder that even small syntax errors can have big consequences. DMARC is only effective when correctly configured. For teams managing multiple domains or sending at scale, automated validation is essential. Tools like MailTester, which support full SPF, DKIM, and DMARC checks before sending, can catch these issues before they impact delivery.

The DMARC policy spec is defined in RFC 7483, which outlines the valid tag values and processing behavior. A misconfigured policy doesn’t just fail—it breaks trust. Ensuring every part of the email authentication chain is valid, from DNS records to sending practices, is a non-negotiable part of modern email operations.

Conclusion: Keep Your DMARC Policy Clean and Valid

A single unknown or invalid tag in your DMARC DNS record can cause email delivery failures across your entire domain, even if the rest of the policy is correct.

Always validate your DMARC record using a trusted tool like MailTester before deployment. Real-time DNS validation catches errors before they impact sender reputation or inbox placement.

Use the in-app AI assistant to decode error messages and resolve issues quickly. Fixing DNS problems early prevents long-term damage to deliverability and sender trust.

Sources

52.1% of the world's top 1.8 million domains (937,931 domains) now publish a valid DMARC record, up from 29.1% in 2023. — EasyDMARC 2026 DMARC Adoption & Enforcement Report (2026)
Google reported 265 billion fewer unauthenticated messages sent to Gmail users in 2024 — a 65% reduction — after its bulk-sender rules took effect, with 500,000+ top domains publishing DMARC records in response. — Google (via MailOver bulk-sender requirements guide) (2024)

Keep reading

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

What does 'DMARC policy uses unknown tag value' mean?

It means your DNS TXT record contains a tag not defined in the DMARC specification, like `p=ban` or `fo=2`. The email server rejects the record as invalid.

Can I fix a DMARC record with unknown tags myself?

Yes—if you understand the DMARC specification, you can edit the record directly. Use tools like MailTester to validate changes in real time.

How do I know if my DMARC record has a syntax error?

Run it through a DMARC validator or use MailTester’s API. The system will report 'unknown tag', 'invalid value', or 'malformed record' if there’s an issue.

Does a DMARC error affect all email sending?

Yes. A malformed DMARC record can cause all outbound emails from the domain to fail authentication checks, leading to rejection or spam filtering.

What’s the difference between p=none, p=quarantine, and p=reject?

`p=none` does nothing. `p=quarantine` sends failing emails to spam. `p=reject` blocks them entirely. Only these three values are valid.

Is MailTester free to test DMARC records?

Yes. You get 100 free verifications to test individual addresses or check DNS records, including DMARC, without cost.

Can I automate DMARC validation with MailTester?

Yes. Use the real-time verification API to validate records programmatically, integrate with your workflow, and catch errors before email sends.

Do DMARC errors expire?

No. A malformed record stays broken until manually corrected. It will continue to block email delivery until fixed.

Why use MailTester instead of open-source tools?

MailTester offers a precise, accurate check with 98.9% correctness, real-time feedback, and AI assistance—not just basic parsing.

Can I prevent DMARC errors with list hygiene tools?

No—DMARC is a domain-level policy, not an email list issue. But correct domain authentication supports broader deliverability, which list hygiene strengthens.