DMARC Record Checker

What is DMARC?

DMARC is a DNS record that works with SPF and DKIM. It tells email providers what to do when mail from your domain fails checks, and also where to send reports back. You add it as a TXT record on _dmarc.yourdomain.com, and the usual starting version has p=none so nothing gets blocked yet—just monitored. The rua part points to an email address that gets the summary reports—for example mailto:dmarc@mailapi.tech when you route reports through mailapi.tech.

Why DMARC matters

It matters because without this policy, spoofed messages can still land in inboxes even if you have the other records set up. Once you move to quarantine or reject, the big providers get clear instructions, and that cuts down on phishing that pretends to be from you. Reports also give a list of who is actually sending as your domain, which helps when marketing or billing teams use separate tools and you did not know about it.

What a DMARC record looks like

DMARC is a TXT record at _dmarc.yourdomain.com. Tags are separated by semicolons and always start with v=DMARC1.

Here is a common Mails.now monitoring record:

v=DMARC1; p=none; rua=mailto:dmarc@mailapi.tech

Real DMARC record examples

Publish exactly one DMARC TXT record at _dmarc. Start with monitoring, then tighten the policy as reports look clean.

How to check DMARC on this site

Use the checker at the top of this page to look up _dmarc.yourdomain.com, parse tags, and get policy guidance.

1. Scroll to the DMARC Record Checker form at the top of this page.
2. Enter your domain in the Domain Name field (for example, mailapi.tech or a domain that sends through Mails.now).
3. Click Check DMARC Record.
4. Confirm the lookup host shown in the report is _dmarc. plus your domain.
5. Review the raw record, parsed tags (policy, rua, pct, alignment), status badge, and recommendations.
6. Update DNS if needed, wait for propagation, then run the check again before tightening policy.

How DMARC works

1. The receiver checks SPF and DKIM for the message.
2. It sees whether at least one passed and aligns with the visible From domain.
3. Alignment can be relaxed or strict, based on your aspf and adkim tags.
4. If authentication fails, the policy applies to the percentage set by pct.
5. Aggregate reports are sent to addresses listed in rua.

DMARC policy explained: none vs quarantine vs reject

Common DMARC mistakes

1. Having no DMARC record at all.
2. Leaving p=none forever without reviewing reports.
3. Publishing two DMARC records on the same _dmarc host.
4. Forgetting the rua address so you never see what is happening.
5. Jumping to reject before every legitimate sender passes SPF or DKIM.

DMARC for popular providers and rollout

For services like Mails.now (mailapi.tech), Google Workspace, or Microsoft 365, you still publish the record yourself after making sure their SPF and DKIM are active. Transactional tools need their includes and keys added first.

1. Start with p=none and a working rua address (for example mailto:dmarc@mailapi.tech).
2. Review aggregate reports and fix missing senders.
3. Move to quarantine at a low pct, then raise it to 100.
4. Switch to reject once legitimate mail stays clean.
5. Keep a way to roll policy back quickly if something breaks.

Subdomains, reports, and DNS timing

Subdomains can be a weak spot if you leave old ones sitting around. An sp= tag on the main record or separate entries for them reduces that. Reports come in XML, so some people send them to a service that makes charts instead of reading raw files. It is good to check the record again after any provider change, because DNS can take a day or two to settle.

Reading DMARC tags and best practices

1. Use pct to apply policy to part of traffic while testing.
2. Keep aspf and adkim relaxed unless you need strict alignment.
3. Watch reports during every policy change.
4. Tell other teams before you move to reject so nobody adds a new sender the same week.

Frequently asked questions