How to add DMARC, SPF and DKIM records on GoDaddy

14 June 2026 · 13 min read

GoDaddy is one of the most common places where a domain lives, and one of the most common places where DMARC, SPF and DKIM go quietly wrong. The GoDaddy DNS editor is friendly enough, but it has a handful of behaviours that catch people out every single time: how it treats the root versus a host name, how it chops up long TXT records, the way it refuses to let a CNAME share a name with other records, and a TTL dropdown that is fine for everything except the moment you are mid-migration. This guide walks through adding all three record types in the actual GoDaddy interface, with the exact field values and the specific traps to avoid.

It assumes your domain's DNS is hosted at GoDaddy, meaning GoDaddy is your authoritative nameserver, not just your registrar. That distinction matters and we will check it first, because if your nameservers point elsewhere (Cloudflare, Route 53, your host), editing records in GoDaddy does nothing.

First, confirm GoDaddy actually controls your DNS

People routinely buy a domain at GoDaddy, point the nameservers at their web host or at Cloudflare, then spend an afternoon editing records in GoDaddy that the internet never reads. Before you touch anything, confirm where DNS is answered.

In GoDaddy, go to your Domain Portfolio, click the domain, and look at Nameservers. If they read something like ns01.domaincontrol.com and ns02.domaincontrol.com, that is GoDaddy's own DNS, and this guide applies directly. If they read something.cloudflare.com, awsdns, or your host's nameservers, then your records must be created there instead, and the GoDaddy DNS editor is a dead end.

You can verify from the outside in seconds. Run your domain through the DNS record checker and look at the authoritative nameservers, or check a specific record type with the TXT record checker. If the live answers do not change after you edit GoDaddy, your nameservers are the reason.

To reach the editor itself: Domain Portfolio then your domain, then DNS (or the DNS menu then Manage Zones). You will see a list of records with Add New Record at the top. That is where everything below happens.

How GoDaddy's "Name" field works (root vs host)

This is the single biggest source of broken records on GoDaddy, so it is worth being precise.

GoDaddy's Name field (sometimes shown as Host) expects the part of the name before your domain, not the full name. GoDaddy appends your domain automatically. So:

• For a record on the root of the domain (the bare yourdomain.com), you enter @ in the Name field. The @ symbol means "the domain itself".
• For a record on a subdomain or host, you enter only the label. For a DMARC record, which lives at _dmarc.yourdomain.com, you enter _dmarc, not _dmarc.yourdomain.com.
• For a DKIM selector at selector1._domainkey.yourdomain.com, you enter selector1._domainkey, not the full hostname.

The classic mistake is typing the full name. If you enter _dmarc.yourdomain.com in the Name field, GoDaddy creates a record at _dmarc.yourdomain.com.yourdomain.com, which resolves nowhere and silently fails. After saving any record, always read it back and mentally append .yourdomain.com to whatever is in the Name column. If that gives you the name you intended, you are correct. If it gives you a doubled domain, fix it.

There is no trailing dot convention to worry about in GoDaddy's Name field, unlike some BIND-style editors. You never type the trailing dot, and you never type your own domain. Just the label, or @ for the root.

Adding the SPF record (TXT on the root)

SPF is a single TXT record on the root of your domain. It declares which servers are allowed to send mail using your domain in the envelope sender. There must be exactly one SPF record per domain. Two v=spf1 records is not "belt and braces", it is a hard configuration error that produces a permerror and breaks SPF for every sender.

In Add New Record, choose:

• Type: TXT
• Name: @
• Value: your SPF string
• TTL: leave at the default (1 hour) for now

A realistic SPF value for a domain sending through, say, Google Workspace plus a marketing tool looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Each provider you actually send from contributes one include: (or a, mx, ip4, ip6) mechanism. The ~all at the end is a soft fail, the sensible default while you stabilise. Some guides suggest -all (hard fail), which is stricter and fine once you are confident every legitimate sender is listed, but start with ~all.

