How to Add SPF, DKIM, and DMARC Records in DigitalOcean DNS

If you need to add SPF DKIM DMARC records in DigitalOcean, the important part is not simply creating four DNS rows. You need to publish the right records at the authoritative DNS provider, preserve any existing sending services, and make sure the domains used for SPF, DKIM, and DMARC can align.

This guide walks through the DigitalOcean dashboard workflow, explains what each email-authentication record does, and shows the Type/Host/Value shape to use. The examples use example.com and placeholders rather than a copy-paste configuration: always use the exact DKIM and return-path values generated for your sending domain in Volanea.

Before you change DNS: confirm DigitalOcean is authoritative

A domain can be registered with one company while DNS is hosted somewhere else. That distinction matters here: DigitalOcean provides DNS hosting, but it is not a domain registrar. If you bought a domain from another registrar and later pointed its nameservers to DigitalOcean, you edit the records in DigitalOcean. If the domain still uses nameservers from your registrar, Cloudflare, or another DNS provider, adding records in DigitalOcean will not affect live email authentication.

Check the domain’s nameservers before you begin. A command-line lookup is one way to do that:

dig NS example.com +short

If the result includes DigitalOcean nameservers such as ns1.digitalocean.com, ns2.digitalocean.com, and ns3.digitalocean.com, DigitalOcean is authoritative and is the right place to publish records. If it does not, make the changes at the provider named in the NS response instead.

This is the first cause of many “record not found” or “domain still pending verification” reports. A record can look perfect inside a DNS dashboard yet be invisible to receivers if the zone is not authoritative.

Do not switch nameservers just to add email records

Changing nameservers is a zone migration, not a normal email setup step. It can interrupt a website, inbound email, verification services, subdomains, and other DNS-dependent services when records are not copied completely. If your DNS is already hosted elsewhere, add the Volanea records there.

If you do intentionally move DNS to DigitalOcean, recreate every required existing record before changing nameservers: A and AAAA records, www aliases, MX records, existing TXT records, CAA records, verification records, and service subdomains. DigitalOcean recommends recreating records before delegation to avoid downtime.

The DigitalOcean dashboard path for DNS records

As of writing, the verified DigitalOcean Control Panel path is:

1. Sign in to the DigitalOcean Control Panel.
2. In the main navigation, select Networking.
3. Select Domains.
4. Choose your apex domain, such as example.com.
5. On the domain’s Domain records page, select Create a record.
6. Choose the required record type, enter the hostname and value, then select Create Record.

If you do not see the domain under Networking → Domains, it has not been added to that DigitalOcean team yet, or you are viewing a different team. Add the apex domain first, then create records below it. For example, add example.com, not mail.example.com, as the managed zone; subdomains are created as records within the example.com zone.

The dashboard may change wording or layout over time, but the functional route is Networking, then Domains, then the domain’s record list. Avoid guessing based on a registrar’s interface: DigitalOcean’s DNS screen is a zone editor, not a domain-registration panel.

The four records you may need

Email authentication has separate jobs. SPF authorizes the infrastructure that uses an envelope sender domain. DKIM publishes a public key or delegated key location that lets receivers validate a cryptographic signature. DMARC tells receivers how to evaluate alignment between the visible From domain and passing SPF or DKIM results. A custom return-path gives the sending platform an envelope-sender subdomain under your domain.

Volanea’s domain setup screen is the source of truth for provider-specific values. In particular, DKIM selectors, CNAME targets, and return-path targets are generated values. Do not substitute values from another account, another provider, a blog post, or an old setup.

Use this table as the DigitalOcean record-entry shape.

The words “shape” and “exact value” are deliberate. selector, bounce, PROVIDER-VALUE, and the CNAME destinations above are examples only. Your Volanea domain page supplies the values that belong to your account and sending domain. Follow its record type exactly.

Add the SPF record without breaking existing mail

SPF is published as a DNS TXT record. It states which servers are permitted to send mail using an envelope sender domain, also called the SMTP MAIL FROM domain or return-path domain. Receivers query that domain’s SPF policy and compare it with the system that actually transmitted the message.

A simple SPF value might look like this:

v=spf1 include:mail-provider.example ~all

That is only an illustration. Do not use mail-provider.example literally. If Volanea provides an include mechanism for your configuration, add that exact mechanism to the SPF record for the hostname it specifies. If your Volanea configuration uses a custom return-path CNAME that is managed by Volanea, SPF may be evaluated against that delegated return-path subdomain instead of the root domain. This is why you should not assume an apex SPF change is always required.

There must be one SPF policy per hostname

