DMARC configuration, policy and reporting

1. DMARC Configuration block overview

This row in your DNSprobe report confirms that a DMARC record was found, shows its raw value and provides a short textual summary of the main settings.

Why this matters

A valid DMARC record is now expected by many major mailbox providers. It helps protect your brand from spoofing and gives you visibility on who is sending mail using your domain.

How to read this block

Check that the hostname is _dmarc.yourdomain, that the value begins with v=DMARC1 and that the high-level policy (none, quarantine or reject) matches your intentions. DNSprobe also displays your “real” DMARC once defaults are applied.

Best practices at a glance

• Publish exactly one DMARC record per domain, at the _dmarc host.
• Move gradually from p=none (monitoring) to p=quarantine or p=reject once SPF and DKIM are correctly configured.
• Keep the record readable so you can review it quickly in tools like DNSprobe.

2. Policy summary (p, sp, pct, alignment)

The Policy summary block in your DNSprobe report answers three questions: what happens to failing messages, what happens for subdomains, and what percentage of traffic is subject to the policy.

Why the policy matters

These settings control how aggressively receivers should treat messages that do not align with your SPF or DKIM, both for the main domain and for its subdomains.

How DNSprobe interprets the policy

DNSprobe reads the p, sp and pct tags and translates them into a short, human-friendly description such as “Policy: reject; Subdomain policy: reject; Percentage applied: 100%”.

Best practices for DMARC policy

• Start with p=none and pct=100 to collect reports without impacting delivery.
• When you are confident that SPF and DKIM are aligned, move to p=quarantine, then eventually p=reject.
• Use sp only if you need a different policy for subdomains; otherwise let them inherit the main policy.

3. Reporting settings (rua, ruf, fo, ri, rf)

The Report settings part of the block tells you where aggregate reports (rua) and forensic reports (ruf) are sent and how often they are expected.

Why DMARC reports are useful

Aggregate reports help you understand which IPs and providers are sending mail for your domain and how often messages fail authentication. Forensic reports can provide detailed samples of failed messages.

How DNSprobe displays reporting configuration

DNSprobe lists your rua and ruf mailto: addresses, the chosen fo options and the ri interval, and highlights when no reports will be sent because the corresponding tags are missing.

Best practices for DMARC reporting

• Always configure at least one rua address that points to a mailbox or DMARC analysis service you control.
• Use fo=1 if you want more detailed failure visibility, but be prepared for additional report volume.
• Request ruf reports only if you have a clear need and can handle the privacy and data-protection implications.

4. Parsed DMARC tags in the report

The Parsed DMARC tags table in DNSprobe shows each tag, its raw value and a short description so you can quickly verify that every parameter is set as intended.

How DNSprobe builds the parsed tags table

After parsing the DMARC string, DNSprobe normalises missing tags to their defaults and displays a three-column table with Tag, Value and Description for v, p, sp, rua, ruf, fo, pct, adkim, aspf, ri and rf.

How to use this table effectively

• Scan for unexpected defaults, such as relaxed alignment or pct lower than 100%.
• Confirm that your report URIs and alignment modes match your DMARC deployment plan.
• Compare the parsed table with your DNS provider’s interface to detect typos or truncated values.

5. DMARC tags and possible values

This reference table summarises all common DMARC tags, whether they are required, what they control, which values are valid and what happens when they are omitted.

Not all receivers implement every reporting option, but keeping your DMARC tags within these supported values ensures broad compatibility.

A complete DMARC record might look like:
v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected]; ruf=none; fo=0; pct=100; adkim=s; aspf=s; ri=604800; rf=afrf;

In its simplest form, a DMARC record can be:
v=DMARC1; p=none

6. Quick interpretation guide

This section adds the practical checks you typically get in DMARC inspector tools: validity, defaults, alignment, subdomain behaviour, reporting and common mistakes.

1) Record validity and correct DNS placement

DMARC must be published as a TXT record on the _dmarc host of the domain you want to protect. If the record is malformed, many receivers ignore it entirely.

• Hostname should be: _dmarc.yourdomain
• The value must start with: v=DMARC1 (and it must be first).
• Publish only one DMARC record per domain (multiple records often invalidate DMARC).

Example record:

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

Keep the string readable (clear separators, consistent formatting). It makes typos much easier to spot.

2) Policy behaviour: p, sp and pct

These tags define what receivers should do when a message fails DMARC (authentication + alignment), and whether that behaviour applies to subdomains and all traffic.

