What is a DMARC Check?
A DMARC check reads the policy published in your DNS and confirms it is valid. Learn how SPF, DKIM and DMARC fit together and how to move to a stricter policy.
Updated
2 min read Email was designed in an era when nobody expected strangers to forge the sender's address, and that weakness still shows. Anyone can type a company's domain into the From line of a message. DMARC is the standard that lets a domain owner tell receiving mail servers what to do with messages that fail authentication. A DMARC check is the quick test that confirms this instruction is in place and written correctly.
If you are still asking what is DMARC and why it keeps coming up in conversations about email delivery, the short answer is that it connects two older checks, adds a policy on top and sends reports back to you.
The three pieces working together
- SPF (Sender Policy Framework) lists the servers allowed to send mail for your domain.
- DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each message so receivers can verify it was not altered.
- DMARC (Domain-based Message Authentication, Reporting and Conformance) checks that at least one of these passes and aligns with the visible From domain, then applies the policy you set.
What a DMARC check looks at
A checker queries your domain's DNS for a TXT record at the _dmarc subdomain and then examines it. Typical tests include:
- whether a record exists and whether there is only one;
- whether the syntax is valid, starting with the version tag v=DMARC1;
- which policy is set with the p tag and whether a separate subdomain policy is defined;
- where aggregate (rua) and forensic (ruf) reports are sent;
- whether report addresses on other domains have agreed to receive them, a step known as external destination verification.
Many tools also look up SPF and DKIM at the same time, since a flawless DMARC record achieves little if the underlying checks fail.
The three policy levels
| Policy | What receivers are asked to do | Typical use |
|---|---|---|
| p=none | Deliver as normal and send reports | Monitoring while you discover all your sending sources |
| p=quarantine | Treat failing mail as suspicious, often via the spam folder | A middle step once legitimate senders are aligned |
| p=reject | Refuse failing messages outright | Full protection against spoofing of your domain |
Large mailbox providers read these instructions and weigh them alongside their own filtering.
Why the record matters for a business
Without DMARC, criminals can send invoices, password-reset notices or payment requests that appear to come from your domain, and customers and staff have little way to tell the difference. A correctly enforced policy closes much of that door. It can also support deliverability, because receivers can see that your genuine messages are authenticated consistently.
The reports are a hidden bonus. They reveal every service sending mail as you, such as newsletter platforms, invoicing tools and help desks, which often uncovers forgotten systems that still need SPF or DKIM set up.
A sensible rollout
Start with p=none and collect reports for a few weeks. Fix any legitimate senders that fail, then move to quarantine, possibly applying it to a portion of mail first with the pct tag. When the reports look clean, step up to reject. Run a DMARC check after every DNS change, because a single typo can quietly disable the whole policy.
What is new in each topic
DrawerTechnology
