DMARC Record Checker

What is a DMARC Checker?

A DMARC checker is a free online tool that performs a live DNS lookup for a domain's DMARC TXT record, then validates its syntax, parses every tag, and returns a structured analysis of the configuration. Rather than manually decoding a raw TXT string, the checker presents each tag with its value, highlights errors and warnings, and recommends improvements — all in seconds.

DMARC (Domain-based Message Authentication, Reporting & Conformance) records live at _dmarc.yourdomain.com and tell receiving mail servers how to handle messages that fail SPF or DKIM authentication checks. When a domain has no DMARC record, or a misconfigured one, attackers can spoof the domain in phishing campaigns — and the domain owner has no visibility into it.

If you don't have a DMARC record yet, use our free DMARC generator to create one in seconds. Once it's published, come back here to verify it's correct.

The Warmbase DMARC checker goes beyond a basic lookup by providing:

• Full tag parsing (v, p, rua, ruf, adkim, aspf, pct, sp, fo)
• Syntax error detection with clear explanations
• Best-practice warnings for weak or incomplete configurations
• A policy strength score (0–100) to prioritize improvements
• SPF and DKIM detection alongside DMARC results
• Actionable recommendations specific to your domain's configuration

How DMARC Works

When a mail server receives an inbound email, it runs two independent authentication checks:

1. SPF check — the receiving server looks up the SPF TXT record for the sending domain and verifies the sending IP address is authorised. SPF only evaluates the envelope sender (also called the Return-Path or MailFrom address), not the visible From header.
2. DKIM check — the receiving server retrieves the public DKIM key from DNS and uses it to verify the digital signature attached to the message headers. A valid DKIM signature proves the message was not altered after signing and was sent by an authorised party.

DMARC adds a third layer on top of these two checks: identifier alignment. For DMARC to pass, at least one of SPF or DKIM must both pass and the authenticated domain must align with the visible From: header domain (either as an exact match in strict mode, or as a parent/subdomain match in relaxed mode).

If alignment fails, the receiving server consults your DMARC record to decide what to do — monitor only (p=none), send to spam (p=quarantine), or block entirely (p=reject). The server also sends a daily XML aggregate report to your rua= address detailing every message sent using your domain.

This combination makes DMARC the only email authentication standard that closes the loop between authentication results and domain owner visibility.

How to Check a DMARC Record

Using the Warmbase DMARC checker above takes under 30 seconds:

1. Enter the domain — type the root domain (e.g. example.com) in the input field. No need to add www, https, or the _dmarc prefix — the tool handles the lookup automatically.
2. Click "Check DMARC Record" — the tool performs a live DNS TXT lookup against _dmarc.yourdomain.com.
3. Review the results — the checker displays the raw DMARC record, all parsed tags, a policy strength score, any errors or warnings, and specific recommendations.
4. Check the authentication summary — the SPF and DKIM detection panels show whether those records are also in place for the domain.

If you prefer to check manually via command line, you can use:

Or on Windows:

Both commands return the raw DMARC record string. The Warmbase checker saves you the manual parsing step and provides immediate expert analysis. If the checker finds no record, use our free DMARC record generator to build a valid record instantly.

Why DMARC Matters for Email Security and Deliverability

Email is the most impersonated communication channel in the world. Without DMARC, any attacker can send emails that appear to come from your domain — and recipients have no reliable way to know the message is fraudulent. DMARC solves this by giving domain owners full control and visibility over their email channel.

The consequences of operating without DMARC include:

• Domain spoofing — criminals can impersonate your domain in phishing attacks, business email compromise (BEC), or malware distribution campaigns targeting your customers and partners.
• Brand damage — when fraudulent emails appear to come from your domain, every recipient who is deceived damages trust in your brand — even though you were not the sender.
• Reduced deliverability — major providers including Google and Yahoo now require DMARC for bulk senders. Domains without DMARC are increasingly rate-limited, spam-filtered, or blocked.
• No visibility — without aggregate reports (rua=), you have no way of knowing who is sending email on behalf of your domain, or whether your own legitimate mail is passing authentication.

DMARC at p=reject effectively eliminates exact-domain spoofing. Combined with regular monitoring of aggregate reports and a mature SPF and DKIM setup, it is one of the highest-ROI security configurations any organisation can deploy.

DMARC Policy Explained: none, quarantine, reject

The p= tag is the most important field in any DMARC record. It tells receiving mail servers how to handle messages that fail DMARC checks. There are three values:

The recommended migration path is: p=none → p=quarantine → p=reject. Spend at least 2–4 weeks at each stage reviewing aggregate reports before advancing. Jumping directly to p=reject without reviewing reports can accidentally block legitimate business email.

DMARC Syntax Explained: All Tags Reference

A DMARC record is a DNS TXT record published at _dmarc.yourdomain.com. It consists of semicolon-separated tag=value pairs. The record must start with v=DMARC1.

Common DMARC Mistakes

These are the most frequent DMARC configuration errors found across millions of domains:

How to Fix DMARC Errors

Once you identify a DMARC problem using this checker, here is how to fix each common error:

