DMARC is a short text record in your domain’s DNS that tells mail providers what to do with email that claims to come from your domain but can’t prove it. Without it, anyone can send messages that appear to be from your address, and receivers have to guess whether to trust them. The checker above reads your DMARC record live, explains each part, flags problems and gives you a corrected record you can paste straight into your DNS settings.

What DMARC Does

DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It builds on two older checks. SPF lists the servers allowed to send mail for your domain, and DKIM adds a digital signature to each message. DMARC ties them to the address people actually see in the From line.

A message passes DMARC when SPF or DKIM passes and the domain it checked matches the domain in the From address. That matching step, called alignment, is what stops a scammer from passing SPF with their own domain while putting yours in the From line. DMARC then tells the receiving server what to do with mail that fails, and where to send reports about it.

How to Read Your Result

The headline in the result sums up how well the domain is protected:

• Protected: the policy is reject, so mail that fails DMARC is refused before anyone sees it
• Partly protected: the policy is quarantine, so failing mail is delivered to spam rather than the inbox
• Monitoring only: the policy is none, so failing mail is still delivered and the record only collects reports
• No DMARC record: receivers have no instructions at all for mail that fakes your domain
• Broken: the record has an error serious enough that receivers may ignore it, such as two records at once or a missing policy

Under the headline, What to Fix lists each problem in order of importance, red first. When a better record exists, the checker builds it for you and shows the exact type, host and value to enter at your DNS provider.

The Three Policies: None, Quarantine and Reject

The policy tag, p, is the heart of the record. A policy of none asks receivers to deliver everything as usual and send you reports. It is the right place to start, because it lets you see every service that sends mail as your domain before anything is blocked.

A policy of quarantine asks receivers to put failing mail in the spam or junk folder. A policy of reject asks them to refuse it outright. Reject is the goal for most domains, since it is the only setting that actually stops spoofed mail from reaching people. The usual path is none for a few weeks while you fix any of your own services that fail, then quarantine, then reject.

What Each Tag Means

A DMARC record is a list of tags separated by semicolons. Only two are required, but a few others matter a great deal in practice:

• Version (v=DMARC1): marks the record as DMARC and must come first, written exactly this way
• Policy (p): the policy for your main domain, set to none, quarantine or reject
• Report address (rua): the address that receives daily summary reports, usually a mailbox you own or a report service
• Subdomain policy (sp): a separate policy for subdomains, if you want them treated differently from the main domain
• Unused subdomain policy (np): a policy for subdomains that don’t exist, which stops scammers from sending from made-up subdomains
• Alignment (adkim and aspf): whether alignment is relaxed, which allows your subdomains to match, or strict, which requires an exact match
• Testing (t): a flag that asks receivers to apply one step softer than your policy while you check the results

The checker explains every tag in your record in the What Each Part Means section, including any it doesn’t recognize.

How to Set Up DMARC

Setting up DMARC takes a few minutes in your DNS settings, plus some patience while reports come in.

First, make sure SPF and DKIM are in place for every service that sends mail as your domain, including your email host, newsletter tool, help desk and billing system. Then add a TXT record with the host or name _dmarc and a value such as v=DMARC1; p=none; rua=mailto: followed by an address where you want reports. Some DNS providers want the full name, _dmarc followed by your domain, instead of just _dmarc.

Leave the policy at none for two to four weeks and read the reports. When every service you use passes, change the policy to quarantine, wait another week or two, and then move to reject. Run the checker after each change to confirm the new record is live.

Reading DMARC Reports

Aggregate reports arrive as compressed XML files, usually once a day from each large mail provider. Each one lists the servers that sent mail using your domain, how many messages each sent, and whether they passed SPF, DKIM and alignment.

The files are hard to read by hand, so most people send them to a DMARC report service that turns them into charts. When the report address is on a different domain from yours, that domain has to publish a small permission record agreeing to receive your reports. Report services set this up for you, and the checker warns you when it’s missing.

Common DMARC Mistakes

A handful of errors account for most broken setups, and the checker looks for all of them:

• Publishing two DMARC records, which makes receivers ignore DMARC for the domain entirely
• Staying at p=none for years, which collects reports but never stops a spoofed message
• Having no rua address, so there are no reports and no safe way to tighten the policy
• Setting sp=none, which leaves every subdomain open even when the main domain is protected
• Putting an SPF record at _dmarc instead of on the domain itself
• Having more than one SPF record on the domain, which makes SPF fail for all of your mail

What Changed in the 2026 DMARC Standard

DMARC was first published as RFC 7489 in 2015. In 2026 it was replaced by a new set of standards: RFC 9989 for DMARC itself, RFC 9990 for aggregate reports and RFC 9991 for failure reports. Existing records keep working, and the version tag is still v=DMARC1.

A few tags changed. The pct tag, which applied the policy to only a percentage of failing mail, is no longer part of the standard, and the new t tag replaces it for testing. The rf and ri tags were also retired. The np tag for subdomains that don’t exist was added, along with a psd tag meant for registries and other public suffixes rather than ordinary domains. The checker flags the retired tags and leaves them out of any record it suggests.

Who Needs DMARC Now

Every domain that sends email should have DMARC, and large mail providers now require it from bulk senders. Google and Yahoo began requiring SPF, DKIM and a DMARC record of at least p=none in 2024 for senders of about 5,000 or more messages a day to their users. Microsoft followed on May 5, 2025 for mail to Outlook.com, Hotmail and Live addresses, and rejects bulk mail that doesn’t meet the rules.

Smaller senders aren’t held to the same thresholds, but the same checks increasingly decide whether their mail reaches the inbox. A correct DMARC record is also what lets the receiver tell your real invoices and password resets apart from fakes.

Domains That Don’t Send Email

Parked domains and domains you hold for a future project are easy targets, because no one is watching them. If a domain never sends mail, protect it with two records: an SPF record of v=spf1 -all on the domain, which says no server may send for it, and a DMARC record with p=reject. The checker spots these domains and suggests reject straight away, since there is no legitimate mail to break.

The checker reads records through public DNS, so it sees what mail providers see. If you just made a change and the result looks old, wait a few minutes and check again. DNS updates can take a few minutes to a few hours to appear everywhere.