How to Add SPF, DKIM, DMARC, and Return-Path Records in GoDaddy

If you need to add SPF DKIM DMARC records in GoDaddy, the hard part is usually not pressing Save. It is knowing which DNS record belongs at which hostname, preserving the records you already have, and recognizing that your email provider’s dashboard values must be copied exactly.

This guide explains how to add SPF, DKIM, DMARC, and custom return-path records for a domain registered with GoDaddy. It is written for teams sending transactional, product, support, or campaign email through an email service provider, including cases where your provider gives you one or more CNAME records instead of a long DKIM TXT value.

Before You Edit DNS: Confirm GoDaddy Is Authoritative

Buying a domain at GoDaddy does not always mean you manage its DNS records at GoDaddy. Your domain might use Cloudflare, a hosting company, another DNS provider, or a company IT platform for its authoritative nameservers.

That distinction matters because email authentication records only work when they are added at the authoritative DNS provider. Adding a perfect SPF or DKIM record in GoDaddy will not change public DNS if the domain’s nameservers point elsewhere.

Start by checking where the nameservers are managed. In GoDaddy, open the domain and look for its DNS or nameserver settings. If the nameservers are GoDaddy nameservers, you can usually manage the zone from GoDaddy. If they point to another provider, make the changes there instead.

As of writing, GoDaddy’s documented route for a domain using GoDaddy DNS is:

1. Sign in to GoDaddy Domain Portfolio.
2. Select the individual domain you want to configure.
3. On the domain’s settings page, select DNS to open the DNS records list.
4. Select Add New Record.
5. Choose the record type, enter the Name, Value, and TTL, then save.

GoDaddy’s labels can change by account layout, country, or product bundle, so treat the exact wording as a current navigation guide rather than a permanent interface guarantee. The important destination is the DNS records or zone-file view for the individual domain—not website settings, mailbox settings, forwarding, or a third-party email product screen.

Before changing anything, take a screenshot or export a list of the existing MX, TXT, and CNAME records. This gives you a rollback reference and helps prevent an accidental deletion of Microsoft 365, Google Workspace, website, verification, or other sending-provider records.

What SPF, DKIM, DMARC, and Return-Path Actually Do

These records are related, but they do different jobs. Treating them as four versions of the same setting is a common source of broken mail authentication.

SPF authorizes the envelope sender

SPF, or Sender Policy Framework, is a TXT record that says which mail systems may send mail for a particular envelope-sender domain. The envelope sender is the SMTP MAIL FROM identity, which is commonly displayed after delivery as the Return-Path header.

SPF does not directly authenticate the inbox-visible From: address. A message can display billing@example.com in the From header while SPF is evaluated against a different domain, such as bounce.example.com or a provider-owned bounce domain.

That is why an email platform may ask you to set up a custom return-path subdomain. It lets the platform use an aligned envelope sender under your domain, such as bounce.example.com, rather than a provider-owned address.

DKIM signs the message

DKIM, or DomainKeys Identified Mail, adds a cryptographic signature to a message. Receiving mail systems use a public key published in DNS to check that the signed parts of the message have not been changed and that the signer controls the signing domain.

A DKIM DNS hostname normally has this shape:

selector._domainkey.example.com

The selector is chosen by the sending provider. It may look like s1, k1, mail, a generated string, or another provider-specific label. Never guess it. Copy the selector and value from the domain-authentication screen of the provider that will sign your messages.

DMARC connects authentication to the visible From domain

DMARC, or Domain-based Message Authentication, Reporting, and Conformance, evaluates whether SPF or DKIM passed and aligned with the domain in the visible From: header.

Alignment is the important extra requirement. A message can technically pass SPF for a provider-owned bounce domain and still fail DMARC if the SPF-authenticated domain is not aligned with the visible From domain. A passing DKIM signature using your From domain, or an aligned custom return-path, can satisfy DMARC.

DMARC also publishes a requested policy for failed authentication, such as monitoring only, quarantine, or reject. It can request aggregate reports that help you discover legitimate senders and spoofing attempts.

A custom return-path gives SPF a domain you control

