A TXT record is a single dense string of tags and mechanisms, and reading one raw is an exercise in squinting: v=spf1 ip4:192.0.2.1 include:_spf.example.com -all packs a whole mail policy into one line, and a DMARC record is worse. When mail fails or a verification keeps failing, the fastest diagnosis is to break that string into its parts and read each tag on its own line. This parser does exactly that, splitting on spaces while respecting quoted values, then labelling each tag or mechanism so you can see what the record actually says, rather than what you assumed it said.
Quick Answer: Paste a TXT record and click Parse to see a tag-by-tag breakdown.
Free Online Tool
DNS TXT Record Parser
Parse a pasted TXT record (SPF, DKIM, or DMARC style) into a readable tag-by-tag breakdown.
How to Use the DNS TXT Record Parser
- Copy the TXT record value from your DNS provider.
- Paste it into the input box, quotes included if present.
- Click Parse.
- Read the breakdown, one tag or mechanism per line.
- Check each value against what you intended to publish.
- Fix the offending tag in your DNS record and re-parse to confirm.
Key Features
- Splits records on spaces while respecting quoted strings.
- Labels key=value tags and bare mechanisms separately.
- Handles SPF, DMARC, DKIM, and verification TXT records.
- Flags the record version tag when present.
- Counts the mechanisms for a quick complexity check.
- Runs entirely in the browser; nothing is sent anywhere.
What the Result Means
Each line of the breakdown is one decision the record makes. In SPF, the order of mechanisms matters because the first match wins, and the final all mechanism is the default for everything else. In DMARC, each tag is independent: p sets the policy, rua sets reporting, and pct sets the rollout share. If a line surprises you, that line is the bug: a common case is an include that points at the wrong provider, or a DMARC policy still set to none when you believed it was enforced.
Worked Example
Pasting v=spf1 ip4:192.0.2.1 include:_spf.example.com -all produces four lines: the version tag v=spf1, the ip4 mechanism authorising 192.0.2.1, the include delegating to the provider record, and the -all ending that rejects everything else. If mail from the provider is being rejected, the breakdown immediately shows whether the include is present and spelled correctly, which is the usual fault, rather than requiring a line-by-line squint at the raw string. A DMARC record benefits the same way: pasting v=DMARC1; p=none; rua=mailto:dmarc@example.com separates the version, the monitoring-only policy, and the reporting address onto three lines, making it obvious at a glance that enforcement has not been switched on yet.
Best Practices and Tips
- Parse the live record, not the one you think you published; they often differ.
- For SPF, count the mechanisms that trigger DNS lookups and keep them under ten.
- For DMARC, check p and sp separately; subdomains do not always inherit what you expect.
- Watch for doubled spaces and stray quotes, which break parsing at the receiver too.
- After fixing a record, re-parse the live value to confirm the change propagated.
Common Mistakes to Avoid
- Reading a TXT record as prose instead of breaking it into tags.
- Assuming the published record matches the draft you wrote.
- Forgetting that SPF mechanism order decides the first match.
- Copying a record with surrounding quotes into a field that adds its own quotes.
Frequently Asked Questions
What is a TXT record?
A DNS record type that carries free text, used for SPF, DKIM, DMARC, and ownership verification.
Why do some values have quotes?
DNS strings are quoted in zone files and some provider displays; the quotes are not part of the value itself.
Can this validate my record?
It breaks the record down for reading; full validation of SPF lookup counts and DKIM keys needs dedicated checkers.
What if the record has no version tag?
Then it is probably a verification string, not SPF or DMARC, and the whole value is the token to compare.