Back to all tools
EMAIL · DMARC · EXTERNAL RESOLVER

DMARC Validator

Retrieve and parse the DMARC TXT record for any domain. Displays the policy (none/quarantine/reject), alignment mode, and reporting addresses.

~/pingie - dmarc-checker
ready

Provide a domain name to validate its DMARC record.

The toolkit

Every network tool you'll ever need.

Purpose-built utilities for ports, IPs, DNS and email. Completely free, all powered by external probes.

Free DMARC Checker: Validate Your Domain's Email Policy

DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It works as a DNS TXT record published at _dmarc.yourdomain.com that instructs receiving mail servers what to do when an incoming message fails SPF or DKIM checks. Without a valid DMARC record, your domain is open to spoofing, and you have no visibility into how your email is being handled by other servers.

This tool queries the _dmarc subdomain for any domain you enter, retrieves the raw TXT record, and validates every tag against the DMARC specification. You get a parsed breakdown of the policy, alignment modes, report URIs, and any errors or warnings in the configuration.

What the DMARC Validator Checks

When you run a dmarc lookup, the tool does more than confirm a record exists. It parses each tag and checks it against the specification rules. Here is what the results cover:

  • Record presence: Whether a TXT record exists at _dmarc.<domain> .
  • Version tag: The record must begin with v=DMARC1 . Anything else is invalid.
  • Policy (p): Must be none , quarantine , or reject . This is a required tag.
  • Subdomain policy (sp): The separate policy applied to subdomains, if specified.
  • Percentage (pct): An integer from 0 to 100 controlling what share of failing messages the policy applies to.
  • RUA and RUF URIs: The aggregate and forensic report addresses, validated for correct mailto: scheme format.
  • Alignment modes (aspf, adkim): Whether SPF and DKIM alignment is relaxed ( r ) or strict ( s ).
  • Failure reporting options (fo) and report interval (ri): Additional tags validated for correct values.

The tool also surfaces warnings for configurations that are technically valid but operationally weak, such as p=none (monitoring only, no enforcement) or a pct value below 100 (policy not applied to all failing messages).

How to Check a DMARC Record

  1. Open the DMARC Validator from the tool menu.
  2. Type or paste a domain name into the input field (for example, example.com ).
  3. Click Check . The tool sends a DNS query to _dmarc.example.com and retrieves the TXT record.
  4. Review the raw record, validity status, and the full list of parsed tags with their values.
  5. Read any errors or warnings to identify what needs fixing before moving to a stricter policy.

No account or login is required. The query runs server-side, so your browser does not need any special DNS access.

Understanding the Results

The parsed output maps each tag to a human-readable label. The most important field to check first is the policy tag. A value of none means receiving servers will take no action on failing mail; it is a monitoring-only state. A value of quarantine routes failing messages to spam, and reject tells the server to block them outright.

The pct tag is worth checking if you are doing a gradual rollout. Setting pct=10 applies the policy to only 10 percent of failing messages, which lets you test enforcement before committing fully. The tool warns you if this value is below 100, because it means a large share of spoofed mail can still reach inboxes.

RUA and RUF addresses tell you where DMARC reports are delivered. If these are missing, you will not receive the aggregate XML reports that show authentication pass and fail rates across all senders using your domain.

When to Run a DMARC Record Check

There are several situations where running a dmarc record checker is the right next step:

  • After publishing a new DMARC record to confirm it was written correctly and DNS has propagated.
  • Before escalating from p=none to quarantine or reject , to verify the record syntax is clean.
  • When troubleshooting deliverability issues to rule out a misconfigured or missing DMARC policy.
  • During a domain audit to check that all sending domains and subdomains have proper coverage.
  • After a domain transfer or DNS migration to confirm the record survived the move.

DMARC builds on SPF and DKIM. If you have not verified those records yet, use the DKIM checker alongside this tool to get a complete picture of your email authentication setup.

A Note on Policy Strength

A record with p=none is a valid DMARC record, but it offers no protection. It tells receiving servers to deliver the message regardless of whether SPF or DKIM passes. Its value is in the reports it generates, which show you who is sending mail on behalf of your domain and whether authentication is passing. Once you have reviewed those reports and confirmed your legitimate senders are aligned, moving to quarantine or reject is the step that actually blocks spoofed messages.

This tool flags a p=none record with a warning so you are not left thinking your domain is protected when it is not.

Sample DMARC Record

Here is an example of a well-formed DMARC record with enforcement enabled and reporting configured: 

