- © 2026 Mailsoftly Inc. The name "Mailsoftly" and the Mailsoftly logo are registered trademarks of Mailsoftly Inc.
Verify your domain’s DMARC configuration, catch misconfigurations before they hurt deliverability, and protect your brand from spoofing attacks.
by Alkan Balkaya · Last updated: 2026-05-14A single misconfigured DMARC record can send thousands of legitimate emails straight to spam. Worse, it can leave your domain wide open to spoofing attacks that damage your brand reputation overnight. A DMARC record lookup tool lets you query your domain’s DNS in seconds, surface the active policy, and tell you exactly what needs fixing.
You can test this on your own domain right now: run it through our free DMARC checker or the combined SPF, DKIM and DMARC checker for an instant report.
This guide walks you through how DMARC lookups work, how to interpret every tag in a DMARC record, common misconfigurations that silently wreck deliverability, and a step by step process for moving your domain to a strict enforcement policy.
New here? Start with our guide on What Is Email Deliverability? for the fundamentals, then come back to this guide.
Quick context: Mailsoftly offers transparent pricing, free hands-on migration, and human support. 500 contacts and 2,000 emails per month, no credit card.
Start free with Mailsoftly →
Key Takeaways
A DMARC record lookup is a DNS query that retrieves the DMARC TXT record published at _dmarc.yourdomain.com. The record tells receiving mail servers how to handle messages that fail SPF or DKIM authentication checks. Without a valid DMARC record, inbox providers like Gmail and Yahoo have no policy instructions for your domain, which means they make their own judgment calls about your mail.
DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It sits on top of two older protocols, SPF and DKIM, and adds two critical capabilities: policy enforcement (what should happen to failing mail) and reporting (send me data about who is using my domain). Understanding how these layers connect is essential. Our breakdown of What Is Email Authentication? covers SPF, DKIM, and DMARC as a unified system.
When a receiving server gets an email claiming to be from your domain, it looks up your DMARC record. If the record says p=reject and the message fails both SPF and DKIM alignment, the server drops it. If the record says p=none, the server delivers it normally but (if you included a rua tag) sends you a report. That distinction is the difference between monitoring mode and active protection.
Read enough? Try Mailsoftly free with 500 contacts and 2,000 emails per month, no credit card.Start free with Mailsoftly →
A DMARC record is a single DNS TXT entry containing semicolon-separated tags. Here is a real example:
Every tag controls a specific behavior. The table below defines each one, its required or optional status, and the recommended value for most senders.
| Tag | Status | Purpose | Recommended Value |
|---|---|---|---|
| v | Required | Protocol version identifier | DMARC1 (always) |
| p | Required | Policy for the organizational domain | reject (after monitoring phase) |
| sp | Optional | Policy for subdomains | reject |
| rua | Optional (strongly recommended) | Aggregate report delivery address | mailto:[email protected] |
| ruf | Optional | Forensic (failure) report address | mailto:[email protected] |
| pct | Optional | Percentage of messages subject to the policy | 100 (default if omitted) |
| adkim | Optional | DKIM alignment mode (strict or relaxed) | s (strict) |
| aspf | Optional | SPF alignment mode (strict or relaxed) | s (strict) |
| fo | Optional | Failure reporting options | 1 (generate report on any failure) |
The two most important tags are p (policy) and rua (reporting). A record with p=none and no rua tag is essentially doing nothing. It tells receivers you have no enforcement preference and you do not want to see the data. That is the single most common DMARC misconfiguration in the wild.
Alignment modes matter more than most people realize. The adkim and aspf tags control whether the domain in the DKIM signature or SPF return-path must exactly match the “From” header domain (strict) or just share the same organizational domain (relaxed). If you use a third party email service that sends from a subdomain like bounce.yourdomain.com, strict SPF alignment will fail unless your SPF record and return-path are configured to match. For a deeper look at how SPF, DKIM, and DMARC fit together, see our guide to Email Authentication Protocols.
You have two options: a web-based DMARC record lookup tool or the command line. Both query the same DNS data. The web tools add a friendlier interface and often flag issues automatically.
Several free tools let you enter a domain and instantly see its parsed DMARC record. MXToolbox, dmarcian, and EasyDMARC are among the most popular. They display each tag with a description, flag missing or problematic values, and sometimes show historical changes. These tools pull the DNS TXT record at _dmarc.yourdomain.com and present it in a table format, similar to the anatomy breakdown above.
The output is the raw TXT value. You will see something like “v=DMARC1; p=none; rua=mailto:[email protected];” and need to parse it yourself. The command line approach is faster for bulk checks or scripted monitoring, but it will not tell you what is wrong. That is where a proper DMARC record lookup tool adds value.
Running a DMARC record lookup tool is only useful if you know what the results mean. Below are the seven issues we see most often when auditing domains.
Issues 1, 2, and 6 account for the vast majority of deliverability problems tied to DMARC. If your lookup shows p=none without a rua address, you are collecting zero intelligence about who is sending mail as your domain. Start there.
Jumping straight to p=reject is like locking every door in a building before you have handed out keys. You will block spoofing, but you will also block legitimate mail from vendors, SaaS tools, and internal systems you forgot about. The safe path is a phased rollout.
Most organizations get stuck between Phase 2 and Phase 3. The reason is shadow IT: departments sign up for SaaS tools that send email using the company domain without telling the IT team. CRM platforms, helpdesk systems, project management tools, invoicing software. Every one of those needs to be accounted for in your SPF record and DKIM configuration before you can safely escalate your policy.
Google and Yahoo now require a published DMARC record for bulk senders (defined as 5,000 or more messages per day to their users). Google’s sender requirements documentation and Yahoo’s sender best practices both specify that domains without a DMARC record may see bulk mail throttled or rejected outright, regardless of SPF and DKIM status.
Once you publish a rua tag, you will start receiving XML files from every receiving domain that processes your mail. Gmail, Yahoo, Microsoft, and others each send their own reports, typically once every 24 hours. These files contain rows for each sending IP address, the number of messages, and whether SPF/DKIM passed or failed.
| Report Field | What It Tells You | Action If Suspicious |
|---|---|---|
| source_ip | The IP address that sent the message | Reverse-DNS lookup to identify the sender. If unrecognized, it may be a spoofing attempt. |
| count | Number of messages from this IP | High volume from an unknown IP is a strong spoofing indicator. |
| disposition | What the receiver did (none, quarantine, reject) | If “none” on a failing IP, your policy is not yet enforcing. |
| dkim result | Pass or fail for DKIM alignment | If failing on a legitimate sender, their DKIM signing domain does not align with your From domain. |
| spf result | Pass or fail for SPF alignment | If failing, the return-path domain does not match. Configure a custom return-path in your ESP. |
Raw XML reports are not practical to read at scale. Use a DMARC report aggregation service to parse them into dashboards. These services (dmarcian, Postmark DMARC, Valimail) pull your rua emails, parse the XML, and show you visualizations of passing versus failing traffic broken down by source, country, and alignment status.
The key metric to watch is the ratio of aligned, passing messages to total messages. When that ratio hits 99% or higher for two consecutive weeks, you are safe to escalate your policy. Any legitimate source still failing needs to be fixed at the source level (SPF include or DKIM key rotation), not by weakening your DMARC policy.
DMARC does not directly improve deliverability the way a clean list or good content does. What it does is remove a major negative signal. When inbox providers see a domain with p=reject, they know that any message passing DMARC is genuinely from that domain. This trust signal reduces the likelihood of legitimate mail being flagged as suspicious.
Conversely, a misconfigured DMARC record actively hurts deliverability. If you publish p=reject but have not configured SPF and DKIM for all your sending sources, those legitimate emails get bounced. The sender sees hard bounces, the receiving domain sees rejected traffic, and your sending reputation takes a hit from both sides.
This is why the “monitor first” approach is non-negotiable. You need data before enforcement. Run your DMARC record lookup tool, verify your record exists, confirm a rua address is collecting reports, and only then begin tightening your policy.
If you are running email campaigns through a platform like Mailsoftly or any other email service provider, DMARC affects you directly. Your ESP sends mail on your behalf, using your domain in the “From” header. If SPF and DKIM are not properly aligned for that ESP’s sending infrastructure, your campaigns will fail DMARC checks.
Here is what email marketers need to configure:
After configuring these settings, run a DMARC record lookup tool against your sending domain and verify that your record is syntactically valid. Then send a test campaign and check the email headers (most email clients let you view “original message” or “show headers”) to confirm DKIM and SPF both pass with proper alignment.
DMARC configuration is defined in the IETF RFC 7489 specification, which documents the full protocol. The specification defines the DNS record format, report schema, and alignment rules that receiving servers implement. Understanding the specification helps when debugging edge cases, such as forwarded messages or mailing list behavior where the original authentication chain breaks.
For the broader picture on email authentication and deliverability, see our complete guide on What Is Email Deliverability?, which covers strategy, fundamentals, and advanced playbooks.
Receiving servers treat your domain as having no DMARC policy. They rely solely on SPF and DKIM results plus their own reputation data. This means you have no control over what happens to failing messages and no reporting data. Anyone can send email that appears to come from your domain, and you will never know it is happening. Gmail and Yahoo may also throttle bulk mail from domains without a DMARC record.
DNS propagation depends on the TTL (time to live) value set on your TXT record. Most DMARC records use a TTL between 300 seconds (5 minutes) and 3600 seconds (1 hour). In practice, most changes are visible within 30 minutes to 2 hours. You can verify propagation by running a DMARC record lookup tool from different geographic locations or using a DNS propagation checker.
Yes, this is one of the most common issues. When an email is forwarded (e.g., from a university address to a personal inbox), the forwarding server changes the envelope sender, which breaks SPF alignment. If DKIM survives intact (it usually does if the message body is not modified), the message still passes DMARC via DKIM alignment. However, mailing lists that modify the message body or Subject line can break DKIM too. The solution is ARC (Authenticated Received Chain), which preserves the original authentication results through forwarding hops.
Start with relaxed alignment (adkim=r; aspf=r;) during your monitoring and rollout phases. Relaxed alignment allows subdomains to pass alignment with the organizational domain, which gives you more flexibility with third party senders. Once all your sending sources are properly configured with exact domain matching, you can tighten to strict (adkim=s; aspf=s;) for maximum security. Strict alignment ensures the DKIM signing domain and SPF return-path match the exact From header domain, not just the organizational domain.
Check your DMARC record after any DNS change, any new ESP or SaaS integration, and at minimum once per quarter as part of routine email authentication hygiene. Automated monitoring services can alert you to record changes or deletions in real time. Since DNS records can be accidentally modified by team members or hosting migrations, proactive monitoring prevents gaps in your DMARC enforcement.
Ready to switch?Start free with Mailsoftly →
500 contacts, 2,000 emails per month. Free hands-on migration. No credit card.
Ready to boost your email marketing?
Start sending beautiful, targeted emails that convert — free to get started.
Try Mailsoftly FreeNo credit card required