What a DMARC Record Is and Why Does It Matters for Email Security?
A DMARC record is a DNS-based instruction that tells receiving mail servers how to handle an email message that claims to come from your domain but fails email authentication. DMARC stands for Domain-based Message Authentication, Reporting, and Conformance, and it is published as a DNS txt record in the Domain Name System.
For example, a basic DMARC TXT record for *example.com* may look like this:
_DMARC.*example.com* TXT “v=DMARC1; p=none; rua=mailto:dmarc-reports@*example.com*”
This DNS DMARC record defines the DMARC policy, the reporting address, and how receiving providers such as Gmail, Yahoo, and Google should treat unauthenticated mail. A properly configured DMARC record is essential for email security because it helps prevent phishing, email spoofing, email abuse, and unauthorized email sent using your domain.
Why does DMARC matter for domain protection?
DMARC gives domain owners visibility and control over their mail streams. Without a dmarc policy, attackers can impersonate your domain in a Phishing Attack, making fraudulent messages appear legitimate to recipients. With DMARC, your organization can move from a monitoring-only none policy to an active quarantine policy or reject policy once your legitimate email flows are authenticated.
DMARC policies at a glance
A dmarc policy usually uses one of three values:
- p=none: Monitor only; no enforcement policy is applied.
- p=quarantine: Suspicious mail may be placed in spam or junk.
- p=reject: Failing mail should be rejected outright.
Policy percentage and rollout control
The pct= tag, also called the policy percentage or policy application percent, allows gradual enforcement. For example, pct=25 applies the selected dmarc policy to only 25% of failing messages, helping reduce disruption during DMARC deployment.
How DMARC Works with SPF and DKIM to Authenticate Email?
DMARC relies on two core email authentication technologies: SPF and DKIM. SPF, or Sender Policy Framework, checks whether the sending email server is authorized to send mail for the domain. DKIM, or DomainKeys Identified Mail, uses cryptographic signatures to verify that an email message was not modified in transit.
A valid spf record is published as a dns txt record and lists approved senders for the domain. A valid dkim record is also published as a TXT record and contains the public key used to verify DKIM signatures. DMARC evaluates the results of the spf record and dkim record, then checks whether the authenticated identity aligns with the visible From domain.
SPF, DKIM, and identifier alignment
DMARC requires identifier alignment. That means the domain authenticated by SPF or DKIM must align with the domain shown to the recipient in the From header.
There are two alignment modes:
- Relaxed alignment: Allows subdomains to align with the organizational domain.
- Strict alignment: Requires an exact domain match.
The DMARC tags aspf and adkim control SPF and DKIM alignment behavior. For example, aspf=s requires strict SPF alignment, while adkim=r allows relaxed DKIM alignment.
Organizational domain and subdomain handling
The organizational domain is the main registered domain, such as *example.com*. A subdomain policy using the sp= tag can define how DMARC applies to subdomains like mail.*example.com* or news.*example.com*. This is useful when different business units, platforms, or third-party senders manage separate email flows.
SPF and DKIM records must be maintained
A broken spf record can cause legitimate mail to fail SPF checks, while an incorrect dkim record can trigger DKIM failures. For strong email security, both the spf record and dkim record should be reviewed whenever you add or remove an email server, marketing platform, CRM, or transactional mail provider.
How to Perform a DMARC Record Lookup Step by Step?
A DMARC lookup verifies whether your domain has a valid dmarc record published in DNS. This is often called a dmarc check, DMARC record validation, or DNS TXT lookup.
Step 1: Identify the domain to check
Start with the domain used in your visible From address. If your messages come from billing@*example.com*, the DMARC lookup should target:
_dmarc.*example.com*
This is where the dns txt record for DMARC must be published. If you use Cloudflare, Google Cloud DNS, or another DNS provider, confirm that the TXT record exists at the correct host.
Step 2: Use a lookup tool or command line
How to add DMARC record lookup using:
- A DMARC management platform such as dmarcian
- A DNS checker
- Command-line tools such as dig or nslookup
- An Email Security DNS Wizard or record wizard
Example command:
dig TXT _dmarc.*example.com*
A successful response should return a dmarc record beginning with v=DMARC1. If no result appears, you may need to create dmarc record syntax and then publish dmarc record data through your DNS provider.
Step 3: Review the domain overview
Many tools provide a domain overview showing whether the domain has SPF, DKIM, and DMARC configured. Platforms such as dmarcian can show SPF Authenticated domains, authentication gaps, mail streams, third-party reports, and aggregate reports in a more readable format.
Example DMARC record
v=DMARC1; p=none; rua=mailto:dmarc@*example.com*; ruf=mailto:forensics@*example.com*; adkim=r; aspf=r; pct=100
This dmarc record uses a monitoring dmarc policy, sends aggregate reports to a rua address, sends forensic reports to a ruf address, and applies the policy to 100% of evaluated mail.
How to Validate Your DMARC Record and Identify Common Errors?
DMARC validation checks whether your dmarc record is syntactically correct, published in the correct location, and aligned with your email authentication strategy. A valid dns txt record must contain only one DMARC policy record for the domain.
Common DMARC record errors
Frequent record validation problems include:
- Multiple DMARC records published for one domain
- Missing v=DMARC1
- Invalid or unsupported tags
- Incorrect reporting address formatting
- A malformed rua address or ruf address
- Report destination domains that are not authorized
- Policy syntax errors in the dmarc policy
- Missing SPF or DKIM alignment
Reporting address and report destination issues
The rua= tag defines where aggregate reports are sent. These reports are usually daily xml reports summarizing authentication results across mail streams. The ruf= tag defines where forensic reports or Forensic DMARC reports may be sent when individual messages fail authentication.
If the report destination is outside the original domain, that external domain may need to publish an authorization record. For example, sending reports from *example.com* to a vendor domain may require additional DNS verification.
Aggregate reports versus forensic reports
Aggregate reports provide broad visibility into email flows, including legitimate senders, unauthorized email, SPF results, DKIM results, and domain compliance trends. Forensic reports, by contrast, may include message-level samples related to a forensic failure. Because forensic reports can contain sensitive data, review your Privacy Policy and internal data handling rules before enabling failure reporting.
Tools such as dmarcian’s XML-to-Human converter, Forensic Viewer, and dmarc management platform can help dmarcian users interpret XML reports, Forensic DMARC reports, DKIM failures, and Security Insights without manually parsing raw files.
Read Dive is a leading technology blog focusing on different domains like Blockchain, AI, Chatbot, Fintech, Health Tech, Software Development and Testing. For guest blogging, please feel free to contact at readdive@gmail.com.
