To set up a DMARC policy for your domain, you publish a DNS TXT record at _dmarc.yourdomain.com that tells receiving mail servers what to do when an email fails authentication checks. The record specifies a policy level, an optional reporting address, and alignment rules for SPF and DKIM. The sections below walk through every step and answer the most common questions along the way.
What are the three DMARC policy levels and what does each one do?
DMARC has three policy levels: p=none, p=quarantine, and p=reject. The none policy monitors email traffic without taking action on failing messages. The quarantine policy sends failing messages to the spam or junk folder. The reject policy instructs receiving servers to block failing messages entirely before they reach the inbox.
Each level represents a different stage of enforcement. Most domain owners start with p=none to collect data and understand their sending landscape before tightening controls. Moving too quickly to p=reject without proper preparation can result in legitimate emails being blocked, which is why a phased approach is strongly recommended.
- p=none: Monitoring only. No messages are filtered. Ideal for initial setup and audit.
- p=quarantine: Failing messages are treated with suspicion and typically land in spam. A useful middle ground during transition.
- p=reject: Full enforcement. Failing messages are rejected at the server level. This is the goal for most domains that are serious about email security.
What do you need before creating a DMARC record?
Before publishing a DMARC record, you need valid SPF and DKIM records already in place for your domain. DMARC works by checking whether an email passes SPF or DKIM alignment, so without at least one of those authentication methods configured correctly, DMARC has nothing to evaluate and your policy will have little effect.
You also need access to your domain’s DNS management interface, typically through your domain registrar or hosting provider. Additionally, you should have a mailbox or reporting tool ready to receive aggregate reports, because without a destination for those reports, you lose the visibility that makes DMARC useful in the early stages.
A quick pre-setup checklist:
- Confirm SPF is published and passing for your primary sending domain
- Confirm DKIM is configured for all major sending sources (your ESP, CRM, marketing tools)
- Identify all legitimate sources that send email on behalf of your domain
- Set up a dedicated inbox or reporting service to receive DMARC aggregate reports
- Log in to your DNS provider and confirm you have permission to add TXT records
How do you write and publish a DMARC DNS record?
A DMARC record is a TXT record published at the subdomain _dmarc.yourdomain.com. A basic starting record looks like this: v=DMARC1; p=none; rua=mailto:reports@yourdomain.com. You add this record in your DNS management panel exactly as you would any other TXT record, with the host set to _dmarc and the value containing the full DMARC tag string.
The required tags in any DMARC record are v=DMARC1 (the version identifier) and p= (the policy). Everything else is optional but often valuable. Once published, DNS propagation typically takes anywhere from a few minutes to 48 hours, depending on your provider’s TTL settings. You can verify the record is live using a free DNS lookup tool or a DMARC checker.
Common optional tags to consider adding from the start:
- rua: Address for aggregate reports (highly recommended)
- ruf: Address for forensic failure reports
- pct: Percentage of messages the policy applies to (useful during gradual rollout)
- sp: Policy for subdomains, if different from the root domain
- adkim / aspf: Alignment mode for DKIM and SPF (relaxed or strict)
What is the rua tag and why does it matter?
The rua tag specifies the email address where receiving mail servers send aggregate DMARC reports. These reports are XML files delivered daily that show you which IP addresses are sending email using your domain, whether those messages passed or failed SPF and DKIM, and what policy was applied. Without a rua address, you are flying blind during the monitoring phase.
Aggregate reports are the core feedback mechanism of DMARC. They allow you to discover unauthorized senders using your domain, identify legitimate sending sources you may have missed during setup, and track your authentication pass rates over time. Because the reports arrive in XML format, many organizations use a DMARC reporting tool or service to parse and visualize the data in a readable way. The rua tag is not technically required, but skipping it removes the most important signal you have for making informed decisions about when and how to tighten your policy.
How do you move from p=none to p=reject safely?
The safe path from p=none to p=reject is a phased transition that runs through p=quarantine first, with monitoring at each stage. You should only move to the next level once your aggregate reports consistently show that the vast majority of legitimate email is passing DMARC alignment. Rushing this process is the most common cause of email delivery failures after DMARC implementation.
A practical approach looks like this:
- Start at p=none and collect at least two to four weeks of aggregate report data
- Identify and fix any legitimate sending sources that are failing authentication
- Move to p=quarantine with pct=10 (applying the policy to only 10% of traffic) to test the impact
- Gradually increase the pct value as you confirm no legitimate mail is being caught
- Once quarantine is stable at pct=100, move to p=reject using the same incremental pct approach
- Remove the pct tag once you are confident full rejection is working correctly
The key principle throughout is to let the data guide each transition. If aggregate reports reveal a sending source you had not accounted for, fix the authentication for that source before moving forward.
Why are emails still failing DMARC after setup?
Emails fail DMARC after setup most often because of alignment mismatches, not missing records. DMARC requires that the domain in the From header aligns with either the SPF-authenticated domain or the DKIM-signing domain. If a third-party sender uses your From address but signs with their own domain and you have not set up custom DKIM for that integration, alignment will fail even if SPF and DKIM themselves pass.
Other common causes include:
- Forwarded email: Email forwarding breaks SPF because the forwarding server’s IP is not listed in your SPF record. DKIM usually survives forwarding, but if DKIM is not configured, forwarded messages will fail.
- Missing sending sources: Marketing platforms, transactional email services, CRMs, and support tools all send on your behalf. Any source not covered by your SPF record or DKIM configuration will fail.
- SPF record exceeding the DNS lookup limit: SPF has a hard limit of 10 DNS lookups. Exceeding this causes SPF to return a PermError, which counts as a failure for DMARC purposes.
- Relaxed vs. strict alignment: In relaxed mode (the default), organizational domain matching is sufficient. In strict mode, the domains must match exactly. Switching to strict alignment without auditing your setup will cause failures.
Revisiting your aggregate reports and cross-referencing failing sources against your current SPF and DKIM configuration is almost always the fastest way to diagnose ongoing failures.
How Email Industries helps with DMARC policy setup
Setting up a DMARC policy correctly requires more than just publishing a DNS record. It demands a clear picture of every source sending on your behalf, a structured transition plan, and ongoing monitoring to catch problems before they affect deliverability. That is exactly where we step in.
At Email Industries, we help organizations of all sizes implement and manage DMARC as part of a broader email authentication strategy. Here is what we bring to the process:
- Full sending source audit: We identify every legitimate source sending email under your domain, including third-party tools that are easy to overlook
- SPF and DKIM alignment review: We ensure all sending sources are correctly authenticated before you move to enforcement
- Phased policy rollout: We guide you through each stage from p=none to p=reject with data-driven checkpoints
- Aggregate report analysis: We interpret your DMARC reports and translate the data into clear, actionable steps
- Ongoing monitoring: Through our Deliverability Assurance Packages, we keep a continuous eye on your authentication health so problems are caught early
If your DMARC setup is stalled, you are seeing unexpected failures, or you simply want to get it right the first time, explore our full range of services or reach out to us directly. We are happy to take a look at where things stand and help you move forward with confidence.
Related Articles
- Should you implement BIMI if you already have DMARC?
- How does SPF work in emails?
- How do email advertising agencies integrate with existing marketing teams?
- What factors affect full service email marketing pricing?
- What expertise should a full service email marketing agency have?
- What services are included in full service email marketing?
- What is the role of domain age in email deliverability?
- What sending frequency is recommended during domain warmup?
- Why is domain reputation important during email migration?
- What is a good sender reputation score before ending IP warming?
- How do ecommerce email agencies increase online sales?
- How do you evaluate email marketing agency performance?
- What is email infrastructure consulting used for?
- What is email blacklist removal and how does it work?
- Can an email agency improve your sender reputation?
