DNS records you're not backing up
A and CNAME records are easy to remember. The ones that break your email, certificates, and SaaS integrations when they disappear are not.
Everyone remembers their A records. Point the domain at the server. Easy. CNAME for www. Got it.
But the records that actually hurt when they vanish are the ones nobody remembers setting up. The ones a contractor configured eighteen months ago. The ones that were copy-pasted from a vendor’s setup guide and never documented.
Here’s what’s sitting in your zones right now that you’d struggle to reconstruct from memory.
DKIM TXT records
DKIM is how receiving mail servers verify that an email actually came from your domain. It’s a TXT record with a long public key, usually on a subdomain like selector1._domainkey.example.com.
Lose this record and your outbound email starts failing DKIM checks. Deliverability drops. Messages land in spam or get rejected outright. The fix requires generating a new key pair and updating your email provider config — which means figuring out which email provider is even using that selector.
Most domains have multiple DKIM selectors. One for Google Workspace, one for Mailchimp, one for your transactional email service. Each is a separate TXT record. Each is critical.
SPF
Your SPF record is a single TXT record on the root domain that lists every server authorized to send email on your behalf. It typically includes references to your email provider, your marketing platform, and your transactional service.
Delete it accidentally and you’ve told the world that no one is authorized to send email for your domain. Receiving servers will soft-fail or hard-fail every message.
Worse: SPF records are cumulative. They get edited over years as you add and remove services. Reconstructing one means auditing every service that sends email on your behalf. Miss one, and that service’s emails bounce.
DMARC
DMARC ties SPF and DKIM together with a policy. It’s a TXT record at _dmarc.example.com that tells receiving servers what to do when authentication fails.
It also contains your reporting address — where you receive aggregate reports about email authentication across your domain. Lose the DMARC record and you lose both policy enforcement and visibility.
CAA records
CAA records specify which certificate authorities are allowed to issue SSL certificates for your domain. Without them, any CA can issue a cert. With them, you’ve locked it down to, say, Let’s Encrypt and DigiCert.
Lose a CAA record and your next certificate renewal might fail if the CA checks and doesn’t find itself authorized. Or worse, you silently lose a security control you’d specifically put in place.
SRV records for Microsoft 365 and SIP
Microsoft 365 uses SRV records for autodiscover, SIP federation, and Teams. These records look like _sip._tls.example.com and _sipfederationtls._tcp.example.com.
Lose them and Outlook autodiscovery breaks. Teams federation stops working. Users can’t find your tenant. The error messages are vague, and the troubleshooting docs are long.
MX priorities
MX records themselves are obvious. But the priorities matter. If you have a primary mail server at priority 10 and a fallback at priority 20, swapping those numbers routes all your email to the fallback. Deleting the fallback means no redundancy. Changing the values means mail goes to the wrong place.
The pattern
These records share two things: they were set up once by someone who understood the context, and they’re invisible until they break. You won’t notice a missing DKIM selector during normal operations. You’ll notice it when a client says your invoices are going to spam.
BackupMyDNS captures every record type your provider’s API returns — TXT, SRV, CAA, MX, all of it. Every change is tracked. When something disappears, you’ll know what it was, when it changed, and exactly what to restore.
Your first domain is free. Back it up before someone deletes something they shouldn’t.