DMARC, and how to read the reports

DMARC, and how to read the reports

DMARC lets the domain named in your From header tell receivers what to do when SPF or DKIM do not align. It also tells them where to send reports. If you send at scale, you need it. Gmail and Yahoo both require DMARC for bulk senders, and having no policy can lead to delays or rejection.

This guide explains the policy you publish in DNS, what the tags mean, how to avoid the common traps, and how to read the XML reports you will receive.

Before you start

This picks up from a mail setup you can already send from and that you can reach over the web, with SPF and DKIM available for each source that uses your domain. If you do not have that, get SPF and DKIM in place for your senders first.

• Access to DNS for your domain: you will publish one TXT record at _dmarc.<your-domain>. If your domain points at Hostworld for hosting, set your nameservers at your registrar to ns1.serverworld.uk, ns2.serverworld.uk, ns3.serverworld.uk and ns4.serverworld.uk. You can then add the DMARC record in cPanel’s Zone Editor.
• Choose where reports will go: DMARC sends aggregate reports (RUA) to one or more mailto: addresses. Failure reports (RUF) are optional and can include message content, so plan for privacy if you enable them.
• Only one DMARC record is valid: if multiple TXT records exist at _dmarc.<domain>, receivers discard them all. Consolidate into a single record before testing.
• v= tag rules: the record must begin with v=DMARC1 (exact case). If it is not first, the whole record is ignored.
• Defaults that bite: adkim and aspf default to relaxed, not strict. Unknown tags are ignored. A malformed v= voids the record.
• New spec, new tags: the 2026 base spec is RFC 9989. It removes pct, ri and rf as active options. Use t=y for test mode instead of pct. It also standardises np and clarifies subdomain handling and discovery.
• Discovery changed: receivers now use a DNS tree walk from _dmarc.<author-domain> up through parent and public suffix domains as defined there. Tools based on the old Public Suffix List logic may disagree with receivers.
• External reporting authorisations: if your rua= or ruf= points to another domain, that domain must publish an authorisation record in DNS or receivers will ignore that destination.
• Caching: updates to report authorisations and DMARC itself follow DNS TTL. Do not assume an immediate switch in where reports land.

Step 1: Decide your starting policy

What this does: you define the action for mail that fails alignment and where to send reports. You start with monitoring, then move to enforcement after you have reviewed the data.

• Policy options: p=none (monitor), p=quarantine (treat as suspicious), p=reject (do not accept).
• Staged rollout: RFC 9989 advises moving from p=none to p=quarantine, then to p=reject after you have assessed reports and handled indirect flows such as forwarders and mailing lists.
• Testing tag: t=y tells receivers to apply one step less than the published policy while still sending reports. It replaces legacy pct ramp-ups. The default is t=n.

Step 2: Plan subdomain and non-existent subdomain policy

What this does: you control how your policy applies to subdomains and to names that do not exist.

• sp= sets subdomain policy. If absent, subdomains inherit p=.
• np= sets policy for non-existent subdomains. RFC 9989 standardises this. If absent, it inherits p=.
• Use sp= to keep stricter control on the apex while giving project subdomains room to fix alignment. For example: p=reject; sp=quarantine.

Step 3: Publish the DMARC TXT record

What this does: you place a TXT record at _dmarc.<your-domain> that receivers will fetch. The only valid value is a single TXT record that begins with v=DMARC1.

If your DNS is with Hostworld

If your domain uses our nameservers (ns1.serverworld.uk to ns4.serverworld.uk), manage the zone in cPanel. Add a TXT record with the name _dmarc and the value shown below for the policy you want. If you prefer step-by-step help in your account, please open a support ticket.

If your DNS is elsewhere

Create a TXT record at the host name _dmarc under your domain. Many DNS portals need the relative name _dmarc, not the full FQDN. Check their help if in doubt.

Examples you can adapt

Monitoring only, aggregate reports to one address:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"

Monitoring to two addresses. Receivers should send to both:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:[email protected],mailto:[email protected]"

Move to quarantine, but test one-step-down during rollout. Relaxed alignment:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; t=y; adkim=r; aspf=r; rua=mailto:[email protected]"

Enforcement at the apex, softer on subdomains, strict alignment:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; sp=quarantine; adkim=s; aspf=s; rua=mailto:[email protected]"

Cover non-existent subdomains explicitly:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; np=reject; rua=mailto:[email protected]"

• Keep a single TXT record. Do not split DMARC across multiple TXT records at the same name.
• Begin with v=DMARC1. If it is not first, the record is ignored.
• Remember the mailto: prefix in rua= and ruf=.
• Within one rua= or ruf= value, separate multiple URIs with commas. If a comma or exclamation mark must appear inside a single URI, percent-encode it. For example: mailto:dmarc+uk%[email protected].

Step 4: Authorise external report collectors, if you use them

What this does: it allows receivers to send your DMARC reports to an address in someone else’s domain.

1. Decide the destination, for example rua=mailto:[email protected].
2. Ask the operator of reports.example.net to publish a TXT record that authorises your domain to send reports there. The required name is <your-domain>._report._dmarc.<reporting-domain> and it must include at least v=DMARC1. Wildcards are allowed on their side if they choose to use them.

Example authorisation that the reporting domain would host for you:

yourdomain.example._report._dmarc.reports.example.net. 3600 IN TXT "v=DMARC1"

• If that authorisation is missing, receivers will ignore the external address in your rua= or ruf=. Teams often mistake this for “no one is sending reports”.
• Changes to these authorisations follow DNS TTL.

Step 5: Verify the record from the command line

What this does: it confirms your record is visible and syntactically usable. It also catches the “more than one record” mistake.

Linux or macOS

