Free DMARC Record Checker & Policy Lookup

If you've ever received an email that looked like it came from your bank, a colleague, or a well-known brand — but turned out to be a scam — you've witnessed what DMARC is designed to stop. DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It's a DNS-published policy that tells the world's email servers exactly what to do when they receive a message that claims to be from your domain but can't prove it's genuine.

Here's the core problem DMARC solves: email was designed in the 1970s with no concept of authentication. Anyone can compose an email and put anything they want in the "From" field. Spammers, phishing gangs, and nation-state attackers have exploited this gap for decades. SPF and DKIM were later invented to add cryptographic verification — but without DMARC, there was still no instruction for what a receiving server should do if those checks failed. Should it deliver the email anyway? Bounce it? Mark it as spam? DMARC fills that gap.

A DMARC record is a simple TXT entry you publish in your domain's DNS, under the subdomain _dmarc.yourdomain.com. It looks something like this:

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=100; adkim=r; aspf=r;

Each tag has a specific job. The p= tag is the policy — the most critical piece. It tells receiving mail servers (Gmail, Outlook, Yahoo, and thousands of others) what to do with emails from your domain that fail authentication:

For DMARC to "pass," at least one of two conditions must be true: either the sending server's IP address matches the domain's SPF record and that domain aligns with the From header, or the email carries a valid DKIM cryptographic signature from the same domain shown in the From header. This concept — requiring the authenticated domain to match the visible From address — is called DMARC alignment, and it's what makes the protocol actually prevent spoofing rather than just checking boxes.

The rua= tag specifies an email address where mail providers send aggregate XML reports, typically once per day. These reports show every IP address that sent mail claiming to be from your domain, along with how many messages passed or failed SPF and DKIM. It's essentially a live map of who's sending email on your behalf — including authorized services you may have forgotten about and attackers actively spoofing you.

In October 2023, Google and Yahoo jointly announced that starting February 2024, all bulk senders — defined as anyone sending more than 5,000 emails per day to Gmail or Yahoo addresses — must meet three email authentication requirements. If they don't comply, their messages will be rejected or heavily filtered. Those requirements are: publish a valid SPF record, sign outbound email with DKIM, and have a DMARC record published with at least p=none.

The announcement sent a wave of urgency through the email industry. For years, DMARC had been best practice — widely recommended but not enforced by anyone except the domain owner. Overnight, two of the largest email providers in the world made it a gating requirement for deliverability. And Google has since signaled that the expectation will move toward stricter policies over time.

But this mandate affects more than just bulk senders. Even domains that send fewer than 5,000 emails daily are discovering that not having DMARC is increasingly interpreted as a signal of poor domain hygiene by spam filters across the industry. Microsoft, Apple, and corporate mail gateways like Proofpoint and Mimecast all use DMARC data as one of many inputs in their deliverability scoring.

Beyond deliverability, there's a more immediate threat: business email compromise (BEC). The FBI's Internet Crime Complaint Center reported over $2.9 billion in BEC losses in a single year. These attacks almost always involve spoofed email — someone sends a message that appears to come from your CEO, your finance team, or your vendor's domain. A properly enforced DMARC policy with p=reject means that when an attacker tries to spoof yourdomain.com, the receiving server will discard the message before anyone ever sees it.

Use our free DMARC checker above to instantly see your current policy. If you have no record, or a policy of p=none with no path to enforcement, it's time to act.

Setting up DMARC is not technically difficult — it's a single DNS TXT record — but the process of safely moving from no DMARC to full enforcement requires patience and a methodical approach. Rushing straight to p=reject without first understanding your email flows can break legitimate mail. Here's how to do it right.

Step 1 — Audit your sending infrastructure

Before you touch DNS, identify every service that sends email on behalf of your domain. This typically includes: your main email provider (Google Workspace, Microsoft 365, Zoho), your marketing platform (Mailchimp, HubSpot, Klaviyo, Constant Contact), your CRM or sales tool (Salesforce, HubSpot CRM), transactional email services (SendGrid, Postmark, Amazon SES), and any legacy or internal systems. You need every one of these passing both SPF and DKIM before you enforce DMARC.