A return-path is the address used for bounce handling during SMTP delivery. For a branded setup, it is usually a subdomain such as:

bounce.example.com

mail.example.com

em.example.com

rp.example.com

Your email provider normally tells you which subdomain label to use and gives you a CNAME destination. The provider can then handle bounces and publish or serve the SPF information required for that delegated subdomain.

Do not assume every platform uses the same label. bounce, mail, and em are examples, not universal instructions.

The DNS Record Shapes You Will Add in GoDaddy

The exact hostnames and target values must come from your sending provider. The table below shows the correct shape of the records so you can map provider instructions into GoDaddy’s fields safely.

For a domain named example.com, GoDaddy normally expects the Name field without the root domain because it appends the domain automatically in the zone. For example:

This distinction is especially important for CNAME-based DKIM and return-path setups.

The GoDaddy Hostname Mistake That Breaks DKIM and Return-Path Setup

The most common GoDaddy-specific mistake is entering the full domain name in the Name field when GoDaddy expects only the hostname or prefix.

Suppose your provider asks you to publish this DKIM hostname:

k1._domainkey.example.com

In GoDaddy, enter this in the Name field:

k1._domainkey

Do not enter:

k1._domainkey.example.com

Because GoDaddy’s DNS form describes Name as the hostname or prefix without the domain name, entering the entire hostname can result in an unintended record such as:

k1._domainkey.example.com.example.com

The record may look plausible in the dashboard, but your email provider will query the intended hostname and fail to find it. The same problem applies to a custom return-path CNAME. If the desired host is bounce.example.com, enter bounce, not bounce.example.com.

There is one related nuance: the CNAME Value is the destination hostname supplied by your email provider. That destination is usually a complete provider hostname, such as a generated target under the provider’s domain. Paste it exactly as supplied. Do not replace it with your own domain, do not point it to an IP address, and do not change its labels to make it look shorter.

A useful mental model is:

• Name: the label under your domain that you own.
• Value: the destination or text instruction supplied by the service.
• TTL: how long DNS resolvers may cache the record.

Step 1: Inventory Existing Email Senders Before Adding SPF

SPF is the record most likely to be damaged by a well-intentioned DNS edit. A domain can have many TXT records, but it should not publish multiple independent SPF policies at the same hostname.

For example, this is problematic at the root domain:

v=spf1 include:_spf.google.com -all
v=spf1 include:another-email-provider.example -all

A receiver can treat multiple SPF records as an SPF permanent error. The solution is typically one combined policy, assuming both services actually send mail with the same envelope-sender domain:

v=spf1 include:_spf.google.com include:another-email-provider.example -all

Do not copy that example into production as written. Your actual include mechanisms, sending IP addresses, and failure qualifier must reflect your setup.

Before editing SPF, identify every system that sends mail using the domain or the specific subdomain in question. This commonly includes:

• Google Workspace or Microsoft 365 for employee email.
• A transactional email provider for password resets, receipts, and account alerts.
• A marketing platform for newsletters and lifecycle campaigns.
• Customer support, CRM, billing, survey, recruiting, or ecommerce tools.
• A self-hosted application, relay, or dedicated sending IP.

Then determine which domain each source uses in the SMTP envelope sender. An application may display a From address at example.com but use a custom return-path at bounce.example.com. In that case, the SPF policy may belong at bounce.example.com, not at the root.

Respect SPF’s DNS-lookup limit

SPF is not an unlimited list of provider includes. SPF evaluation has a limit of 10 DNS-querying mechanisms or modifiers. Nested include, a, mx, exists, redirect, and similar mechanisms can consume lookups too.

That means continually appending another include: can eventually cause SPF permerror, making a supposedly more complete record fail. Audit before merging, remove retired providers, and avoid authorizing systems that no longer send mail.

If your provider gives you a CNAME-based custom return-path, do not assume you need to add its SPF include to the root-domain SPF record. The provider may host SPF for the branded bounce subdomain through the CNAME target. Follow the provider’s domain-authentication instructions for that exact host.

Step 2: Add or Update Your SPF TXT Record

