Adding DKIM and Return-Path records to DigitalOcean is a core part of making application email trustworthy. Whether you send through an SMTP relay or a REST email API, correct DNS records let receiving servers verify your identity, evaluate SPF, and send delivery failures back to a domain you control.

This guide is vendor-neutral: the exact hostname and target values must come from your email provider, but the record types, DNS rules, verification steps, and troubleshooting process apply to any transactional or campaign sender.

What you are configuring—and why it matters

Two related but different email-authentication jobs are involved:

DKIM publishes a public key, or sometimes a provider-managed alias to that key. Your email service uses the matching private key to sign messages.
Return-Path, also called the envelope sender, MAIL FROM domain, or bounce domain, identifies where SMTP delivery status notifications and bounces should go. A custom Return-Path usually helps SPF authenticate a domain that is related to your visible From: domain.

These are not cosmetic DNS settings. A recipient server uses them at different points in processing a message. DKIM validation reads the DKIM-Signature header, obtains the selector and signing domain, and queries DNS for the corresponding key. SPF evaluates the domain used in SMTP's MAIL FROM command—typically shown after delivery in the Return-Path: header—not necessarily the address a recipient sees in the From: header. (datatracker.ietf.org)

A correctly configured domain does not guarantee inbox placement by itself. Content, sending patterns, complaint rates, recipient engagement, list quality, IP reputation, and link domains still matter. But a missing or malformed DKIM record can cause authentication failures immediately, while a poorly configured Return-Path can make SPF fail or pass without DMARC alignment.

For Gmail-bound mail, authentication is especially consequential. Google requires all senders to use SPF or DKIM, and senders dispatching more than 5,000 messages per day to personal Gmail accounts need SPF, DKIM, and DMARC. (support.google.com)

Before you add records in DigitalOcean

Confirm that DigitalOcean is authoritative for the DNS zone. It is common to host an application on a DigitalOcean Droplet while DNS is still managed at a registrar, Cloudflare, or another DNS provider. In that situation, adding records in the DigitalOcean control panel will not affect public DNS.

DigitalOcean's DNS workflow is to add the apex domain to your account, create the required records, and delegate the domain at your registrar to DigitalOcean's name servers. In the control panel, the documented path is Networking, then Domains; select the domain, choose Create a record, select a type, fill in its data, and choose Create Record. (docs.digitalocean.com)

Before changing anything, make an inventory of the email-related records already in production:

Existing SPF TXT record at the root domain, such as example.com.
Existing DKIM selectors used by Google Workspace, Microsoft 365, an ecommerce platform, a support tool, or another mail provider.
Existing DMARC record at _dmarc.example.com.
Existing subdomains such as mail.example.com, bounce.example.com, send.example.com, and em.example.com.
MX records for inbound mail. These are separate from most outbound Return-Path setups and should not be deleted.
DNS records used for website hosting, verification services, TLS certificates, or domain ownership checks.

Export or otherwise record the values before editing. DNS errors are often caused not by the new email record but by replacing an existing SPF policy, deleting a selector still used by another service, or attempting to put incompatible records at the same hostname.

Collect the exact values from your email provider

Your sending provider normally supplies a domain-authentication screen or setup documentation containing values similar to one of these patterns:

Purpose	Typical DNS type	Example hostname	Example value
DKIM direct key	TXT	`mta1._domainkey.example.com`	`v=DKIM1; k=rsa; p=MIIBIjAN...`
DKIM managed key	CNAME	`mta1._domainkey.example.com`	`mta1.example.provider-dkim.net`
Custom Return-Path delegation	CNAME	`bounce.example.com`	`u123.provider-mail.net`
Custom MAIL FROM route	MX	`mail.example.com`	`10 feedback-smtp.provider-mail.net`
SPF for a MAIL FROM subdomain	TXT	`mail.example.com`	`v=spf1 include:spf.provider-mail.net -all`

The provider values above are intentionally illustrative. Do not copy their hostnames or targets into a production zone. Your provider may give one CNAME, three DKIM CNAMEs, a TXT public key, an MX record plus a TXT SPF record, or a combination. Enter the values exactly as issued for your account.

If your mail platform supports both SMTP relay and an HTTP/REST API, the DNS records usually apply to the sending domain rather than the submission method. The same verified domain can be used by an application that sends through authenticated SMTP or through an API endpoint. Consult the provider's email API and setup documentation for its required domain values and its domain-verification behavior.

