Troubleshooting DMARC Setup and Compliance Issues

Troubleshooting DMARC setup and compliance issues starts with one valid TXT record at _dmarc.example.com. Then confirm SPF or DKIM passes and aligns with the From domain, and use aggregate reports to fix failing senders.

Most DMARC problems fall into three groups: the record itself is wrong, authentication passes but does not align, or a legitimate sender was never authorized. Work through them in that order.

Quick diagnosis checklist

Before digging deep, run through these checks:

• Is there exactly one DMARC TXT record, published at _dmarc.example.com?
• Does it start with v=DMARC1 and contain a valid p= tag?
• Does SPF or DKIM pass for each of your sending sources?
• Does the passing domain match (align with) the visible From domain?
• Are you receiving aggregate reports at the address in rua=?

You can check the first two items in seconds with the free DMARC record lookup, and the domain scanner checks DMARC, SPF, DKIM and related records together.

Why is my DMARC record not being found or validated?

A DMARC record is usually not found because it is published at the wrong hostname, duplicated, or malformed. It must be a single TXT record at _dmarc. plus your domain, beginning with v=DMARC1. Receivers ignore invalid records, so a typo can leave your domain with no DMARC policy at all.

A minimal, valid monitoring record looks like this:

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

Common record-level mistakes:

• Wrong host. Publishing at example.com or dmarc.example.com instead of _dmarc.example.com. Some DNS panels append the domain automatically, producing _dmarc.example.com.example.com.
• Two records. Publishing a second DMARC TXT record, for example when a vendor asks you to add one. Merge them into one.
• Bad syntax. Tags are separated by semicolons, v=DMARC1 must come first, and p= must follow it. Smart quotes pasted from documents also break records.
• Reports sent to another domain. If rua= points to an address outside your domain, the receiving domain must publish an authorization record at example.com._report._dmarc.reportingdomain.com containing v=DMARC1. Without it, receivers may not send reports. See RFC 7489 for the details.
• Subdomains forgotten. Subdomains inherit the parent policy unless you set sp= or publish a record on the subdomain.

DNS changes can take time to propagate, so re-check after the record's TTL has passed.

Why is DMARC failing even though SPF and DKIM pass?

DMARC fails when SPF or DKIM passes but not for a domain that matches the From header. DMARC needs only one of the two to pass and align. If SPF validates the bounce domain of your email platform and DKIM signs with the vendor's domain, both can pass while DMARC still fails.

Alignment works like this:

• SPF alignment compares the domain in the envelope sender (Return-Path / MAIL FROM) with the From domain.
• DKIM alignment compares the d= domain in the DKIM signature with the From domain.

The aspf and adkim tags control the mode. Relaxed (r, the default) accepts a matching organizational domain, so mail.example.com aligns with example.com. Strict (s) requires an exact match.

v=DMARC1; p=none; adkim=r; aspf=r; rua=mailto:dmarc-reports@example.com

To fix misalignment, configure custom DKIM signing with your own domain at each third-party sender, usually by publishing a CNAME or TXT record the vendor provides. Custom DKIM is generally the most reliable route, because SPF alignment depends on the sender using a Return-Path on your domain.

SPF problems that break compliance

• More than 10 DNS lookups. SPF evaluation is limited to 10 lookups across include, a, mx, ptr, exists and the redirect modifier. Exceeding the limit returns a permanent error (see RFC 7208). Remove unused includes and retired vendors.
• Multiple SPF records. A domain must publish only one SPF TXT record. Combine them.
• Missing senders. A service that uses your domain in its Return-Path fails SPF until it is in your record. A service that uses its own bounce domain passes SPF on that domain but does not align, and adding it to your record will not change that.

DKIM problems that break compliance

• Selector not published. The signature references a selector such as s1._domainkey.example.com that does not exist in DNS.
• Key mismatch. The published public key does not match the private key the sender uses, often after a key rotation.
• Broken signatures. Gateways or footers that modify the message body after signing invalidate the signature.
• Forwarding and lists. Forwarding often breaks SPF, and mailing lists may alter messages and break DKIM. Expect some failures from these paths.

How do I find which senders are failing DMARC?

