No DMARC Record Found: How to Set Up DMARC from Scratch

What This Error Means

"No DMARC record found" means there is no TXT record published at _dmarc.yourdomain.com. Without this record, your domain has no DMARC protection — anyone can send email that appears to come from your domain, and receiving servers have no policy for handling unauthenticated messages. The fix: publish a DMARC record starting with p=none, monitor your sending sources, then progress to enforcement.

Use the mxio DMARC Checker to verify your domain's DMARC status.

This is not a theoretical risk. Without DMARC (RFC 7489), your customers, employees, and partners can receive phishing emails that look like they came from you. Receivers can still apply SPF/DKIM checks and reputation scoring, but without DMARC they lack your explicit domain-level enforcement policy and reporting.

Why DMARC Matters

Domain Spoofing Protection

DMARC tells receiving servers what to do when an email claiming to be from your domain fails authentication. Without DMARC, a spoofed email that fails SPF and DKIM is still likely to be delivered — the receiving server has no instructions to reject it. With DMARC at p=reject, that spoofed email gets blocked.

Deliverability Improvement

Major email providers — Gmail, Microsoft, Yahoo — factor DMARC into deliverability decisions. Domains with DMARC records signal that the domain owner takes authentication seriously. As of 2024, Gmail and Yahoo require DMARC for bulk senders (5,000+ messages per day), and enforcement has continued tightening into 2026. See Bulk Sender Requirements for the latest requirements.

Visibility into Your Email Ecosystem

DMARC aggregate reports (rua=) show you every IP address that sends email using your domain. This is invaluable for discovering:

• Shadow IT services sending email without authorization
• Compromised accounts or servers being used for spam
• Third-party vendors you forgot were sending on your behalf
• Active phishing campaigns spoofing your domain

Without DMARC, you are blind to all of this.

Prerequisites: SPF and DKIM

DMARC builds on SPF and DKIM. Before setting up DMARC, verify that both are properly configured. For a complete overview of how these protocols work together, see the Email Authentication Guide.

1. Use the mxio SPF Checker — Confirm your domain has a valid SPF record that includes all services authorized to send email on your behalf
2. Use the mxio DKIM Checker — Confirm DKIM keys are published and your mail server is signing outbound messages

DMARC can be deployed without both in place (it only requires one to pass with alignment), but having both configured gives you redundancy. If SPF breaks due to forwarding, DKIM saves DMARC. If DKIM breaks due to body modification, SPF saves DMARC. See DMARC Alignment Failure for details on how alignment works.

How to Create Your First DMARC Record

Step 1: Choose a Reporting Address

Before you write the record, decide where DMARC aggregate reports should be sent. This is the email address that receives XML reports from major receivers (Gmail, Microsoft, Yahoo, and others) showing authentication results for messages claiming to be from your domain.

Use a dedicated mailbox like dmarc-reports@yourdomain.com or dmarc@yourdomain.com. These reports can be high-volume for domains with significant email traffic, so avoid sending them to a personal inbox.

Step 2: Start with p=none

Your first DMARC record should use p=none, which enables monitoring without affecting email delivery. This lets you collect data about your email ecosystem before taking enforcement action.

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com"

Breaking this down:

Step 3: Publish the DNS Record

Add the TXT record at _dmarc.yourdomain.com in your DNS management panel. The record name is _dmarc (as a subdomain of your domain). If your DNS provider asks for the full name, enter _dmarc.yourdomain.com. If it asks for just the subdomain portion, enter _dmarc.

DNS propagation typically takes a few minutes, but can take up to the TTL of any cached negative response (often up to an hour).

Step 4: Verify the Record

After publishing, use the mxio DMARC Checker on your domain to verify:

• The record is found at the correct location
• The syntax is valid
• The policy is set to your intended level
• The reporting address is correctly formatted

Step 5: Monitor Aggregate Reports

Within 24-48 hours, you should start receiving DMARC aggregate reports from major receivers. These XML files contain:

• Source IPs — Which servers sent email as your domain
• Authentication results — Whether SPF and DKIM passed or failed for each source
• Alignment results — Whether the authenticated domain matched the From: header domain
• Message counts — How many messages were sent from each source