How DKIM DNS records work

DKIM, or DomainKeys Identified Mail, gives a receiving system a way to verify that designated parts of a message have not changed since the signing server created the signature. The sending system adds a DKIM-Signature: header. That header includes, among other parameters, a signing domain (d=) and selector (s=).

A receiver combines those values into a DNS lookup name:

<selector>._domainkey.<signing-domain>

For a message containing this header fragment:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mta1; ...

The receiving server looks up:

mta1._domainkey.example.com

DKIM uses DNS TXT records as its standard key-distribution mechanism. A selector lets a domain publish multiple keys at once, which is useful for different sending systems and for key rotation. (datatracker.ietf.org)

DKIM TXT records

A direct DKIM record typically resembles this zone-file notation:

mta1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

In DigitalOcean, create a TXT record. Enter the hostname portion your provider specifies and put the entire DKIM value in the record data. If the provider gives mta1._domainkey as the host name for the example.com zone, do not append .example.com again unless the provider explicitly gave the fully qualified name and DigitalOcean accepts it as such.

The critical field is p=, which holds a base64-encoded public key. It can be long. Do not add spaces, line breaks, smart quotation marks, or your own semicolons inside the key. A provider may display a long TXT value across several visual lines for readability; its instructions should tell you whether to enter it as one value or as quoted chunks. When in doubt, preserve the exact logical string supplied by the provider.

DKIM CNAME records

Many email services use CNAME records for DKIM instead of asking you to publish a raw public key. This lets the service rotate or update signing keys without requiring you to edit your zone every time.

Example zone-file notation:

mta1._domainkey.example.com. 3600 IN CNAME mta1.example.provider-dkim.net.

In DigitalOcean, create a CNAME record with the provider's specified hostname and target. A CNAME points one hostname to another canonical hostname; DigitalOcean supports CNAME records in its DNS management interface. (docs.digitalocean.com)

Do not convert a CNAME target into a TXT value. If the provider says CNAME, create CNAME. If it says TXT, create TXT. A DKIM lookup may eventually resolve to a TXT key through a CNAME chain, but the record you publish must match the provider's instruction.

Multiple selectors are normal

Seeing records such as s1._domainkey, s2._domainkey, google._domainkey, and mta1._domainkey is not evidence of a conflict. Each selector is a separate hostname. A domain can use multiple providers and rotate keys by publishing a new selector before switching the signing service to it.

Do not delete an older selector immediately after adding a new one. Messages sent before the change can be retried or delivered later, and a provider may still be signing from the older selector during a staged change. Keep it until the provider confirms the rotation is complete and you have allowed time for DNS caches and outstanding delivery attempts.

What a Return-Path is—and what it is not

The Return-Path is not the visible sender address shown in a mail client. The visible author address is in the RFC 5322 From: header, for example:

From: Product Alerts <alerts@example.com>

The envelope sender is used during SMTP transmission:

MAIL FROM:<bounces@bounce.example.com>

After final delivery, a receiving system commonly records that envelope sender in a header such as:

Return-Path: <bounces@bounce.example.com>

SMTP defines the MAIL FROM: command in terms of a reverse-path. It is this envelope identity that is relevant to delivery notifications and SPF evaluation, not the friendly display name or visible From: header. (rfc-editor.org)

A custom Return-Path generally uses a subdomain rather than the apex domain. For example:

From: receipts@example.com
Return-Path: bounces@bounce.example.com

This design separates operational bounces from normal user mail while retaining organizational alignment. It also prevents a sending service's own domain from being used as the envelope identity, which can improve clarity and help support SPF alignment for DMARC.

The phrase “Return-Path record” can mean different records

There is no universal DNS record type named “Return-Path.” The term is shorthand for whichever DNS records an email provider requires to enable a custom bounce domain or custom MAIL FROM domain.

Common patterns include:

One CNAME record that delegates bounce.example.com to the provider.
An MX record plus a TXT SPF record at a MAIL FROM subdomain such as mail.example.com.
A CNAME plus additional tracking-domain CNAME records, where only one is tied to the Return-Path.
No customer-managed Return-Path DNS at all, because a provider handles the envelope domain on its own infrastructure.

