XiaTools

Linode DNS Manager: How to Publish DKIM TXT Records

By Rohit, founder of XiaTools · Updated 22 Oct 2026

Setting up email authentication can feel daunting, but getting your cryptographic signatures right is essential for deliverability. To verify your outbound messages, you need to publish DomainKeys Identified Mail records in your zone file using the Linode DNS Manager. Before you push changes live, you can always test your configuration using the DKIM Checker to instantly validate your public key syntax and ensure your emails pass receiving server checks.

Understanding DKIM and Linode DNS

DomainKeys Identified Mail (DKIM) adds a cryptographic signature to every outgoing email header. This signature matches a public key published in your domain's DNS records, proving to mailbox providers like Gmail and Microsoft that the message genuinely originated from your domain and was not altered in transit.

Linode provides a robust, highly available nameserver infrastructure accessible through its Cloud Manager. While Linode does not host your mail server, its DNS Manager acts as the authoritative nameserver holding your DNS zone records, including your crucial DKIM TXT entries.

Prerequisites for DKIM Setup

Before you touch the Linode DNS Manager, you must gather specific pieces of information from your email service provider, such as Google Workspace, Microsoft 365, Postfix, or a transactional mail provider like Mailgun or SendGrid.

  • Selector Name: A unique string (e.g., default, google, mail) that helps receiving servers locate the correct public key within your domain.
  • Public Key Data: A long string of characters (usually Base64 encoded) representing your public cryptographic key.
  • Domain Name: The root domain (e.g., example.com) where the record will live.

Step-by-Step: Adding a DKIM TXT Record in Linode DNS

Follow these steps to publish your DKIM record using the Linode Cloud Manager interface. Note that menu paths in cloud control panels may differ slightly depending on UI updates, but the core DNS zone editing workflow remains consistent.

Step 1: Log in and Access the DNS Manager

  1. Navigate to the Linode Cloud Manager and log in to your account.
  2. In the left-hand navigation menu, click on Domains to view your list of hosted DNS zones.
  3. Locate the domain name (e.g., example.com) where you want to add the DKIM record and click the Edit button (pencil icon) next to it.

Step 2: Prepare Your DNS Record Values

DKIM records are published as standard TXT records. They follow a very strict syntax. The hostname combines your selector and a mandatory sub-prefix.

  • Record Type: TXT or TXT Record
  • Hostname / Name: [selector]._domainkey (For example: default._domainkey or google._domainkey). Crucial tip: In the Linode DNS Manager, you usually only enter the subdomain part. If your full record name is default._domainkey.example.com, you enter default._domainkey in the hostname field, leaving off your root domain to prevent duplication.
  • TTL (Time to Live): Set this to Default or 3600 (1 hour) during setup. You can lower it beforehand if you plan to rotate keys.
  • Value / Text: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQ... (Paste the exact public key provided by your email service, wrapped in quotation marks if required by the interface).

Step 3: Save and Publish the Record

  1. Scroll to the bottom of your domain's zone file records list in the Linode interface and click Add a TXT Record.
  2. Paste your prepared Hostname and Value into the respective fields.
  3. Click Save Changes.

Linode will immediately push this record out to its authoritative nameservers. Global propagation usually takes anywhere from 5 to 30 minutes, depending on the TTL values of cached queries across the internet.

Exact Record Syntax and Examples

To ensure you do not encounter syntax errors, review how a properly formatted Linode TXT record looks in practice. For testing environments, assume your domain is example.com and your documentation IP network is 192.0.2.0/24 for your mail server subnet.

Field Example Value Notes
Record Type TXT Must be a TXT record, not CNAME (unless using CNAME flattening services)
Hostname mail._domainkey Combines your selector (mail) with ._domainkey
TTL 3600 1 hour is standard for propagation speed
Value v=DKIM1; k=rsa; p=MIIBIjANBg... Must begin with v=DKIM1; and include p= public key data

Here is how the zone file entry conceptually appears in raw zone file format:

mail._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEB..."

Verifying Your Linode DNS DKIM Setup

Once published, you must verify that the record is globally accessible and syntactically valid. You can use command-line tools or web utilities to verify your work.

Using Command Line Tools

Open your terminal or PowerShell prompt and run a DNS query using dig or nslookup:

dig TXT mail._domainkey.example.com +short

On Windows PowerShell, use:

Resolve-DnsName -Name mail._domainkey.example.com -Type TXT

If configured correctly, the output should return your exact public key string enclosed in quotation marks.

Common Mistakes and How to Fix Them

Even experienced engineers occasionally trip over subtle DNS formatting rules. Watch out for these common pitfalls:

  • Duplicating the Domain Name in the Hostname: Entering default._domainkey.example.com into the Linode hostname field results in Linode expanding it to default._domainkey.example.com.example.com, which breaks the lookup. Always strip the root domain from the hostname field.
  • Line Breaks in the Public Key: Copy-pasting long RSA public keys can introduce hidden newline characters. Ensure the p= string is one continuous, unbroken block of text.
  • Exceeding Character Limits: Standard DNS TXT records have a 255-character limit per string. Modern 2048-bit DKIM keys exceed this length and must be split into multiple quoted strings within the same record, though Linode's form interface usually handles string concatenation automatically if you paste the key in full.
  • Propagation Delays: Testing immediately after saving often leads to false negatives. Give the global DNS network a few minutes to update before panicking.

DKIM Setup Checklist

  • Obtain the exact selector and public key from your mail provider.
  • Log in to the Linode Cloud Manager and open the DNS Manager for your domain.
  • Create a new TXT record.
  • Enter [selector]._domainkey in the hostname field without your root domain.
  • Paste the full v=DKIM1; ... public key string into the value field.
  • Save the record and verify propagation using dig or an online validator.

Frequently asked questions

What should I do if my DKIM key is longer than 255 characters?

Modern 2048-bit DKIM keys frequently exceed 255 characters. When pasting into the Linode DNS Manager TXT record field, simply paste the full string. Linode's interface automatically manages string splitting behind the scenes for standard zone file compliance.

Can I use a CNAME record instead of a TXT record for DKIM?

Yes, many modern email providers like Google Workspace or Microsoft 365 use CNAME-based DKIM setup (often called CNAME flattening or delegation). In this case, you will create a CNAME record in the Linode DNS Manager pointing your selector subdomain directly to the target record provided by your mail host instead of a TXT record.

How long does it take for Linode DNS changes to propagate?

Linode updates its authoritative nameservers almost instantly when you click save. However, global propagation depends on the Time to Live (TTL) values cached by intermediate recursive resolvers across the internet, which typically takes between 5 and 30 minutes.

Why is my email still failing authentication after adding the DKIM record?

Authentication failures usually happen due to a typo in the selector name, a malformed public key string containing accidental line breaks, or because your mail server is not actually signing outgoing messages with that specific selector key yet.

Do I need to include my root domain name in the Linode Hostname field?

No. Linode automatically appends your root domain name to the end of any record you create. Entering `default._domainkey` is correct, whereas entering `default._domainkey.example.com` will create a broken duplicate domain entry.

Related articles

Free tools