Establishing DMARC can be straightforward. An appropriately set up DMARC record safeguards your domain against spoofing, phishing, and unauthorized email usage, while also enhancing the credibility of genuine messages. This guide, designed for beginners, will walk you through the process of creating, publishing, testing, and progressively reinforcing a DMARC record with easy-to-follow steps.
What DMARC Is and Why Your Domain Needs It
DMARC, short for Domain-based Message Authentication, Reporting, and Conformance, is an email authentication standard that helps a domain owner protect a domain from email spoofing, phishing prevention failures, and broader email abuse. A DMARC record tells an email receiver what to do when a message claims to come from your domain but does not pass SPF, DKIM, or identifier alignment checks.
At its core, a DMARC record is a DNS TXT record published at _dmarc.yourdomain.com. When you publish DMARC record data in DNS, receiving systems such as Gmail, Yahoo, Microsoft 365, and other mailbox providers can evaluate your DMARC policy and apply policy instructions to messages that fail authentication.
For technical grounding, the formal standard is documented in RFC 7489, while the broader ecosystem is maintained by organizations such as DMARC.org. In practice, DMARC improves security by closing the authentication gap between your visible “From” domain and the systems authorized to send mail.
How DMARC Works With Email Authentication
DMARC depends on two major email authentication mechanisms: SPF and DKIM. SPF checks whether an email server or mail server is authorized to send on behalf of a domain. DKIM validates a cryptographic signature added by the sending system. DMARC then checks identifier alignment, meaning the authenticated SPF or DKIM domain must align with the visible From domain.
Alignment can be either relaxed alignment or strict alignment. Relaxed alignment allows a subdomain to align with the Organizational Domain, while strict alignment requires an exact match. For example, mail from news.example.com may pass relaxed alignment for example.com, but not strict alignment.
Prerequisites Before You Create a DMARC Record: SPF, DKIM, and DNS Access
Before you create a DMARC record syntax, confirm that your SPF and DKIM records are already working. A DMARC record does not replace SPF or DKIM; it builds on them. If SPF-authenticated domains are incomplete or DKIM Alignment is broken, messages may fail authentication even if they are legitimate.
You also need DNS access for the domain. To publish DMARC record content, you must add a TXT record to your DNS zone. This is usually done through your DNS host, domain registrar, hosting provider, or cloud DNS platform.
Microsoft provides a practical configuration overview for Microsoft 365 environments in its DMARC configuration guide, and Google Workspace administrators can reference Google’s official set up DMARC documentation for Gmail and Workspace routing considerations.
SPF and DKIM Readiness Checklist
Before DMARC deployment, verify:
- Your SPF TXT record includes all legitimate sending services.
- Your DKIM keys are enabled for each email platform.
- Your mail stream is mapped, including marketing platforms, CRM tools, ticketing systems, and transactional email.
- Your DNS provider allows TXT record creation.
- You have a reporting address ready for aggregate reports and forensic reports.
How to Create a DMARC Record Step by Step
The beginner-friendly way to create DMARC record values is to start with monitoring. A basic DMARC record might look like this:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-failures@example.com; pct=100; sp=none
This TXT record tells receivers that the DMARC policy is a none policy, that aggregate reports should go to the rua address, that forensic reports should go to the ruf address, that the policy application percentage is 100, and that the subdomain policy is also none.
You can use a record generator such as the dmarcian DMARC Record Wizard, MXToolBox DMARC Record Generator, or EasyDMARC DMARC Record Generator to create DMARC record syntax without memorizing every tag. Tools from dmarcian, EasyDMARC, MXToolBox, SuperTool, and Delivery Center can also help perform a DMARC check after you publish it in DNS.
Step 1: Select Your Policy Tags
Every DMARC record starts with v=DMARC1. The most important tag is p=, which defines the DMARC policy for the domain. Common values are none, quarantine, and reject.
You may also include:
- sp= for subdomain policy or policy for subdomains.
- pct= for policy percentage or Policy Application Percent.
- rua= for Aggregate DMARC reports.
- ruf= for Forensic DMARC reports.
- adkim= for DKIM Alignment mode.
- aspf= for SPF Alignment mode.
Example Beginner Record
v=DMARC1; p=none; rua=mailto:dmarc@example.com; pct=100; sp=none
This is suitable when you first create a DMARC record and want to monitor email before enforcement.
Step 2: Publish DMARC Record in DNS
To publish DMARC record settings, create a DNS TXT record:
- Type: TXT record
- Host/Name: _dmarc
- Value: your DMARC record
- TTL: default or 1 hour
After you publish the DMARC record data, allow time for DNS propagation. You can use a public checker such as the DNSChecker DMARC Record Generator to confirm whether the TXT record is visible globally.
Choosing the Right DMARC Policy: none, quarantine, or reject
The DMARC policy determines how email receivers handle messages that fail authentication. Choosing the right DMARC policy depends on how well you understand your mail stream and how confident you are in your SPF and DKIM setup.
none Policy
A none policy means “monitor only.” Messages that fail authentication are not automatically blocked because of DMARC. This is the safest starting point when you create DMARC record settings for the first time.
Use p=none while you monitor email, receive reports, and visualize DMARC data in dashboards such as Domain Overview, Failure Reports, Forensic Reports, or an XML-to-Human converter.
Quarantine Policy
A quarantine policy tells receivers to treat failing mail as suspicious. In many environments, quarantine means the message may go to spam or junk. This is a good middle step in policy ramp-up after you have reviewed aggregate reports and fixed unauthorized use.
Example:
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; pct=50; sp=quarantine
Here, the policy percentage applies enforcement to 50% of failing mail, while the subdomain policy also uses quarantine.
Reject Policy
A reject policy is the strongest DMARC policy. It instructs receiving systems to reject mail that fails authentication and DMARC alignment. This helps stop email spoofing but should be used only after DMARC deployment is stable.
Example:
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; pct=100; sp=reject
A reject policy is ideal when SPF, DKIM, identifier alignment, and subdomain policy behavior are fully validated.
Subdomain Policy Considerations
The subdomain policy controls what happens to mail from subdomains. If your main domain is example.com, a subdomain policy applies to names like mail.example.com or offers.example.com. A conservative subdomain policy may be sp=none during testing, then sp=quarantine, and finally sp=reject.
Advanced Setup Options
For an advanced setup, use adkim=s for strict alignment, aspf=s for strict SPF alignment, or keep defaults for relaxed alignment. You can also perform a manual edit after using a record generator if your organization requires specific policy application rules.
Testing, Monitoring, and Troubleshooting Your DMARC Setup
After you publish DMARC record content in DNS, testing and monitoring are essential. A DMARC check confirms whether the TXT record exists, but reports show whether your mail stream is healthy.
Aggregate reports are usually XML reports sent daily by participating email receiver systems. They show sending IPs, SPF results, DKIM results, DKIM Alignment, SPF Alignment, policy application, and whether messages passed or failed authentication. Forensic reports, sometimes called Failure Reports, provide message-level failure details when supported, though many providers limit forensic data for privacy and security reasons.
You can also compare your setup against community education resources such as the M3AAWG DMARC Training Series or use practitioner guides like this DMARC record walkthrough when planning phishing prevention improvements.
Troubleshooting Common DMARC Problems
Common problems include:
- Multiple DMARC records on one domain.
- Missing or malformed TXT record syntax.
- SPF exceeds the DNS lookup limit.
- DKIM is not enabled for a sending platform.
- The visible From domain does not match DKIM or SPF-authenticated domains.
- The rua address or ruf address is typed incorrectly.
- The subdomain policy is stricter than intended.
If you use dmarcian.com, EasyDMARC, MXToolBox, Forensic Viewer, or a similar forensic viewer, review both Aggregate DMARC reports and Forensic DMARC reports. A good platform should help visualize DMARC data, identify unauthorized use, and highlight which email server or mail server is responsible for failures.
When to Ramp Up Enforcement
Move from p=none to p=quarantine only after legitimate sources pass email authentication consistently. Move from quarantine to reject when you are confident that SPF, DKIM, DNS, TXT record syntax, DMARC policy, and subdomain policy are correct across the full domain. A careful policy ramp-up reduces disruption while improving security against email abuse and spoofing.
