GoDaddy SPF, DKIM and DMARC setup, step by step

In GoDaddy, open Domain Portfolio → your domain → DNS, then add or edit the TXT and CNAME records supplied by the service that sends your email. GoDaddy DNS does not determine your SPF include or create an external sender's DKIM key. Microsoft 365 from GoDaddy, Advanced Email Security and Professional Email powered by Titan require different workflows. GoDaddy TXT publication and product-specific SPF guidance

This guide covers DNS publication for any legitimate sending service using a GoDaddy-hosted zone. The mailbox sections explain common GoDaddy products without replacing the external-sender workflow.

Establish what GoDaddy manages

Separate four facts: who registered the domain, who hosts authoritative DNS, who accepts your outbound messages, and who makes the final delivery to recipients. They may be different companies. A GoDaddy domain can use external DNS and Google Workspace email; a domain registered elsewhere can use GoDaddy DNS with a marketing platform.

Before editing, collect the exact sender account, visible From domain, actual envelope MAIL FROM domain, required DKIM selectors, record types and targets. Obtain administrator access to both the sender and the authoritative DNS zone. Confirm account product names rather than inferring them from a regional help-page URL. These instructions do not establish a universal record for legacy email products, direct Microsoft subscriptions or every hosting plan.

Save a copy of the existing DNS records, including TTLs. Preserve working MX, A/AAAA, verification TXT, DKIM and DMARC records. Adding authentication for a marketing service should not move incoming mail or change nameservers. If another provider is authoritative, use its DNS editor instead. GoDaddy's own mail instructions explicitly require this distinction. GoDaddy hosting-email prerequisites

Add TXT or CNAME records without duplicating the domain

1. Open Domain Portfolio, select the domain, then DNS.
2. Inspect existing records at the requested owner. Edit an existing SPF or DMARC policy instead of adding a second one.
3. For a genuinely new record, choose Add New Record, then the exact Type supplied by the sender.
4. Enter Name, Value and TTL. GoDaddy documents a default TTL of one hour. Use the sender's required TTL when applicable.
5. Choose Save, or Save All Records for a batch. Complete any required Domain Protection identity verification, then reopen the saved records and check them. TXT fields and save procedure

GoDaddy's Name field uses the host prefix without the zone's domain. Use @ for an apex TXT record. These examples assume you are editing the example.com zone:

For a delegated news.example.com zone, remove that zone suffix instead: s1._domainkey and _dmarc. If _domainkey.news.example.com is separately delegated, publish full owner s1._domainkey.news.example.com through that namespace’s administrator with relative name s1. Preserve legitimate NS delegations and DNSSEC; do not remove them to make a parent-zone edit visible. Check the final saved full name. Do not create s1._domainkey.example.com.example.com. GoDaddy owner-name rules

A DKIM CNAME must point to the complete sender-provided hostname, with no https:// prefix or path. A DKIM TXT value contains the complete sender-issued public key and its tags. GoDaddy documents an ASCII TXT Value limit of 1,024 characters: if the complete value will not fit, obtain supported guidance rather than truncating it. A long key may be represented as multiple character strings within one logical TXT record; DKIM concatenates those strings without adding spaces. Do not create independent TXT records for its chunks or manually introduce quote characters into the key. TXT concatenation. These are not interchangeable. Stop if the selector already belongs to another sender: a CNAME cannot share its owner with other record data. Arrange a supported new selector or coordinated rotation instead of deleting the conflicting record blindly. GoDaddy also disallows apex @ CNAMEs in this editor. CNAME restrictions

If a different DNS host is authoritative, publish there, not in an inactive GoDaddy copy. For authentication CNAMEs, keep a literal DNS alias rather than an HTTP-proxied answer. GoDaddy’s cited editor does not document Cloudflare-style proxy or Flatten controls. If the actual authoritative host is Cloudflare, use DNS only, turn the applicable per-record Flatten control off where available, and ensure a whole-zone CNAME flattening for all CNAME records setting does not hide the required alias. Coordinate shared-zone changes rather than disabling them blindly. Apex flattening and mandatory same-zone behavior may still apply; when they prevent the required CNAME answer, stop and obtain a supported arrangement without deleting delegations. Cloudflare verification, flattening controls.

Choose SPF for the actual outbound route

An SPF check uses the SMTP MAIL FROM domain (or HELO in applicable cases, including a null reverse-path), not the message's visible From. Record the receiver's smtp.mailfrom value and sending IP before diagnosing a failure. SPF at example.com does not automatically cover bounce.example.com; nor can it alter authentication for a provider-owned return path. SPF identity and record selection