Review these reports to build a complete picture of your email sending landscape. Identify any legitimate services that are failing authentication and fix them before moving to enforcement.

The DMARC Progression Path

Moving directly to p=reject without monitoring is the most common DMARC deployment mistake. It blocks spoofing, but it also blocks any legitimate email that is not properly authenticated — and you almost certainly have sources you have forgotten about. The DMARC Deployment Guide covers this process in full detail.

Phase 1: p=none (2-4 weeks minimum)

"v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com"

Goal: Discover all email sources. Fix SPF and DKIM for each legitimate source. Identify any third-party services sending on your behalf.

Move on when: Aggregate reports show that all legitimate sources consistently pass DMARC.

Phase 2: p=quarantine with pct=25 (2-4 weeks)

"v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@yourdomain.com"

Goal: Test enforcement on a percentage of traffic. The pct=25 tag tells receivers to apply the quarantine policy to only 25% of failing messages. The other 75% are treated as p=none.

Move on when: No legitimate email is being quarantined. Increase pct to 50, then 100.

Phase 3: p=quarantine at pct=100 (2-4 weeks)

"v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com"

Goal: Full quarantine enforcement. All failing messages go to spam.

Move on when: No complaints about legitimate email going to spam.

Phase 4: p=reject

"v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com"

Goal: Full protection. Unauthenticated email is rejected outright. This is the end state that provides maximum protection against domain spoofing. See DMARC p=none: Why You Should Enforce for the business case.

Optional DMARC Tags

Beyond the minimum record, these tags give you more control:

Common DMARC Setup Mistakes

Wrong DNS Location

The DMARC record must be at _dmarc.yourdomain.com, not at the root domain. Publishing a TXT record with DMARC content at yourdomain.com (without the _dmarc prefix) will not be found by receiving servers.

Typos in the Record

DMARC is unforgiving about syntax. Common typos that break the record:

• v=DMARC1 must be the first tag (putting p= first invalidates the record)
• Missing semicolons between tags
• Extra spaces inside tag values
• rua=dmarc@example.com — missing the mailto: prefix

Missing External Report Authorization

If your DMARC reporting address is at a different domain than the one being protected (e.g., DMARC for yourdomain.com sends reports to reports@thirdparty.com), the receiving domain needs to publish an authorization record:

yourdomain.com._report._dmarc.thirdparty.com  TXT  "v=DMARC1"

Without this record, receivers will not send aggregate reports to the external address.

Skipping p=none

Going straight to p=reject without a monitoring phase breaks legitimate email delivery. Even if you think you know all your sending sources, DMARC reports almost always reveal surprises — a forgotten CRM integration, an HR system sending password resets, a development server sending staging notifications with production From: addresses.

Bulk Sender Requirements

As of 2024-2026, Gmail, Yahoo, and Microsoft have implemented requirements that make DMARC effectively mandatory for large senders. If your domain sends more than 5,000 messages per day to any of these providers, you need:

• A published DMARC record (at minimum p=none)
• SPF and DKIM authentication that passes
• DMARC alignment for the From: domain

Even for smaller senders, having a DMARC record improves deliverability and protects your domain from spoofing. There is no good reason to skip it. See Bulk Sender Requirements for the complete requirements.

Prevention and Ongoing Monitoring

Publishing a DMARC record is the first step. The real value comes from monitoring authentication results over time, progressing to enforcement, and catching problems as they arise.

Set up domain health monitoring to track your DMARC configuration, authentication pass rates, and enforcement status continuously. mxio alerts you when sending sources start failing authentication — so you can fix issues before they affect delivery or protection.

Related Issues

• Why Is DMARC Failing? — Troubleshooting DMARC failures after setup
• DMARC p=none: Why You Should Enforce — Moving beyond monitoring to enforcement
• DMARC Alignment Failure — When SPF/DKIM pass but DMARC fails
• Emails Going to Spam — Missing DMARC is a top deliverability issue
• Bulk Sender Requirements — Gmail, Yahoo, and Microsoft requirements