In GoDaddy’s DNS records view, find an existing TXT record at @ whose value begins with v=spf1. If one exists, edit it rather than creating another root SPF record.

If no SPF policy exists for the required hostname, choose Add New Record, select TXT, and use the record shape supplied by the provider.

For a root-domain policy, the GoDaddy fields generally look like this:

For a dedicated return-path subdomain, the record may not be a TXT record you write yourself. Your provider may instead require a CNAME such as bounce pointing to a provider hostname. In that design, the provider controls the SPF policy at the CNAME destination.

Do not change ~all to -all simply because a generic guide says strict is better. ~all and -all have operational implications, and the correct setting depends on whether your sender inventory is complete. More importantly, neither qualifier compensates for missing legitimate senders or broken alignment.

Step 3: Add DKIM Records Exactly as Your Provider Supplies Them

DKIM comes in two common DNS patterns: a TXT public key or a CNAME delegation record. Your sending platform decides which one you need.

DKIM TXT pattern

A provider using direct DKIM TXT records might give you a hostname and a long public key value. It can look broadly like this:

Type: TXT
Host: selector._domainkey
Value: v=DKIM1; k=rsa; p=<long-public-key>

The key may be hundreds of characters long. Do not add line breaks, omit characters, add quotes manually, or combine it with a different provider’s DKIM key. A long value is normal.

DKIM CNAME pattern

A provider using DKIM delegation may give you records similar to:

Type: CNAME
Host: selector1._domainkey
Value: selector1.example.provider-domain.com

and sometimes a second selector:

Type: CNAME
Host: selector2._domainkey
Value: selector2.example.provider-domain.com

Add every record the provider supplies. Multiple selectors are normal and can support key rotation or separate infrastructure.

In GoDaddy, select Add New Record, choose CNAME, put only the prefix in the Name field, paste the provider target into Value, select a TTL, and save. A CNAME cannot coexist with another record at the identical hostname, so if GoDaddy reports a conflict, inspect the existing record rather than deleting it automatically.

A conflict could mean the hostname is already used by an old email platform, a previous DKIM setup, or an unrelated DNS record. Removing it without understanding the dependency can break mail authentication for an existing sender.

Step 4: Add the Custom Return-Path CNAME Without Touching MX

A custom return-path is often the missing piece in an otherwise working domain-authentication setup. It lets the sending service use a bounce domain under your domain, making SPF alignment possible when the visible From domain is also under that organizational domain.

Your provider might instruct you to add a CNAME for a host such as bounce, mail, em, or a generated label. In GoDaddy, the record shape is:

The result might resolve publicly as:

bounce.example.com CNAME provider-generated-target.example

Do not confuse this with inbound email routing. Your domain’s MX records control where incoming mail is delivered. A custom return-path CNAME is used for outbound-envelope identity and bounce processing. It should not require replacing @ MX records for Google Workspace, Microsoft 365, or another inbound mail service.

Also avoid using a subdomain already assigned to another purpose. If mail.example.com hosts a webmail app, has an A record, or is used by another email provider, choose the provider’s alternate supported label or a clean subdomain. One hostname cannot be both a CNAME and an A, MX, TXT, or other conflicting record type.

Step 5: Publish DMARC in Monitoring Mode First

DMARC lives at a fixed hostname beneath the domain:

_dmarc.example.com

In GoDaddy, create it as a TXT record using _dmarc in the Name field. A practical starting value is:

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

Replace the reporting address with a mailbox or reporting service you actually monitor. The mailbox should be able to receive aggregate report attachments, which are often XML files packaged in compressed formats.

A conservative rollout looks like this:

1. Publish p=none to request monitoring without enforcement.
2. Review aggregate reports and message headers to find all authorized senders.
3. Fix missing DKIM, missing SPF authorization, and alignment failures.
4. Move to p=quarantine when you are confident most legitimate mail passes.
5. Move to p=reject only after you have verified that legitimate sources are consistently aligned.

DMARC policy is not a deliverability shortcut. Publishing p=reject before you understand your actual mail sources can cause legitimate mail to be filtered or rejected by receivers. This is especially risky for organizations with separate systems for receipts, support notifications, calendar platforms, ecommerce tools, and employee mail.

