DNS SPF & DMARC Record Validator

Parse, validate, and audit DNS TXT SPF and DMARC email authentication records client-side. Count query limits and flag security loopholes instantly.

🛡️ SPF Record TXT Value

Paste SPF Record

📋 DMARC Record TXT Value

Paste DMARC Record

🛡️ SPF Audit Report

Unknown

DNS Lookups Triggered: 0 / 10 limit

Audit your records to inspect structural security settings.

📋 DMARC Audit Report

Unknown

Audit your records to inspect policy parameters.

Why Email Security Demands SPF & DMARC Alignment

Modern email delivery depends heavily on validating outbound servers. A domain missing SPF or DKIM is prone to spoofing, phishing, and domain hijacking attacks. Recipient systems like Gmail and Yahoo reject mail blocks that fail SPF or DMARC alignments outright.

Performing standard DNS audits helps trace nested `include` mechanisms, checking if you exceed the 10-query SPF limit, and helps audit your DMARC quarantine/reject rules to guarantee maximum delivery protection.

SPF Mechanism Lookup Weights

Mechanism	Lookup Weight	Crawl Notes
include	1 lookup	Queries nested third-party SPF records
a / mx	1 lookup	Resolves host A/AAAA or mail handler MX servers
ip4 / ip6	0 lookups	Direct IP blocks require zero DNS lookups
all	0 lookups	Fallback criteria requiring zero DNS lookups

Under the Hood: How SPF, DKIM, and DMARC Coordinate Email Delivery

Email was originally designed without built-in sender verification mechanisms, allowing anyone to send messages with spoofed headers. To secure the global email ecosystem, three core protocols were developed: SPF, DKIM, and DMARC. These standards work together to establish a robust, verifiable sender identity that modern receiving mail servers can trust.

Under the hood, SPF (Sender Policy Framework) acts as an IP authorization list, declaring which servers are allowed to send mail for a domain. DKIM (DomainKeys Identified Mail) provides a cryptographic signature on outbound emails, proving the message content was not altered in transit. DMARC (Domain-based Message Authentication, Reporting, and Conformance) sits on top of both protocols. It dictates what action a receiver should take if an email fails SPF or DKIM alignment, and it defines reporting endpoints so domain owners can monitor authentication results globally.

Before and After: DNS Mail Record Implementations

Below is a typical code illustration comparing basic, insecure mail configurations with a highly secure SPF and DMARC setup:

Before: Basic SPF with No DMARC Security

// SPF allows too many servers (~all softfail)
// No DMARC record exists in domain DNS
example.com. IN TXT "v=spf1 include:_spf.google.com ~all"

After: Hardened SPF & Strong DMARC Policy

// Restrictive SPF with strict HardFail (-all)
example.com. IN TXT "v=spf1 include:_spf.google.com -all"

// DMARC policy enforces strict email reject rules
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"

3-Column Email Authentication Protocol Matrix

Protocol / Standard	Core Verification Method	Primary Defense & Alignment Behavior
SPF (RFC 7208)	Validates sending server IP against the domain's SPF record.	Prevents spoofing of the envelope sender ("Return-Path") address.
DKIM (RFC 6376)	Verifies cryptographic headers using public keys from domain DNS.	Ensures that body content and critical headers were not modified in transit.
DMARC (RFC 7489)	Enforces alignment of SPF and DKIM domains with the "Header From" address.	Protects the user-visible "From" header and generates detailed XML deliverability reports.

Common Validation Mistakes & Troubleshooting Guide

Exceeding the 10-DNS Lookup Limit in SPF: One of the most common SPF errors is adding too many nested include mechanisms (e.g. including Google Workspace, Microsoft 365, HubSpot, and Mailgun in a single record). If the total number of DNS lookups exceeds 10, receiving mail systems will trigger a PermError, causing standard mail to bounce.
Creating Multiple SPF or DMARC Records: A domain must have exactly one SPF record and one DMARC record. If you publish multiple TXT records for SPF or DMARC, receiving mail servers will immediately invalidate all of them, rendering your domain unprotected against spoofing attacks.
Syntax Errors and Mismatched Case: Common typos, such as using v=spf1 with incorrect spacing or publishing DMARC records on the root domain instead of the _dmarc subdomain, will cause parsing failures. Regular DNS audits using our local validator prevent these issues.

Best Practices for Email Domain Security

