Troubleshooting guideReviewed 2026-08-07By HostWithShery technical editorial

DMARC record missing

A domain without _dmarc does not publish a DMARC policy or aggregate-report destination.

Start with evidence from your own domain before changing DNS, SSL or mail settings.
Check your own configuration

Email Health Check

This page is preconfigured with the Email Health Check that best matches this problem.

No accountPublic evidence only
Live public check

Checks MX routing plus SPF, DKIM discovery, DMARC, BIMI, MTA-STS and TLS-RPT public signals.

No account · Public configuration only
On this page

What this symptom usually tells you

DMARC is published at _dmarc and tells receivers how to evaluate alignment plus where to send reports. Without that record, a domain can still use SPF and DKIM, but it has no DMARC policy and receives no DMARC aggregate feedback through a rua destination.

Evidence that narrows the cause

Use the live diagnostic to test the exact hostname involved. For this problem, the highest-value evidence is below. Treat each result as one piece of the business-email DNS and mail authentication diagnosis rather than as a standalone health score.

  • Publish p=none for monitoring if appropriateVerify publish p=none for monitoring if appropriate from the public Internet and compare it with the value the responsible provider says should be live.
  • Add ruaVerify add rua from the public Internet and compare it with the value the responsible provider says should be live.
  • Verify SPF/DKIM alignmentInspect the single public v=spf1 policy, validate its terms and count DNS-query-causing mechanisms; duplicate policies or excessive lookups can invalidate SPF.

Record the current state before editing

Before changing business-email DNS and mail authentication settings, save the exact public values for publish p=none for monitoring if appropriate, add rua, verify SPF/DKIM alignment and note which hostname or mail path is failing. This creates a rollback point and prevents a later resolver cache, provider dashboard or unrelated working record from being mistaken for the original cause. Change one evidence-backed setting at a time, then compare the same signals again.

Safest repair path

Confirm SPF and/or DKIM are functioning first, then publish a syntactically valid DMARC record. A monitoring policy such as p=none can be appropriate while collecting evidence; choose reporting addresses and later enforcement deliberately based on legitimate mail sources.

How to confirm this specific repair

_dmarc should return one parseable policy with the intended p value and reporting destination. Real messages should show DMARC pass when either aligned SPF or aligned DKIM passes. Review aggregate reports before moving to quarantine or reject.

A common wrong turn

Publishing p=reject before discovering all legitimate senders can block valid mail. DMARC enforcement is not a substitute for fixing SPF/DKIM alignment first.

When to escalate with evidence

If these public checks match the provider's current documented configuration but the service still fails, give support the exact hostname, the observed business-email DNS and mail authentication result, a timestamp, and the failing network or message path. That separates a provider-side incident from a DNS change that has not actually become authoritative.

Technical references

These primary standards and provider documents are used to verify the behavior described on this page. Provider dashboards can change, so use the current official value for tenant-specific DNS records rather than copying an example from another account.