DMARC Record Checker

DMARC is the TXT record at _dmarc.yourdomain.com that tells inbox providers what to do with messages that fail SPF or DKIM checks. Setting the wrong policy can block legitimate mail; missing the record entirely leaves you wide open to spoofing. This checker queries the record and presents each tag in a readable table, so you can review the policy yourself.

How to check a DMARC record

  1. 1

    Enter the domain

    Type the root domain, e.g. `example.com`. The tool queries `_dmarc.example.com` for the TXT record.

  2. 2

    Review tag by tag

    Each DMARC tag found in the record (v, p, sp, adkim, aspf, pct, rua, ruf, fo) is shown with its value.

  3. 3

    Review the policy

    Look at the `p` tag to see whether the policy is `none`, `quarantine` or `reject`, and check `pct`, `rua` and the alignment tags against the recommendations below.

  4. 4

    Verify your record

    Compare the raw record with what your DNS provider publishes to confirm the policy is exactly what you intend.

DMARC tags at a glance

Tag Meaning Typical value
v Version, always DMARC1 v=DMARC1
p Policy for failing mail none, quarantine, reject
sp Policy for subdomains inherits p by default
pct Percentage of mail the policy applies to 1-100, default 100
adkim DKIM alignment mode r (relaxed) or s (strict)
aspf SPF alignment mode r (relaxed) or s (strict)
rua Aggregate report address mailto:dmarc@...
ruf Forensic report address mailto:forensic@...
fo Forensic options 0, 1, d, s
ri Reporting interval in seconds default 86400 (one day)

Rollout path

Go live in three stages, not one jump:

  1. p=none with rua set. Collect reports for 4-6 weeks, identify legitimate senders that fail SPF/DKIM alignment.
  2. p=quarantine; pct=25. Tighten gradually: 25, 50, 75, 100 percent over a few weeks.
  3. p=reject. Full enforcement. Spoofed mail is rejected at the receiving MTA.

Never start at p=reject without reports: you will find out which legitimate senders you broke by watching support tickets.

Common DMARC misconfigurations

  • Missing rua. You have a policy but no way to learn what it is rejecting.
  • pct below 100 with p=reject. Semantically odd; mixing reject with partial application causes confusion at receivers.
  • Trailing semicolon or missing v=DMARC1. Syntax errors make the record invisible to parsers.
  • Report addresses on other domains without the matching _report._dmarc authorization record on the destination domain.
  • Multiple DMARC records on the same domain. Only one is allowed; receivers treat duplicates as an error and default to p=none.

Interpreting reports

Aggregate reports are XML files delivered daily to your rua address. Tools like MxToolbox, Postmark, Valimail and Dmarcian parse them into dashboards. Forensic reports (ruf) are per-message copies that help debug specific failures but are disabled by many ISPs for privacy reasons.

Frequently Asked Questions

SPF authorizes which servers can send for your domain; DKIM cryptographically signs outgoing mail. DMARC ties the two together: it tells receivers what to do when both SPF and DKIM fail and provides a reporting mechanism. You need all three for modern deliverability.

DMARC protects the envelope domain but not display names. An attacker sending “Example Corp attacker@gmail.com” is not impersonating your domain, just your brand. Display-name spoofing is blocked at the receiver by other filters, not DMARC.

Yes, but remember to cover all sending sources: marketing platforms, transactional senders, help desks, calendar invites. Every source needs to be aligned via SPF or DKIM for DMARC to pass.

The lookup is a public DNS query and is cached briefly to reduce load. The domain name is not stored long-term and no user identifier is attached to the query.

Related Tools

Tool available in other languages