• p=none: monitoring only (no enforcement).
• p=quarantine: treat failing mail as suspicious (often spam/junk).
• p=reject: reject failing mail at the receiver.
• pct controls the enforcement percentage (mostly relevant for quarantine/reject).

3) Alignment: adkim and aspf (relaxed vs strict)

Alignment answers a simple question: does the domain that authenticated match the domain visible to the user in the From: header? Relaxed allows an organisational match; strict requires an exact match.

• adkim controls DKIM alignment (the DKIM d= domain vs From:).
• aspf controls SPF alignment (MailFrom/Return-Path domain vs From:).

In practice, relaxed alignment is common. Strict alignment can be useful for tighter control but requires disciplined sending infrastructure.

4) Subdomains and organisational domain behaviour

DMARC is evaluated on the exact domain in the visible From:. If that exact domain has no DMARC record, receivers may apply the organisational domain’s DMARC record instead, depending on the public suffix rules.

• sp sets a dedicated policy for subdomains; if omitted, subdomains inherit p.
• If you send from subdomains (news.yourdomain, billing.yourdomain), plan them as part of your DMARC rollout.
• Be consistent: avoid accidental “shadow” policies across subdomains unless you really mean it.

5) Reporting: rua, ruf, fo, ri and rf

Reporting tags control where aggregate reports (rua) and (optionally) forensic/failure reports (ruf) are sent, and what level of detail is requested.

• rua: aggregate reports (usually the most valuable and widely supported).
• ruf + fo: forensic/failure reporting (implementation varies; can raise privacy/volume concerns).
• ri: requested interval in seconds, but many receivers still send at most daily.

6) External report addresses: required DNS authorisation

When your rua/ruf points to a different domain (for example, a DMARC analytics provider), that destination domain typically needs an authorisation TXT record. Without it, some receivers will refuse to send reports to that external address.

Example authorisation record:

example.org._report._dmarc.sample.net TXT "v=DMARC1;"

Your DMARC provider usually tells you the exact hostname/value to publish for external destination verification.

7) Common mistakes to avoid

Most DMARC issues come from small DNS or syntax mistakes. Here are the ones worth checking first:

• Publishing more than one DMARC TXT record at _dmarc (can invalidate DMARC).
• v=DMARC1 not first, or written with the wrong casing.
• Missing semicolons or accidental extra separators that break parsing.
• Using report addresses you don’t control (or forgetting external authorisation).
• Moving to reject before all legitimate senders have aligned SPF/DKIM.

7. Test DMARC records manually from your own terminal

The DMARC section in DNSprobe reads the TXT record at _dmarc.yourdomain and parses tags such as policy (p), subdomain policy (sp), reporting addresses (rua/ruf) and alignment modes (adkim/aspf). You can inspect the raw DMARC record yourself from a terminal by querying the TXT record on the _dmarc subdomain.

Linux: using dig (BIND utilities)

On most Linux distributions, the dig command is provided by the BIND utilities package. The commands below query the DMARC TXT record for your domain and then focus on the line that starts with v=DMARC1:

                dig _dmarc.example.com TXT
                dig _dmarc.example.com TXT +short
    
                # Optional: filter TXT records to show only the DMARC policy (the line starting with v=DMARC1)    
                dig _dmarc.example.com TXT | grep "v=DMARC1"
        

macOS: using dig from the built-in tools

macOS ships with dig as part of its standard command-line tools. Open Terminal and run the same commands as on Linux to list the DMARC TXT record and isolate the policy line that begins with v=DMARC1:

                dig _dmarc.example.com TXT
                dig _dmarc.example.com TXT +short
    
                # Optional: filter TXT records to show only the DMARC policy (the line starting with v=DMARC1)    
                dig _dmarc.example.com TXT | grep "v=DMARC1"
        

Windows: using nslookup

On Windows, the legacy nslookup tool can query TXT records on the _dmarc subdomain. From a Command Prompt or PowerShell window, you can retrieve the main DMARC policy and, if needed, test a delegated DMARC record on a subdomain:

                nslookup -type=TXT _dmarc.example.com
    
                REM Optional: query a subdomain-specific DMARC record such as _dmarc.sub.example.com if you override the policy there    
                nslookup -type=TXT _dmarc.sub.example.com
        

Important: only query DMARC records for domains that you own or are authorised to analyse. Repeated automated lookups against third-party domains without permission may be treated as abusive traffic by some providers.