Step 2 — Publish a monitoring-only DMARC record

In your DNS provider (Cloudflare, GoDaddy, Namecheap, Route 53, etc.), add a TXT record with the name _dmarc and this value:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-reports@yourdomain.com; pct=100;

Use a real mailbox you'll actually check for rua. Better yet, use a dedicated DMARC reporting service (many are free for low volume) that converts XML reports into readable dashboards. DNS propagation takes anywhere from a few minutes to 48 hours depending on your TTL settings.

Step 3 — Analyze your aggregate reports for 2–4 weeks

Your rua reports will show every IP address sending mail that claims your domain. Look for: unauthorized senders (potential attackers), legitimate senders that are failing SPF or DKIM (these need to be fixed before you enforce), and forwarded mail (which often breaks SPF alignment — this is normal and DKIM is the solution).

Step 4 — Fix SPF and DKIM for all legitimate senders

For each legitimate service appearing in your reports that isn't passing authentication, follow that provider's documentation to add its SPF include: mechanism and enable DKIM signing. For example, for Mailchimp you add include:servers.mcsv.net to your SPF record and configure their DKIM by adding a CNAME record they provide. For SendGrid, you add two CNAME records they give you during domain authentication setup.

Step 5 — Gradually move to enforcement

Once your reports show that nearly all legitimate mail is passing, update your DMARC record step by step:

• Move to p=quarantine; pct=10 — quarantine 10% of failing mail (a small rollout)
• Expand to p=quarantine; pct=100 — quarantine all failing mail
• Final goal: p=reject; pct=100 — full blocking protection

Monitor your reports at each stage for at least a week before advancing. If you see legitimate mail being affected, investigate which service is failing and fix it before proceeding.

Even experienced sysadmins and email deliverability specialists make DMARC configuration mistakes. These are the most common ones our DMARC checker catches — and how to avoid or fix them.

Mistake 1: Setting p=none and never revisiting it

Publishing a DMARC record with p=none is Step 1, not a destination. Many domains stay at p=none indefinitely because nobody follows up. p=none provides zero spoofing protection — it's monitoring mode only. Put a calendar reminder to review your DMARC reports every two weeks until you reach p=reject.

Mistake 2: Forgetting the subdomain policy (sp=) tag

By default, a DMARC policy at your root domain does not automatically apply to subdomains. If you have mail.yourdomain.com, support.yourdomain.com, or no-reply.yourdomain.com sending email, you either need to add sp=reject to your root DMARC record, or publish separate DMARC records for each sending subdomain. Without this, attackers can spoof your subdomains freely even if your root domain is fully protected.

Mistake 3: An invalid rua= format causing no reports

The reporting address must be formatted exactly as rua=mailto:email@yourdomain.com — including the mailto: prefix. Missing it means you receive no aggregate reports and fly blind. Also note: if your rua address is on a different domain than the one your DMARC record protects, you need to publish an additional DNS record on that receiving domain to authorize it.

Mistake 4: Publishing multiple DMARC records

Like SPF, a domain must have exactly one DMARC TXT record at _dmarc.yourdomain.com. If you have two, receiving servers will typically throw a permerror and ignore DMARC entirely. Check with dig TXT _dmarc.yourdomain.com and ensure only one record exists.

Mistake 5: Assuming DMARC alignment will "just work" with all ESPs

Many Email Service Providers send mail from their own servers using your domain in the From header, but their SPF record covers their own servers — not yours. This means SPF often fails alignment for ESP-sent mail. The solution is to ensure DKIM signing is set up with your domain (not the ESP's domain) for all platforms. DKIM alignment is generally more reliable than SPF alignment for third-party senders.

Email authentication is not a "set it and forget it" exercise. Vendors change their sending infrastructure, you add new tools to your stack, and attackers continuously probe for gaps. A monthly DMARC check using our free tool keeps you ahead of problems before they affect your deliverability or brand reputation.