Where is the DMARC record published?

As a TXT record at _dmarc. followed by the domain, for example _dmarc.example.com . If the sending domain has no record, receivers look for one at the organisational domain (RFC 7489 section 6.6.3). The DMARC check does the same lookup.

It is the starting point. It asks receivers not to act on failures, but it still enables aggregate reports ( rua ), which show who sends mail as your domain and whether it aligns. It does not protect the domain against spoofing.

Can DMARC pass if SPF fails?

Yes. A message passes DMARC when at least one of SPF or DKIM passes in alignment with the From domain (RFC 7489 section 4.2). Mail that is forwarded often fails SPF but keeps a valid DKIM signature.

Does the check verify that report addresses on other domains accept reports?

No. RFC 7489 section 7.1 requires a domain that receives reports for another domain to publish an authorisation record, and report senders check it. The DMARC check reads the record you publish and does not test that authorisation.

DMARC explained: policy, alignment and reports

Domain-based Message Authentication, Reporting and Conformance (DMARC) is specified in RFC 7489. It builds on SPF and DKIM. It lets the owner of the domain in the visible From address say what receivers should do when a message fails both, and it asks receivers to send back reports.

What DMARC adds to SPF and DKIM

SPF and DKIM each authenticate a domain, but neither one has to be the domain in the From header. An SPF pass is about the envelope sender; a DKIM pass is about the d= domain of a signature. DMARC passes a message only when SPF or DKIM passes and the authenticated domain is aligned with the From domain (alignment is defined in RFC 7489 section 3.1, the pass rule in section 4.2). Without that link, an attacker could pass SPF with their own domain while showing yours to the reader. See SPF explained and DKIM explained.

Alignment

Alignment compares the authenticated domain with the From domain. In relaxed mode (the default) the two only need the same organisational domain, so mail.example.com aligns with example.com. In strict mode they must be identical. The tags aspf and adkim choose the mode for SPF and DKIM. The organisational domain is found with the Public Suffix List, which is how example.co.uk is told apart from co.uk.

The record

A DMARC record is a TXT record at _dmarc.<domain> made of tag=value pairs separated by semicolons. The first tag must be v=DMARC1, and p must be present.

Tag	Meaning
`p`	Policy for the domain: `none`, `quarantine` or `reject`.
`sp`	Policy for subdomains. If absent, `p` applies to them as well.
`pct`	Percentage of failing messages the policy applies to, 0 to 100, default 100.
`rua`	Where to send aggregate reports, as `mailto:` URIs.
`ruf`	Where to send failure (forensic) reports.
`adkim`, `aspf`	Alignment mode, `r` (relaxed, default) or `s` (strict).

If the record is missing, a domain is treated as having no DMARC policy. If a sending domain has no record of its own, the record of the organisational domain is used, and its sp tag (or p, if there is no sp) applies to the subdomain. The check reports this as DMARC_INHERITED.

With pct below 100, the policy is applied to that share of failing messages and the next weaker policy to the rest (from reject to quarantine, from quarantine to none). The check flags this as DMARC_PARTIAL_PCT because the domain is not yet fully protected.

Rolling out a policy

Publish v=DMARC1; p=none; rua=mailto:... and read the aggregate reports. They list the sources that send mail as your domain and whether SPF and DKIM align for them.
Fix legitimate senders until they pass in alignment: authorise them in SPF or, better, have them sign with a DKIM key for your domain.
Move to p=quarantine, optionally with a low pct that you raise over time.
Move to p=reject when the reports show no legitimate failing mail.

Mailing lists and forwarding services can break both SPF and DKIM, so a strict policy can affect legitimate mail from those paths. The reports are how you see it.

Reports

Aggregate reports (rua) are XML files, usually sent daily, with counts per source IP and the SPF, DKIM and DMARC results. Failure reports (ruf) are per-message copies. Many receivers do not send them at all, partly for privacy reasons, so do not rely on them. Each URI may carry a size limit, for example mailto:[email protected]!10m.

If a report address is in a domain with a different organisational domain than the one that publishes the policy, the receiving domain must publish an authorisation TXT record (RFC 7489 section 7.1); otherwise report senders discard the address. A report address that uses a scheme other than mailto is reported as DMARC_UNSUPPORTED_REPORT_URI, since mailto is the form every report sender is expected to support.

Common mistakes

No record on the sending domain or its organisational domain (DMARC_NOT_FOUND).
Several DMARC records on the same name (DMARC_MULTIPLE_RECORDS).
A missing or invalid p (DMARC_INVALID_POLICY). RFC 7489 says that if p is invalid but a valid rua is present, the record is handled as p=none.
Staying on p=none (DMARC_POLICY_NONE) or having no rua (DMARC_NO_RUA), which leaves you without data.
Typos in tags and values (DMARC_SYNTAX_ERROR), and tags that are not defined (DMARC_UNKNOWN_TAG).

Use the DMARC check to read the effective policy for a domain, or the mail check to see it next to SPF, DKIM and MX. The check reads published records only. It does not look at your mail flow or at received reports.