DMARC Record Syntax:
All Tags at a Glance
A DMARC record consists of tag-value pairs separated by semicolons. Two tags are mandatory, all others optional. This page explains every tag according to RFC 9989 (DMARCbis) – the current DMARC standard that has replaced RFC 7489.
Tags
v Versionp Policysp Subpolicynp Non-exist.t Testingrua RUAruf RUFadkim DKIMaspf SPFfo Forensicpsd PSDpct ⚠ deprecatedri ⚠ deprecatedrf ⚠ deprecatedDMARC1The version tag identifies the DNS TXT entry as a DMARC record. Without this tag, receiving mail servers do not recognize the entry as DMARC and ignore it entirely.
v=DMARC1The most important tag in the DMARC record. It defines what receiving mail servers should do when an email fails the DMARC check – i.e. is not correctly aligned via either SPF or DKIM.
| Value | Behavior |
|---|---|
| none | Emails are delivered normally, regardless of the DMARC result. Provides no spoofing protection. ⚠ For the monitoring phase only |
| quarantine | Non-authenticated emails are moved to the spam folder. |
| reject | Non-authenticated emails are rejected entirely and never arrive. Maximum protection. |
p=quarantinesp , the main policy p also applies to subdomainsAllows subdomains to be treated more strictly or more lenientlyDefines what should happen to emails from subdomains that have no DMARC record of their own. Useful when subdomains are used by third-party providers that are not yet fully configured.
| Value | Behavior |
|---|---|
| none | No action for subdomain emails that fail the check. |
| quarantine | Non-authenticated subdomain emails land in spam. |
| reject | Non-authenticated subdomain emails are rejected. |
sp=rejectsp for non-existent subdomainsWithout np: spapplies first, otherwise pnptag addresses an abuse vector that RFC 7489 did not cover: emails from subdomains that do not exist at all (e.g. xyz123.example.com). Such domains are frequently used for phishing, since a missing DNS entry does not trigger a DMARC check. np closes this gap.Defines the policy for emails from subdomains that have no DNS entry. The difference to sp: sp applies to existing subdomains without their own DMARC record, np applies to non-existent subdomains (NXDOMAIN). For maximum protection, np=reject.
| Value | Behavior |
|---|---|
| none | No action for emails from non-existent subdomains. |
| quarantine | Emails from non-existent subdomains land in spam. |
| reject | Emails from non-existent subdomains are rejected. Recommended. |
np=rejectpcttagDefault: no testing mode (policy is fully applied)ttag is the clean replacement for pct. Instead of a percentage, there is now only a binary flag: either the policy is active (t=n, default behavior) or the record is explicitly in testing mode (t=y) – in which case emails are delivered but reports are still sent.Allows a DMARC record to be activated without the policy being enforced immediately. In testing mode, all emails are delivered normally – regardless of the configured policy. Reports still come in, however, so the configuration can be observed before enforcement is activated.
| Value | Behavior |
|---|---|
| y | Testing active: Policy is not enforced. Emails are delivered normally, reports are still sent. Equivalent to the old pct=0. |
| n | Testing inactive (default behavior): Policy is fully enforced. |
t=yrua you receive no DMARC reportsMultiple addresses separated by commas, maximum of 2 recommendedOnly mailto:URIs are guaranteed to be processedMailbox providers send daily aggregate reports in XML format to the specified address. These contain statistical data: IP addresses of sending servers, volume, SPF and DKIM results. Without an RUA address, you are blind to the email traffic under your domain.
yourdomain.com._report._dmarc.externaldomain.com with the value v=DMARC1.rua=mailto:dmarc@example.commailto:URIs; external-domain rule as with RUAForensic reports contain details about the individual email that failed the DMARC check – partly including headers and subject. Since these reports may contain personal data, many large mailbox providers have stopped sending them. In practice, RUF reports rarely arrive today.
ruf=mailto:forensic@example.comr (relaxed)Determines how strictly the DKIM signature domain must match the From-header domainDKIM alignment checks whether the domain of the DKIM signature matches the domain in the From header. In relaxedmode it is sufficient for both to belong to the same organizational domain (subdomains allowed). In strictmode they must match exactly.
| Value | Behavior |
|---|---|
| r | Relaxed: DKIM signature domain and From domain must belong to the same organizational domain. Subdomains are allowed (e.g. mail.example.com for example.com). |
| s | Strict: DKIM signature domain and From domain must be exactly identical. Subdomains are not allowed. |
adkim=rr (relaxed)Determines how strictly the SPF domain must match the From-header domainSPF alignment checks whether the domain that SPF authenticated (Return-Path / MAIL FROM) matches the From-header domain. In relaxedmode the same organizational domain is sufficient. In strictmode it must match exactly. Forwarding can break the SPF check – DKIM is more stable in this respect.
MAIL FROMpath. The previously possible fallback to HELO/EHLO is explicitly no longer provided for in DMARCbis.| Value | Behavior |
|---|---|
| r | Relaxed: SPF-authenticated domain and From domain must belong to the same organizational domain. Subdomains allowed. |
| s | Strict: SPF-authenticated domain and From domain must be exactly identical. No subdomains. |
aspf=spsdtag allows registries (e.g. operators of .co.uk, .com.br) to explicitly declare their DMARC record as a public suffix domain.Declares a domain as a public suffix domain. This makes it possible to set a DMARC policy even at the level of top-level domains or country-code domains. For standard corporate domains (e.g. example.com), this tag is not relevant.
| Value | Behavior |
|---|---|
| y | This domain is a public suffix domain. DMARC treats it accordingly. |
| n | This domain is not a public suffix domain (default behavior). |
psd=ypcttag has been dropped from the standard. Its purpose (controlled rollout without full enforcement) is taken over by the new t=ytag. In existing records, pct is ignored by RFC-9989-compliant recipients.t=y for testing modePreviously allowed the DMARC policy to be activated gradually. A value of 50 meant: the policy was applied to only half of the affected emails. In practice this was imprecise and frequently misused. RFC 9989 removed this tag in favor of the clearer ttag.
pct=100→ today: t=n (default) or omit0Multiple options separated by colons (:)Only effective if a ruftag is definedDetermines under which conditions forensic reports are generated. Since many mailbox providers no longer send RUF reports, this tag has little significance in practice.
| Value | Condition |
|---|---|
| 0 | Failure report when both DKIM and SPF fail to return pass . |
| 1 | Failure report when DKIM or SPF fails to return pass . |
| d | DKIM failure report, regardless of the alignment result. |
| s | SPF failure report, regardless of the alignment result. |
fo=1:dritag was removed because it was ineffective in practice – no mailbox provider delivered an interval other than 24 hours. The reporting interval is therefore no longer configurable.Previously specified the desired reporting interval for aggregate reports in seconds. In practice, all mailbox providers sent once a day as a rule, regardless of the configured value. RFC 9989 therefore simply removed the tag.
ri=86400rftag was removed because afrf was the only format ever implemented and there was no real choice. RFC 9989 anchored the format firmly in the associated RFC 9991 (Failure Reporting).Previously defined the format for forensic reports. Since only afrf (Authentication Failure Reporting Format) was ever implemented, the tag was meaningless. RFC 9989 removed it from the standard accordingly.
rf=afrfWant to know whether your current DMARC record is configured correctly? The Analyser checks syntax, policy and alignment directly in the browser.
DMARC Record Analyser Record Generator