What are the best practices for naming and documentation?

Think about the last time someone left your team and took all the DNS knowledge with them. Suddenly nobody knows what sel2._domainkey.yourdomain.com is for, or whether it's safe to delete. Good naming and documentation is how you make sure that never happens.

Start with naming. Your DNS record names should tell you something before you even click on them. Use clear, descriptive subdomains like mail.yourdomain.com, tracking.yourdomain.com, or selector1._domainkey.yourdomain.com. If you're managing DNS records across multiple domains, keep the naming convention identical across all of them. Someone maintaining newsletter.brand-a.com should immediately recognize the equivalent on newsletter.brand-b.com. Cryptic abbreviations might save you three keystrokes today and cost you two hours of confusion later.

Documentation is where most teams fall short. A shared spreadsheet or internal wiki page beats a folder of half-remembered Slack messages every time. For each record, capture these five things:

• What it does (e.g., "DKIM selector for Mailchimp transactional sends")
• Who owns it (the person or team responsible for it)
• When it was created and last modified
• Why it exists (which service or campaign it supports)
• What breaks if you remove it (dependencies matter a lot here)

That last field is the one teams skip most often. Knowing a record exists is useful. Knowing that deleting it will break your DKIM signing for your entire transactional stream is essential. (You'd be surprised how many production incidents trace back to someone "cleaning up" an old-looking record with no context.)

Format-wise, a simple table works well. Link each row to the related service documentation where you can, for example the DKIM setup page from your ESP or your hosting provider's DNS guide. Store it somewhere the whole team can access, not in one person's Google Drive folder.

If you're managing DNS records for more than one domain, add a "Domain" column and keep everything in one master document. Splitting into per-domain files sounds logical until you need to do a cross-domain audit and you're juggling six separate spreadsheets.

But one more thing worth noting: date your documentation updates. If the last entry in a record's history is from 2019 and you're in 2025, that's a flag to go verify it still does what you think it does.

If you want to check whether your existing records are set up correctly before you start documenting, our free email header analyzer is a good starting point. And if you're in the middle of a DNS migration or reorganization, the DNS migration guide is worth a read first.