For an external service, obtain its current account-specific instructions. Some senders request a root SPF include; others authenticate a custom MAIL FROM subdomain or manage their own envelope domain. Publish at the requested owner. Do not add secureserver.net solely because GoDaddy hosts your DNS.

For Microsoft 365 from GoDaddy without Advanced Email Security, the current GoDaddy example is:

v=spf1 include:secureserver.net -all

For Microsoft 365 with Advanced Email Security, retrieve the actual value from Email & Office Dashboard instead. GoDaddy may already provision SPF when domain, DNS and email are in the same account; inspect rather than duplicate it. A directly purchased Microsoft 365 tenant is a different service configuration. GoDaddy SPF product branches

Keep exactly one SPF TXT policy per owner, preserving other approved senders and the established terminal qualifier. Merge the necessary mechanisms before all; never paste a second v=spf1 into a record. Check the complete evaluation for more than ten DNS-lookup-causing terms, including evaluated nested mechanisms, not ten includes alone. include, a, mx, ptr, exists and redirect count when evaluated; literal ip4, ip6 and all do not. A second policy, invalid syntax or lookup-limit violation can produce permerror. ~all is softfail, -all is fail for unmatched senders, and neither is an inbox-placement command. Do not repair by using +all. An all mechanism makes SPF ignore redirect= irrespective of ordering; terms after all are unreachable. Preserve an existing redirect-only policy’s intended control flow rather than adding an all that disables it. SPF all precedence. SPF evaluation rules

Publish DKIM for external sending services

The sending platform must first be configured for the domain you intend to use. Generate or retrieve its DKIM records there, then copy every required selector, type and public value into GoDaddy. Do not generate an unrelated key pair in a web tool: it will not match the sender's private key. Never publish private keys.

After DNS resolves, return to that service for verification and any enable signing or start authentication step. Save the expected signing domain and active selector for the delivered-message check. The sending service’s own account controls remain separate from this DNS publication interface. DKIM signer and selector model

Microsoft 365 from GoDaddy: publish both CNAMEs, then enable signing

In the Microsoft 365 Defender Portal, sign in with Microsoft 365 credentials, select the custom domain under DKIM, and choose Create DKIM keys. Copy both generated CNAME records. Publish both in GoDaddy, then return and enable Sign messages for this domain with DKIM signatures. Repeat for each custom domain. Automatic signing for an initial onmicrosoft.com domain does not establish branded-domain alignment. GoDaddy Microsoft 365 DKIM procedure

Do not construct tenant targets from example domain names. Use the displayed values even if they differ from an older tutorial. Use the actual custom domain’s generated pair and activation state, not another tenant’s example.

If Advanced Email Security from Proofpoint is enabled

Complete the Microsoft procedure and the additional Proofpoint setup. First ask GoDaddy support to grant Domains access. In Advanced Email Security, open Administration → Account Management → Domains → domain → Configure DKIM, create a signing key, and copy its generated host/value. Publish the TXT record. Return to Verify DKIM Keypair → More options → Verify Key; successful verification enables this signing layer. Do not substitute this TXT record for the Microsoft CNAME pair. GoDaddy's additional Advanced Email Security steps

Professional Email powered by Titan: use its own dashboard records

In Email & Office Dashboard → Users → Manage, choose Set mail destination or Help me fix this. The documented setup shows two DKIM CNAMEs in step 2 and SPF/DMARC TXT details in step 5. Copy the targets from your account. GoDaddy specifies these two selector owners:

secureserver1._domainkey
secureserver2._domainkey

The current Titan article specifies v=spf1 include:secureserver.net -all, not the spf.titan.email example used by some other resellers. Check for an existing policy before adding it. Publish both account-provided CNAME targets, retain any established DMARC policy, and inspect a newly delivered message. This documented workflow does not include the Microsoft Defender signing toggle. Do not invent one or assume another Titan reseller has identical DNS. GoDaddy Titan authentication instructions

Hosting email is another branch

For GoDaddy cPanel hosting mail, retrieve the suggested TXT record from cPanel → Email Deliverability → Manage for the domain, then publish its exact Name/Value at authoritative DNS. Plesk has its own Domains → domain → Mail → Mail Settings and How to configure external DNS export; do not transplant cPanel selectors or Titan targets. The hosting help text’s Plesk Name/Value description is ambiguous: obtain an unambiguous current owner/type/public-value packet from the account or hosting support before publishing. Do not paste an owner name as a key or infer fields merely from string length. This is not a complete Plesk signing-activation recipe. The hosting guide's plan-specific controls are not an activation recipe for an unrelated marketing sender. GoDaddy hosting authentication

Retain DMARC policy and set up reporting deliberately