Two GoDaddy-specific points and one universal one:

• Check for an existing TXT record first. GoDaddy may already have a TXT record on @ from a previous setup or a verification step. If a v=spf1 record exists, edit it, do not add a second one. The editor will happily let you create two, and SPF will then permerror.
• GoDaddy does not require surrounding quotes in the Value field. Paste the SPF string as plain text. Do not wrap it in extra " characters, or you can end up with literal quotes baked into the published value.
• The 10-lookup limit applies on GoDaddy exactly as anywhere else. SPF evaluation allows at most 10 DNS lookups, and each include: that itself contains includes counts cumulatively. A record like include:_spf.google.com include:servers.mcsv.net include:sendgrid.net include:spf.protection.outlook.com can blow past 10 and turn into a permerror that mailbox providers treat as a failure.

After saving, verify the lookup count and syntax with the SPF checker. If you are near or over the limit, flattening is the fix, explained in SPF flattening, and the maths behind the limit is in the SPF 10-lookup limit. If you would rather not maintain the include chain by hand at all, our hosted SPF keeps a single flattened record published for you.

The TXT chunking gotcha (and why it bites long records)

DNS has a quirk that GoDaddy mostly hides, but you need to know it exists. A single DNS TXT string can be at most 255 characters. Records longer than that, which happens with long DKIM public keys and occasionally with a heavily-flattened SPF record, must be split into multiple 255-character strings inside the same TXT record. At the protocol level they look like:

"v=DKIM1; k=rsa; p=MIIBIjANBgkq...first255chars..." "...remaining chars...IDAQAB"

The receiving resolver concatenates the chunks back into one value with no separator. Here is the GoDaddy-specific behaviour:

• For SPF and DMARC, your values are short (well under 255), so chunking never applies. Paste them as one line.
• For DKIM, a 2048-bit key is roughly 400 characters of base64, which exceeds 255. In GoDaddy's editor you generally paste the whole key as one value and GoDaddy splits it into 255-char chunks for you on publish. You do not manually add quotes or split the key yourself. If you split it by hand and add your own quotes, you risk a malformed record.
• The thing to watch is stray whitespace or line breaks introduced when you copy a key out of a provider's console. A newline pasted into the middle of the key will corrupt it. Paste into a plain text editor first, remove any line breaks so the key is one continuous string, then paste into GoDaddy.

Most modern DKIM setups dodge this entirely by using CNAME records instead of raw TXT keys, which is the next section, and which is why so many providers now hand you CNAMEs.

Adding DKIM (the two common shapes)

DKIM on GoDaddy comes in one of two shapes depending on how your email provider issues keys. You will use whichever your provider gives you, and the difference matters for the GoDaddy editor.

Shape one: CNAME-based DKIM (most modern providers)

