A DMARC record is a DNS record that tells receiving mail servers what to do with messages that claim to come from your domain but fail authentication, and where to send reports about them. It builds on SPF and DKIM, adds a policy and ties the checks to the visible From address. For anyone who sends email from their own domain, a DMARC record is one of the most useful protections against spoofing and one of the requirements that large mailbox providers expect from bulk senders. This guide explains what a DMARC record is, what each part of it means, how to create one step by step, how to check and test it and how to move safely from monitoring to enforcement.
What is a DMARC record?
DMARC stands for Domain-based Message Authentication, Reporting and Conformance. The owner of a domain publishes a record that says three things. First, a message that claims to be from this domain should be checked using SPF and DKIM, and at least one of them must pass in alignment with the visible From domain. Second, if neither does, the receiver should treat the message according to the published policy: do nothing special, quarantine it or reject it. Third, receivers should send reports to the address given, so that the owner can see who is sending mail in their name.
The idea of alignment is the heart of DMARC. SPF checks the envelope sender and DKIM checks the signing domain, but neither one looks at the From address a person sees. DMARC requires the domain in a passing SPF or DKIM check to match the From domain. See DMARC alignment explained and email authentication explained.
What does a DMARC record look like?
A record is a TXT record published at the name _dmarc under your domain. A simple monitoring-only example:
Name: _dmarc.example.com Type: TXT Value: v=DMARC1; p=none; rua=mailto:[email protected]
A stricter example:
v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=s; aspf=s
DMARC record tags explained
| Tag | Meaning | Example |
|---|---|---|
v | Version. Required, and must be first. | v=DMARC1 |
p | Policy for the domain. Required. Values: none, quarantine, reject. | p=quarantine |
rua | Where aggregate reports are sent. | rua=mailto:[email protected] |
ruf | Where failure (forensic) reports are sent. Support varies and privacy rules apply. | ruf=mailto:[email protected] |
sp | Policy for subdomains, if different. | sp=reject |
adkim | DKIM alignment mode: r (relaxed) or s (strict). | adkim=r |
aspf | SPF alignment mode: r or s. | aspf=r |
pct | Percentage of failing messages the policy applies to. Part of the original standard; newer drafts revise it. | pct=25 |
fo | Options for when failure reports are generated. | fo=1 |
The three policies
- p=none asks receivers to take no special action. You still receive reports. This is the right starting point.
- p=quarantine asks receivers to treat failing messages with suspicion, usually by placing them in the spam folder.
- p=reject asks receivers to refuse failing messages during delivery. It gives the strongest protection against spoofing.
How to create a DMARC record
- Make sure SPF and DKIM work first. DMARC depends on them. Publish SPF (see SPF record explained) and set up DKIM signing for every system that sends mail for your domain.
- Create a mailbox or address for reports. Reports arrive as compressed XML files from many receivers. Use a dedicated address, or a service that processes them for you. A busy domain can receive many files a day.
- Write the record. Start with
v=DMARC1; p=none; rua=mailto:your-report-address. - Publish it as a TXT record with the host name
_dmarcin your DNS panel. Some panels want the full name, others only the part before your domain. - Wait and read the reports. After a few days you will see which servers send mail as your domain and whether they pass.
- Fix the failures. Add missing senders to SPF, enable DKIM for each service and make sure the domains align.
- Move to quarantine, then reject. Tighten the policy gradually as the reports come back clean. Details in DMARC reports and moving to reject.
If several services send for you, managing multiple vendors on one domain explains how to keep the records tidy.
How to check a DMARC record
With an online checker
Our SPF, DKIM and DMARC checker fetches the record, reads each tag and points out syntax problems.
From the command line
dig +short TXT _dmarc.example.com nslookup -type=TXT _dmarc.example.com
You should see one line beginning v=DMARC1. No answer means no record. Two answers beginning with the same version tag means two records, which invalidates the policy, so remove the extra one.
With a real message
Send a test message to a mailbox you control and look at the authentication results in the headers. You want to see dmarc=pass. See how to read email headers.
How to test a DMARC record safely
- Start with
p=none, so that nothing is blocked while you learn. - Check each sending system separately: your mailbox provider, your marketing platform, your help desk, your billing system and your website.
- Look for failures in the reports and identify the cause, usually a missing DKIM signature or a misaligned domain.
- When using
pct, apply stricter policies to a small share first, if your receivers honour it. - Move up one step at a time and watch the reports for a few weeks before the next step.
Common DMARC record problems
| Problem | Cause | Fix |
|---|---|---|
| "No DMARC record found" | Record missing, wrong host name or DNS not updated | Publish a TXT record at _dmarc.yourdomain and wait for DNS |
| Two records | Records added by different people | Keep only one |
| Syntax error | Missing semicolon, wrong tag, spaces in addresses | Run a checker and compare with the examples above |
| Legitimate mail fails | A sender is missing from SPF or has no aligned DKIM | Fix the sender before tightening the policy |
| Reports never arrive | Wrong rua address, or an external report address not authorised | Check the address, and if it is on another domain, publish the authorisation record the standard describes |
| Mailing list or forwarded mail fails | Forwarding breaks SPF and may alter content | See email forwarding explained |
Do I need a DMARC record?
If you send email from your own domain, yes. Without it, anyone can try to send mail pretending to be you, and receivers have no policy to follow. Large mailbox providers have published sender requirements for bulk senders, and a DMARC record with at least a monitoring policy is part of those expectations. Requirements change, so check the current guidelines of the providers you send to, for example Google's email sender guidelines. Even if you send little mail, a record with reporting helps you see who is using your domain.
DMARC for domains that do not send mail
Parked and unused domains are attractive to spoofers. For a domain that never sends email, publish v=spf1 -all as the SPF record and a DMARC record with p=reject. This tells receivers that no mail from that domain is legitimate.
Check your DMARC record now See your policy, report address and alignment settings, and find syntax errors before they cost you mail.
References and further reading
Frequently asked questions
What is a DMARC record?
A TXT record at _dmarc.yourdomain that tells receivers what to do with messages that fail SPF and DKIM alignment for your domain and where to send reports.
What should my first DMARC record be?
A monitoring record such as v=DMARC1; p=none; rua=mailto:[email protected]. It blocks nothing and gives you reports to fix problems before you enforce.
How do I check my DMARC record?
Use a DMARC checker, run dig +short TXT _dmarc.yourdomain.com, or look for dmarc=pass in the headers of a test message.
What is the difference between quarantine and reject?
Quarantine asks receivers to treat failing mail as suspicious, usually the spam folder. Reject asks them to refuse it during delivery.
Do I need DMARC if I only send a little email?
Yes, it is still worthwhile. It protects your domain from spoofing and shows who sends mail in your name, and large mailbox providers expect it from bulk senders.