Why does a DMARC record sometimes return an SPF value?
Matthew Whittaker
Co-founder & CTO, Suped
Published 27 May 2025
Updated 7 Sep 2025
7 min read
It can be confusing to perform a DNS lookup for a DMARC record, only to find that it returns an SPF value instead of the expected DMARC policy. This seemingly odd behavior points to a common DNS misconfiguration, often involving wildcard records. Understanding why this happens is crucial for maintaining proper email authentication and ensuring your messages reach their intended recipients without being flagged as spam or fraudulent.
When a receiving mail server checks your domain's DMARC policy, it specifically queries for a TXT record at the subdomain _dmarc.yourdomain.com. If there isn't an explicit DMARC record set at this exact location, the DNS resolver might fall back to a broader rule, such as a wildcard entry. If that wildcard happens to point to an SPF record, then an SPF value will be returned instead of a DMARC one.
This article will clarify why this happens, explain the implications for your email deliverability, and provide steps to correct these types of DNS errors. Getting your DMARC setup right is fundamental to robust email security.
A common culprit behind a DMARC record returning an SPF value is the presence of an overreaching DNS wildcard record. Wildcard records are denoted by an asterisk (*) and are designed to catch queries for any subdomain that doesn't have an explicit record defined. For example, a wildcard record for *.yourdomain.com would apply to blog.yourdomain.com or mail.yourdomain.com if no specific records exist for those subdomains.
If you haven't explicitly created a DMARC TXT record for _dmarc.yourdomain.com, a wildcard record can step in and provide a response. Sometimes, this wildcard record might inadvertently be configured to return an SPF value. This is typically a misconfiguration rather than an intended behavior. A common problem with DMARC records is that wildcard DNS entries return non-DMARC records, usually SPF records.
For instance, if your DNS includes a wildcard TXT record that contains an SPF policy, any query for a TXT record on a subdomain without a specific entry will receive that SPF policy as a response. This includes queries for _dmarc.yourdomain.com.
Example of a dig query returning an SPF record from a DMARC lookupBASH
DMARC, or Domain-based Message Authentication, Reporting & Conformance, has strict requirements for its DNS record. A valid DMARC record must begin with the tag v=DMARC1, followed by a semicolon. This is explicitly stated in Section 7.1.5 of RFC 7489, which mandates that this tag is mandatory and must appear first. Any record found at the DMARC query location that does not start with v=DMARC1 will be ignored by receiving mail servers.
DMARC validation strictness
If a DNS query for a DMARC record returns an SPF value, or any other value that doesn't start with v=DMARC1, that record will be treated as invalid. This means the domain effectively has no DMARC policy in place. For more details on tags, review our list of DMARC tags.
This strict validation process is in place to prevent misinterpretation and ensure that DMARC policies are clearly defined and consistently applied. A record that begins with v=spf1 will always be treated as an SPF record, even if it appears in a context where a DMARC record is expected. This distinction is critical for email authentication protocols to function correctly.
Impact on email deliverability and security
The primary impact of a DMARC query returning an SPF record is that your domain is not effectively protected by DMARC. Without a valid DMARC policy, you lose several key benefits for email security and deliverability, including the ability to instruct receiving mail servers on how to handle emails that fail SPF or DKIM authentication.
With an invalid DMARC record
Vulnerability to spoofing: Attackers can easily send emails appearing to be from your domain, leading to phishing attacks and brand damage.
No DMARC reports: You won't receive aggregate or forensic reports, which are vital for monitoring email authentication status and identifying unauthorized senders. This is where Suped's DMARC monitoring can provide invaluable insights.
Reduced deliverability: Emails from your domain are more likely to land in spam folders or be rejected, especially by mail providers with strict DMARC enforcement.
With a valid DMARC record
Enhanced brand protection: DMARC prevents unauthorized use of your domain, safeguarding your brand reputation and customer trust.
Visibility into email ecosystem: Reports offer a clear picture of who is sending email on your behalf, allowing you to identify and authorize legitimate senders, like Google or Yahoo.
Improved inbox placement: With DMARC, your emails are more trusted by recipients, leading to better inbox delivery rates. Learn more about the benefits of DMARC.
Essentially, an SPF record appearing in place of a DMARC record means your domain's email authentication strategy is incomplete. This can lead to issues where legitimate emails fail DMARC checks, even if SPF and DKIM pass individually, due to a lack of a clear DMARC policy. This highlights the importance of precise DNS configuration for all email authentication protocols.
Correcting DMARC record issues
To resolve the issue of a DMARC query returning an SPF value, you need to address the underlying DNS misconfiguration. The solution typically involves two key steps: removing the problematic wildcard record (or modifying it) and ensuring a correct DMARC record is published.
Identify the rogue wildcard: Access your domain's DNS settings through your DNS provider (e.g., Cloudflare, GoDaddy, etc.). Look for TXT records with a hostname of * or similar. If one contains an SPF value (v=spf1), it's likely the culprit.
Remove or modify the wildcard: Delete the wildcard TXT record that contains the SPF value. If you need a wildcard record for other purposes, ensure it does not include an SPF policy. SPF records should only exist as a specific TXT record for your root domain or relevant subdomains.
Publish a proper DMARC record: Create a TXT record specifically for _dmarc.yourdomain.com. It must start with v=DMARC1 and include your desired DMARC policy. You can use a free DMARC record generator to help you construct the record.
After making these changes, always allow for DNS propagation time, which can take several hours. Then, use a DNS lookup tool to verify that your DMARC record now correctly returns the DMARC policy you published. Regular DMARC monitoring with a tool like Suped will help you catch these types of misconfigurations early and maintain optimal email deliverability.
Ensuring robust email authentication
Encountering an SPF record when querying for DMARC can be a puzzling experience, but it's a clear indicator of a DNS configuration error. Correcting this involves ensuring that wildcard records don't inadvertently serve SPF policies for DMARC lookups and that a properly formatted DMARC record is published. This ensures your domain is fully protected against spoofing and phishing attempts, and your emails maintain optimal deliverability.
Remember, DMARC is a critical layer of email security that works in conjunction with SPF and DKIM. Any misstep in its configuration can undermine your entire email authentication strategy. Tools like Suped are designed to simplify DMARC management and reporting, providing clear insights into your email authentication status.
Implementing and monitoring DMARC correctly is not just a technical task, it's a fundamental aspect of safeguarding your brand and ensuring your messages reliably reach your audience. Take the time to audit your DNS records and rectify any inconsistencies to establish a robust and effective email authentication framework.
Views from the trenches
Best practices
Always publish an explicit DMARC TXT record for _dmarc.yourdomain.com to avoid wildcard fallback.
Regularly audit your DNS records for unintended wildcard entries that might interfere with DMARC lookups.
Utilize DMARC reporting tools like Suped to gain visibility into your authentication status and identify issues.
Common pitfalls
Forgetting to publish a specific DMARC record, causing a wildcard record to be returned instead.
Having a wildcard TXT record that inadvertently contains an SPF policy.
Assuming an SPF record returned during a DMARC query is acceptable for email authentication.
Expert tips
If you suspect a wildcard DNS entry is causing issues, temporarily create a specific, empty TXT record for the DMARC subdomain to test if the wildcard is indeed overriding it.
When dealing with complex DNS configurations, document all your records, especially wildcards, to prevent unexpected interactions.
Always verify your DMARC record with a reliable DNS lookup tool after making any changes to ensure correct propagation.
Expert view
Expert from Email Geeks says if a DMARC query returns an SPF value, it should be ignored by recipient servers because the DMARC record must start with 'v=DMARC1;'.
2024-08-29 - Email Geeks
Expert view
Expert from Email Geeks says this scenario likely results from a rogue wildcard DNS record providing an SPF value when a specific DMARC record is not present.
Google or 
Yahoo.
Cloudflare, 
GoDaddy, etc.). Look for TXT records with a hostname of * or similar. If one contains an SPF value (v=spf1), it's likely the culprit.
