Publishing DMARC, SPF and DKIM on common DNS hosts

21 May 2026 · 13 min read

You can have the perfect DMARC, SPF and DKIM values worked out and still fail authentication, because the records never make it into DNS correctly. The values are only half the job. The other half is publishing them as the right record type, at the right name, in the right zone, without your provider's editor quietly mangling them. Every DNS host has its own quirks: some strip trailing dots, some refuse long TXT values, some flatten CNAMEs at the apex in ways that break DKIM, and most of them disagree about whether you type @, your bare domain, or a fully qualified name in the host field.

This guide walks through publishing all three records on the four hosts most people use: Cloudflare, GoDaddy, Namecheap and AWS Route 53. For each one you get the exact steps, then we cover the cross-provider gotchas that catch everyone, chiefly TXT chunking on long DKIM keys and CNAME flattening at the apex. Throughout, verify your work with the free DMARC checker, SPF checker and DKIM checker rather than trusting the editor's "saved" confirmation.

If the mechanics of these records are still fuzzy, read What is DMARC, What is SPF and What is DKIM first. This article assumes you know what each record does and focuses purely on getting it published.

The three records and where they live

Before touching any provider, fix the target names in your head. The single most common publishing mistake is putting the right value at the wrong name.

• SPF is one TXT record published at the root of your domain. The host name is your bare domain (example.com), which most editors represent as @. The value starts with v=spf1 and you must have exactly one such record. Two SPF records is a permanent error, covered in Fix SPF PermError.
• DMARC is one TXT record published at the special subdomain _dmarc. The host name is _dmarc (which becomes _dmarc.example.com). The value starts with v=DMARC1. Build it with the DMARC generator if you have not got one yet.
• DKIM is published per selector at selector._domainkey. The host name is something like s1._domainkey or google._domainkey, giving s1._domainkey.example.com. The value is either a long TXT record holding the public key, or a CNAME pointing at your provider's hosted key. Which one you use depends on your sending platform. See DKIM selectors explained.

Two rules apply on every host:

1. Never type the full record name twice. Editors append your domain automatically. If you enter _dmarc.example.com in the host field, you usually create _dmarc.example.com.example.com, which resolves to nothing. Enter only the prefix: _dmarc, @, s1._domainkey.
2. Underscores are mandatory and literal. _dmarc and _domainkey must keep their leading underscore. Some old editors strip or reject underscores; if yours does, that host cannot publish DMARC or DKIM and you have a bigger problem.

Cloudflare

Cloudflare is the most forgiving of the four and the one we recommend, partly because it does TXT chunking and apex CNAME flattening for you instead of against you.

To add a record:

1. Log in and select your domain, then open DNS then Records.
2. Click Add record.
3. Choose the Type (TXT or CNAME).
4. In Name, enter the prefix only. For DMARC type _dmarc. For SPF type @. For DKIM type s1._domainkey (your selector).
5. In Content, paste the full value. Cloudflare does not want surrounding quotes; it adds them internally.
6. Leave TTL on Auto, and for any new record leave Proxy status as DNS only (the grey cloud). TXT and the _domainkey records cannot be proxied anyway, but it is worth checking.
7. Save.

Concrete examples, entered exactly as shown:

• DMARC record. Type TXT, Name _dmarc, Content:

v=DMARC1; p=none; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com; fo=1

• SPF record. Type TXT, Name @, Content:

v=spf1 include:_spf.google.com include:servers.mcsv.net -all

• DKIM record (TXT style). Type TXT, Name s1._domainkey, Content is the long v=DKIM1; k=rsa; p=... string. Paste the whole thing on one line. Cloudflare automatically splits it into 255 character chunks under the hood; you do not add the quotes or the splits yourself.

Cloudflare gotchas:

• The orange cloud. If you ever proxy a record that should not be proxied, Cloudflare returns its own IP instead of the value. Authentication records are never proxied, but a misconfigured A or MX record next to them can confuse you during debugging. Keep authentication records grey.
• Apex CNAME. Cloudflare supports CNAME at the root via "CNAME flattening" and does it safely. This matters for some BIMI and hosted setups but rarely for SPF or DMARC, which are TXT.
• Trailing dots. Cloudflare adds the canonical trailing dot to CNAME targets for you. Do not add your own.

After saving, confirm with the DMARC checker. Cloudflare propagates in seconds because it is authoritative, so you should see the record almost immediately.

GoDaddy

GoDaddy's editor is the one most likely to surprise you, because it historically truncated long TXT values and has an idiosyncratic host field.

To add a record:

1. Sign in, go to My Products, find your domain and click DNS (or Manage DNS).
2. Under Records, click Add (or Add New Record).
3. Select the Type.
4. In Name (sometimes labelled Host), enter the prefix only: _dmarc, @, or s1._domainkey.
5. In Value (or TXT Value), paste the record without surrounding quotes.
6. Set TTL to 1 hour, which is fine for steady records, or 600 seconds while you are testing.
7. Save.

GoDaddy gotchas:

• @ means the root. GoDaddy uses @ for the apex. Do not type your domain name in the host field.
• The 255 and 512 character traps. Older GoDaddy editors would reject or silently cut TXT values longer than 255 characters, which breaks 2048 bit DKIM keys (those run roughly 400 to 450 characters). The current editor accepts longer values in a single field and handles chunking server side, but always verify a long DKIM record after saving. If the DKIM checker reports a malformed or truncated key, the editor ate part of it. Workarounds: paste again carefully, or use a CNAME based DKIM selector from your sending platform instead of a raw key.
• Auto appended domain. GoDaddy appends your domain to the host. Entering _dmarc produces _dmarc.example.com, which is correct. Entering the full name double appends.
• Quotes. Do not wrap the value in double quotes. GoDaddy treats the quotes as literal characters and your record becomes "v=spf1..." with the quotes inside the value, which fails parsing.
• Forwarding and parked pages. If your domain uses GoDaddy domain forwarding or a parked page, GoDaddy may inject its own records. Make sure forwarding is off if you are running real mail.

Propagation on GoDaddy can take up to an hour, sometimes longer than the TTL suggests, so do not panic if the checker shows nothing for a few minutes.

Namecheap

Namecheap's Advanced DNS is clean, but it has two specific habits: it wants no trailing dots, and it has a separate field for TTL that defaults to Automatic.

To add a record:

1. Sign in, go to Domain List, click Manage next to your domain.
2. Open the Advanced DNS tab.
3. Under Host Records, click Add New Record.
4. Choose the Type (TXT Record or CNAME Record).
5. In Host, enter the prefix only: _dmarc, @, s1._domainkey.
6. In Value, paste the record (no surrounding quotes).
7. Leave TTL as Automatic, or set it to a low value while testing.
8. Click the green tick to save the row, then Save All Changes if prompted.

Namecheap gotchas:

• The green tick. Each row must be confirmed with the green tick. People frequently type a record, navigate away, and find it was never committed. Make sure the row shows as saved.
• Trailing dots on CNAME. For DKIM CNAME records, do not add a trailing dot to the target. Namecheap adds the canonical form itself, and a stray dot can produce a double dot target that fails.
• CNAME and other records at the same host. DNS forbids a CNAME coexisting with any other record at the same name. If you have an existing record at s1._domainkey, Namecheap blocks the CNAME. Remove the conflicting record first.
• Email forwarding's own MX. If you enable Namecheap Email Forwarding, it sets its own MX and may add an SPF include. Reconcile that with your real SPF so you do not end up with two SPF records.

Namecheap propagation is usually quick, within a few minutes, but the public default TTL of 30 minutes means edits to existing records can lag.

AWS Route 53

