What a zone file line actually is
Every record is five fields: owner name, TTL, class, type, and the type-specific data. The class is IN and has been for every record you will ever write. So www.example.com. 3600 IN A 203.0.113.10 reads as: the name www.example.com, cacheable for an hour, in the internet class, is an address record pointing at that IPv4 address. Web control panels split those fields into boxes and usually hide the class, but the underlying record is the same and knowing the raw form makes provider documentation legible.
The trailing dot on the owner name is not decoration. A name ending in a dot is absolute. A name without one is relative to the zone, and the zone name gets appended. Write www.example.com without the dot in a zone for example.com and you have published www.example.com.example.com, which resolves for nobody and looks correct at a glance. This is the single most common zone file error and it survives review because the string you typed is right there and reads correctly.
The apex, and why CNAME cannot go there
The apex is the domain itself — example.com with nothing in front. It is not an ordinary name: it always carries the SOA record that defines the zone and the NS records that delegate it. The rule for CNAME is that a name carrying one may carry no other record of any type, because a CNAME says "everything about this name is over there instead". Those two facts collide at the apex, so a CNAME there is invalid, and a resolver that gets both a CNAME and NS records for one name has no defined behaviour.
The practical consequence is that you cannot point a bare domain at a hostname using standard DNS. The workarounds are an A or AAAA record with a real address in it, or a provider-specific alias record type that resolves the target at query time and returns addresses rather than a CNAME. Those alias types are not part of the DNS specification, they are not portable between providers, and they behave differently from each other, so read your provider documentation rather than assuming a record called ALIAS somewhere else works the same way.
TXT records, 255 characters, and SPF
A TXT record contains one or more character strings, and each individual string is limited to 255 characters. The record as a whole can be longer, because it may hold several strings, and a reader concatenates them with nothing in between. So a 400-character policy is published as two quoted strings side by side on one line — not two records, and not one string with a line break in it. Providers that give you a single text box usually do this splitting for you; providers that do not will reject the value with an unhelpful error.
SPF has its own set of hard rules. It is published as a TXT record — the dedicated record type numbered 99 was retired and should not be used. The value must start with v=spf1. There may be exactly one such record per domain: two of them is a permanent error, and the usual outcome is that receivers apply neither, which is worse than having none. Evaluating a policy is limited to 10 DNS lookups, and every include, a, mx and exists term costs at least one, with nested includes costing more. Going over the limit is also a permanent error. Policies grow one vendor at a time until they cross the line, and nothing tells you.
MX priority, and the target that must not be a CNAME
An MX record has two parts: a preference number and a hostname. Lower numbers are tried first, so 10 is preferred over 20. Numbers with the same value share traffic between them. The actual values do not matter — 10 and 20 behave identically to 1 and 2 — so the spacing convention exists only to leave room to insert something later.
The target must be a hostname that has an A or AAAA record of its own, and it must not be an IP address and must not be a CNAME. Both of those are stated in the mail standards and both are still published regularly, because most of the time they appear to work: many senders will follow a CNAME anyway. The failures show up with the strictest receivers, intermittently, and are miserable to diagnose. Point MX at a name that resolves directly to an address.
CAA, and what it does not do
A CAA record lists which certificate authorities are permitted to issue for a name. It is consulted by the authority at the moment of issuance and by nothing else — no browser checks it, no resolver enforces it, and it has no effect on certificates already issued. It is a control on future issuance, not a runtime protection, and describing it as either more or less than that leads to bad decisions. A record on the apex covers everything below it unless a closer name has its own, so publishing one that lists a single authority will block every other authority for the whole tree, including one some other team quietly uses.
Everything on this page is syntax and rule checking on text you typed. No query is sent, nothing is resolved, and no comparison is made against what is currently published — for that you need a resolver, and this page deliberately is not one. If you are working through the HTTP side of the same deployment, the status code reference and the cache header builder cover the layer above.
Questions people ask
Why does my provider reject a CNAME on the bare domain?
Because standard DNS does not allow it. The apex must carry SOA and NS records, and a name with a CNAME is not permitted to carry any other record, so the two requirements cannot both hold. Providers that appear to allow it are using a non-standard alias record that resolves the target and returns addresses instead of a CNAME. That works, it is not portable to another provider, and the behaviour around TTLs and geographic answers differs between implementations.
My TXT value is 380 characters. Do I publish two records?
No — one record containing two strings. The 255-character limit applies to a single string inside the record, not to the record. The correct zone line has two quoted strings separated by a space, and any reader joins them with nothing in between. Publishing two separate TXT records is a different thing entirely, and for SPF specifically it is a permanent error that causes the policy to be ignored.
Can I have two SPF records if one is for a subdomain?
Yes, because they are different names. The rule is one SPF record per name, not per organisation. mail.example.com may have its own policy, entirely separate from the one on example.com, and subdomains do not inherit the parent policy. What you must not do is publish two TXT records both starting v=spf1 on the same name. To authorise an additional sender, edit the single existing record.
What TTL should I use before moving a service?
Lower the TTL to a few minutes at least one full old-TTL period before the change, so every cached copy of the old value has expired and been refetched with the short value. Then make the change, watch it, and raise the TTL again once you are confident. Lowering the TTL at the moment of the cutover does nothing, because resolvers that already hold the record hold it with the old, long TTL and will not come back to see the new one.
Does this tool check my domain live?
No, and it cannot. Everything runs in the page on the text in the fields — nothing is sent anywhere and no name is resolved. It validates the shape of the record against the rules for that type, splits a long TXT value correctly, and points out the mistakes that are visible in the record itself. Whether the record conflicts with something already published, or whether the target actually exists, needs a resolver, and that is a separate step.