Command: query the TXT records at _dmarc.<domain> with dig.

dig +short TXT _dmarc.example.com

What to look for: one TXT string that starts with "v=DMARC1;…". If you see more than one, consolidate them. If you see no output, check the name and the zone’s nameservers.

Windows

Command: use nslookup in interactive mode.

nslookup
set type=TXT
_dmarc.example.com

What to look for: the same single TXT response, beginning with v=DMARC1. If the record appears quoted across multiple lines, that is fine. What matters is that receivers assemble one DMARC policy from it.

Step 6: Read aggregate (RUA) reports

What this does: aggregate reports show, per receiver and per source IP, how your mail authenticated and how the receiver applied your policy. RFC 9990 defines the format. The XML uses the namespace urn:ietf:params:xml:ns:dmarc-2.0.

You will receive a compressed XML attachment at the rua= address. Unzip it and open the XML in a viewer or parser. Key elements to look for:

• report_metadata: who sent the report, a unique report_id, and the date_range.
• policy_published: the policy that receiver discovered and applied: p, sp, np, t, and alignment modes.
• record: one per source. Each contains:
  • row: source_ip and count, plus policy_evaluated with disposition and the dkim/spf pass or fail.
  • identifiers: the header From domain and any d= (for DKIM) or helo/return-path domains the receiver evaluated for alignment.
  • auth_results: per-method pass or fail details.

Minimal example, annotated:

<feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0">
  <report_metadata>
    <org_name>Receiver Ltd</org_name>
    <report_id>20260915-12345</report_id>
    <date_range><begin>1694736000</begin><end>1694822400</end></date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <p>quarantine</p><sp>none</sp><np>reject</np><t>n</t>
    <adkim>r</adkim><aspf>r</aspf>
  </policy_published>
  <record>
    <row>
      <source_ip>203.0.113.25</source_ip><count>54</count>
      <policy_evaluated><disposition>none</disposition><dkim>pass</dkim><spf>fail</spf></policy_evaluated>
    </row>
    <identifiers><header_from>example.com</header_from></identifiers>
    <auth_results><dkim><domain>example.com</domain><result>pass</result></dkim><spf><domain>mailer.example.net</domain><result>pass</result></spf></auth_results>
  </record>
</feedback>

How to use this data:

• Group by source_ip. Unknown IPs sending at volume merit investigation. Check if a supplier or a forwarder is involved.
• Check policy_evaluated. If dkim is pass and alignment is relaxed, SPF can fail without consequence. That is often fine. If both DKIM and SPF are failing alignment for your domain, find out why before moving to enforcement.
• Look at identifiers. They show which domains were evaluated for alignment. If your ESP uses d= on your domain, DKIM will align even if the return-path is their domain.
• Note policy_published. If you expected strict alignment but see adkim=r and aspf=r, that is the default. Tighten only after you confirm all legitimate sources align.
• Keep an eye on disposition. Under p=quarantine or p=reject, a high count of quarantine or reject dispositions on legitimate sources means you moved too far, too fast.

Step 7: Move to enforcement in stages

What this does: it reduces spoofing that uses your domain by telling receivers to quarantine or reject messages that fail alignment.

1. Run at p=none with rua= for long enough to see your normal traffic pattern. That might be a full business cycle. The exact timing is your call.
2. Fix obvious alignment issues. For each sender:
   • Ensure SPF includes the sending IP or host and that the visible From domain aligns with the SPF domain in relaxed mode.
   • Ensure at least one DKIM signature uses your domain in d= and passes. DKIM alignment often survives forwarding better than SPF.
   • Decide if you can move to strict alignment later. Some SaaS platforms cannot sign with your domain.
3. Switch to p=quarantine. Consider t=y for a short bedding-in phase, which will make receivers treat it as one step down while still reporting.
4. Review aggregate reports again. Address any legitimate traffic that is getting quarantined. Watch forwarders and mailing lists in particular.
5. When comfortable, move to p=reject. If subdomains are varied, you can keep sp=quarantine while the apex is at reject.

Example enforcement record with staged subdomain policy and test mode off:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; sp=quarantine; adkim=r; aspf=r; rua=mailto:[email protected]"

Step 8: Use failure (RUF) reports cautiously

What this does: per-message diagnostics that can include headers and sometimes content. RFC 9991 standardises them. Not all receivers send them even if you request them.

• Enable only if you have a clear reason to debug a problem. Treat the mailbox as sensitive.
• Example addition that asks for failure reports and sets failure options:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1"

• If ruf= points outside your domain, the same external reporting authorisation rules apply as for rua=.

Troubleshooting and gotchas

• No reports arriving: check you used mailto:, and check any external destination is authorised by the reporting domain. Receivers may still impose limits, but they should support at least two rua destinations.
• Legacy tags: pct, ri and rf are historic in RFC 9989. Do not rely on them. Use t=y for a one-step-down test.
• Multiple DMARC records: fix immediately. Receivers will ignore all of them until you have a single record.
• Strict alignment too soon: switching adkim=s/aspf=s without checking every sender can align will cause legitimate mail to fail under enforcement.
• Discovery mismatches: if a validator claims a different policy applies to a subdomain than a receiver’s report shows, remember that RFC 9989 uses a DNS tree walk for discovery, not the older Public Suffix List logic.

What next

If you run your own mail server on a VPS and want to test alignment end to end, see our VPS guides. If you need a machine to host your own mail stack, our Linux VPS line is available in Maidenhead and New York.

If you want help setting or reviewing your DMARC record in your Hostworld DNS zone, please open a support ticket from your account so we can look at the live record with you.

The next step in this playbook is: bring all legitimate senders into SPF/DKIM alignment so you can move from monitoring to enforcement with confidence.