Based on RFC 7489: DMARC Specification. Read the full specification for the authoritative reference.
Without DMARC, anyone can send email claiming to be from your domain. Your company name, your logo, your letterhead, with no way for recipients to tell the real thing from a fake.
A DMARC record is a DNS TXT record that tells mail servers how to verify email from your domain and what to do when verification fails. You publish it once, and email providers like Gmail, Yahoo, and Microsoft read it before delivering messages that claim to be from your domain.
RFC 7489 is the document that defines how this works. Published by the IETF in March 2015, it specifies 11 tags you can use to configure your policy. You do not need to read the RFC. This guide gives you everything you need in plain language.
What you will learn
Your first DMARC record
A DMARC record is a single line of text you add to your domain's DNS. It always starts with v=DMARC1 (the version) followed by p= (your policy). Everything else is optional.
Here is the simplest useful DMARC record. It tells email providers: "I am not enforcing anything yet, but please send me daily reports so I can see who is sending email as my domain."
Add this as a TXT record at _dmarc.example.com (replace with your domain).
That is it. Three tags, one DNS record, and you are already getting visibility into your email authentication. The reports arrive as XML files, typically once a day from each provider that processes your email.
Ready-to-use records for common setups
Find your situation below, copy the record, and replace the email address with yours.
Just starting out (monitoring only)
You want to see what is happening before making any changes. Good choice.
Gmail or Microsoft 365 + a marketing tool (Mailchimp, HubSpot, etc.)
You send email from your inbox and through a marketing platform. Start with monitoring, then move to quarantine once your reports show clean results.
adkim=r and aspf=r use "relaxed" alignment. This means mail.example.com and example.com are treated as the same organization. This is what you want when third-party services send on your behalf.
Full protection (after 2-4 weeks of clean monitoring)
You have reviewed your reports and confirmed that all legitimate senders pass SPF and DKIM. Time to tell providers: reject anything that fails.
p=reject tells providers to block fraudulent email. sp=reject does the same for subdomains. adkim=s and aspf=s switch to "strict" alignment for maximum security.
Enterprise with external DMARC reporting service
You use a service like DMARCTrust to collect and analyze your reports. You can send reports to multiple addresses.
Reports go to both your internal inbox and your DMARC reporting service. The external service must authorize your domain via a DNS record (explained below).
Not sure which record fits? Use our free DMARC generator to build a record step by step, or check your existing record to see what you have today.
All 11 DMARC tags explained
RFC 7489 defines exactly 11 tags. Two are mandatory (v and p), six are commonly used, and three (pct, rf, ri) are being removed in the upcoming DMARCbis revision. Here is what each one does, when you need it, and how to use it.
| Tag | What it does | Example value | Default | Status |
|---|---|---|---|---|
| v | Identifies this as a DMARC record | DMARC1 | Required | Mandatory |
| p | What to do with failing email | none | quarantine | reject | Required | Mandatory |
| sp | Policy for subdomains | none | quarantine | reject | Inherits p | Optional |
| adkim | How strictly to check DKIM alignment | r (relaxed) | s (strict) | r | Optional |
| aspf | How strictly to check SPF alignment | r (relaxed) | s (strict) | r | Optional |
| rua | Where to send daily summary reports | mailto:[email protected] | None | Optional |
| ruf | Where to send per-failure reports | mailto:[email protected] | None | Optional |
| fo | When to trigger failure reports | 0 | 1 | d | s | 0 | Optional |
| pct | Percentage of email to apply policy to | 0-100 | 100 | Removed in DMARCbis |
| rf | Format for failure reports | afrf | afrf | Removed in DMARCbis |
| ri | How often to send aggregate reports | 86400 (seconds) | 86400 | Removed in DMARCbis |
Tags being removed. The pct, rf, and ri tags are defined in RFC 7489 but are being removed in the upcoming DMARCbis revision. Most email providers already ignore them. You can safely skip these in new records.
The two mandatory tags: v and p
Every DMARC record must start with these two tags, in this exact order. Swap them and the record is invalid.
v = version
Always v=DMARC1. No other value exists. It tells email servers that this DNS record is a DMARC policy, not some other TXT record. While RFC 7489 says tag values are not case-sensitive, always use uppercase DMARC1 for maximum compatibility, as some receivers only accept the uppercase form.
p = policy
This is the core decision. You are telling every email provider in the world what to do when someone sends an email that claims to be from your domain but fails authentication. Three choices:
| Value | What happens | When to use |
|---|---|---|
| none | Deliver the email normally. Just send me reports. | You are starting out and want to observe before enforcing. |
| quarantine | Flag the email as suspicious. Usually goes to spam. | You are fairly confident in your setup but want a safety net. |
| reject | Block the email entirely. It never reaches the recipient. | You have verified all legitimate senders and want maximum protection. |
Start with p=none. Jumping straight to p=reject without monitoring first is the most common mistake. You risk blocking your own legitimate email (newsletters, transactional messages, SaaS tools that send on your behalf).
Optional tags: fine-tuning your policy
sp = subdomain policy
Your main policy (p=) covers your root domain (example.com). But what about mail.example.com, shop.example.com, or any other subdomain? By default, subdomains inherit whatever policy you set for the parent. The sp tag lets you override that.
Common scenario: You want to protect subdomains that do not send email. Attackers love these because they are often unmonitored.
If you omit sp, subdomains inherit the p value.
adkim = DKIM alignment mode
When an email arrives with a DKIM signature, the receiving server checks whether the signing domain matches the From address. The adkim tag controls how strict that match needs to be.
Relaxed allows subdomains to match the organizational domain. Strict requires an exact domain match.
| Mode | From address | DKIM d= domain | Result |
|---|---|---|---|
| r (relaxed) | [email protected] | example.com | Pass Same organization |
| s (strict) | [email protected] | example.com | Fail Domains do not match exactly |
| s (strict) | [email protected] | mail.example.com | Pass Exact match |
Default is relaxed. Use strict only when you have full control over all signing domains. If you use third-party services (Mailchimp, SendGrid, etc.), keep relaxed or make sure they sign with your exact domain.
aspf = SPF alignment mode
Same concept as adkim, but for SPF. It checks whether the domain that passed SPF matches the From address.
| Mode | From address | SPF-validated domain | Result |
|---|---|---|---|
| r (relaxed) | [email protected] | example.com | Pass Same organization |
| s (strict) | [email protected] | example.com | Fail Domains do not match exactly |
| s (strict) | [email protected] | mail.example.com | Pass Exact match |
Default is relaxed. Same guidance as adkim. Start relaxed, tighten later if needed. For a deep dive on alignment, see our guide on DMARC aspf and adkim tags.
How alignment determines your "organization"
Both adkim and aspf rely on the concept of an "organizational domain." DMARC uses the Public Suffix List to figure out where your domain ends and the public suffix begins:
Reporting tags: seeing what is happening
Without reporting tags, you have a policy with no visibility into what it is doing. Two types of reports exist:
rua = aggregate reports (the daily summary)
Every 24 hours, email providers send you an XML file summarizing: who sent email claiming to be your domain, from which IP addresses, and whether those emails passed or failed SPF and DKIM.
These reports contain statistics, not actual emails. A typical entry looks like: "IP 203.0.113.42 sent 1,200 emails as your domain; 1,180 passed DKIM, 20 failed SPF."
The !50m suffix means "do not send reports larger than 50 megabytes." Size units: k (kilobytes), m (megabytes), g (gigabytes).
Privacy note: Aggregate reports contain source IP addresses, which can be considered personal data under GDPR. Handle them with appropriate data protection measures.
Sending reports to a different domain
If your DMARC record points rua to an address outside your domain (like a reporting service), the receiving domain must give permission. Otherwise, anyone could flood a victim's inbox with millions of DMARC reports from random domains.
The receiving domain grants permission by publishing a DNS TXT record:
Without this permission record, email providers silently discard the reports. If you use a DMARC reporting service, they handle this setup for you.
ruf = forensic reports (per-failure detail)
While rua gives you the summary, ruf tries to give you the details: the actual headers (and sometimes body) of individual emails that failed authentication.
In practice, ruf is rarely useful. Gmail, Yahoo, and Microsoft no longer send forensic reports due to privacy concerns (the reports contain real user data). Most DMARC deployments work perfectly with rua only.
The syntax is identical to rua:
fo = failure reporting options
The fo tag controls when forensic reports (ruf) are triggered. Since most providers do not send forensic reports anyway, this tag has limited practical value. But here is what each option means:
| Value | Trigger condition | Report volume |
|---|---|---|
| 0 | Both SPF and DKIM fail (default) | Lowest. Only total failures. |
| 1 | Either SPF or DKIM fails | Highest. Any single failure triggers a report. |
| d | DKIM fails (regardless of SPF) | Moderate. DKIM-specific issues only. |
| s | SPF fails (regardless of DKIM) | Moderate. SPF-specific issues only. |
You can combine options with a colon: fo=1:d. In practice, if you use ruf at all, fo=1 gives you the most visibility.
Tags being removed: skip these in new records
Three tags from RFC 7489 are being removed in the upcoming DMARCbis revision. Email providers already ignore most of them. Avoid using these in new DMARC records.
pct (percentage)
Originally let you apply your policy to only a percentage of failing email (e.g., pct=25 would quarantine 25% and let the rest through). In practice, only pct=0 and pct=100 worked reliably. DMARCbis replaces this with a simple testing flag.
ri (report interval)
Supposed to control how often aggregate reports are sent (default: 86400 seconds = 24 hours). In reality, every provider sends daily regardless of this value.
rf (report format)
Only one value was ever defined (afrf), and no alternative was ever implemented. There is nothing to configure.
From monitoring to full protection: a deployment path
Do not jump straight to p=reject. Follow this three-phase approach to avoid blocking your own legitimate email.
Monitor (2-4 weeks)
Collect reports, identify all legitimate senders, fix any SPF/DKIM issues.
What to look for in reports: unknown IPs sending as your domain, SPF or DKIM failures from services you use (fix those first).
Quarantine (1-2 weeks)
Suspicious emails go to spam instead of the inbox. Continue monitoring reports for false positives.
If legitimate emails start landing in spam, check whether the sending service has proper SPF/DKIM configuration for your domain.
Reject (ongoing)
Maximum protection. Fraudulent email is blocked before it reaches recipients.
Keep monitoring reports even at reject. New services or infrastructure changes can introduce SPF/DKIM failures.
Common mistakes that break DMARC records
These are the errors we see most often when checking DMARC records. Each one silently invalidates your entire record.
p=reject; v=DMARC1; rua=mailto:[email protected]
Wrong tag order. v=DMARC1 must always come first, p= must come second.
v=dmarc1; p=REJECT
Risky casing. While RFC 7489 says tag values are case-insensitive, some receivers only accept uppercase DMARC1 and lowercase policy values like reject. Always use the standard casing.
v=DMARC1; rua=mailto:[email protected]
Missing p= tag. The policy tag is mandatory. Without it, the entire record is ignored.
v=DMARC1; p=block
Invalid policy value. Only three values are valid: none, quarantine, reject.
v=DMARC1; p=none; [email protected]
Missing mailto: prefix. Report URIs must start with mailto:.
Want to check your record? Run a free DMARC check on your domain.
Syntax rules
A few formatting rules to keep in mind when writing DMARC records:
-
Semicolons separate tags:
v=DMARC1; p=none; rua=... -
Spaces around
=and;are optional:p=noneandp = noneare both valid -
Commas separate multiple report addresses:
rua=mailto:[email protected],mailto:[email protected] - Maximum length of a single DNS TXT string is 255 characters. Longer records are automatically split into multiple strings and concatenated by DNS
- No trailing semicolon is required, but it does not cause errors if present
Testing your DMARC record
After publishing your record, verify it from the command line:
DNS changes can take up to 48 hours to propagate, but most updates are visible within minutes.
Or use our DMARC checker for a full analysis with specific fixes.
Deep dive: formal ABNF grammar (for developers)
If you are building a DMARC parser, validator, or generator, you need the formal syntax from RFC 7489 Section 4.2. This uses ABNF (Augmented Backus-Naur Form) notation as defined in RFC 5234.
Key rules from the grammar
-
Tag ordering is mandatory:
dmarc-versionfirst,dmarc-request(p=) second. All other tags are unordered. -
*WSPmeans optional whitespace around=and;separators. -
%s"DMARC1"means case-sensitive string match. "DMARC1" only, not "dmarc1". -
URI scheme: Only
mailto:is defined for rua/ruf. The optional!suffix sets a size limit. - Multiple TXT strings: DNS concatenates them automatically (RFC 7208 Section 3.3). Split at 255 characters, preferably after a semicolon.
IANA DMARC tag registry
The official IANA registry lists all standardized tags. DMARCbis will add np (non-existent subdomain policy) and psd (public suffix domain) while removing pct, rf, and ri. Records will keep using v=DMARC1 for backward compatibility.
Frequently asked questions
What is RFC 7489?
RFC 7489 is the IETF standard published in March 2015 that defines DMARC (Domain-based Message Authentication, Reporting, and Conformance). It specifies how domain owners publish email authentication policies in DNS and how email receivers should handle messages that fail SPF or DKIM alignment checks.
When was RFC 7489 published?
RFC 7489 was published in March 2015 by the Internet Engineering Task Force (IETF). It was authored by M. Kucherawy and E. Zwicky and carries the status of Informational RFC.
What does RFC 7489 define?
RFC 7489 defines 11 official DMARC tags for DNS TXT records, including policy (p), subdomain policy (sp), aggregate reporting (rua), forensic reporting (ruf), alignment modes (adkim, aspf), percentage (pct), report format (rf), report interval (ri), failure reporting options (fo), and the version tag (v). These tags are published at _dmarc.yourdomain.com.
Is RFC 7489 still the current DMARC standard?
Yes. While the DMARCbis draft is being developed as a Standards Track update, RFC 7489 remains the authoritative DMARC specification. DMARCbis maintains backward compatibility with v=DMARC1 records, so existing RFC 7489 configurations will continue to work.
What is the difference between RFC 7489 and DMARCbis?
RFC 7489 (March 2015) is the original DMARC specification with Informational status. DMARCbis is the upcoming Standards Track revision that deprecates some tags (like pct and rf), adds the t= tag for testing, and clarifies alignment rules. Both use the v=DMARC1 version identifier, so existing records remain valid.
Additional resources
Standards and specifications
- RFC 7489 - Domain-based Message Authentication, Reporting, and Conformance (DMARC)
- RFC 7208 - Sender Policy Framework (SPF)
- RFC 6376 - DomainKeys Identified Mail (DKIM)
- DMARCbis Draft - Upcoming revision to RFC 7489
- IANA DMARC Parameter Registry
Tools
- Free DMARC generator - Build an RFC 7489 compliant record step by step
- DMARC checker - Validate your domain's current configuration
- Real-time DMARC state of top 100 domains