The rule that catches many teams is simple: do not create a second TXT record that begins with v=spf1 at the same hostname. SPF standards do not permit multiple SPF records for one owner name. Multiple records can produce an SPF permanent error, which prevents SPF from passing even for otherwise valid senders.

For example, this is wrong at the apex of example.com:

@ TXT "v=spf1 include:_spf.google.com ~all"
@ TXT "v=spf1 include:volanea.example ~all"

Instead, merge approved mechanisms into one policy after confirming both services need to send with the same envelope-sender domain:

@ TXT "v=spf1 include:_spf.google.com include:volanea.example ~all"

Again, the Volanea include value is illustrative. Use the platform’s generated or documented sending-domain instructions. If your company uses Google Workspace, Microsoft 365, a support desk, an e-commerce tool, and a transactional-email provider, each may need to be represented in one policy—but only if it sends using that same SPF identity.

Avoid SPF lookup-limit surprises

SPF evaluation has a DNS-lookup limit. Includes, redirects, a, mx, exists, and some other mechanisms can cause lookups. A record may appear short while expanding through nested includes into too many lookups. That failure can be hard to spot because each individual vendor instruction looks reasonable in isolation.

Before merging new infrastructure into an older SPF policy, inventory all systems that send mail as the relevant domain. Remove services that no longer send. Do not add IP ranges “just in case,” and do not flatten or rewrite a provider’s SPF record without a process for keeping it current. A specific, maintained SPF record is safer than a long collection of historical senders.

Choose ~all or -all deliberately

The final SPF qualifier signals how non-authorized senders should be treated. ~all is a soft fail and is often used while a domain’s sending inventory is being stabilized. -all is a hard fail and is more restrictive. Neither setting alone creates DMARC enforcement; DMARC separately evaluates aligned SPF and DKIM results.

For most new transactional domains, the stronger practical milestone is a working DKIM signature aligned with the visible From domain, plus a DMARC record in monitoring mode. Move toward stricter SPF and DMARC policies only after testing every legitimate mail stream.

Add DKIM exactly as Volanea provides it

DKIM signs an outgoing message with a private key. The receiving server fetches the matching public key—or follows a CNAME delegation—to verify that the message was signed by an authorized domain and that the signed content was not modified after signing.

A DKIM DNS name normally includes a selector and the _domainkey label:

selector._domainkey.example.com

When you are editing the example.com zone in DigitalOcean, the Host field normally represents the label beneath that zone. Therefore, enter:

selector._domainkey

not the whole hostname, unless the DigitalOcean form clearly renders and confirms the full name exactly as intended.

CNAME DKIM versus TXT DKIM

A provider can ask you to publish DKIM in either of two common ways:

• CNAME DKIM: You create a CNAME at a selector hostname that points to a provider-controlled hostname. The provider can rotate or manage the underlying key without asking you to republish a very long public-key TXT value.
• TXT DKIM: You create a TXT record at the selector hostname containing v=DKIM1 and the public key, often beginning with p=.

Use the type Volanea presents. Do not convert a CNAME instruction into a TXT record or vice versa. A receiver queries a specific selector name; publishing the right value under the wrong record type leaves DKIM unavailable.

If Volanea displays more than one DKIM record, create every record it requires. Multiple selectors can be normal. They are different names, such as s1._domainkey and s2._domainkey, so they are not the same issue as publishing multiple SPF policies at one hostname.

The most common DigitalOcean hostname mistake

The DigitalOcean-specific mistake to watch for is entering a fully qualified hostname into a host/name field that already appends the zone name. If you are editing example.com and Volanea tells you to create:

v1._domainkey.example.com

the host value you usually want in the DigitalOcean zone is:

v1._domainkey

Entering v1._domainkey.example.com can result in a record effectively named:

v1._domainkey.example.com.example.com

That record is valid DNS syntax but is at the wrong name, so Volanea and recipient servers cannot find it. After saving, inspect the record list and confirm that DigitalOcean displays the final hostname as exactly v1._domainkey.example.com.

The same rule applies to DMARC and return-path labels. Use _dmarc, not _dmarc.example.com; use bounce, not bounce.example.com, when the domain zone is already example.com.

Preserve the CNAME destination exactly

For a CNAME value, copy the provider destination exactly as shown. Do not replace it with an IP address, do not put the destination in quotation marks, and do not point a CNAME to your website. A CNAME is an alias to another DNS hostname, not a redirect and not a URL.

Also check for a conflict at the DKIM hostname. A CNAME cannot coexist with another record type at the same hostname. If selector._domainkey already has a TXT, CNAME, MX, or other record, investigate before adding a new CNAME. It may be an old mail-provider key or an existing active selector.

Publish a DMARC record for the visible From domain