What the DMARC tags mean

The small set of tags below covers a sound initial implementation:

• v=DMARC1: required version tag.
• p=none: monitor failures without requesting quarantine or rejection.
• p=quarantine: request that failing messages be treated suspiciously, often sent to spam.
• p=reject: request rejection of failing messages.
• rua=mailto:...: address for aggregate reports.
• pct=25: optionally apply the requested policy to a percentage of failing mail during a gradual rollout.
• adkim=s or aspf=s: strict alignment options; do not enable them casually.

Relaxed alignment is normally the safer default. For example, a DKIM signing domain of mail.example.com can align with a visible From domain of example.com under relaxed alignment. Strict alignment requires an exact domain match, which can be useful in some architectures but may expose overlooked sending setups.

Step 6: Save, Wait for DNS, Then Verify the Right Things

GoDaddy states that many DNS changes take effect within about an hour, though global propagation can take up to 48 hours. The actual delay depends on TTL, resolver caching, previous record state, and the provider’s verification process.

Do not treat a saved record as a verified record. Verification has two separate layers:

1. DNS publication: public resolvers can find the intended record at the intended hostname.
2. Email authentication: a real delivered message passes SPF, DKIM, and DMARC in its headers.

Use your email provider’s domain-verification screen after DNS has propagated. It should confirm whether each required DKIM, return-path, SPF, and tracking record is visible. If the provider says a record is missing, compare the hostname character by character before making another change.

Then send a real test message to a mailbox you control and inspect the original message headers. Look for authentication results resembling:

spf=pass
 dkim=pass
 dmarc=pass

Also inspect the domains associated with the result:

• The visible From: domain should be the domain you intended to represent.
• The smtp.mailfrom= or Return-Path domain shows the SPF identity.
• The header.d= value shows the DKIM signing domain.
• The header.from= value shows the domain DMARC evaluates as the author domain.

A message can pass DKIM and still fail DMARC if the signing domain does not align with header.from. Similarly, it can pass SPF but fail DMARC if the return-path domain is not aligned. The goal is not merely green status for a single protocol; it is a DMARC pass based on aligned SPF or aligned DKIM.

For broader setup guidance, use the platform’s email API setup guides alongside the exact domain-authentication values shown in your sending dashboard.

Troubleshooting GoDaddy DNS Errors and Verification Failures

When verification fails, do not immediately delete and recreate every record. Most cases fall into a short list of identifiable problems.

The record was added at the wrong DNS provider

If the domain uses non-GoDaddy nameservers, GoDaddy’s zone is not authoritative. Confirm nameservers before changing record values repeatedly.

The Name field includes the root domain twice

This is the classic GoDaddy hostname problem. selector._domainkey.example.com belongs in public DNS, but GoDaddy’s Name field typically needs only selector._domainkey.

The CNAME target was modified

Provider-generated CNAME values can look unusual. Do not remove labels, swap the target for the visible domain, add a protocol such as https://, or convert it to an IP address.

A CNAME conflicts with an existing record

A host with a CNAME cannot also have a TXT, MX, A, AAAA, or another CNAME record. Use a different supported subdomain if the intended host is already occupied, or retire the old configuration only after confirming it is no longer in use.

Multiple SPF policies exist

Search the DNS records for every TXT value beginning with v=spf1 at the same hostname. Consolidate only after accounting for every legitimate sender.

DMARC was published on the root host

DMARC is not a root TXT record. Its Name field must be _dmarc, producing _dmarc.example.com.

The DKIM selector is incorrect

The selector must match the provider’s signing configuration. s1._domainkey and s2._domainkey are different records. A typo, an old selector, or a partial hostname will prevent validation.

DNS is correct but mail still does not align

A provider can verify a DKIM record successfully while the message still fails DMARC because the platform is signing with a different domain than the visible From domain. Check the actual test-message headers, then configure the provider’s authenticated sending domain, custom return-path, or sending identity correctly.

A Safer Change Plan for Production Domains

