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

A correct GoDaddy SPF DKIM DMARC setup helps receiving mailbox providers identify authorized mail, validate message signatures, and apply your domain’s delivery policy. The DNS work is straightforward once you separate records that are fixed by standards from records that must be copied exactly from your email-sending provider.

What these DNS records do—and why all four matter

Email authentication is not one switch. It is a set of independent checks that receivers such as Gmail, Yahoo, Microsoft, and corporate gateways combine with reputation, content, engagement, and other signals when deciding whether to accept, spam-folder, quarantine, or reject a message.

The three best-known standards are SPF, DKIM, and DMARC. A branded return-path is closely related because it establishes the domain used for SPF authentication and bounce handling. Providers may describe that same setting as a custom return-path, custom MAIL FROM domain, bounce domain, or envelope sender domain.

SPF authorizes sending infrastructure

Sender Policy Framework (SPF) is a DNS TXT policy that tells a receiver which systems are permitted to send mail using a domain in the SMTP envelope sender (MAIL FROM) or HELO/EHLO identity. When an SMTP server receives a message, it looks up the relevant SPF TXT record and evaluates the sending IP address against it.

SPF does not sign a message, and it does not authenticate the visible address that a recipient sees in the From: header by itself. That distinction is crucial. A message can pass SPF for a bounce domain while displaying a different visible From domain. DMARC is the standard that evaluates whether an authenticated SPF domain is suitably aligned with the visible From domain.

DKIM signs the content of each message

DomainKeys Identified Mail (DKIM) adds a cryptographic signature to the message headers. The sending platform signs the mail with a private key; a receiving server retrieves the corresponding public key from DNS and checks the signature.

The DKIM DNS name includes a selector, such as s1._domainkey or 2025a._domainkey. The selector lets a domain publish more than one DKIM key at once, which supports key rotation and separate sending services. Never assume a selector name: copy the selector and public key or CNAME target shown by the sending platform.

Unlike SPF, DKIM can remain valid after forwarding because it is tied to the message rather than to the connecting IP address. It can fail if an intermediary materially changes a signed header or the signed body content, but it is often the durable authentication path that preserves DMARC alignment.

DMARC tells receivers how to use authentication results

Domain-based Message Authentication, Reporting, and Conformance (DMARC) is published as a TXT record at _dmarc.yourdomain.com. It requires the visible From: domain to align with either a passing SPF identity or a passing DKIM identity.

DMARC also states what a receiver should do when aligned authentication fails. The common policy values are:

• p=none: request reporting and monitoring, with no DMARC enforcement request.
• p=quarantine: ask receivers to treat failing mail suspiciously, often by placing it in spam.
• p=reject: ask receivers to reject failing mail during delivery.

Starting with monitoring is usually safer for an established domain, because it reveals legitimate systems that send mail on the domain before enforcement affects them.

A return-path gives SPF a domain you control

Every SMTP message has an envelope sender, also called the return-path in common email terminology. It is where delivery-status notifications and bounces are directed. A provider-managed bounce address may look unlike your brand, while a custom return-path can use a delegated subdomain such as bounce.example.com or mail.example.com.

In most provider setups, you create a CNAME from your chosen subdomain to a provider-supplied target. The provider then controls bounce processing and the SPF policy for that delegated hostname. This is not the same as creating an SPF TXT record at the root of your domain; follow the record set displayed by the provider for the exact return-path it uses.

Before changing DNS: collect the provider-issued values

GoDaddy hosts the DNS zone, but it does not generate the correct authentication values for the platform that sends your mail. Open the sender-authentication or domain-verification section of your sending service first and copy every requested record into a scratchpad.

For Volanea, consult the current email API setup guides for the records and verification flow associated with the sending domain. The actual DKIM selector, public key, verification token, and custom return-path target are account- or domain-specific. They must be copied exactly rather than substituted with a generic example from a blog post.

Record requests can differ in meaningful ways. One provider may request a long DKIM TXT public key, while another requests a DKIM CNAME that points to a hosted key. One may use bounce as the return-path host, while another uses a generated host. Both are normal, but a record type or target from one provider cannot be reused for another.

Before opening GoDaddy, note the following for each record:

1. Record type: normally TXT for SPF and DMARC, and TXT or CNAME for DKIM; return-path delegation is commonly CNAME.
2. Host/name: the relative label to enter in GoDaddy, such as @, _dmarc, s1._domainkey, or bounce.
3. Value/content/target: the full SPF or DMARC policy, a DKIM public key, or the precise CNAME destination supplied by the sender.
4. TTL: use the provider’s requested TTL when one is provided. Otherwise, GoDaddy’s default is generally suitable during setup.
5. Whether an existing record already occupies the name: this matters especially for SPF, DMARC, and CNAME records.

