SSL & Certs Intermediate

Certbot DNS-01 TXT Record Mismatch on macOS: Troubleshooting Guide

Fix Certbot DNS-01 challenge failures on macOS caused by TXT record mismatches. Diagnose propagation, incorrect entries, and local caching issues.

👨‍💻
Senior Systems Architect • Verified in Staging Labs

Fix Certbot DNS-01 challenge failures on macOS caused by TXT record mismatches. Diagnose propagation, incorrect entries, and local caching issues.

Acquiring SSL/TLS certificates using Certbot's DNS-01 challenge is an essential method for securing domains, especially for wildcard certificates or servers not directly exposed to the internet. However, encountering "TXT record mismatch" errors on your macOS local environment can be a frustrating roadblock. This guide will walk you through the common causes and provide a structured approach to resolve these issues, ensuring your Certbot DNS-01 challenge completes successfully.

Symptom & Error Signature

When running Certbot to obtain or renew a certificate using the DNS-01 challenge, you will typically see an error similar to one of these in your terminal output:

Certbot failed to authenticate some domains (authenticator: manual). The Certificate Authority reported these problems:
  Domain: example.com
  Type:   dns
  Status: invalid
  Detail: The key authorization was not found or was not in the expected state for any of the URLs provided.

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: _acme-challenge.example.com
   Type:   dns
   Status: invalid
   Detail: Incorrect TXT record "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" found at _acme-challenge.example.com. Expected "yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy".

Alternatively, you might see:

Certbot failed to authenticate some domains (authenticator: dns-cloudflare). The Certificate Authority reported these problems:
  Domain: _acme-challenge.example.com
  Type:   dns
  Detail: During secondary validation: DNS problem: NXDOMAIN looking up TXT for _acme-challenge.example.com - check that a DNS record exists for this domain

The key indicator is Incorrect TXT record, NXDOMAIN looking up TXT, or any message implying that Let's Encrypt could not find or validate the expected TXT record.

Root Cause Analysis

A "TXT record mismatch" error during a Certbot DNS-01 challenge on macOS typically stems from one of several issues related to how the DNS record is created, propagated, or resolved:

  1. DNS Propagation Delays: This is the most common culprit. DNS changes, especially new records, can take time to propagate across global DNS servers. Let's Encrypt performs checks from multiple geographic locations, and if your record hasn't fully propagated to all of them, verification will fail.
  2. Incorrect TXT Record Value: A simple typo, an extra space, or copying an incomplete or incorrect challenge string (the yyyyyyyyyyyyyyy part) into your DNS provider's interface.
  3. Incorrect TXT Record Name: The record name must be _acme-challenge.yourdomain.com. Common mistakes include missing the _acme-challenge. prefix, using the apex domain only, or an incorrect subdomain.
  4. Conflicting or Multiple TXT Records: If there are multiple _acme-challenge.yourdomain.com TXT records, or an old one still exists from a previous attempt, Let's Encrypt might pick up the wrong one or become confused.
  5. DNS Provider Specific Issues: Some DNS providers have quirks in their interfaces (e.g., automatically appending the domain name, requiring quotes for TXT values). Internal caching or API delays at the provider can also contribute.
  6. macOS Local DNS Cache: While less likely to affect Let's Encrypt's external validation, a stale DNS cache on your macOS machine could prevent you from seeing the actual current DNS record, leading to misdiagnosis during your own verification steps.
  7. Certbot Configuration Error (DNS Plugins): If you're using a Certbot DNS plugin (e.g., certbot-dns-cloudflare), incorrect API credentials, insufficient permissions, or a misconfiguration of the plugin itself can lead to it failing to create or update the record correctly.

Step-by-Step Resolution

Follow these steps meticulously to diagnose and resolve your Certbot DNS-01 TXT record mismatch.

1. Verify the TXT Record Manually

Before anything else, check the TXT record yourself from your macOS terminal and an online tool. This helps confirm what DNS servers are currently reporting.

  • From your macOS terminal:

    dig -t TXT _acme-challenge.yourdomain.com +short
    

    Replace yourdomain.com with your actual domain. The output should be the exact TXT record string provided by Certbot. For example, if Certbot asks for yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy, dig should return "yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy".

  • Using online DNS checkers: Visit websites like whatsmydns.net or dnschecker.org. Enter _acme-challenge.yourdomain.com and select "TXT" as the record type. Observe the results from various global locations.

    The value returned by dig might include quotes ("value"). When entering the TXT record in your DNS provider's interface, you usually do not include these quotes unless specifically instructed by your provider.

2. Confirm DNS Propagation

If dig or online tools show the correct record from some locations but not all, it's a propagation issue.