DMARC is a TXT record located at _dmarc beneath the domain used in the visible From: header. If your application sends messages as receipts@example.com, the relevant DMARC lookup is normally:

_dmarc.example.com

In the DigitalOcean example.com zone, create a TXT record with Host:

_dmarc

A practical starting policy is:

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

Create the reporting mailbox or group before using it. Aggregate DMARC reports are XML attachments sent by participating receivers, and a busy domain can receive many of them. Use a dedicated mailbox, group, or report-processing service rather than an individual inbox.

What DMARC actually checks

DMARC does not merely ask whether SPF exists or whether a DKIM key can be looked up. It checks whether at least one of these passes and aligns with the domain displayed in the From header:

1. SPF passes for the envelope-sender or return-path domain, and that domain aligns with the visible From domain.
2. DKIM passes, and the signing domain in the DKIM signature aligns with the visible From domain.

For relaxed alignment, a related subdomain can align. For example, bounce.example.com can align with example.com. Strict alignment is narrower and requires an exact domain match. A custom return-path under your domain is useful because it can let SPF pass with a domain that is aligned to the visible sender identity.

DKIM often provides the most resilient alignment path for transactional platforms, while the return-path helps establish a branded envelope sender and can provide SPF alignment too. Configure both when Volanea provides both.

Start monitoring before enforcing

p=none asks receivers to monitor and report failures without requesting quarantine or rejection. It is the appropriate first step for many domains because it lets you discover legitimate senders you may have forgotten: billing systems, help desks, CRM platforms, website forms, internal apps, and forwarding services.

After reviewing reports and testing, you can increase enforcement in stages:

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

Then, when all legitimate traffic reliably authenticates:

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

Do not copy an aggressive p=reject policy just because another domain uses it. A restrictive policy protects against impersonation only when your real sources have been mapped and configured. Otherwise, it can send your own legitimate mail to spam or cause rejection.

Configure the custom return-path record

The return-path is the SMTP envelope sender used for bounces and many SPF evaluations. Recipients may see it in the message source as Return-Path, while the person reading the email sees the more familiar From: address. These are related identities, but they do not have to be identical.

A transactional provider may ask you to create a return-path CNAME such as:

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

In the DigitalOcean zone for example.com, that normally becomes:

Do not invent bounce if Volanea gives you a different hostname. The provider’s generated value controls where its bounce handling and SPF identity are configured.

Why a branded return-path is worth setting up

A default provider-owned envelope sender can still allow a message to pass DKIM and DMARC if DKIM aligns. But a custom return-path under your domain adds a second authentication path: the provider can send mail with a return-path such as bounce.example.com, and SPF can potentially align with example.com under relaxed DMARC alignment.

It also keeps bounce handling tied to a domain you control rather than exposing a shared or provider-branded envelope identity. That does not replace good sending practices, permission, unsubscribe handling, or content quality, but it is a sound part of an authenticated sending setup.

Set records safely in DigitalOcean

For each entry, select Create a record, choose the type, and fill the requested fields. DigitalOcean supports the TXT and CNAME record types used by standard email authentication. Leave TTL at the existing default unless you are actively troubleshooting a rollout or have a DNS policy that requires a specific value.

A shorter TTL can reduce the time resolvers retain a prior answer after a change, but it does not guarantee immediate global visibility. DNS propagation is a combination of authoritative updates, resolver caches, negative caching, and the TTL that was in place before your change.

Use this implementation checklist:

• Confirm that DigitalOcean nameservers are authoritative for the domain.
• Take a screenshot or export of existing TXT and CNAME records before editing.
• Copy Volanea’s DKIM and return-path hostnames and values exactly.
• Check whether an SPF record already exists before adding one.
• Merge SPF mechanisms into one policy when multiple legitimate services use the same hostname.
• Publish one DMARC TXT record at _dmarc.
• Inspect the final fully qualified names displayed in DigitalOcean after saving.
• Wait for DNS visibility, then trigger domain verification in Volanea.
• Send a real test message and inspect authentication results in its headers.

Verify DNS and verify the message are both correct

A DNS dashboard showing a saved record is not the same as a working email setup. Verification needs two layers: confirm that public DNS resolves to the expected value, then confirm that a delivered message passes authentication.

For DNS, query the exact names:

dig TXT example.com +short
dig TXT _dmarc.example.com +short
dig CNAME selector._domainkey.example.com +short
dig CNAME bounce.example.com +short

Replace selector and bounce with the labels Volanea generated. If your DKIM setup uses TXT rather than CNAME, query TXT for the selector name instead.

For the message layer, send a test email to a mailbox that lets you inspect original headers. Look for authentication results similar to:

spf=pass
dkim=pass
dmarc=pass