Read the labels in your provider's setup flow carefully. “Custom MAIL FROM,” “bounce domain,” “envelope sender,” “return path,” and “SPF subdomain” are often used for overlapping features, but their exact DNS requirements differ.

Add the records in the DigitalOcean control panel

Once you have verified that DigitalOcean is authoritative and obtained the exact values, create the records one at a time. DigitalOcean supports TXT, CNAME, MX, and other standard record types, and DNS records have an independently configured TTL. (docs.digitalocean.com)

Add a DKIM TXT record

Suppose your provider gives these values:

Type: TXT
Host: mta1._domainkey
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...

In the DigitalOcean domain's records page:

Choose Create a record.
Select TXT.
Enter mta1._domainkey as the host name if that is the provider's relative host value.
Paste the full DKIM string into the record data.
Choose a TTL. A value such as 300 or 600 seconds is practical while validating; 3600 seconds is a reasonable steady-state choice for records that rarely change.
Select Create Record.

DigitalOcean notes that 300 or 600 seconds can be useful for frequently updated records, while 3,600 or 86,400 seconds are reasonable when updates are infrequent. Lower TTL values help future changes propagate through resolver caches sooner, but they do not repair a currently cached negative result immediately everywhere. (docs.digitalocean.com)

Add a DKIM CNAME record

If your provider instead supplies:

Type: CNAME
Host: mta1._domainkey
Target: mta1.example.provider-dkim.net

create a CNAME record rather than a TXT record. The hostname remains mta1._domainkey; the record data is the provider target.

If the service provides three selectors—perhaps mta1, mta2, and mta3—create all three. A missing one can leave a domain partially authenticated or cause the provider's verification screen to remain pending.

Add a custom Return-Path CNAME

For a CNAME-based bounce-domain setup, the provider may issue values like:

Type: CNAME
Host: bounce
Target: u123.provider-mail.net

Create:

bounce.example.com. 3600 IN CNAME u123.provider-mail.net.

The sending provider can then use envelope addresses such as bounces@bounce.example.com. Do not create an A record at bounce.example.com as well. A hostname that has a CNAME should not also carry MX, TXT, A, or other data records; choose a different subdomain if you need a separate record set.

Add an MX and SPF-based custom MAIL FROM setup

Some providers instead ask for an MX record and a TXT SPF record at a dedicated subdomain. An illustrative set might be:

mail.example.com. 3600 IN MX 10 feedback-smtp.provider-mail.net.
mail.example.com. 3600 IN TXT "v=spf1 include:spf.provider-mail.net -all"

In DigitalOcean, create the MX record with the requested priority—10 in this example—and the provider's mail-exchange host. Then create the separate TXT record at the same mail hostname with the exact SPF string supplied by the provider.

This pattern is compatible because MX and TXT are separate record types at the same name. It is not compatible with a CNAME at that same name. If you already created mail.example.com as a CNAME for another service, use the dedicated subdomain your provider recommends or choose another unused subdomain if the provider permits it.

SPF, DMARC, and alignment after the change

DKIM and Return-Path configuration should be evaluated together with SPF and DMARC, not as isolated green checks.

SPF is a DNS-based authorization system. A receiving server checks whether the sending IP is permitted by the SPF policy for the SMTP envelope domain. An SPF record often starts with v=spf1; it can include mechanisms such as include:, ip4:, ip6:, a, and mx, followed by a policy such as -all or ~all. (datatracker.ietf.org)

Never publish multiple SPF TXT policies at one hostname

A common operational mistake is creating a second root-domain TXT record such as:

v=spf1 include:spf.new-provider.example -all

when example.com already has a record for Microsoft 365, Google Workspace, or another sender. SPF expects one policy record for a domain. Multiple competing v=spf1 records can produce an SPF PermError.

Instead, merge authorized sending mechanisms into one policy only after confirming the existing services still need them. For example:

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

That is only an example. Use the exact include domains your services document, and count DNS-query-producing mechanisms. SPF evaluation has a limit of 10 DNS lookups, so adding includes blindly can create failures even when the syntax looks valid.

A dedicated Return-Path subdomain often avoids changing the root SPF record. If a provider asks you to publish SPF at mail.example.com, it is usually asking for an authorization policy specifically for the envelope domain it will use.

DMARC alignment is the important second-order result

DMARC compares the visible From: domain against domains authenticated by SPF and DKIM. A message can have spf=pass for a provider-owned bounce domain but still fail SPF alignment if that domain is unrelated to the visible author domain. Conversely, DKIM can provide aligned authentication even if SPF is not aligned.

