DMARC Lookup

A DMARC record is a DNS TXT entry published on your domain (specifically at _dmarc.yourdomain.com) that tells receiving mail servers how to handle messages that fail email authentication checks. DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It builds on two existing authentication mechanisms — SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) — by adding a policy layer and a reporting mechanism.

When you publish a DMARC record, you're telling the world three things: how strictly to check emails claiming to be from your domain, what to do with emails that fail those checks (monitor, quarantine, or reject), and where to send reports about authentication results. Those reports — called DMARC aggregate reports (RUA) — are the raw data that tools like Viewleaf parse and visualize so you can actually understand what's happening with your domain's email.

Running a DMARC record check is the fastest way to confirm your domain's email authentication is configured correctly. Misconfigurations are common and often invisible — your emails might be silently landing in spam, or your domain could be vulnerable to spoofing, without any obvious symptoms.

Since February 2024, Google and Yahoo require DMARC records for domains sending bulk email. Without a valid record, your messages may be rejected outright or routed to spam. Even if you're not a bulk sender, any domain without DMARC is an easier target for phishing attacks that impersonate your brand. A quick lookup tells you whether your record exists, whether the syntax is valid, what policy you're enforcing, and where your aggregate reports are being sent. For a step-by-step walkthrough of verifying all three records, see our email authentication verification guide.

A DMARC record is a single line of text made up of tag-value pairs separated by semicolons. Here's what the most common tags mean:

v=DMARC1 — The version tag. This must be present and must be "DMARC1" for the record to be valid.

p= — The policy tag, which is the most important setting. It tells receiving servers what to do with messages that fail authentication: none means take no action (monitor only), quarantine means send to spam, and reject means block the message entirely.

rua= — The aggregate report address. This is where receiving servers send daily XML reports about authentication results for your domain. This is the data that DMARC monitoring tools like Viewleaf process and visualize for you.

ruf= — The forensic report address. These are more detailed failure reports sent for individual messages, though many providers no longer send them due to privacy concerns.

pct= — The percentage of messages the policy applies to. Useful for gradual rollouts — for example, pct=10 applies your policy to only 10% of failing messages.

adkim= and aspf= — Alignment modes for DKIM and SPF. These can be r (relaxed, the default) or s (strict). Strict alignment requires an exact domain match; relaxed allows subdomains to pass.

sp= — The subdomain policy, if you want subdomains handled differently from your main domain.

If this lookup tool shows no DMARC record for your domain, it means receiving mail servers have no instructions for how to handle authentication failures from your domain. In practice, this means two things: your domain is more vulnerable to being spoofed in phishing attacks, and you're not receiving any reports about who is sending email on your behalf.

The fix is straightforward. Add a TXT record to your DNS at _dmarc.yourdomain.com with a value like:

v=DMARC1; p=none; rua=mailto:your-rua-address@example.com

Starting with p=none is recommended — it enables monitoring without affecting email delivery, so you can see what's happening before enforcing a stricter policy. The rua address is where aggregate reports get sent. If you sign up for Viewleaf, you'll get a dedicated collector address to use here, and reports will be parsed and visualized automatically — no need to read raw XML.

Even domains with a DMARC record in place often have configuration issues that undermine its effectiveness:

Staying on p=none indefinitely. A monitoring-only policy is a good starting point, but it doesn't actually protect your domain. Once you've confirmed your legitimate email sources are passing authentication, you should move to quarantine or reject. Many domains set p=none and never revisit it.

Missing or incorrect rua address. If the rua tag is missing or points to an address that isn't configured to receive reports, you're flying blind. You won't know who's sending email as your domain or whether your authentication is working. This is the most common reason people think DMARC "isn't doing anything."

SPF or DKIM not aligned. DMARC requires that at least one of SPF or DKIM passes and aligns with the From domain. A common mistake is having SPF configured for one domain but sending email from a subdomain (or vice versa), causing alignment failures even though SPF technically passes.

Forgetting about subdomains. Without an sp= tag, subdomains inherit the parent domain's policy. If you have subdomains that send email differently, you may need separate handling. Conversely, attackers often spoof subdomains specifically because the parent domain's DMARC doesn't cover them.

Not monitoring reports. Publishing a DMARC record is only the first step. The real value comes from reading the aggregate reports it generates. These reports reveal unauthorized senders, misconfigured services, and alignment issues — but only if you're actually collecting and reviewing them. Tools like Viewleaf exist specifically to make this data accessible without parsing XML by hand.

You should verify your DMARC record whenever you make DNS changes, add a new email sending service (like a marketing platform, CRM, or transactional email provider), or notice deliverability issues. Beyond that, continuous monitoring through DMARC aggregate reports is more valuable than periodic lookups — the reports tell you in near-real-time whether your authentication is passing or failing across all receiving servers, not just what your DNS currently says. For a step-by-step verification and troubleshooting checklist, see our email authentication verification guide.