How to Add a TXT Record in Porkbun

What Is a TXT Record and Why Porkbun Needs One

A TXT (text) record is a DNS record type that stores arbitrary text data at a hostname, defined in RFC 1035 §3.3.14. Each string inside a TXT record is limited to 255 bytes, but a record can concatenate multiple quoted strings — which is why long DKIM keys sometimes arrive pre-split into several "..." "..." segments. Porkbun stores whatever value you paste into the Answer field and serves it back over standard DNS queries; it doesn't interpret or validate what the string means.

Porkbun uses TXT records for the same purposes any registrar's DNS does: proving domain ownership (Google Search Console, Microsoft 365, Zoho, GitHub Pages), publishing email authentication policy (SPF, DKIM, DMARC), and satisfying ACME challenges for wildcard SSL certificates. Because TXT is a general-purpose container, one domain can have many TXT records at different hosts — root, _dmarc, google._domainkey — without conflict, as long as none of them duplicate the same host with a competing v=spf1 string (the classic "two SPF records" bug covered below).

Porkbun's dashboard doesn't distinguish "verification TXT" from "SPF TXT" — they're all the same record type, just with different Host and Answer values. Understanding that upfront prevents a common mistake: creating a second v=spf1 record instead of editing the existing one when you add a new mail provider. If you're setting up mail auth specifically, see the SPF Record Generator guide for building the value correctly before you paste it here.

Step-by-Step: Adding a TXT Record in Porkbun

1. Log in to your Porkbun account and land on the Domain Management screen, which lists every domain in the account.

2. Click the "DNS" button under the domain you're editing. (You can also click Details next to the domain, then the edit icon under DNS Records — both paths open the same Manage DNS Records screen.)

3. Click "Add Record" to open the new-record form.

4. Set Type to TXT. Porkbun's form doesn't add any TXT-specific fields beyond the standard Host/Answer/TTL set — there's no proxy toggle or priority field to worry about, since Priority only applies to MX and SRV records.

5. Enter the Host exactly as given. For a root-domain record (example.com), leave Host blank. For a record at a subdomain — _dmarc.example.com or google._domainkey.example.com — enter only the subdomain portion (_dmarc or google._domainkey); Porkbun appends the zone apex automatically. Don't type the domain twice — _dmarc.example.com.example.com is a common copy-paste error.

6. Paste the Answer field exactly, including quotes if given. Copy-paste rather than retype; TXT values are case-sensitive and a single dropped character invalidates SPF, DKIM, and most verification tokens.

7. Leave TTL at the default. Porkbun's minimum TTL is 600 seconds (10 minutes); drop it lower only if you're actively troubleshooting and plan to raise it back once verification succeeds.

8. Click Add. The record appears in the list immediately. According to Porkbun's own documentation, brand-new records typically resolve globally within seconds on Porkbun's nameservers, while edits to an existing record can take up to the old record's TTL (10 minutes minimum) to fully clear from caching resolvers.

9. Confirm propagation before re-checking with the third party — see the CLI and tool checks below.

Host Field Reference Table

The Host field is the most common source of TXT record failures in Porkbun — an extra domain suffix or a mismatched selector produces a record that saves successfully but never matches what the verifying service looks up.

Verifying the Record with dig and nslookup

Run these from a terminal after saving, using your zone's actual name in place of example.com:

# Query the TXT record directly from Porkbun's authoritative nameservers
dig TXT _dmarc.example.com @curitiba.ns.porkbun.com +short

# Query from your local resolver to check what's actually propagated to you
dig TXT example.com +short

# Windows/macOS equivalent
nslookup -type=TXT _dmarc.example.com

If the direct-to-Porkbun query returns the record but your local resolver doesn't yet, the record itself is correct and you're waiting on resolver cache TTL — not a Porkbun misconfiguration. Cross-check global visibility with the DNS Propagation Checker, or confirm the exact record set with the DNS Lookup tool.

Common Issues & Troubleshooting

Problem: The verifying service says the TXT record isn't found, but Porkbun shows it saved. Cause: usually a Host field mismatch — a trailing domain suffix, wrong selector, or the record was added to a different domain in the account (easy to do if you manage several). Fix: re-open the record in Porkbun and compare the Host character-for-character against what the third party specified, then re-verify with dig.

Problem: SPF stopped working after adding a new TXT record. Cause: two v=spf1 records now exist at the root host. RFC 7208 §4.5 requires exactly one SPF record per domain — two or more causes a PermError, which most receivers treat as an outright SPF fail. Fix: merge both include: mechanisms into a single v=spf1 string rather than adding a second record. See the SPF Record Generator guide for building one merged value.

Problem: Long DKIM key gets rejected or looks truncated. Cause: DKIM public keys frequently exceed 255 bytes, and some providers generate the value already pre-split into quoted segments ("part1" "part2"), which Porkbun expects verbatim in the Answer field. Fix: paste the full string exactly as your provider gave it, including any existing quote splits. Don't manually re-wrap or shorten it. See the DKIM Selector guide for selector-naming specifics.

Problem: Record shows in Porkbun but a global checker reports NXDOMAIN. Cause: the domain's nameservers at the registrar don't point to Porkbun's DNS yet, so none of Porkbun's records are authoritative for the domain. Fix: confirm delegation with the NS Lookup tool before troubleshooting the TXT record itself — a record in the right zone with the wrong nameservers upstream will never resolve publicly.

Problem: Edited an existing TXT record but the old value still resolves. Cause: per Porkbun's own propagation guidance, edits (unlike brand-new records) are subject to the previous record's TTL — resolvers keep serving the cached old value until it expires. Fix: wait out the TTL (10 minutes minimum on Porkbun), or query Porkbun's authoritative nameservers directly with dig to confirm the new value already saved correctly server-side.

Key Takeaways

• ✓ In Porkbun, leave Host blank for a root-domain TXT record; enter only the subdomain portion for anything else.
• ✓ Per RFC 1035, each string in a TXT record is capped at 255 bytes; long values may arrive pre-split into quoted segments — paste them verbatim.
• ✓ A domain must have exactly one v=spf1 TXT record (RFC 7208 §4.5) — a second one causes PermError, not stacking.
• ✓ New Porkbun records typically resolve within seconds to minutes; edits to existing records can take up to the old TTL (minimum 600 seconds) to clear from caches.
• ✓ Verify the Host field character-for-character — it's the single most common cause of "saved but not found" verification failures.

Frequently Asked Questions

Next Steps

Once the record is saved, confirm it resolves correctly with the DNS Lookup tool and check global propagation with the DNS Propagation Checker. If verification still fails after the record looks correct, confirm your domain's nameservers actually point to Porkbun using the NS Lookup tool, or check for a stale reverse mapping with Reverse DNS Lookup. For deeper background on TXT record syntax and other record types, see DNS TXT Records Explained. Managing DNS at a different registrar or platform instead? See How to Add a TXT Record in Cloudflare, How to Add a TXT Record in GoDaddy, How to Add a TXT Record in Namecheap, or How to Add a TXT Record in Amazon Route 53 for the equivalent steps.