Start by publishing a DMARC record with a policy of p=none and monitor the daily aggregate reports sent to your rua= reporting address. This allows you to identify all legitimate sending services (such as newsletters, support desks, and transaction mailers) and configure their SPF and DKIM keys correctly.

Once you confirm that all legitimate mail sources are passing authentication and domain alignment checks, graduate your policy to p=quarantine, and ultimately to p=reject. A strict reject policy provides the highest level of security, ensuring that unauthenticated, spoofed emails are blocked before they can reach your customers' inboxes.

Frequently Asked Questions

What is a DNS SPF record, and how does it prevent domain email spoofing?

A Sender Policy Framework (SPF) record is a specialized DNS TXT record that identifies the specific mail servers and IP addresses authorized to send emails on behalf of a domain. During an incoming mail transmission, the receiving mail server retrieves the sender domain's SPF record and checks if the originating server's IP address matches the declared list of mechanisms. If a match is found, the SPF check passes, signaling that the message is legitimate. If no match is found, the server applies the specified qualifier (such as a SoftFail or HardFail), helping to block spoofed domain emails, spam campaigns, and malicious phishing attempts.

What is the strict 10-DNS lookup limit in SPF records, and why is it critical?

The official RFC 7208 standard mandates that SPF record validation must not trigger more than 10 nested DNS queries during evaluation. This constraint prevents denial-of-service (DoS) vectors on global DNS infrastructure by limiting nested recursive checks. Mechanisms such as a, mx, include, exists, and redirect each count as 1 query, whereas direct IP blocks like ip4 and ip6 require no additional DNS queries and do not count toward the limit. If your SPF record exceeds 10 lookups, recipient mail servers will fail verification with a permanent "PermError", causing authentic emails to bounce.

How do the different qualifiers in SPF records manage email authentication results?

SPF mechanisms can be prefixed with four distinct qualifiers that dictate how receiving servers treat emails failing validation checks. The - (HardFail) qualifier instructs receivers to reject unauthorized emails immediately, while the ~ (SoftFail) qualifier suggests accepting the email but flagging it as suspicious or routing it to spam. The + (Pass) qualifier explicitly authorizes matching senders, and the ? (Neutral) qualifier acts as an open-ended monitor, indicating no specific preference. Selecting the correct qualifier allows email administrators to align their sender verification policies with domain deliverability requirements.

What is a DNS DMARC record, and how does it relate to SPF and DKIM authentication?

A Domain-based Message Authentication, Reporting, and Conformance (DMARC) record is a DNS TXT configuration that builds upon SPF and DKIM checks. It instructs receiving servers exactly how to process incoming mail that fails both SPF and DKIM alignments. To achieve DMARC alignment, the email's "Header From" domain must match the domain validated by SPF and DKIM. DMARC coordinates security by ensuring that these security protocols work in tandem, providing a unified authentication layer that prevents attackers from spoofing trusted sender domains.

What are the differences between DMARC policy levels (none, quarantine, and reject)?

A DMARC record must specify a policy parameter, labeled as p=, which defines the containment strategy for emails failing security alignment checks. The p=none policy acts in monitoring mode, gathering XML diagnostic reports from receiving servers without blocking or filtering incoming emails. The p=quarantine policy shifts suspicious, unaligned emails to the recipient's spam folder, shielding primary inboxes from untrusted messages. Finally, the p=reject policy instructs receiving servers to block unauthorized emails completely at the mail gateway, providing the highest level of security against phishing.

What are DMARC forensic (ruf) and aggregate (rua) XML reports used for?

DMARC reports provide administrators with deep visibility into how global mail systems handle messages sent from their domains. Aggregate reports, configured via the rua tag, send daily XML files summarizing sending volumes, source IP addresses, and authentication pass/fail ratios across participating email providers. Forensic reports, defined by the ruf tag, deliver real-time, detailed alerts containing individual header details for spoofed emails that fail DMARC alignment. Analyzing these XML files helps domain owners detect shadow IT services, optimize email deliverability, and expose active spoofing campaigns.

Why is it safer to audit your SPF and DMARC settings using this local validator?

Auditing your configurations with the FlowStack SPF & DMARC Validator ensures that your email security records are fully compliant without exposing sensitive domain data to external servers. The validator parses records, counts nested DNS queries, and maps DMARC alignment rules entirely within your browser's local memory using client-side JavaScript. This completely offline execution model ensures your domain setups remain confidential and secure from external surveillance or unauthorized caching. By checking your configurations against RFC rules in real-time, it guarantees a safe validation process before live deployment.