Also inspect the domains involved. A dkim=pass result alone is useful, but DMARC success depends on alignment with the visible From domain. If SPF passes for an unrelated provider domain and DKIM signs with an unrelated domain, DMARC can still fail for From: billing@example.com.

You can also use the email authentication setup guides to compare the records in your Volanea domain settings with public DNS. For a quick pre-send check of an individual recipient address, use the email address verification tool separately from domain authentication; address validity and domain authentication solve different delivery problems.

Troubleshooting DigitalOcean email DNS errors

Most setup failures come down to a record name, record type, stale DNS authority, or an existing conflicting record. Work through the symptoms methodically instead of repeatedly deleting and recreating the same records.

“Volanea cannot find my DKIM record”

First, query the exact fully qualified selector hostname shown by Volanea. If the result is empty, check whether the host field includes the root domain twice. For the example.com zone, selector._domainkey is generally the host label; entering selector._domainkey.example.com may create an unintended doubled suffix.

Next, check the type. A required CNAME cannot be replaced with TXT, and a CNAME target should be copied exactly. Finally, make sure the selector does not already have another record that blocks creation of the expected CNAME.

“My SPF record shows a permanent error”

List every TXT record at the same SPF hostname. If more than one begins with v=spf1, combine the approved mechanisms into one record and remove duplicate SPF policies. Do not delete non-SPF TXT records used for verification; multiple general TXT records are allowed, but there must not be multiple selected SPF policies.

Then inspect the record for syntax errors, accidental line breaks, malformed include: mechanisms, and excessive nested DNS lookups. If you are unsure which sender a mechanism belongs to, verify it before preserving it.

“DMARC exists but email still fails”

DMARC relies on aligned SPF or aligned DKIM, not just publication of a _dmarc record. Open a delivered message’s headers and compare the visible From domain to the DKIM d= domain and the SPF envelope-sender domain. A custom return-path on a subdomain of your From domain can help SPF alignment, while DKIM must sign using your domain or an aligned subdomain.

Also check the policy syntax. A DMARC record must begin with v=DMARC1, be published at _dmarc, and contain one policy value such as p=none, p=quarantine, or p=reject.

“The record was added, but verification is still pending”

DNS updates are not always immediate. Check public DNS rather than relying only on the Control Panel. If a query still returns the old data, allow time for caches to expire based on the prior TTL. If it returns no data, re-check nameserver authority and the final record name.

Do not keep changing values during propagation unless you have identified an error. Each change can reset what you are trying to observe and make diagnosis harder.

A final configuration checklist

Before you consider the domain ready for production sending, confirm all of the following:

1. DigitalOcean is authoritative for the domain’s DNS.
2. The root or envelope-sender SPF hostname has one valid v=spf1 record.
3. Volanea’s DKIM record type, selector hostname, and value match exactly.
4. The custom return-path CNAME uses the provider-generated label and destination.
5. _dmarc.example.com has one valid DMARC TXT record.
6. DMARC reporting goes to a mailbox or service you can monitor.
7. A real message shows SPF and/or DKIM passing with DMARC alignment.
8. Existing business mail streams still authenticate after the change.

Email authentication is not a one-time checkbox. Any time you add a new platform that sends as your domain, revisit SPF, DKIM, and DMARC alignment. The safest approach is to treat DNS as production infrastructure: document each record’s owner, remove obsolete senders, test actual message headers, and move DMARC enforcement gradually.

FAQ

Do I need all four records to send with Volanea?

You should configure the records Volanea generates for your domain. SPF, DKIM, and DMARC serve different purposes; the custom return-path is especially useful for branded bounce handling and SPF alignment. DKIM and DMARC are central to domain authentication, while the exact SPF and return-path implementation depends on the sending-domain setup shown in Volanea.

What should I enter in DigitalOcean’s Host field for _dmarc.example.com?

When editing the example.com zone, enter _dmarc. After saving, confirm that the displayed full hostname is _dmarc.example.com, not _dmarc.example.com.example.com.

Can I create a separate SPF TXT record for every email provider?

No. You can have multiple TXT records at a hostname, but only one SPF policy beginning with v=spf1 should exist for that hostname. Merge authorized mechanisms into one SPF record.

How long will DigitalOcean DNS changes take?

The record is saved immediately in the DigitalOcean zone, but public resolvers may retain older responses until their cached TTL expires. Query public DNS and wait before changing records again unless you find a clear configuration error.

Should I set DMARC to p=reject immediately?

Usually not. Begin with p=none, collect and review reports, verify every legitimate sender, then progress to quarantine or reject. Enforcing too early can harm delivery from systems that have not yet been authenticated.