Can I have two SPF records in GoDaddy if I use two mail providers?

No. A domain must publish exactly one SPF record. GoDaddy's own setup guidance says duplicates can stop mail from being delivered. Merge every sender into a single record as additional include mechanisms, with one all mechanism at the end, and keep the total under the ten DNS-lookup limit set by RFC 7208.

Why does my DKIM record look correct in GoDaddy but still fail?

Three usual causes. The Name field holds the full hostname instead of just the selector prefix, so the record sits one level too deep. The provider side was never switched on, for example Start authentication was never clicked in the Google Workspace Admin console. Or the long 2048-bit key was truncated, which Google documents as a consequence of the 255-character limit on a single TXT string.

How long do I have to wait after saving records in GoDaddy?

GoDaddy's guidance is that most DNS updates take effect within an hour, with up to 48 hours for full global propagation, and the default TTL on a new record is one hour. Before you assume it is a propagation problem, query the exact hostname yourself and send a test message to an outside address to read the Authentication-Results header.

SPF, DKIM and DMARC on GoDaddy: the exact records

A client forwards a bounce and asks why Gmail suddenly refuses the invoices their accountant has sent for three years. The domain is registered at GoDaddy, the nameservers are still GoDaddy's, and sitting in the DNS list are two separate TXT records that both start with v=spf1. That is the whole failure. It takes about four minutes to fix once you know which screen to open and what the fields mean.

This is the practical version: the three records email authentication needs, in the exact shape GoDaddy's DNS editor expects, for the three setups we see most on GoDaddy domains. Google Workspace, Microsoft 365, and GoDaddy's own Professional Email.

Where your DNS records actually live

GoDaddy sells the domain, the DNS hosting and the mailbox as separate things, and people mix up their control panels constantly. Authentication records go in the DNS zone, not in the mail product.

Sign in to your GoDaddy Domain Portfolio and select the individual domain to open its Domain Settings page.
Select DNS to see the records.
Select Add New Record and choose the record type.

Two details about that editor decide whether your records work at all.

The Name field is a prefix, not a full hostname. GoDaddy documents it as the hostname without the domain name. Enter @ to place the record on the root domain, or a prefix such as _dmarc. GoDaddy appends your domain for you, which is why pasting _dmarc.yourdomain.com quietly creates a record at _dmarc.yourdomain.com.yourdomain.com that no receiver will ever read.
TTL defaults to one hour. GoDaddy's guidance is that most updates take effect within an hour and can take up to 48 hours to reach every resolver.

One check before any of this: if the domain's nameservers were pointed at Cloudflare, your web host or another provider, the GoDaddy DNS editor is not the zone the internet reads. Records added there will look correct and do nothing. Confirm the nameservers first, then edit wherever they point.

SPF: one record, and probably one you did not write

SPF says which servers are allowed to send mail for your domain. The rule people break on GoDaddy is that a domain gets exactly one SPF record. GoDaddy states this plainly in its own Professional Email setup guide: make sure your domain only has one SPF record, because duplicates can stop mail from being delivered. Two records is not extra coverage, it is a permanent error, and receivers treat the result as unusable.

So before you add anything, read what is already on @. Many GoDaddy domains carry an SPF record created when a mailbox, a website builder or a hosting plan was first set up. If you find one, you are merging, not adding.

The baseline Google documents for a Workspace-only domain:

Type:  TXT
Name:  @
Value: v=spf1 include:_spf.google.com ~all
TTL:   1 hour

The value GoDaddy documents for its own Professional Email:

v=spf1 include:secureserver.net -all

Microsoft 365 tenants publish Microsoft's include instead, include:spf.protection.outlook.com. If your mail lives at Microsoft, our Microsoft 365 authentication checklist walks the whole tenant side.

When a second system sends on your behalf, a CRM, an invoicing platform, a store, it goes into the same single record as another include, with one all mechanism at the end:

v=spf1 include:_spf.google.com include:_spf.example-vendor.com ~all

Use the exact include string that vendor publishes, never a guess. And keep count: RFC 7208 limits SPF evaluation to ten DNS-querying terms, and an implementation that exceeds the limit must return permerror. Past ten includes, your SPF does not degrade politely, it fails. That is the subject of the ten-lookup guide, and it arrives faster than most people expect.

DKIM: the record depends on who sends your mail

DKIM signs each message with a private key held by your mail provider, and publishes the matching public key in your DNS. GoDaddy does not generate DKIM keys. It only stores what your provider gives you, so the first step is always in the mail platform, not in the domain.

Google Workspace

In the Admin console, open Apps, then Google Workspace, then Gmail, and choose Authenticate email. Select the domain, then Generate new record. Choose the 2048-bit key length if your DNS provider supports it, and keep the default google selector prefix. Google publishes one caveat worth knowing before you plan a cutover: after you turn on Gmail for the organisation you may need to wait 24 to 72 hours before the DKIM key is available in the console.

