Online Tool Store
· 4 min read
How to Write DNS Records That Actually Work
Manesh Jayawardhana
CIO & Co-founder
Email stops working after a DNS change. The MX record looks correct in the control panel. It takes two hours to notice that the target reads mx1.provider.net.example.com — because someone left off a trailing dot, and DNS helpfully appended the zone name.
DNS syntax has a small number of rules that produce a large number of outages. Most of them come down to two: the dot, and how many SPF records you’re allowed.
The rules that cause the most breakage
The trailing dot. A name ending in a dot is absolute — fully qualified, taken literally. A name without one is relative, and the zone name gets appended. mx1.provider.net in a zone for example.com becomes mx1.provider.net.example.com, which resolves to nothing.
The complication is that many hosting control panels add the dot themselves, so typing it produces a double dot and breaks the record a different way. Whether you type it depends on the interface, which is why this catches people who’ve done it correctly a hundred times elsewhere.
One SPF record only. A domain may publish exactly one SPF record. Two TXT records that both start v=spf1 cause a permanent error at the receiving server, and mail from every sender starts failing — not just the one you added. Multiple senders go into one record as multiple include: statements. RFC 7208 is explicit about this, and it’s still the most common email authentication mistake.
TTL and migrations. A record cached with a 86,400-second TTL keeps serving the old value for a day after you change it. Lowering the TTL well before a migration — at least a full old-TTL period ahead — is what makes a cutover quick.
Why people get stuck here
- No feedback. A malformed record doesn’t error; it just doesn’t work, sometimes for a subset of users.
- Propagation confusion. Changes appear instantly for you and hours later for others, depending on what cached what.
- Panel inconsistencies. Every provider’s interface handles the trailing dot and the
@symbol slightly differently. - Root CNAME. You can’t put a CNAME at the domain apex, and the workarounds are provider-specific.
What good DNS hygiene looks like
Low TTL before a change, higher after
Drop to 300 seconds a day or more before a migration. Raise it back afterwards, because a permanently low TTL means more queries and slower first loads.
One SPF, all senders included
Audit which services send mail as your domain — marketing platform, ticketing system, application server — and put every one in a single record.
Verified from outside your network
Check a record with a public resolver rather than your own, which may have cached something helpful.
| Record | Common Mistake | Effect |
|---|---|---|
| MX | Missing trailing dot | Mail fails silently |
| SPF | Two TXT records | All authentication fails |
| CNAME | Placed at the root | Invalid zone |
| TTL | Left high before migration | Long cutover, stale results |
Common mistakes to avoid
- Adding a second SPF record for a new sender instead of extending the existing one.
- Setting a CAA record without including every certificate authority you actually use, which blocks renewals.
- Leaving a wildcard record in place that catches typos and sends them somewhere unexpected.
- Testing only from your own machine, where the resolver may have the new value already.
- Deleting an old record immediately after adding its replacement, before caches have expired.
How to do it with DNS Record Generator
The DNS Record Generator formats records with the syntax rules applied.
- Choose the record type and enter the host and target.
- Pick a TTL — low while you’re making changes, higher once things are stable.
- Copy the record into your zone file or provider panel.
- Check whether your panel adds the trailing dot itself before pasting one.
- Verify from an external resolver, not from your own network.
Other network diagnostics are in the tools directory.
Frequently asked questions
Why can there be only one SPF record?
Because a receiving server that finds two treats the result as a permanent error, and mail from every sender starts failing authentication. Merge all senders into a single record with multiple include: statements.
What TTL should I use before a migration?
Drop it to around 300 seconds at least one full old-TTL period before the change, so caches have expired by the time you cut over. Raise it again once the new value is stable.
Can a CNAME sit at the domain root?
Not in standard DNS — the apex needs SOA and NS records, which a CNAME can’t coexist with. Providers offer ALIAS or ANAME records as a workaround, but they’re provider-specific rather than standard.
Final thought
Before saving any record, check two things: does it need a trailing dot in this panel, and does a record of this type already exist? Those two questions prevent most DNS outages.