Route 53 is the most precise and the least beginner friendly. Its biggest quirk is TXT chunking: Route 53 makes you split long TXT values yourself, with explicit quotes, or it rejects them.

To add a record:

1. Open the Route 53 console, go to Hosted zones, and select your domain's zone.
2. Click Create record.
3. In Record name, enter the prefix only: _dmarc, leave blank for the apex (do not type @; Route 53 uses an empty name for the root), or s1._domainkey.
4. Set Record type to TXT or CNAME.
5. In Value, enter the value wrapped in double quotes. Route 53 requires the quotes for TXT.
6. Set TTL to 300 while testing.
7. Click Create records.

Route 53 specifics:

• The apex is an empty name, not @. Leaving Record name blank targets the root of the zone. Typing @ literally creates a record at @.example.com.
• Quotes are required, not forbidden. This is the opposite of Cloudflare, GoDaddy and Namecheap. In Route 53 every TXT value must be inside double quotes. SPF goes in as "v=spf1 include:amazonses.com -all" with the quotes.
• Manual TXT chunking. A DNS TXT string is limited to 255 characters per quoted segment. A 2048 bit DKIM key exceeds that. Route 53 does not split it for you. You must break the long key into chunks of at most 255 characters and present them as adjacent quoted strings on one line, like this:

"v=DKIM1; k=rsa; p=MIIBIjANBgkqh...first255chars" "...remainingchars=="

The resolver concatenates the segments back into one string with no space between them, so split at any point as long as you do not add or drop characters. Most DKIM key generators that target Route 53 emit the value already pre split. If yours does not, count to 255 carefully or use a CNAME selector instead.

• Alias records do not help here. Route 53 alias records are for AWS resources (load balancers, CloudFront), not for authentication TXT or DKIM CNAMEs. Use a normal CNAME for DKIM delegation.
• Multiple values in one record. Route 53 lets you put several values in a single record set on separate lines. Do not accidentally create two SPF strings this way; SPF must be a single concatenated record.

Route 53 propagates fast once saved, but the console's "INSYNC" status refers to its own infrastructure, not global resolver caches, so still verify with an external SPF checker.

The TXT chunking gotcha, explained properly

This trips up DKIM more than anything else, so it deserves its own section.

A single TXT character string in DNS can hold at most 255 bytes. That is a hard protocol limit, not a provider limit. A 1024 bit RSA DKIM public key fits inside 255 characters; a 2048 bit key does not, running to roughly 400 plus characters. So a 2048 bit DKIM record must be expressed as two or more 255 byte strings inside one TXT record. The resolver joins them with no separator.

Providers handle this in two opposite ways:

• They chunk it for you. Cloudflare, current GoDaddy and Namecheap accept the long value on one line and split it internally. You paste the whole key, no quotes, and trust the editor.
• They make you chunk it. Route 53 and most BIND style zone files require you to insert the quotes and the split yourself: "firstpart" "secondpart".

The failure mode is the same in both worlds: a key that looks present but is truncated or mis split authenticates as nothing. Symptoms in the DKIM checker include "key not found", "invalid public key", or a key that is mysteriously short. The fix is to republish the full key and, on manual hosts, ensure the segments concatenate to exactly the original string with no inserted spaces.

If 2048 bit keys keep causing trouble on a stubborn editor, two escape routes exist. First, use a CNAME delegated selector so your provider hosts the key and you only publish a short pointer (this is how Google Workspace, Microsoft 365, SendGrid and Postmark commonly work). Second, if you genuinely must use a raw key and only 1024 bits will fit, understand the security trade off in DKIM key length: 1024 vs 2048 before settling for the shorter key, and prefer rotating to 2048 via CNAME later.

The CNAME flattening gotcha at the apex

CNAME flattening is the second classic trap, and it bites at the root of your domain.