A simplified desired result looks like this:

From: notices@example.com
DKIM d=example.com; result=pass
Return-Path: bounces@bounce.example.com
SPF domain=bounce.example.com; result=pass
DMARC header.from=example.com; result=pass

For DMARC, example.com and bounce.example.com are organizationally related under relaxed alignment, which is the common default. Strict alignment is more restrictive. Review your own DMARC record before making assumptions about policy behavior.

Verify public DNS before clicking “verify”

After publishing a record, verify it independently. Provider dashboards can cache results or poll on a schedule; public DNS tools show whether the record is visible to resolvers.

Use dig on macOS, Linux, or Windows systems with BIND tools installed:

dig +short TXT mta1._domainkey.example.com
dig +short CNAME mta1._domainkey.example.com
dig +short CNAME bounce.example.com
dig +short MX mail.example.com
dig +short TXT mail.example.com

Query a known resolver when troubleshooting cache differences:

dig @1.1.1.1 +short TXT mta1._domainkey.example.com
dig @8.8.8.8 +short CNAME bounce.example.com

On Windows PowerShell, use:

Resolve-DnsName -Type TXT mta1._domainkey.example.com
Resolve-DnsName -Type CNAME bounce.example.com
Resolve-DnsName -Type MX mail.example.com

You can also use named web tools such as MXToolbox for DKIM, SPF, MX, and DMARC lookups. DigitalOcean provides a browser-based DNS Lookup tool as part of its DNS reference resources. (docs.digitalocean.com)

Check these details rather than merely checking whether “a record exists”:

The record is at the full expected hostname.
The type is correct: TXT is not CNAME, and CNAME is not TXT.
The CNAME target is complete and has no accidental duplicate suffix.
The DKIM TXT value includes v=DKIM1 and an intact p= value when using a direct key.
An MX record has the required priority and exact target.
The Return-Path hostname does not have conflicting records.
Authoritative name servers for your domain are actually the provider where you made the edit.

Test a real message, not just DNS

DNS verification proves that a receiver can find your records. It does not prove that your mail platform is signing with DKIM, using the custom envelope domain, or sending from an authorized IP. Send a real message after the provider reports the domain verified.

Use a test mailbox you control, then inspect the message source or “original” view. Look for an Authentication-Results: header resembling:

Authentication-Results: mx.recipient.example;
       dkim=pass header.d=example.com header.s=mta1;
       spf=pass smtp.mailfrom=bounces@bounce.example.com;
       dmarc=pass header.from=example.com

Exact header formatting differs by mailbox provider, but the important outcomes are:

dkim=pass, with the expected header.d= domain.
spf=pass, with the intended envelope sender domain.
dmarc=pass, when you have published DMARC and alignment is expected.
A Return-Path: that matches the custom bounce domain you configured.

For a broader deliverability diagnostic, send a test to mail-tester.com and review its authentication findings alongside content and message-structure feedback. Do not treat one score as an inbox-placement guarantee; use it to identify specific configuration defects.

At the SMTP submission layer, a successful handoff normally returns a 250 reply after message acceptance. A 451 reply is generally a transient failure that may be retried, while a 550 reply indicates a permanent rejection in many mail flows. Those codes tell you whether a receiving or relay server accepted the message; they do not alone reveal whether DKIM or SPF passed after delivery. (rfc-editor.org)

Common DigitalOcean DNS mistakes and fixes

DigitalOcean is not authoritative

Symptom: The control panel shows the new record, but dig against public resolvers returns nothing or returns an older value.

Fix: Check the domain's NS delegation at the registrar. If the registrar points to another DNS provider, create the record there instead. If you are migrating DNS to DigitalOcean, recreate all production records before changing name servers to avoid website and email outages. DigitalOcean specifically recommends recreating existing records before delegation. (docs.digitalocean.com)

The domain suffix was duplicated

Symptom: You intended mta1._domainkey.example.com, but the record resolves as mta1._domainkey.example.com.example.com.

Fix: Use the hostname format expected by the DigitalOcean zone editor and provider instructions. Inspect the full hostname shown after saving, then query that exact fully qualified domain name.

CNAME and other records share the same name

Symptom: Provider verification fails, an existing record disappeared, or DigitalOcean rejects the record arrangement.