Do not publish authentication records for a domain you do not control, and do not delete pre-existing records merely because their names look unfamiliar. Domains often have records for a website, Google Workspace or Microsoft 365, support software, verification services, and other senders.

Find DNS management in GoDaddy

As of writing, GoDaddy’s current domain-management flow starts in Domain Portfolio. After signing in, open My Products or the Domain Portfolio area, select the domain you want to edit to open Domain Settings, then select the DNS tab or DNS option to view the DNS records.

GoDaddy periodically changes page layout and wording, so you may instead see an entry such as Manage DNS from the selected domain’s controls. The important confirmation is that you reach the DNS records table for the exact domain that appears in the visible From address—for example, example.com, not a similarly named parked or forwarding domain.

Confirm that GoDaddy is actually authoritative

Buying a domain from GoDaddy does not always mean GoDaddy hosts its active DNS. The domain may use nameservers from Cloudflare, a website host, another registrar, or a company IT provider. If that is the case, records added to GoDaddy’s default DNS zone will not be returned publicly and email verification will fail.

Check the domain’s configured nameservers in the domain settings. If they point to another DNS service, make the changes in that service instead, or ask the DNS administrator to add them. A domain’s registrar, web host, DNS host, and email provider can all be different companies.

Work carefully in the records table

In the DNS records view, choose the control to add a record, select the requested record type, enter the host and value, then save. Existing records are edited from their row. GoDaddy may call the host field Name or Host and the data field Value, Data, Points to, or similar depending on record type and interface version.

After saving, return to the record list and inspect what GoDaddy displays as the fully qualified record name. This simple check catches the most frequent GoDaddy-specific entry error before you wait for a verification attempt.

SPF, DKIM, DMARC, and return-path record shapes

The following table shows the required shape of common authentication records. Replace every example domain, selector, key, include mechanism, and CNAME target with the values appropriate for your domain and sending provider. Quotation marks are typically not typed into GoDaddy unless the provider explicitly includes them as part of the value.

For example.com, the records above resolve conceptually as follows:

• @ represents example.com.
• _dmarc represents _dmarc.example.com.
• selector._domainkey represents selector._domainkey.example.com.
• bounce represents bounce.example.com.

When sending from a subdomain such as news.example.com, the right host names depend on the domain you authenticated. For example, a DMARC policy for that specific subdomain could be published at _dmarc.news.example.com, while a DKIM host could be selector._domainkey.news when entered relative to the example.com zone. Do not guess the relative form; compare the full name requested by the provider with the full name GoDaddy shows after saving.

Add SPF without breaking existing senders

SPF is deceptively easy to misconfigure because a domain often already has an SPF record for a business mailbox provider. Adding another TXT record beginning with v=spf1 at the same hostname is not a valid way to authorize a second service. Multiple SPF records can lead to an SPF PermError, which means receivers cannot reliably evaluate the policy.

Inspect the current root TXT records first

Search the GoDaddy DNS record list for TXT records at @. A TXT record is not automatically SPF: it may verify Google, Microsoft, a payment processor, or another service. Look specifically for a value beginning with v=spf1.

If no SPF record exists, add the provider-prescribed policy. If an SPF record exists, combine the mechanisms into the existing single SPF record only after confirming that each service needs root-domain authorization. For example, a conceptual combined policy might be:

v=spf1 include:_spf.google.com include:spf.sending-provider.example -all

That is an illustrative format, not a universal policy. Use the exact include domain documented by each service. Removing an existing mechanism can stop legitimate mailbox or application mail from passing SPF.

Keep DNS lookup limits in mind

SPF evaluation has a limit of 10 DNS-query-causing mechanisms and modifiers. Includes can themselves include other mechanisms, so a short-looking SPF policy can still exceed the limit. A policy that exceeds the limit can return PermError and weaken deliverability.

This is one reason to inventory every sending source instead of repeatedly appending includes over time. If your domain has several vendors, dedicated IP ranges, and a mailbox provider, consider consolidating senders or using an SPF-flattening strategy only with a clear process for maintaining it. Never flatten casually and then forget to update changed vendor IP ranges.

Choose ~all or -all deliberately

The final all mechanism says what SPF should do for senders that do not match the preceding authorization mechanisms. ~all is a soft fail, while -all is a hard fail. The right choice depends on whether you have completed your sender inventory and how your systems use SPF.

SPF alone does not instruct mailboxes how to handle visible From-domain impersonation. DMARC policy and alignment do that. Therefore, do not treat a soft SPF qualifier as a substitute for a staged DMARC rollout.

Add DKIM exactly as issued

