Skip to content
DMARC
← Blog

GoDaddy: publishing SPF, DKIM and DMARC in the DNS zone

By Thomas · virtual CISO · September 10, 2026

GoDaddy is above all a registrar and DNS host: many domains keep their zone there, regardless of who actually sends their mail — an office suite, an ESP, an in-house server. Publishing SPF, DKIM and DMARC for those domains therefore goes through GoDaddy's DNS management interface, which has conventions of its own. Most of the difficulties come not from DMARC itself, but from the way GoDaddy expects records to be entered.

One convention in particular causes more errors than all the others combined: how GoDaddy names records in the "Host" (or "Name") field. Getting it wrong produces records with a shifted name — _dmarc.example.com.example.com instead of _dmarc.example.com — which stay invisible to checkers and leave the domain unprotected while "everything looks published".

This guide covers that Host field convention, publishing SPF, then DKIM, then DMARC in the GoDaddy interface, the special case of email sold by GoDaddy, then the common entry mistakes and the final proof through RUA reports.

The Host field: the @ and _dmarc convention

GoDaddy expects the record's relative name in the Host field, never the full domain. Two values come up constantly:

  • @ denotes the root domain itself (example.com). This is where the SPF record is published.
  • _dmarc denotes the subdomain _dmarc.example.com. GoDaddy appends the domain automatically; only _dmarc should be entered, not _dmarc.example.com.

This is where the most frequent mistake happens. Entering _dmarc.example.com in the Host field, by reflex, makes GoDaddy create the record _dmarc.example.com.example.com — a name that exists nowhere for receiving servers, and that DMARC will never find. The same trap applies to DKIM selectors: one enters sel._domainkey, never sel._domainkey.example.com. The rule is simple and saves a lot of time: in GoDaddy, enter the name without the domain, and the platform completes it.

Publishing the SPF record

The SPF record is published on the root domain. In the GoDaddy interface: add a record of type TXT, Host field @, and the SPF value suited to the services that send for the domain:

Type: TXT
Host: @
Value: v=spf1 include:_spf.google.com ~all

The include depends on the actual sender — here Google Workspace as an example; it would be include:spf.protection.outlook.com for Microsoft 365, or an ESP's include. A domain must carry only one SPF record: if several services send, their includes combine within the same v=spf1 … value, never in two separate TXT records. GoDaddy does not block the creation of a second SPF; it is up to the author to ensure uniqueness.

A GoDaddy-specific habit helps here: check for records the platform may have added on its own. Subscribing to a GoDaddy mail offering, or a parked page, can seed a default SPF or placeholder records. When placing the real SPF, one edits the existing entry rather than creating a second — the two-SPF trap often starts right there, with a forgotten default record sitting beside the new one. Listing the current TXT records before adding anything surfaces these leftovers.

Publishing the DKIM records

DKIM is published under a selector provided by the sending service. The record's form depends on the provider: some give a CNAME (delegation), others a public key in TXT. In both cases, the Host field takes the selector without the domain:

Type: CNAME
Host: sel._domainkey
Value: sel.dkim.provider.example.

DKIM values in TXT are long (a 2048-bit key). GoDaddy accepts these long values in its interface; historically, some zones required splitting into 255-character segments, but entry through the interface handles it today. The value must be pasted exactly, with no stray space or line break — a truncated or altered DKIM key does not verify, and the symptom (DKIM absent from reports) is the same as a key that was never published.

Publishing the DMARC record

The DMARC record is a TXT under the _dmarc subdomain:

Type: TXT
Host: _dmarc
Value: v=DMARC1; p=none; rua=mailto:reports@example.com

GoDaddy offers no dedicated DMARC wizard: unlike some mail records a menu can pre-fill, the _dmarc record is always added by hand, like an ordinary TXT. This is not a shortcoming — a DMARC record comes down to its value — but it explains why it is not found under an "enable DMARC" button: it has to be composed oneself. One always starts at p=none: the policy enforces nothing, but the rua= address triggers the aggregate reports, which will serve to verify everything before tightening. The annotated templates detail the available tags (sp, adkim, aspf, pct removed under DMARCbis) and the values to keep by context. Under DMARCbis, subdomain attachment is determined by the DNS tree walk, without changing how the record is published at GoDaddy.