A DMARC pass needs either aligned SPF or aligned DKIM to pass. SPF alignment compares the envelope domain with visible From; DKIM alignment compares d= with visible From. Relaxed alignment uses the same organizational domain; strict alignment requires an exact domain match. For hypothetical From: news@example.com, a passing intended signature with d=mail.example.com aligns in relaxed mode (assuming the same Organizational Domain), but not strict mode. A passing d=example.com matches exactly in both modes. These are comparison examples, not GoDaddy product defaults. A passing signature from a vendor’s unrelated domain is not enough. DMARC alignment

Inspect both the domain's policy and any applicable inherited policy. Keep an existing quarantine or reject policy and approved reporting settings. Do not create a duplicate or weaken a parent policy by adding an unreviewed child p=none record.

Only when no direct or applicable inherited policy exists, and the domain owner approves a monitoring plan and reporting destination, a first TXT policy can use this illustrative value:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Replace the mailbox. Publish at _dmarc.example.com using Name _dmarc in example.com; use _dmarc.news for _dmarc.news.example.com in the parent zone, or _dmarc in the delegated child zone. Monitoring does not guarantee acceptance. Review all legitimate streams before enforcing quarantine or rejection. DMARC policy handling

When the Organizational Domain of the report destination host differs from that of the domain where the DMARC policy was found, the report-generating receiver must check DNS authorization. Destinations within the same Organizational Domain are excepted; a different hostname alone does not make a destination external for this rule. DNS authorization does not replace owner approval of report-data sharing. Never copy a tutorial’s report mailbox. RFC 9990 section 4.

See raw DKIM results versus aligned DKIM results when a passing signature does not authenticate the intended brand.

Validate authoritative DNS and the final message

Replace the example domain, MAIL FROM owner, selector and authoritative server with your actual values. These commands illustrate checks; they are not results from a tested GoDaddy account.

dig +short NS example.com
dig @ns1.dns-host.example TXT example.com +noall +answer
dig @ns1.dns-host.example CNAME s1._domainkey.example.com +noall +answer
dig @ns1.dns-host.example TXT s1._domainkey.example.com +noall +answer
dig @1.1.1.1 TXT bounce.example.com +noall +answer
dig @1.1.1.1 TXT _dmarc.example.com +noall +answer

Check each authoritative nameserver, then repeat the SPF and every DKIM query through a public resolver. A TXT DKIM answer must contain the complete sender-provided public value. A CNAME must match its target; query TXT at that target to check the key chain. Two required CNAMEs means checking both, even if only one currently signs. Confirm exactly one SPF policy at the actual envelope owner and the intended DMARC policy.

If authoritative data is correct but recursive data is old, caching may explain the difference. GoDaddy says changes often appear within an hour but can take up to 48 hours globally. NXDOMAIN, SERVFAIL, truncation or the wrong full name needs diagnosis, not an automatic 48-hour wait. GoDaddy DNS timing

After the relevant sender activation succeeds, send a newly authorized message through each real route to an external mailbox whose raw source you can inspect. Use Authentication-Results produced inside the actual receiving service’s known mail-processing boundary. Establish through its documentation or administrator how externally supplied result fields are removed or isolated, or obtain an authenticated receiver trace. Header position, an authserv-id string or a display label alone is not proof. Ignore attacker-supplied results and leave acceptance open if provenance is uncertain. Confirm the visible From, actual smtp.mailfrom, SPF result, and intended DKIM d=/s= with a matching dkim=pass. For the newly configured branded route, require the intended sender’s signature to pass and align with the intended visible From under current policy, plus trusted dmarc=pass. Reject provider-owned From rewrites as substitutes for authenticating that brand. Authentication-Results trust

A DMARC pass through SPF does not prove the branded DKIM change worked. A provider-domain DKIM pass does not substitute for your intended branded signature. Likewise, inspect actual SPF failures and errors even if DKIM passes: permerror needs policy/lookup diagnosis; temperror needs DNS investigation; fail or softfail on direct sending needs a route-versus-authorization comparison. Test forwarding separately rather than broadening SPF indiscriminately.

Troubleshooting and rollback

Rollback only the faulty record to its saved prior value after checking for concurrent edits. Preserve other senders' selectors and existing DMARC enforcement. Do not use a whole-zone template reset as a repair. Retire old DKIM keys only under the sender's rotation instructions, allowing for queued messages, and retest affected and unaffected routes.

Documentation review and testing limits

This is a documentary configuration guide. No customer account was accessed, no DNS was changed and no email was sent. Account-specific values, real delivery, deployed-page behavior, indexing and inbox placement remain untested.