DKIM entries are usually long, and formatting errors are common. The safest process is copy-and-paste from the sending platform, then compare the saved GoDaddy record with the source character for character. Do not add spaces, wrap lines manually, remove semicolons, or convert a TXT record into a CNAME because another guide used a different method.

TXT DKIM versus CNAME DKIM

A TXT-based DKIM record contains a value similar to v=DKIM1; k=rsa; p=..., where the p= content is the public key. GoDaddy may display the long TXT data as a single field even if it wraps visually in the browser. Visual wrapping is not necessarily a DNS line break.

A CNAME-based DKIM setup delegates the selector name to a target controlled by the email provider. In that model, the target—not a public key pasted into the record—is the important data. A CNAME cannot coexist with other records at exactly the same hostname, so remove conflicts only when you have confirmed they are obsolete and belong to the same intended service.

Preserve selector names

The selector is part of the DNS name, not part of the text value. If your provider asks for mta1._domainkey.example.com, entering only _domainkey or only mta1 will fail. If it asks for multiple selectors, publish each one; multiple DKIM selectors are normal during rotation.

A selector can contain letters, numbers, and permitted punctuation according to the provider’s setup. Its exact spelling and case handling should be preserved as issued. More importantly, do not reuse an old selector’s value for a new provider unless the provider specifically instructs you to do so.

Publish DMARC safely and make the reports useful

DMARC is powerful because it connects authentication to the user-visible From domain. It is also the easiest record to over-enforce prematurely. A strict p=reject policy on a domain with forgotten marketing tools, ticketing systems, forwarding workflows, or employee devices can block legitimate email.

A practical starting policy for a domain that has not been audited is:

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

This syntax is an example. The reporting mailbox must exist, be monitored, and be able to receive aggregate XML report attachments. The address can be on a separate reporting domain, but external reporting addresses require additional authorization records; using a mailbox at the protected domain avoids that extra setup.

Understand alignment before enforcing

DMARC passes when at least one of these conditions is met:

• SPF passes and the authenticated SPF domain aligns with the visible From domain.
• DKIM passes and the d= signing domain aligns with the visible From domain.

Alignment can be relaxed or strict. Under relaxed alignment, related organizational domains may align; strict alignment requires an exact domain match. The DMARC adkim and aspf tags control this behavior when specified. Leaving them unspecified uses relaxed alignment by default under the DMARC standard.

A custom return-path can make SPF alignment possible when it uses an aligned subdomain, such as a bounce.example.com envelope sender for visible mail from example.com. However, DKIM alignment is often the more robust path because it is not dependent on the return-path surviving every forwarding scenario.

Move from monitoring to enforcement in stages

Review aggregate reports for all legitimate sources over a meaningful period, including monthly invoices, password resets, support replies, product notifications, and campaign sends. Fix misaligned sources rather than simply allowing unknown traffic.

A measured progression might be p=none, then p=quarantine, then p=reject. The optional pct tag can apply a policy request to a percentage of failing mail during a transition. Enforcement is a domain-reputation and anti-spoofing control, not merely a deliverability setting, so involve the people responsible for every system that sends as your domain.

Configure a branded return-path CNAME

A branded return-path typically uses a subdomain dedicated to mail infrastructure. Common naming choices include bounce, mail, em, or a provider-recommended generated label. Choose the name requested in the authentication instructions rather than selecting a familiar-looking one from another service.

In GoDaddy, add a CNAME record with the relative host label and the exact provider target. For example, if the provider requests a mapping from bounce.example.com to u123.provider-mail.example, enter bounce in the host/name field and u123.provider-mail.example as the target/value. This example is illustrative only.

Do not use the root host @ for a return-path CNAME. The apex usually already needs other DNS records and cannot function as a normal CNAME in a conventional DNS zone. A distinct subdomain prevents that conflict and makes the mail role clear to administrators.

Why a CNAME target may look unfamiliar

The destination may contain a provider name, account identifier, region, or generated token. That is expected. The CNAME delegates the chosen subdomain to infrastructure that can process bounces and publish the necessary mail authentication data. Replacing it with your domain, website address, or an IP address defeats the configuration.

Some sending services request more than one CNAME, such as separate records for tracking, DKIM, and return-path. Each has a different function. A tracking CNAME does not authenticate mail, and a return-path CNAME does not replace DKIM.

The common GoDaddy mistake: entering a full domain in Host

The most common error when adding mail records in GoDaddy is entering a fully qualified host name in a field that expects only the label relative to the managed zone. GoDaddy appends the root domain to relative host entries, so a full name can produce a duplicated name.

For a DNS zone for example.com, use these entries:

If you enter bounce.example.com in a relative host field, inspect the resulting name after saving. Depending on the GoDaddy interface and entry parsing, it can be displayed or treated as bounce.example.com.example.com, which is not the hostname your provider queries. The same issue affects _dmarc.example.com and DKIM selector names.

The remedy is simple: edit the host to the relative label, save, and verify that the record list displays the expected fully qualified name. Do not rely on a provider’s “pending” status alone to diagnose this; query or inspect the exact record name.

A second common issue is confusing the host with the CNAME target. For a return-path record, bounce belongs in the host field; the provider-supplied destination belongs in the value/points-to field. For a DKIM TXT record, the selector belongs in host and the long key belongs in value.

Verify DNS publication and sender authentication

DNS changes can take time to become visible due to TTLs, recursive resolver caches, and provider-side verification intervals. A newly saved GoDaddy record may be visible quickly, but do not assume an immediate result is universal. Keep the record in place and allow the sending platform to retry verification according to its guidance.

Check the public DNS answer

Use a DNS lookup tool or command-line resolver to inspect the exact names:

• Query TXT for example.com to find SPF.
• Query TXT for selector._domainkey.example.com when DKIM uses TXT.
• Query CNAME for selector._domainkey.example.com when DKIM uses CNAME.
• Query TXT for _dmarc.example.com.
• Query CNAME for bounce.example.com.

The returned record must match the provider’s requested data. For SPF and DMARC, check every character in tags, include domains, semicolons, and final mechanism. For DKIM, ensure the public key is complete. For CNAME records, make sure the response is a CNAME to the exact requested target rather than a duplicated GoDaddy hostname.

Verify in the sending platform, then test a real message

Once public DNS returns the right records, use the provider’s domain-verification control. Do not send production traffic before the domain shows as authenticated if the service requires verification.

Then send a test message to a mailbox where you can inspect full headers. Look for authentication results showing SPF, DKIM, and DMARC. A successful result should identify the relevant domains and typically state pass; also check that the DKIM signing domain and SPF domain align with the visible From domain as expected.

If verification remains pending, work through this order:

1. Confirm GoDaddy’s nameservers are authoritative for the live domain.
2. Confirm record type, host, and value against the provider-issued values.
3. Look for host-name duplication caused by entering the full domain in the host field.
4. Check for conflicting CNAMEs, duplicate DMARC records, or multiple SPF policies.
5. Allow the requested TTL and retry verification.
6. Contact the sending provider with the full queried DNS result, not a screenshot of only the GoDaddy form.

Ongoing maintenance and delivery implications

Authentication should be treated as maintained infrastructure, not a one-time launch task. Keep a record of which application or service owns every mail-related DNS entry, who can change it, and what messages it sends. This documentation makes it far safer to rotate providers, move DNS hosting, or raise DMARC enforcement later.

When changing email platforms, do not remove old SPF includes, DKIM records, or return-path CNAMEs until all traffic has moved and delayed messages or retries have completed. Conversely, remove unused authorization after a migration is finished; leaving stale senders authorized expands the set of systems that can legitimately send as your domain.

Monitor bounce rates, complaint signals, authentication failures, and DMARC aggregate reports after significant changes. Authentication does not guarantee inbox placement, but missing or misaligned authentication makes it harder to build and preserve trust. Good list practices, accurate recipient data, useful content, sensible sending patterns, and clear unsubscribe handling remain essential.

FAQ

Do I need SPF, DKIM, and DMARC if I only send transactional email?

Yes. Password resets, receipts, invitations, and other transactional messages still need trustworthy authentication. DKIM and DMARC alignment are especially important for protecting the visible From domain, while SPF and a custom return-path support envelope-sender authentication and bounce processing.

Should I create a second SPF TXT record for my new email provider?

No. A hostname should have one SPF policy record. If a root-domain SPF record already exists, merge the required authorization mechanism into that existing v=spf1 value after confirming it will not remove other legitimate senders.

What should I enter for the Host field for a DKIM record in GoDaddy?

Enter the relative host label provided by your sender. For a full name such as s1._domainkey.example.com in the example.com DNS zone, enter s1._domainkey. Verify that GoDaddy displays the resulting full name correctly after saving.

Can I set DMARC to p=reject immediately?

You can, but it is risky unless you have inventoried every legitimate sender and confirmed alignment. Start with p=none, review aggregate reports, fix unauthorized or misconfigured sources, and move toward enforcement deliberately.

Does a return-path CNAME replace SPF or DKIM?

No. A return-path CNAME delegates a bounce or MAIL FROM subdomain to the sending provider. SPF, DKIM, and DMARC each have separate roles and should be configured according to the provider’s requested record set.