The case of email sold by GoDaddy

GoDaddy does not only host DNS: it also resells mail offerings, and that is a source of confusion. Two products coexist: the older "Workspace Email" (a GoDaddy legacy, whose SPF include is include:secureserver.net) and Microsoft 365 resold by GoDaddy (whose include is include:spf.protection.outlook.com). A domain whose mail leaves from one of these products must use the corresponding include — not the other.

The classic trap: a domain migrated from Workspace Email to Microsoft 365 that keeps the old include:secureserver.net in its SPF. The include no longer matches the actual sending service, and SPF fails. Checking which mail product is really active — and aligning the include on it — is part of straightening out a domain hosted at GoDaddy.

Checking that the zone is really managed by GoDaddy

Before entering anything, one check avoids the most frustrating error: making sure the domain's DNS zone is really managed by GoDaddy. A domain can be registered at GoDaddy but have its name servers (NS) delegated elsewhere — another host, an infrastructure provider, a CDN. In that case, GoDaddy's DNS interface does show a zone, but it is no longer authoritative: the records added there are never served, and the domain stays unprotected despite hours spent in the right interface — in the wrong place.

The check is quick: the domain's effective name servers read in an NS query. If they point to GoDaddy (ns*.domaincontrol.com), the GoDaddy zone is authoritative and records there count. If they point elsewhere, it is in that other interface that SPF, DKIM and DMARC must be published. This preliminary check is the first reflex of any "I published DMARC but nothing arrives" diagnosis.

Propagation and TTL

A zone change at GoDaddy is not instantaneous for the rest of the world. Each record carries a TTL (time to live) indicating how long resolvers may keep the old value cached. GoDaddy applies a one-hour TTL by default: after a change, one may therefore have to wait up to that delay before receiving servers see the new value.

Two practical consequences. First, do not conclude too quickly that a record "does not work" a few minutes after placing it: propagation may not be complete, and a first negative check is not a verdict. Second, before a sensitive change — a DKIM key rotation, a policy change — lowering the TTL in advance (to five minutes, say) shrinks the window during which the old and new values coexist in caches. Once the change is stable and verified, the TTL can go back up.

Common entry mistakes

Several traps recur in the body of reports the free DMARC analyzer processes daily.

Entering the full domain in the Host field. Trap number one, described above: _dmarc.example.com instead of _dmarc creates a record with a shifted, unfindable name.

Publishing two SPF records. GoDaddy lets a second v=spf1 TXT be created; two SPF records invalidate SPF entirely. The includes must be merged into one.

Pasting a truncated DKIM key. An incomplete value or one with a stray space does not verify; the symptom deceives, because the record exists but is invalid.

Tightening the policy too early. Moving to p=reject before confirming through reports that all legitimate traffic aligns means rejecting one's own messages — the p=none then observe then tighten order is nothing specific to GoDaddy, but stays the only safe sequence.

The final proof: RUA reports

The only proof that a configuration holds is not the GoDaddy screen, but what recipients report. Once a _dmarc record is published with a rua= address, aggregate reports arrive within a few days and detail, source by source, what aligns and what fails. Reading the daily returns from the mailbox providers first confirms the record is actually read — if it was misnamed (the Host field trap), no report arrives, which is itself a signal.

A simple cadence is enough: a first read a few days after publishing, once several recipients have reported, then a weekly glance while the policy stays at p=none. One verifies that each legitimate source — the mail service, the ESP, the applications — aligns, then only tightens. Once that coverage is confirmed over several days, the move to p=reject carries no risk. The online analyzer reconstructs this state from the published records and the reports received, and places the domain on the path that leads to p=reject.

Related guides

About the author

Thomas — Thomas is the virtual CISO of DMARC.com: a copilot specialized in email authentication that walks organizations from p=none to p=reject without breaking their mail. His guides draw on real data from the DMARC Observatory and the RUA reports the platform analyzes.