v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-failures@example.com; aspf=r; adkim=r;

This record sets a quarantine policy for all failing messages, requests both aggregate and forensic reports, and uses relaxed alignment for both SPF and DKIM. Paste a record like this into the validator to see each tag parsed and checked individually.

FAQ

A DMARC record is a DNS TXT record published at the subdomain _dmarc.yourdomain.com . When a receiving mail server gets a message claiming to be from your domain, it queries that subdomain to find out what policy you have set. The record contains tags that define the policy action, alignment requirements, and where to send authentication reports. Without it, receiving servers have no DMARC instructions to follow.

After you enter a domain and click Check, the tool performs a DNS TXT lookup at _dmarc.<domain> from the server side. It retrieves the raw record string and then parses each semicolon-delimited tag. Every tag is checked against the DMARC specification: required tags are confirmed present, values are checked for valid options, and URI formats are verified. The output lists each parsed tag, its value, and any errors or warnings found.

These three values define what a receiving server does when a message fails both SPF and DKIM checks. With p=none , the server delivers the message normally and only sends a report. With p=quarantine , the server routes the failing message to the spam or junk folder. With p=reject , the server refuses the message entirely during the SMTP transaction, so it never reaches the recipient. Only quarantine and reject provide active protection against spoofing.

The pct tag tells receiving servers what percentage of failing messages the policy should apply to. Setting pct=10 means only 10 percent of messages that fail authentication will be quarantined or rejected; the other 90 percent are delivered as if the policy were none . This is useful for gradual rollout, but it also means most spoofed mail still gets through. The tool warns when pct is below 100 because enforcement is incomplete at that point.

A DMARC checker queries the _dmarc.<domain> DNS record and validates the policy, alignment settings, and report URIs. It tells you how your domain instructs receivers to handle authentication failures. A DKIM checker queries a selector-specific DNS record (for example, selector._domainkey.domain.com ) and validates the public key used to verify email signatures. DMARC sits above DKIM and SPF as the policy layer; DKIM is one of the authentication methods DMARC evaluates.

RUA is the aggregate report URI. Receiving servers send daily XML summaries to this address showing authentication pass and fail counts across all sources. RUF is the forensic report URI, which receives copies of individual failing messages or redacted headers, depending on the receiver's policy. RUA is the more widely supported and practically useful of the two. RUF support varies by receiving server and some providers do not send forensic reports at all. Including RUA is strongly recommended; RUF is optional.

Alignment refers to whether the domain in the From header matches the domain used for SPF or DKIM authentication. Relaxed alignment ( r ) allows a match between the From domain and an organizational parent domain, so mail.example.com aligns with example.com . Strict alignment ( s ) requires an exact domain match. If alignment fails for both SPF and DKIM, the message is treated as failing DMARC regardless of whether SPF or DKIM individually passed.

Yes. DMARC records are publicly accessible DNS records, so the tool can query any domain. This is useful when you want to check whether a vendor, partner, or sending service has DMARC configured before you start receiving mail from them, or when auditing domains during a security review. No special permissions or ownership of the domain are needed.

This means either no TXT record exists at _dmarc.<yourdomain> , or DNS propagation has not completed after a recent publish. DMARC records can take up to 48 hours to propagate globally, though most resolvers pick up changes within a few hours. If you recently added the record, wait and run the check again. If you have not published one yet, you will need to add a TXT record through your DNS provider before any policy takes effect.

No. DMARC is a policy layer that depends on SPF and DKIM being in place. It reads the results of those two checks and then applies the action you specified in your policy. A DMARC record alone, without at least one of SPF or DKIM configured and passing, will not protect your domain because there are no authentication results for DMARC to act on. You need all three working together for complete email authentication coverage. See the DKIM checker to verify that side of your setup.

The tool queries DNS for the domain you enter and returns the result. No account is required and no domain names are retained for marketing purposes. Standard server request logs may record the query as part of normal infrastructure operation, consistent with the site's privacy policy . Because DMARC records are public DNS data, there is no sensitive information involved in the lookup itself.

Yes. The tool exposes a GET endpoint at /api/check-dmarc?domain=<domain> . The response returns structured JSON fields including dmarc_found , dmarc_record , is_valid , policy , pct , rua , ruf , aspf , adkim , plus arrays for errors and warnings . This makes it straightforward to integrate DMARC validation into monitoring scripts, CI pipelines, or domain audit workflows without manual browser-based checks each time.