Google Workspace is the TXT exception, but many providers (Amazon SES, SendGrid, Mailchimp, Microsoft 365's newer flow, and others) give you CNAME records that point at keys they host and rotate for you. These are the easiest to add and never hit the 255-character chunking problem because the key itself lives on the provider's side.

A typical provider gives you something like:

Type   Name (Host)              Value (Target)
CNAME  s1._domainkey            s1.dkim.provider.example
CNAME  s2._domainkey            s2.dkim.provider.example

In GoDaddy:

• Type: CNAME
• Name: s1._domainkey (the label only, GoDaddy appends your domain)
• Value: the full target hostname exactly as the provider gave it, for example s1.dkim.provider.example
• TTL: default

Two CNAME-specific traps on GoDaddy:

• A CNAME cannot coexist with any other record on the same name. This is a DNS rule, not a GoDaddy quirk, but GoDaddy enforces it. It is almost never a problem for _domainkey selectors because nothing else lives there, but it does mean you cannot also put a TXT note on the same host.
• Do not append your domain to the target unless the provider's value already includes it. Paste the target value verbatim. GoDaddy does not modify the Value field of a CNAME the way it appends to the Name field, so the target must be the complete, correct hostname.

GoDaddy does not "flatten" CNAMEs into A records at the root, and you should never be putting DKIM at the root anyway (it always lives under _domainkey), so the apex-CNAME problem that affects website records does not apply to DKIM here.

Shape two: TXT-based DKIM (Google Workspace and others)

Google Workspace publishes DKIM as a TXT record with a selector, by default google._domainkey. You generate the key inside the Google Admin console (Apps then Google Workspace then Gmail then Authenticate email), and Google shows you a long value beginning v=DKIM1; k=rsa; p=....

In GoDaddy:

• Type: TXT
• Name: google._domainkey
• Value: the entire v=DKIM1; k=rsa; p=... string as one continuous line
• TTL: default

This is where the chunking discussion above matters. Paste the whole value, let GoDaddy handle the 255-character split, and make sure no line breaks crept in during copy and paste. The step-by-step for the Google side is in enabling DKIM in Google Workspace, and the Microsoft equivalent in enabling DKIM in Office 365.

Whichever shape you used, confirm the published key resolves and parses with the DKIM checker. Enter your selector (s1, google, or whatever your provider issued) and your domain. If the checker cannot find it, the most likely cause is a Name field that doubled your domain, or a stray newline in a TXT key. For background on why selectors exist and how providers namespace them, see DKIM selectors explained.

Adding the DMARC record (TXT at _dmarc)

DMARC is a single TXT record at _dmarc.yourdomain.com. It is short, so chunking never applies, and it lives on a host name, so the @ versus label rule matters.

In Add New Record:

• Type: TXT
• Name: _dmarc
• Value: your DMARC policy string
• TTL: default

Crucially, do not start at enforcement. Publish a monitoring-only policy first so you collect data while nothing is rejected:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; fo=1; adkim=r; aspf=r

What each tag does:

• p=none tells receivers to enforce nothing yet, just observe and report. This is your safety net.
• rua=mailto:... is where the daily aggregate reports go. This is the data that tells you whether your SPF and DKIM are actually aligning. Without it, you are flying blind.
• fo=1 asks for a failure report whenever any mechanism fails alignment, surfacing problems early.
• adkim=r; aspf=r set relaxed alignment, the sensible default. You only want strict alignment in narrow cases.

A subtlety GoDaddy users hit: if the mailbox in your rua is on a different domain than the one being protected, that other domain has to publish an authorisation record permitting it to receive your reports. Within the same domain this never applies. The full anatomy of the record is in the DMARC record explained and the policy ladder in none, quarantine, reject. You can also build a correct record with the DMARC generator and paste the output straight into GoDaddy.

If you do not fancy reading raw XML aggregate reports, point rua at a monitoring address instead. Our monitoring ingests the reports GoDaddy users would otherwise have to parse by hand and turns them into a plain picture of who is sending as you and whether each source aligns.

Understanding TTL in the GoDaddy editor

GoDaddy's TTL dropdown offers presets (1 hour is the usual default, with options down to a custom value) and a Custom entry for arbitrary seconds. TTL is how long resolvers cache the record before re-fetching. It matters in two specific situations.

• During normal operation, leave it at the default. A one-hour TTL is fine for SPF, DKIM and a settled DMARC record. Longer TTLs reduce DNS query load fractionally but you will not notice.
• When you are about to change a record you might need to roll back fast, lower the TTL first. The classic example is the DMARC policy ramp. Before you move from p=none to p=quarantine to p=reject, set the _dmarc record's TTL to something short like 600 seconds (10 minutes), wait for the old TTL to expire, then make policy changes. If a change causes a problem, your fix propagates in minutes rather than an hour. Once you are stable at p=reject, you can raise the TTL again.

The trap is changing TTL and the value at the same time and expecting the new short TTL to govern rollback of that change. It does not. The TTL that controls how long the world caches your record is the TTL that was already published before you made the change. So lower TTL first, wait, then change the value.

A note on GoDaddy's editor quirks

A few interface behaviours worth naming, because they cause "I saved it but it is not working" confusion:

• Saving is per record, and there is often a brief save delay. After you click Save, give it a moment and refresh the zone view to confirm the record landed exactly as typed.
• GoDaddy may show records without the trailing domain, so the Name column shows _dmarc and @, not the full hostnames. That is normal. Append .yourdomain.com in your head to read the true name.
• Propagation is not instant. Even with a one-hour TTL, allow time for the new record to be readable everywhere. A provider's "verify" button failing immediately after you save usually just means propagation has not caught up. Re-check in 30 to 60 minutes rather than re-entering everything. You can watch propagation with the DNS propagation checker.
• GoDaddy's older "TXT (SPF)" type. Some legacy GoDaddy zones expose a separate SPF record type. Ignore it. The deprecated SPF DNS type is not used by receivers; SPF must be a plain TXT record. Always choose TXT for SPF.
• Forwarding and parked-domain auto records. If you use GoDaddy email forwarding or a parked page, GoDaddy sometimes injects its own MX or TXT entries. Review them so they do not clash with your real mail setup.

Putting it together and confirming alignment

Adding the three records is mechanical. Making DMARC actually pass is about alignment, and GoDaddy cannot tell you whether you got that right. DMARC passes only if SPF or DKIM passes and the passing domain matches the domain in your visible From address. Publishing the records is necessary but not sufficient.

The order that works:

1. Publish SPF on @ (one record, under 10 lookups), verified with the SPF checker.
2. Publish DKIM under _domainkey (CNAME or TXT, depending on provider), verified with the DKIM checker.
3. Publish DMARC at _dmarc as p=none with a rua address, verified with the DMARC checker.
4. Wait one to four weeks and read the aggregate reports. You are looking for every legitimate sender showing SPF or DKIM pass and aligned on your domain. Decode reports with the DMARC report analyzer so you are not reading XML by hand.
5. Only when reports are clean, ramp the policy: lower the _dmarc TTL, then go p=quarantine with a pct=25 sample, then pct=100, then p=reject.

The reason for the watching period is concrete: GoDaddy customers very often discover, in their first week of reports, a forgotten sender (an old contact form, a billing system, a help desk) sending as their domain without alignment. If you had jumped straight to p=reject, that legitimate mail would have bounced. The enforcement journey doc and the post on reaching p=reject without breaking email cover the ramp in detail, and common DMARC mistakes lists the ones GoDaddy setups hit most.

If your mail is on a major provider, the provider-specific guides are worth a read alongside this one: DMARC for Google Workspace and DMARC for Microsoft 365. For terminology, the glossary defines every tag and acronym used above, and the requirements page summarises what Gmail, Yahoo and Microsoft now demand of bulk senders.

The short version

For a domain whose DNS is hosted at GoDaddy:

• SPF: one TXT record, Name @, value v=spf1 ... ~all, kept under 10 lookups, never duplicated.
• DKIM: records under _domainkey, usually CNAME (paste the target verbatim) or a TXT key for Google Workspace (paste as one line, let GoDaddy chunk it, no stray newlines).
• DMARC: one TXT record, Name _dmarc, value starting v=DMARC1; p=none; rua=mailto:..., ramped to p=reject only after reports are clean.
• The GoDaddy-specific rules: use @ for the root and the bare label for hosts (never the full name, or you double your domain); let GoDaddy handle TXT chunking; keep CNAME names free of other records; and lower the TTL before a change you may need to undo.

Get the three records published, then prove they align before you enforce. Start by checking what is live on your domain today with the DMARC checker, the SPF checker and the DKIM checker. If you would rather hand the whole job over, including the GoDaddy DNS edits, the report reading and the safe ramp to p=reject, our done-for-you DMARC service takes the domain there for you and our monitoring flags the moment a sender stops aligning.