Read your DMARC aggregate (rua) reports. They list each sending IP, the volume, and whether SPF, DKIM and DMARC passed and aligned. Group the failures by source, then decide whether each one is a legitimate service to fix or an unauthorized sender to block.

Raw reports are XML files sent by receivers, so they are hard to read at scale. A DMARC monitoring tool, such as the one yourDMARC provides, collects and visualises aggregate reports across your domains so failing sources are easier to spot.

A practical triage routine:

1. Sort sources by message volume and start with the largest.
2. Identify the sender from the IP's reverse DNS or the vendor's documentation.
3. If it is legitimate, set up custom DKIM. Add it to SPF only if it uses a Return-Path on your domain, because otherwise the entry does nothing for DMARC and still uses up lookups.
4. If you do not recognize it, treat it as potential spoofing and leave it to be blocked by enforcement.
5. Re-check reports after a few days to confirm the fix.

Failure (ruf) reports are optional and many receivers do not send them, so do not rely on them. Aggregate reports are the dependable source.

How do I fix deliverability problems without losing protection?

If legitimate mail is being rejected or sent to spam because of DMARC, move the policy back to p=none, fix the failing senders, and then tighten step by step. Monitoring mode keeps reports flowing without asking receivers to act on failures.

A safe progression:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@example.com
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com

Each line is a stage, not a record set. Publish only one at a time, and publish exactly one record at any moment. The pct tag applies the policy to a share of failing mail, which lets you test enforcement gradually. Treat that stage as optional: receivers do not apply partial percentages consistently, and DMARCbis, the update to DMARC, replaces pct with the t= test flag. Move to the next stage only when reports show your legitimate sources passing consistently.

Note that p=none does not block spoofing; it only observes. If you would rather not run the rollout yourself, the managed DMARC service has the yourDMARC team take the domain to p=reject for you.

BIMI logo display also depends on DMARC. A BIMI record will not take effect until the domain enforces with p=quarantine or p=reject on all of its mail, so the pct=25 stage above does not qualify, and neither does a subdomain policy of sp=none. A missing logo is often a policy issue rather than a BIMI issue.

What compliance requirements should I check?

Compliance usually means meeting a mailbox provider's or regulator's minimum authentication rules. Gmail treats a domain as a bulk sender once it sends about 5,000 messages a day to personal Gmail accounts, and Yahoo sets similar expectations for bulk senders. On authentication, those senders need:

• SPF and DKIM both set up for the sending domain.
• A DMARC record with a policy of at least p=none, so monitoring mode is enough to meet this rule.
• A From domain that aligns with either SPF or DKIM.

The usual symptom of missing these rules is mail being deferred or rejected at the receiver, often with an SMTP error that mentions authentication, such as Gmail's 5.7.26. Providers also set rules beyond authentication, such as unsubscribe and spam-rate limits, so check the current requirements for your volume and sector.

Our email sender compliance page covers the bulk-sender requirements and DMARC expectations in regulations. Use it to confirm which rules apply to you, then verify your own domains against them.

To keep a working setup compliant over time:

• Review your DMARC policy and reports on a regular schedule, such as quarterly.
• Update SPF and DKIM whenever you add, replace or retire an email service provider.
• Re-run a lookup after any DNS migration or registrar change.
• Remember parked and unused domains: publish a DMARC record with a restrictive policy for domains that should never send mail.

Setting up DMARC from scratch is a separate process from troubleshooting an existing one. If your record does not exist yet, start with our setup guides, including the walkthroughs for Cloudflare, Route 53, Namecheap and Office 365, then return here when something fails.

Key takeaways

• Publish exactly one valid DMARC TXT record at _dmarc.example.com, starting with v=DMARC1.
• DMARC passes when either SPF or DKIM passes and aligns with the From domain; passing alone is not enough.
• Keep SPF to no more than 10 DNS lookups and publish only one SPF record.
• Use custom DKIM signing for third-party senders so alignment holds.
• Read aggregate reports to identify failing sources before tightening policy.
• If mail is wrongly rejected, return to p=none, fix the senders, then move to quarantine and reject gradually.
• Recheck compliance requirements and your records whenever you change email providers.