Free tool
What do this domain's TXT records do?
Every TXT record on a name, sorted by what it does: SPF, DKIM, DMARC and the verification tokens left behind. DMARC is read from the one name it actually lives on. No sign-up, no email to leave.
The junk drawer of DNS, and nothing in it is labelled
The TXT record has no job of its own. It is a free-text field that everybody found a use for. A company domain carries twenty or thirty of them without trying, most left behind by services nobody uses now. The SPF is in there somewhere, and it is the only one deciding whether mail goes out at all.
DMARC is never where people look for it
This is mistake number one on a TXT lookup. You query the domain, you see no DMARC, and you decide there is none. DMARC does not live on the domain. It lives on _dmarc in front of it. So the tool fetches it there and puts it in the same table under its real name. Records come out sorted too, so the SPF is not the twenty-ninth row.
The catch-all drawer
Six loose lines, each with one exact place
A TXT record can hold anything at all. It is the slot where everything without a slot of its own ends up. What matters is not the content, it is the NAME you place it at. Click a line to file it.
Loose (6)
SPF
Must be placed at
example.com
The servers allowed to send mail for this domain.
DMARC
Must be placed at
_dmarc.example.com
What to do with messages that fail the checks.
DKIM
Must be placed at
selector._domainkey.example.com
The public key that verifies the signature on messages.
Proof of ownership
Must be placed at
example.com
The token a service asks you to publish to prove the domain is really yours.
Nothing at all
Must be placed at
anywhere
A TXT record can hold free text. Nobody reads it, and it bothers nobody.
A DMARC record placed at example.com instead of _dmarc.example.com will never be read by anyone. Right content, wrong address — the most common mistake in this family.
Three writing rules
Three numbers, and half of failed TXT records disappear
None of the three is a convention. They are limits of the format, and your host's interface never mentions any of them.
255chars
One fragment, not a character more
Past that the interface rejects the value, or truncates it in silence. A longer record goes out as several fragments the reader joins back together — and one space added between two of them breaks a DKIM key.
1SPF
One per name, never two
With two v=spf1 records the check fails instead of merging the authorizations. This is the mistake you make while adding a sending service.
6formats
Recognizable from the first word
SPF, DKIM, DMARC, MTA-STS, TLS-RPT, BIMI. Six mail standards that all live inside a TXT record, are read from their prefix, and belong in six different places.
The 255-character limit per fragment comes from the definition of the TXT format (RFC 1035), the single-SPF rule from RFC 7208. The six formats are the ones this check can name.
Reading the result
The table gives you every record and what it is, whenever the record announces that itself. An unlabelled TXT is not suspicious. It is just content no standard lets us identify for certain.
- All clear — one SPF, exactly one
- One record starts with v=spf1, and only one. That is what the standard requires, and where you want to be.
- All clear — a DMARC found
- A record turned up on _dmarc in front of the domain. It appears in the table under that name, so nobody mistakes it for a TXT on the domain itself.
- Worth watching — no TXT at all
- This name carries no text record at all. Common enough on a subdomain. On a domain that sends mail, it means there is neither an SPF nor a single ownership proof filed.
- Problem — several SPF records
- Two or more records start with v=spf1. The standard allows one. Given two, the check does not choose between them — it fails, and your messages count as unauthenticated.
- Problem — the name does not exist
- No nameserver knows this name. The problem is not a missing TXT — the name is undeclared.
- Undetermined — no SPF found
- The name carries TXT records, and not one of them starts with v=spf1. Harmless on a domain that sends nothing. On any other, nothing tells recipients who is allowed to write on its behalf.
- Undetermined — a record split into chunks
- A TXT runs past 255 characters, so it gets published in several fragments that the resolver joins before reading. Normal, written into the standard, and it changes nothing about the content.
- Undetermined — no answer in time
- The resolver came back with nothing in time. That happens on a slow zone, and it says nothing about the domain.
The mistakes we see most often
A second SPF was created to add a service
What causes it: you want to authorize a new sending tool, and the panel invites you to add a record. Now you have two v=spf1 lines. The standard allows one, and two makes the whole check fail — which is worse than having none.
What fixes it: merge them into one record, with every service listed inside it and a single all at the end.
DMARC was created on the domain instead of _dmarc
What causes it: the record is syntactically perfect, and nobody will ever read it there. Receiving servers query _dmarc in front of the domain, and nowhere else.
What fixes it: create the record with _dmarc as the host name. Some panels want _dmarc on its own, others want the full name. Both exist, so read what the field is asking for.
The value was pasted with its quotation marks
What causes it: the provider's documentation shows the value in quotes, because that is how a zone file is written. Paste it as-is into a form that adds its own and the quotation marks end up INSIDE the content, where nothing recognizes it.
What fixes it: paste the value without the quotes, then read back the record as it was actually published — which is what the tool above hands you.
A DKIM key longer than 255 characters was rejected
What causes it: a TXT is built from fragments of at most 255 characters. A 2048-bit public key runs past that and has to go out in several fragments. Some panels handle it for you. Others reject the value, or truncate it without a word.
What fixes it: use a field that accepts the split, or publish the key in fragments yourself. A truncated key throws no visible error. Every signature simply fails.
The verification token was deleted once verification was done
What causes it: you prove ownership of a domain, you get access, and later you tidy up. Several services re-verify on a schedule and pull your access if the record is gone — at the worst possible moment, which is the one where you need it.
What fixes it: leave the tokens of services still in use where they are, and remove only the ones whose accounts you deliberately closed.
Recognizing a TXT by how it starts
Most records announce what they are in their first few characters. That is the only reliable way to sort the twenty lines on a company domain, and it also tells you where each one belongs.
| Starts with | What it is | Where it belongs |
|---|---|---|
| v=spf1 | SPF — the list of servers allowed to send on the domain's behalf. | On the domain itself. One only, never two. |
| v=DKIM1 | DKIM — the public key used to verify the signature on messages. | On <selector>._domainkey in front of the domain. One per selector. |
| v=DMARC1 | DMARC — what recipients should do with messages that fail the two checks above. | On _dmarc in front of the domain. Never on the domain. |
| v=STSv1 | MTA-STS — requires an encrypted connection when mail is delivered. | On _mta-sts in front of the domain, alongside a file served over HTTPS. |
| v=TLSRPTv1 | TLS-RPT — the address to send encryption failure reports to. | On _smtp._tls in front of the domain. |
| v=BIMI1 | BIMI — where to find the logo shown next to messages, when the mail provider supports it. | On default._bimi in front of the domain. Requires an enforced DMARC. |
| google-site-verification= | Proof that you control the domain, filed for Google services. | On the domain. Keep it as long as the service is in use. |
| MS= | The same proof, for Microsoft services. | On the domain. |
| _acme-challenge | The proof requested to issue a certificate through DNS validation. | On _acme-challenge in front of the name being certified. Added and removed automatically at every renewal. |
Every one of these formats has its own specification: SPF in RFC 7208, DKIM in RFC 6376, DMARC in RFC 7489, MTA-STS in RFC 8461, TLS-RPT in RFC 8460, certificate validation in RFC 8555. BIMI is still a work in progress, and several mail providers already honour it.
The writing rules of a TXT record
They explain most of the records that are perfectly correct and still do not work. Not one of them produces an error message. The record gets accepted, and then ignored.
| Rule | What it requires | What happens if you ignore it |
|---|---|---|
| 255 characters | A TXT fragment cannot exceed 255 characters. | The panel rejects the value, or truncates it without warning. |
| Several fragments | A longer record goes out in several fragments, which the reader joins end to end with no space. | One space added between two fragments breaks a DKIM key. |
| One SPF only | A name can carry only one record starting with v=spf1. | With two, the check fails rather than combining the authorizations. |
| No quotes in the value | Quotation marks delimit the string in a zone file. They are not part of the content. | The published record starts with a quote, and nothing recognizes it. |
| The name matters | SPF goes on the domain, DMARC on _dmarc, DKIM on a selector. | A DMARC published in the wrong place is never read, and nothing flags it. |
| Case does not matter | v=spf1 and V=SPF1 are equivalent when read. | Nothing. One of the few things here you cannot get wrong. |
| Several TXT allowed | One name can carry as many text records as you like, the single-SPF rule aside. | Nothing — though past a few dozen the answer swells, and eventually forces a second query. |
The 255-character limit per fragment and the joining rule come from the definition of the TXT format itself (RFC 1035). The single-SPF rule comes from RFC 7208.
Common questions
What is a TXT record used for?
For nothing in particular, which is precisely what it is for. It is a free-text field attached to a domain name, and it has been repurposed to carry almost anything you need to prove in public — permission to send mail, the key that signs messages, ownership of a domain, certificate validation.
Why is my DMARC record not showing up?
Because it is not there. DMARC is published on _dmarc in front of the domain, and that is the only place a receiving server will read it. The tool above queries both names and shows each one under its own.
Can a domain have two SPF records?
No, and two is worse than none. Given two records the check does not pick one. It stops in error, and your messages count as unauthenticated. To authorize several sending services, list them all inside one record.
Can a TXT record be longer than 255 characters?
The record can be, each of its fragments cannot. Past 255 characters the value goes out in several chunks that the reader joins back together. 2048-bit DKIM keys land in exactly this case, which is why some panels reject them.
Can I delete a verification TXT record once it has been verified?
Not without risk. Several services re-check on a schedule that their record is still there, and pull your access once it is gone. Tidy up service by service, and remove only the tokens of accounts you actually closed.
How long does a TXT record change take to apply?
As long as it takes the previous answer to leave resolvers' memory, which is the lifetime declared on the record. While it runs, some servers read the old value and others the new one — which is why an ownership check fails for a few hours and then passes on its own.
Can I delete a TXT record I do not recognize?
Not until you know what it does. Verification tokens have to stay for as long as the service is in use, because several of them re-check on a schedule and pull your access once the proof is gone. Two categories come off safely: an _acme-challenge proof left behind after a certificate renewal, and a value that starts with no recognized format.
I added the TXT record and the service still cannot see it
Three different clocks can explain it. The most common is negative caching. If anyone queried the name before it existed, resolvers memorized that it does not exist, and they hold that for the duration written in the zone's origin record — nothing to do with the lifetime you just chose. After that comes the service's own re-check rhythm, which DNS does not control.
The TXT records on a company domain: which ones can you delete?
The table above tells you what each line is. This one answers the question you actually have in front of a zone you inherited from somebody else. What am I allowed to remove?
example.com
Keepv=spf1 include:_spf.example.net ~allAdded by: whoever administers the mail. Delete it and messages sent from your domain lose their authorization and land in junk, when they are not refused outright. This is the most dangerous line to touch, because its absence only ever shows at the receiving end.
_dmarc.example.com
Keepv=DMARC1; p=quarantine; rua=mailto:reports@example.comAdded by: whoever administers the mail. It tells recipients what to do with messages that fail the two previous checks. Without it there is no policy and no report, so the visibility goes before the problem does.
selector1._domainkey.example.com
Keepv=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A…Added by: the mail provider, often automatically. Every selector matches a key in service. Delete the one belonging to a service still in use and its signatures become unverifiable overnight, with no message at all on the sending side.
example.com
Ask firstgoogle-site-verification=…Added by: whoever connected the domain to a service, possibly three years ago. For as long as the service is in use the token has to stay, because several services re-check on a schedule and pull your access once the proof is gone. Remove it only once you have established that nobody uses the service.
example.com
Ask firstMS=…Added by: the same person, for another service. Same reasoning. On an inherited zone these two or three lines are the ones nobody can account for, which is a reason to document them, not to delete them.
_acme-challenge.example.com
Removetemporary-validation-tokenAdded by: the automation that renews a certificate. A proof of this kind only lives for the few minutes of an issuance. Still there weeks later means a renewal failed to clean up after itself. Harmless, and useless.
example.com
Removenote left by a contractor, in no known formatAdded by: nobody knows. No software reads a value that starts with no recognized format. It does no harm, beyond lengthening the answer and cluttering every other line you are trying to read.
The values above are examples built on the domains reserved for documentation (RFC 2606); keys and tokens are truncated and belong to nobody. The formats quoted are defined by RFC 7208 (SPF), 6376 (DKIM), 7489 (DMARC) and 8555 (certificate validation over DNS).
255 characters: why a DKIM key is published in two pieces
This is the limit behind most records rejected for no reason, and it does not come from your host. It sits in the definition of the format itself.
The value exceeds the size of one fragment
A text record is built from one or more fragments, each preceded by a counter that fits in a single byte. So a fragment cannot exceed 255 characters. A 2,048-bit public key takes about 390 on its own.
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA… ← about 390 charactersIt is cut into two fragments
Nothing is lost. The value goes out as two consecutive pieces inside the same record. In a zone file that is written as two quoted strings separated by a space.
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC" "AQ8AMIIBCgKCAQEA…"The reader glues them back with nothing in between
Whoever reads the record joins the fragments end to end, with no space and no separator. Which is why a space added between the two pieces to tidy things up breaks the key. The reassembled value is no longer the right one, and the signature becomes unverifiable.
What you actually have to do
Almost nothing. Most interfaces split the value for you when you paste it. The ones that reject it outright say so with a message about length, and then you enter the fragments by hand and put nothing between them. The check at the top of this page shows the value already reassembled, so if a space appears in the middle of the key, that space is in the zone.
The maximum size of a fragment and the concatenation rule come from the definition of the text format in RFC 1035, § 3.3.14; the requirement to join fragments with no intervening whitespace is restated in RFC 6376, § 3.6.2.2.
The “name” field: where everything gets lost
You paste the value of a TXT record, so it is rarely wrong. You type the name by hand into an interface with habits of its own — and a perfect record placed at the wrong name is read by nobody, with no error message whatsoever.
The full name was typed into a relative field
You type
_dmarc.example.comWhat gets published
_dmarc.example.com.example.comMost interfaces expect the left-hand part of the name and append the domain themselves. You wanted _dmarc on its own. The record exists, it is valid, and it sits somewhere no software will ever look.
The field was left empty for a DMARC record
You type
(empty field), or @What gets published
example.comEmpty and @ both mean the domain itself. That is right for an SPF record or a verification token. It is wrong for DMARC, which has to live on _dmarc, and for a DKIM key, which has to live on a selector followed by ._domainkey.
The DKIM selector was copied without its suffix
You type
selector1What gets published
selector1.example.com._domainkey is missing. The name expected is selector1._domainkey, and the verifier looks nowhere else. It builds that name itself from the selector announced in the message signature.
The record was placed on www
You type
wwwWhat gets published
www.example.comAn SPF or DMARC record on www protects nothing. A sender's domain is whatever follows the at sign, and nobody sends mail from www. The check at the top of this page queries the name you hand it, so type the domain exactly as it appears in your email addresses.
How long before it works: three clocks, not one
Most unexplained waits come from the second one, and nobody looks at it because the record you just created has no say in it.
The record's lifetime
The one you chose
It only applies once a resolver has obtained a positive answer. On a name that did not exist yet, it has settled nothing at all.
The memory of a negative answer
Set by the zone
If anyone queried the name before you created it — a verification service, say — the resolver memorized that it does not exist. It holds to that for the duration written in the zone's origin record, which has nothing to do with the lifetime you just chose. This is the most common wait and the most disorienting: the record is visible to you and invisible to the service.
The checking service's own cycle
Unknown to you
A console waiting on a proof of ownership has its own re-check rhythm, and DNS has no say in it. Until it asks again, your record can be perfect and the button stays red. Where you can trigger a re-check by hand, that cuts the wait short.
Negative caching is defined by RFC 2308. Its duration is set by the zone's origin record, and the standard calls one to three hours sensible and anything beyond a day problematic. The last number returned by dig SOA example.com +short gives that value, and the duration actually used is the smaller of it and the origin record's own lifetime.
The costliest mistake
The name matters more than the value
A correct value under the wrong name produces no error at all. It is simply never read.
The domain itself
SPF, and the ownership proofs filed for Google or Microsoft. The only place anyone looks by reflex, which is why it fills up._dmarc before the domain
DMARC, and nowhere else. Publish it on the domain and nobody reads it, and no tool will tell you.selector._domainkey
DKIM, one per selector. The service signing your mail picks the selector, and it shows up in the header of sent messages._acme-challenge
The proof required to issue a certificate through DNS validation. Placed and removed automatically, so if one lingers, an issuance failed.
A DMARC record published in the wrong place is never read, and nothing says so.