The DNS standard forbids a CNAME at the zone apex (your bare example.com), because the apex must carry SOA and NS records and a CNAME cannot coexist with other records at the same name. Many providers offer a workaround they call CNAME flattening or ALIAS or ANAME: you enter what looks like a CNAME at the apex, and the provider resolves it and serves the resulting A and AAAA records instead.

Where this intersects with authentication:

• SPF and DMARC are TXT, so flattening does not affect them directly. You will never put SPF or DMARC behind an apex CNAME. The danger is collateral: if you point your apex at a hosting provider via ALIAS, make sure that provider is not also injecting an SPF or MX record that conflicts with yours.
• DKIM and BIMI and MTA-STS use CNAMEs at subdomains, never the apex. s1._domainkey, default._bimi, _mta-sts and the mta-sts policy host are all below the apex, so the apex CNAME rule does not apply. The real DKIM CNAME pitfall is the coexistence rule: you cannot have a CNAME and a TXT at the same selector._domainkey name. If you previously published a raw TXT key and now want to switch to a CNAME selector, delete the TXT first.
• Flattening can hide changes. Because a flattened apex resolves dynamically, a provider may cache the target's old IPs. This is an availability problem, not an authentication one, but it muddies debugging when records "look right" yet behave oddly.

The practical rule: keep authentication records on TXT and on subdomain CNAMEs, never lean on apex CNAME tricks for them, and when you do use CNAME for DKIM, make sure nothing else lives at that exact name.

Verifying and the inevitable propagation wait

Saving a record and seeing it work are different events. After publishing on any host, verify externally rather than trusting the editor:

1. Run the DMARC checker, SPF checker and DKIM checker against your domain. These query live DNS, not your provider's draft state.
2. If a record is missing, check the three usual suspects in order: wrong name (double appended domain or @ versus blank), wrong type (an A record where a TXT belongs), and a stray quoting or chunking error.
3. Allow for TTL. A brand new name appears quickly because nothing has it cached. Editing an existing record can take as long as the old record's TTL to clear from resolvers, which is why lowering TTL before a change is sensible.

Once SPF and DKIM verify cleanly and your DMARC record is live at p=none, you are ready to start collecting aggregate reports and reading them. That is the real beginning of the journey, not the end, and it is covered in DMARC RUA and RUF reports and the DMARC report analyzer. From there you move deliberately from monitoring to enforcement, as described in DMARC policy: none, quarantine, reject.

Platform specific shortcuts

If your mail runs on a major platform, the records are largely prescribed and you should follow the platform guide rather than hand crafting keys:

• Google Workspace publishes DKIM via a TXT key you generate in the admin console, plus standard SPF and DMARC. See DMARC for Google Workspace.
• Microsoft 365 uses two CNAME selectors (selector1 and selector2) that point back to Microsoft, which sidesteps the 2048 bit chunking problem entirely. See DMARC for Microsoft 365.
• Whatever your platform, your SPF will reference its include. The common ones, and how to combine them without blowing the SPF 10 lookup limit, are listed in SPF for common providers. If you are already over the limit, read SPF flattening explained.

The practical takeaway

Publishing email authentication is mostly about three disciplines: enter the prefix only and let the host append your domain, respect each host's quoting convention (Route 53 demands quotes, the others reject them), and handle the 255 character TXT limit deliberately for 2048 bit DKIM keys, either by trusting an editor that chunks for you or by splitting the value yourself. The two named gotchas, TXT chunking and CNAME apex coexistence, account for the large majority of "I published it but it does not work" tickets.

Always confirm with a live external check, never the provider's "saved" message. Start with the free tools to validate each record, generate a clean policy with the DMARC generator, and keep an eye on drift with ongoing monitoring so a future zone edit does not silently undo your work.

If juggling four different editors, manual chunking and CNAME coexistence rules is more than you want to own, that is exactly what our done-for-you hosted service handles: we publish and maintain DMARC, SPF, DKIM, MTA-STS and BIMI for you, then take the domain from p=none to p=reject without an email outage.