DNS propagation can take anywhere from a few minutes to several hours, depending on your DNS provider's TTL (Time To Live) settings and network conditions. Patience is key here. Wait until a majority of global DNS servers report the correct TXT record before attempting Certbot again.

3. Inspect and Clean Up TXT Records

Log in to your DNS provider's control panel and navigate to your domain's DNS management section.

  • Ensure the Record Name is Correct: Verify that the "Host" or "Name" field for your TXT record is exactly _acme-challenge (your DNS provider usually appends the domain automatically, resulting in _acme-challenge.yourdomain.com).
  • Verify the TXT Value: Double-check that the value (the string provided by Certbot) is entered precisely, with no extra spaces, characters, or missing parts.
  • Remove Conflicting Records: Look for any other TXT records associated with _acme-challenge.yourdomain.com. If you find old or duplicate entries, delete them. Only one TXT record with the current challenge string should exist.

4. Clear macOS DNS Cache

While not directly impacting Let's Encrypt's validation servers, clearing your local DNS cache on macOS ensures that your dig commands and other network tools are retrieving fresh DNS information.

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

After running these commands, re-run your dig check to confirm if it makes any difference.

5. Extend Certbot's DNS Challenge Timeout (Manual Challenges)

If you are using the --manual authenticator and frequently encounter propagation issues, you might need more time between adding the record and Certbot checking it.

certbot certonly 
  --manual 
  --preferred-challenges dns 
  --email [email protected] 
  --agree-tos 
  -d yourdomain.com 
  -d *.yourdomain.com 
  --manual-auth-hook "/path/to/your/auth_hook.sh" 
  --manual-cleanup-hook "/path/to/your/cleanup_hook.sh" 
  --manual-public-ip-logging-ok 
  --server https://acme-v02.api.letsencrypt.org/directory 
  --manual-auth-extra-delay 300 # Add a 300-second (5 minute) delay

The --manual-auth-extra-delay flag gives you and the DNS propagation additional time. Adjust the value (in seconds) as needed.

If you're using a DNS plugin, consult its specific documentation for timeout configurations, as --manual-auth-extra-delay might not apply.

6. Double-Check Certbot Command and DNS Plugin Configuration

If you're using a Certbot DNS plugin (e.g., certbot-dns-cloudflare, certbot-dns-route53, certbot-dns-digitalocean):

  • API Credentials: Ensure your API key/token and secret are correct and stored securely (e.g., in a ~/.secrets/certbot/cloudflare.ini file) as per the plugin's documentation.
  • Permissions: Verify that the API credentials have the necessary permissions to read and modify DNS records for your domain.
  • Plugin Installation: Confirm the plugin is correctly installed (pip install certbot-dns-yourprovider).
  • Domain Mapping: Ensure the domain specified in your Certbot command (-d yourdomain.com) matches the domain configured with your DNS plugin.

Example using a plugin:

certbot certonly 
  --dns-cloudflare 
  --dns-cloudflare-credentials ~/.secrets/certbot/cloudflare.ini 
  --dns-cloudflare-propagation-seconds 60 
  --email [email protected] 
  --agree-tos 
  -d yourdomain.com 
  -d *.yourdomain.com

7. Utilize Certbot Staging Environment

During troubleshooting, it's highly recommended to use Let's Encrypt's staging environment. This helps you avoid hitting rate limits on the production server.

certbot certonly --staging ... # Add your other Certbot flags here

The --staging flag tells Certbot to use the test ACME server. Once successful there, remove --staging to issue a production certificate.

8. Review DNS Provider Documentation

Each DNS provider has its own interface and specific requirements for adding TXT records. If you're still stuck, consult your provider's official documentation or support channels for instructions on adding TXT records. Pay close attention to how they handle subdomains and if they automatically append the domain name.

By systematically working through these steps, you should be able to pinpoint the exact cause of your Certbot DNS-01 TXT record mismatch and successfully obtain your SSL/TLS certificate.

👨‍💻

Johnathon Wheeler

Senior Systems Architect & DevOps Engineer • Austin, TX

Connect on LinkedIn →

Johnathon has over 16 years of hands-on experience designing, debugging, and scaling Linux web hosting stacks, container clusters, and high-availability database architectures. Every guide on ButItWorkedLocal is independently tested against Debian 12, Ubuntu 24.04/22.04 LTS, Rocky Linux, and Docker environments to guarantee reproducibility in production.

🛡️

Our Production Verification Guarantee

Encountering a bug not covered here or running a non-standard kernel configuration? Our solutions are continually refined against real production incidents. Submit an environment trace for our editorial team to replicate.