Fix: A CNAME alias must stand alone at its hostname. Move the conflicting service to another subdomain, or use the provider's alternate configuration pattern if it offers one.

The DKIM key was edited or split incorrectly

Symptom: The selector resolves but a message shows dkim=fail, dkim=neutral, or a provider says the key is invalid.

Fix: Compare every character against the provider's supplied value. Pay particular attention to quotation marks, spaces introduced by copying, missing p= data, and accidentally pasting a second TXT record into the same value. Do not manually rewrap a key unless the provider explicitly documents the needed format.

The wrong selector was tested

Symptom: dig finds a DKIM record, yet messages still fail.

Fix: Open the actual message source and inspect s= and d= in DKIM-Signature. Query exactly s._domainkey.d. A correct mta1 record does nothing for a message signed with s=mta2.

A second SPF record was added

Symptom: SPF result is permerror or a checker reports multiple SPF records.

Fix: Consolidate policies into one valid v=spf1 TXT record at that hostname. Do not remove legitimate authorization mechanisms for other senders without confirming their mail flow.

DNS was correct, but the provider has not enabled the domain

Symptom: Lookups are correct, but test messages use the provider's default DKIM domain or default Return-Path.

Fix: Complete the provider's verification or activation step, then ensure your application uses an approved From: domain. Some services will accept API or SMTP submissions but rewrite unverified sender identities or use a default bounce domain until verification is complete.

Automate records carefully with doctl or the API

For infrastructure-as-code workflows, DigitalOcean supports DNS record management through its API and the official doctl CLI. The doctl compute domain records create command accepts record type, name, data, TTL, and—for MX records—priority. Its documented default TTL is 1800 seconds if you do not pass a TTL explicitly. (docs.digitalocean.com)

Illustrative commands:

doctl compute domain records create example.com \
  --record-type CNAME \
  --record-name bounce \
  --record-data u123.provider-mail.net \
  --record-ttl 3600

doctl compute domain records create example.com \
  --record-type TXT \
  --record-name mta1._domainkey \
  --record-data 'v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...' \
  --record-ttl 3600

doctl compute domain records create example.com \
  --record-type MX \
  --record-name mail \
  --record-data feedback-smtp.provider-mail.net \
  --record-priority 10 \
  --record-ttl 3600

Treat these commands as examples, not a substitute for provider-specific values. Keep authentication records in version control only when your process protects sensitive operational details. DKIM public keys are public by design, but API tokens, provider credentials, and private signing keys must never be committed.

Before automating changes, list the current zone and compare it to the desired state. An idempotent deployment should avoid duplicating TXT records or overwriting unrelated MX records. DigitalOcean documents doctl compute domain records list <domain> for retrieving records and IDs before updates or deletions. (docs.digitalocean.com)

A safe production checklist

Use this checklist before declaring the setup complete:

FAQ

Do I need both DKIM and a custom Return-Path?

They solve different problems. DKIM cryptographically signs the message using a DNS-published public key, while a custom Return-Path controls the SMTP envelope domain used for bounces and SPF evaluation. Many providers can send with DKIM alone, but configuring both usually provides a stronger, more controllable authentication setup.

Should the Return-Path match the visible From address exactly?

Usually no. It is common to use a dedicated subdomain, such as bounce.example.com, while sending visible mail from example.com. That structure separates bounce handling while remaining organizationally related for relaxed DMARC alignment.

Can I have more than one DKIM record?

Yes. Multiple DKIM selectors are normal and allow several sending services or staged key rotation. Each selector must use its own hostname, such as mta1._domainkey.example.com and mta2._domainkey.example.com.

Why does DigitalOcean show the record but my provider cannot verify it?

Most often, DigitalOcean is not the authoritative DNS host, the hostname was entered incorrectly, the record type is wrong, DNS caches have not expired, or the provider is checking a different selector or subdomain. Verify the exact fully qualified record with dig and inspect your registrar's name-server delegation.

Does a 250 SMTP response mean DKIM and SPF passed?

No. 250 means the SMTP server accepted the message at that stage. Authentication results are evaluated by receiving systems later in the delivery process. Inspect the delivered message's Authentication-Results header to confirm dkim=pass, spf=pass, and—where applicable—dmarc=pass.

How to Add DKIM and Return-Path Records to DigitalOcean DNS