Set up SPF, DKIM and DMARC for Google Workspace — with your DNS on GoDaddy
First published 20 October 2026 · Record values follow Google's current documentation; GoDaddy behaviours below are from GoDaddy's own help pages, read in full for this guide. The DNS values are identical to our Cloudflare edition — what changes is everything GoDaddy does around them.
FIRST, CHECK GoDaddy may have written two of your records already
Domains bought or moved to GoDaddy since April 2025 can arrive with a default DMARC record (policy: quarantine; reports: sent to GoDaddy, not you) — and domains that ever touched GoDaddy email products carry GoDaddy's SPF. On GoDaddy, this setup is half editing, half adding.
GoDaddy → DNS — what may already be sitting in your list (drawn by Merroway)
TXT · @v=spf1 include:secureserver.net -all — GoDaddy's SPF for its own email products
Your jobEdit both — never add duplicates beside them
Do this: before adding anything, read your whole DNS list once. On GoDaddy the setup starts with recognising which records are yours and which the platform placed.
MX: one record, host @, value smtp.google.com, priority 1 (Google's number — GoDaddy's guide prints 0; with a single MX the value barely matters, but we follow the mail provider).
SPF: you will almost certainly edit, not add: the one TXT record at @ should read v=spf1 include:_spf.google.com ~all (plus includes of any other real senders, merged — never a second record).
DKIM: Google Admin → Apps → Google Workspace → Gmail → Authenticate email → Generate (2048-bit, selector google) → TXT in GoDaddy at host google._domainkey → back in Admin, Start authentication.
DMARC: find the existing _dmarc TXT first. Edit it to v=DMARC1; p=none; rua=mailto:dmarc@yourdomain. Only if no record exists do you add one.
Ignore GoDaddy's own SPF example for Workspace. Its beginner guide prints v=spf1 mx -all for Google Workspace. Google has never published that value — Google's is the include:_spf.google.com record above.
Step 1 — MX at GoDaddy: fields, exactly
GoDaddy field
Enter
Type
MX
Name (Host)
@
Value
smtp.google.com
Priority
1
TTL
1 hour (GoDaddy's standard default)
If GoDaddy email products ever touched this domain, GoDaddy may have placed its own MX rows — remove other MX records so Google's is the set, per Google's instruction. If mail already flows correctly to Workspace, verify and move on; MX changes can take up to 72 hours to be recognised everywhere.
A working habit before you start editing: set the TTL on the records you are about to change to Custom → 600 seconds while you work, and restore 1 hour when everything passes. At GoDaddy's default your every test waits on the long cache; at 600, a corrected record is visible to checkers in minutes — which is the difference between an afternoon of iterations and a week of them.
Prove it: Google's Admin Toolbox — Check MX on your domain reports MX healthy.
GoDaddy → DNS → Add/Edit record — MX
Type1MX
Host2@
Points to3smtp.google.com
Priority41 (Google's number; GoDaddy's guide prints 0 — follow the mail provider)
TTL1 hour — or 600 while you are still fixing things
Save
Do this: one MX row for Google. Remove other MX rows left by GoDaddy email products so Google's set is the only set. Field map drawn by Merroway.
Step 2 — SPF: this is a rewrite, not an addition
In GoDaddy's DNS list, find the TXT record at @ whose value starts v=spf1. On a GoDaddy-touched domain it commonly reads v=spf1 include:secureserver.net -all — GoDaddy's SPF for its email products.
Edit that record (do not use Add — GoDaddy's editor will happily save a duplicate, and two SPF records are a PermError that voids both):
TXT · Name: @ · Value
v=spf1 include:_spf.google.com ~all
Still use a GoDaddy email product as well? Merge instead: one record carrying both includes — v=spf1 include:_spf.google.com include:secureserver.net ~all — then mind the lookup budget.
Prove it: read the record back: exactly one v=spf1 TXT at the root, with Google's include inside it.
GoDaddy → DNS → Edit the EXISTING TXT record at @ — do not use Add
Type1TXT (already there)
Host2@
Value — replace with3v=spf1 include:_spf.google.com ~all
If GoDaddy mail is also usedv=spf1 include:_spf.google.com include:secureserver.net ~all — merged, still one record
Save
Do this: GoDaddy's editor will happily save a second v=spf1 record — and two records void both. Edit, always. Field map drawn by Merroway.
Step 3 — DKIM: Google generates, GoDaddy holds, Google starts
Google Admin: Apps → Google Workspace → Gmail → Authenticate email → select your domain → Generate New Record → 2048-bit, selector google.
GoDaddy: add TXT — Name google._domainkey, Value = the long key exactly as Google shows it. The 2048-bit value (~390 characters) fits GoDaddy's TXT limits, which is one more reason to choose 2048 over the old 1024 default. Host-field discipline: type the relative name only — GoDaddy appends your domain; typing the full name doubles it.
Read it back before continuing. If the value displays as two quoted chunks at the one name, that is the normal long-value presentation — Google's and GoDaddy's documentation do not promise how the split displays, so the read-back, not the appearance, is your test: one record, one name, complete value.
Google Admin, same page: Start authentication. The record without this click signs nothing.
Prove it: a message sent to an outside address, opened there with Show original: dkim=pass, header.d = your domain.
GoDaddy → DNS → Add New Record — the DKIM key from Google Admin
Type1TXT
Host2google._domainkey — relative name only; GoDaddy appends your domain
Value3The 2048-bit key exactly as Google shows it (~390 characters; splitting into quoted chunks on read-back is normal)
Save → then Start authentication in Google Admin
Do this: read it back before continuing — one record, one name, complete value. The doubled-name record is the single most common reason Google "cannot find" this key. Field map drawn by Merroway.
Step 4 — DMARC: edit the record GoDaddy gave you
Look for a TXT record at _dmarcbefore adding anything. If your domain arrived at GoDaddy after April 2025, expect to find GoDaddy's default: policy p=quarantine with reports addressed to a GoDaddy mailbox (dmarc_rua@onsecureserver.net). Understand what that means until you change it: your domain already enforces DMARC — a policy you did not choose, with reports you never see.
Edit it to the correct starting point (after SPF/DKIM have run 48 hours, with your report mailbox created):
TXT · Name: _dmarc · Value (edit or add)
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain
Type the value yourself rather than copying GoDaddy's printed default — GoDaddy's help renders its default without the mailto: prefix that a real record requires, so read-back verification is mandatory here, not decorative.
Then climb deliberately from p=none using the safe rollout — your advantage over the default is that now the reports come to you.
Prove it: Check MX exercises all four record types; then the header test on a real message — spf=pass, dkim=pass (your domain), dmarc=pass. And in the following days: aggregate reports arriving at your address are the receipt that the record is truly yours now.
GoDaddy → DNS → Edit the _dmarc record you found — this is the edit that makes it yours
Type the valueYourself — GoDaddy's help prints its default without the mailto: prefix a real record needs
Save
Do this: only if no _dmarc record exists at all do you Add one with this value. From this edit on, reports arrive at your mailbox — silence stops masquerading as health. Field map drawn by Merroway.SAMPLE HEADER
Do this: the finished GoDaddy setup reads the same as on any host — three passes on your domain — plus one receipt no other host gives you: aggregate reports landing in your inbox over the following days. Sample values.
GoDaddy-specific traps, collected
Trap
Why it bites here
The habit
Adding a second SPF via the friendly editor
GoDaddy saves duplicates without protest; receivers void both records.
Always edit the existing v=spf1 record.
Host-field doubling
GoDaddy appends your domain to the Name you type.
Relative names only; read every record back.
Trusting GoDaddy's Workspace examples
Its guide's SPF (mx -all) is not Google's value; its MX priority differs from Google's.
Values come from the mail provider; fields come from the host.
Never seeing your DMARC reports
The default record reports to GoDaddy; silence feels like health.
Your own rua is non-negotiable.
Old GoDaddy email defaults lingering
Product-placed MX/SPF rows survive the product.
Audit the whole DNS list once, deliberately, before starting.
FAQ — the issues people hit in this exact setup
Did GoDaddy really add a DMARC record to my domain?
On domains purchased or transferred in since April 2025, yes — GoDaddy announced exactly that (framed as an industry anti-spoofing move). It is a defensible default with one real flaw for owners: the reports go to GoDaddy. Editing the record, as in Step 4, is the intended owner action.
I bought my domain through Google, but it lives in a GoDaddy account. Same guide?
Yes — what matters is where the DNS is edited, and that is GoDaddy. Your Workspace tenant is a normal direct-Google tenant; follow the steps as written.
My reports still have not arrived after the edit.
Receivers send aggregate reports roughly daily, and only some send at all — Microsoft sends only when your MX points directly at Microsoft 365 (not your case), and coverage across receivers is partial by design. Silence from one receiver is normal; silence from everyone after several days means re-check the rua value and the mailbox.
Sources
Google Workspace Admin Help — MX, SPF, DKIM, DMARC · GoDaddy Help and blog — DNS record management, TXT limits, product SPF (secureserver.net), and the April 2025 default-DMARC announcement · Live DNS verification of the default record's report-authorisation chain, October 2026. · Method cross-check (TTL-while-editing habit): Mahato Soft GoDaddy Workspace guide; default-DMARC behaviour corroborated by the dmarcian GoDaddy publishing guide (updated October 2026).
Verification note: the GoDaddy default-DMARC behaviour, product SPF value, and the contradictions in GoDaddy's own Workspace examples were read from GoDaddy's pages for this guide on 20 October 2026. Reports-go-missing behaviour attributed to a single specialist source in research is NOT stated as fact in this guide; what is stated — the default record and its report address — is on the record itself.
Did this guide work for you?
Your reaction tells us whether this guide solved the problem it promised to solve.