The record is a TXT record whose Name is the selector plus _domainkey:

Type:  TXT
Name:  google._domainkey
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkq...   (the key Google generated)
TTL:   1 hour

Save it, wait for it to resolve, then go back to the Admin console and select Start authentication. Skipping that last click is the single most common reason a correct-looking DKIM record signs nothing.

Microsoft 365

Microsoft hosts and rotates the keys for you, so you publish two CNAME records rather than a key. Microsoft Learn documents them in this shape, where the first part is derived from your mail domain and the target ends in your tenant's initial onmicrosoft.com domain:

Type:  CNAME
Name:  selector1._domainkey
Value: selector1-contoso-com._domainkey.contoso.onmicrosoft.com

Type:  CNAME
Name:  selector2._domainkey
Value: selector2-contoso-com._domainkey.contoso.onmicrosoft.com

Both records get published. The second one exists so Microsoft can rotate keys without an outage, and a tenant that publishes only selector1 will break the day rotation happens.

GoDaddy Professional Email

GoDaddy's own mailbox product also uses two CNAME records, named secureserver1._domainkey and secureserver2._domainkey, pointing at the targets shown during setup in the Email Dashboard. Copy them from that screen rather than from any article, including this one, because the target values are specific to your account.

One practical note for all three: a 2048-bit key is a long string, and Google's own troubleshooting guidance flags the 255-character limit on a single TXT string as a cause of truncated or reordered keys. If your record saves but never validates, look at what actually resolves rather than at what you pasted.

DMARC: the record that makes the other two mean something

SPF and DKIM answer technical questions. DMARC is the one that protects the name your customers actually see, the address in the From line, and it is the record that tells receivers what to do when a message fails. Start here, always, no matter how confident you feel:

Type:  TXT
Name:  _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
TTL:   1 hour

p=none changes nothing about delivery. It asks receivers to send you reports, and those reports are how you discover the four systems sending as your domain that nobody remembered. The word that matters here is alignment. Google's sender guidelines require the domain in the From header to align with either the SPF domain or the DKIM domain, so a message can pass SPF against a vendor's return path and still fail DMARC. This trips up mail sent through mailbox providers and marketing platforms alike, and it is why DKIM is usually the leg that carries alignment.

Read a couple of weeks of reports, fix the senders that show up unaligned, then raise the policy to quarantine and finally to reject. The rollout guide has the order and the timeline, and the report guide decodes the XML. If you send at any volume this stops being optional: Google asks bulk senders, defined as those sending roughly 5,000 messages a day or more to Gmail accounts, to authenticate with SPF, DKIM and DMARC, support one-click unsubscribe on marketing mail, and keep the spam rate reported in Postmaster Tools below 0.30 percent.

Propagation, and how to actually verify

GoDaddy's stated expectation is under an hour in most cases, up to 48 hours worldwide. In practice the pattern that wastes an afternoon is different: the record resolves fine, and the setup is still wrong. Three checks, in order.

Does the record resolve where you think it does? Query the exact hostname, including the selector, and confirm there is exactly one v=spf1 TXT record on the root.
Does the provider agree? Google Workspace shows authentication as started, Microsoft 365 shows DKIM signing as enabled. A published record the provider has not activated signs nothing.
Does a real message pass? Send one to an outside address, open the raw headers and read the Authentication-Results line. Our header analyzer does that part for you, and it is the only check that tests the path a customer's mail actually takes.

The mistakes we keep finding on GoDaddy domains

Two SPF records. Usually one from the mail product and one someone added later for a CRM. Merge the includes into one record and delete the other.
The full hostname in the Name field. GoDaddy appends the domain, so the record lands one level too deep and silently does nothing.
DKIM published, authentication never started. Very common with Google Workspace, because the DNS half looks finished.
Editing the wrong zone. The domain is at GoDaddy, the nameservers are not, and every change goes into a file nobody queries.
Jumping straight to p=reject. Skipping the reporting phase is how invoicing systems, appointment reminders and the office scanner stop being delivered on a Monday.
A DMARC record with no rua. A policy with no reports gives you enforcement and no visibility, which is the worst trade in this entire subject.

How Guanacos Tech helps

We are an independent consultancy with Google-certified engineers, and email deliverability is what we do most. If your domain sits at GoDaddy and mail is landing in spam or bouncing outright, the useful first step is a diagnosis rather than a rewrite: what is published today, which senders are actually aligned, and what order to change things in so nothing stops during the week. Our troubleshooter and DMARC analyzer are free and give you most of that in a minute. If you would rather hand it to someone, see how we work or book a short call and bring one bounce message with you.

SPF, DKIM and DMARC on GoDaddy DNS: the exact records for Workspace, Microsoft 365 and GoDaddy email