1. No DMARC record found — Use our free DMARC generator to build a valid record, then log in to your DNS provider and add a TXT record with host _dmarc. Allow up to 48 hours for propagation, then re-check here.
2. Invalid syntax — the most common syntax errors are a missing semicolon between tags, spaces around the = sign, or an invalid p= value. Edit the TXT record carefully. Each tag must be in the format tag=value; with semicolons between pairs.
3. Missing p= tag — the p tag is required. Add p=none as a minimum. Without it, the DMARC record is invalid and will be ignored by receiving servers.
4. Malformed rua= address — the rua tag must use the format mailto:email@domain.com. A common error is entering just an email address without the mailto: prefix.
5. Duplicate records — in your DNS provider, search for all TXT records at _dmarc.yourdomain.com and delete all but one. Keep the most complete record.
6. pct below 100 — in your DNS TXT record, change pct= to pct=100 to ensure 100% of messages are subject to the DMARC policy.

After making any DNS change, use this DMARC checker again to confirm the record is live and valid. DNS propagation normally takes 15 minutes to a few hours, occasionally up to 48 hours.

DMARC for Google Workspace

Google Workspace fully supports DMARC, SPF, and DKIM. As of February 2024, Google requires all bulk senders (5,000+ messages/day to Gmail) to have a valid DMARC record with at least p=none. Failing to comply results in messages being rate-limited, spam-filtered, or rejected by Gmail.

To configure DMARC correctly for Google Workspace:

1. Verify DKIM is enabled — in Google Admin, go to Apps → Google Workspace → Gmail → Authenticate Email. If DKIM signing is not enabled, turn it on and add the DKIM TXT record to your DNS before publishing DMARC.
2. Verify SPF is set — add v=spf1 include:_spf.google.com ~all as a TXT record on your root domain if it is not already present.
3. Publish a DMARC record — add a TXT record at _dmarc.yourdomain.com with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
4. Review aggregate reports — after 2–4 weeks, confirm all legitimate mail is passing, then advance to p=quarantine and eventually p=reject.

Google signs with your exact domain via DKIM, so strict alignment (adkim=s) is achievable for Workspace customers and is recommended for maximum protection.

DMARC for Cold Email Outreach

Cold email senders face unique DMARC considerations. Unlike transactional or marketing mail, cold outreach operates at high volume across many sending domains and inboxes. Here is how DMARC fits into a cold email infrastructure:

• Use dedicated sending domains — never send cold email from your primary business domain. Use dedicated sending domains (e.g. try-yourcompany.com, yourbrand-mail.com). Each domain needs its own DMARC, SPF, and DKIM setup.
• Start with p=none — cold email sending domains are new and actively warming up, so use p=none with rua= to monitor without risking email blocking during the warm-up phase.
• Use relaxed alignment — many cold email platforms (Instantly, Smartlead, custom SMTP) sign with subdomains or third-party domains. Use adkim=r; aspf=r to avoid alignment failures.
• Still publish DMARC on parked domains — any domain you own but do not actively send from should have v=DMARC1; p=reject; to prevent spoofing.
• Warm up inboxes before sending — DMARC is necessary but not sufficient. Inbox placement depends on sender reputation built through consistent inbox-to-inbox engagement. Warmbase automates this process, building the reputation your sending domains need to land in the inbox.

The combination of correct DMARC, SPF, and DKIM authentication plus a warmed-up sender reputation is the baseline for effective cold email deliverability in 2025 and beyond.

DMARC Monitoring Best Practices

Publishing a DMARC record is just the beginning. Ongoing monitoring is essential to catch new sending sources, misconfigurations, and potential spoofing attempts. Follow these best practices:

• Always include rua= — aggregate reports are the foundation of DMARC monitoring. Use a dedicated mailbox or a DMARC report parsing service to receive and analyse daily XML reports.
• Parse reports, don't read raw XML — DMARC aggregate reports are machine-readable XML files. Use a DMARC report analyser (there are several free options) to parse them into readable summaries showing pass/fail rates by source.
• Review reports before escalating policy — before moving from p=none to p=quarantine, confirm that all legitimate mail sources show a near-100% DMARC pass rate. Any legitimate source failing DMARC must be fixed first.
• Monitor for new sending sources — aggregate reports reveal every source sending email with your domain. Unknown sources in your reports indicate either a new service someone authorised without updating SPF/DKIM, or an active spoofing attempt.
• Re-check DMARC after any DNS or ESP changes — changing ESP, adding a new email service, or modifying SPF can break DMARC alignment. Run this checker after any email infrastructure change.
• Check subdomains independently — if you send from subdomains (e.g. mail.example.com), check their DMARC configuration too. Each subdomain can have its own DMARC record, or inherit the parent's using the sp= tag.

SPF vs DKIM vs DMARC — What Each One Does

SPF, DKIM, and DMARC work together to form a complete email authentication stack. Understanding each one helps you diagnose problems and build a more secure configuration.

The recommended setup is: SPF + DKIM + DMARC. All three together provide the most complete protection. DMARC alone is not effective — it requires at least one of SPF or DKIM to be correctly configured and passing before it can function. Use our free SPF checker, DKIM checker, and DMARC generator to verify and build your complete authentication stack.

Troubleshooting DMARC Issues