Production email DNS should be treated as infrastructure, not a one-time copy-and-paste task. The following workflow minimizes disruption:

1. Document the current zone. Record existing MX, SPF, DKIM, DMARC, and provider-verification entries.
2. Map each mail stream. Separate employee mail, product mail, marketing, support, billing, and legacy applications.
3. Add new DKIM and return-path records first. These are usually additive and less likely to disrupt existing mail.
4. Verify the new sending provider. Do this before switching your application’s From address or production traffic.
5. Merge SPF only when necessary. Avoid duplicate records and account for the SPF lookup budget.
6. Publish DMARC at p=none. Use reports and real-message headers to discover gaps.
7. Enforce gradually. Move toward quarantine and reject only after the sender inventory is stable.

If you send transactional email from a production application, test more than a single “hello world” message. Send a password reset, receipt, notification, and any template with an unsubscribe link or a reply-to address. Different application paths sometimes use different sending settings or providers.

When You Do Not Need to Change the Root SPF Record

A frequent misconception is that every new email platform must be added to the root SPF record. That is not always true.

You may not need to touch root SPF when:

• The provider uses its own envelope sender domain and DKIM provides DMARC alignment for your visible From domain.
• The provider uses a custom return-path subdomain with a CNAME that delegates SPF to the provider.
• You are adding a sender that does not use your root domain in the SMTP envelope sender.

You likely do need to update SPF when:

• The provider explicitly tells you to add an include: mechanism to an existing SPF record.
• A server sends with MAIL FROM at the root domain and must be authorized there.
• You operate your own relay or dedicated sending IP that needs authorization.

The best source of truth is the sending platform’s domain-authentication screen, not a generic include record found in another provider’s documentation. Each provider’s return-path architecture can differ.

Final Checklist Before You Turn On Sending

Use this checklist after adding records in GoDaddy:

• The domain uses GoDaddy nameservers, or the records were added at the actual authoritative DNS provider.
• Existing MX records for inbound email were preserved.
• There is only one SPF TXT policy at each hostname where SPF is required.
• Every SPF include or IP authorization belongs to an active sending source.
• DKIM hostnames use the exact selector supplied by the sending provider.
• GoDaddy Name fields use prefixes such as _dmarc, bounce, or selector._domainkey, not the full root domain.
• CNAME values were pasted exactly from the provider’s instructions.
• The custom return-path does not conflict with another record at the same hostname.
• DMARC exists at _dmarc and begins with v=DMARC1.
• DMARC is initially in monitoring mode unless every sending source has already been audited.
• A live test message shows aligned SPF or DKIM and a DMARC pass.

A correct DNS setup does more than satisfy a provider verification screen. It gives mailbox providers a coherent identity story: the visible From domain, the DKIM signing domain, and the bounce or return-path domain are all intentional, authorized, and aligned.

FAQ

How do I get to DNS management in GoDaddy?

As of writing, sign in to GoDaddy Domain Portfolio, select the individual domain, then select DNS from its domain settings page. From the DNS records view, use Add New Record to create TXT or CNAME records. If your domain uses external nameservers, manage DNS with that provider instead.

Should I enter my full domain in GoDaddy’s Name field?

Usually no. For example.com, enter @ for the root, _dmarc for DMARC, selector._domainkey for DKIM, and bounce for a return-path subdomain. Entering the full hostname can lead to an unintended doubled domain name.

Can I have more than one SPF record in GoDaddy?

You can have TXT records for many purposes, but publish only one SPF policy beginning with v=spf1 for a given hostname. Merge legitimate sender mechanisms into one record where required.

Is a custom return-path the same as an MX record?

No. A custom return-path is typically a CNAME used for the SMTP envelope sender and bounce handling. MX records route inbound mail for a domain. Do not replace existing inbound MX records when setting up a return-path.

Should I set DMARC to p=reject immediately?

Usually not. Start with p=none, collect reports, and confirm that employee mail, transactional email, marketing platforms, support tools, and other legitimate senders pass aligned SPF or DKIM. Move to enforcement gradually once your sender inventory is complete.