DigitalOcean SPF, DKIM and DMARC setup, step by step

On this page: Before you edit: confirm authority and preserve the baseline · Map the complete DNS owner to the correct zone · Publish or merge the SPF TXT policy · Publish the sender's DKIM record, then enable signing · Publish DMARC without weakening existing protection · Verify authoritative DNS, recursive DNS and actual mail · Troubleshooting and controlled recovery · Frequently asked questions · Documentation review and testing boundary

Quick answer: In DigitalOcean, open Networking → Domains → your domain → Create a record. Publish SPF and DMARC as TXT records. Publish DKIM as the TXT public key or CNAME delegation supplied by your actual sending service. If an SPF policy already exists at the required name, edit that policy rather than adding another. Then verify public DNS and complete the sender's own verification or signing activation. DigitalOcean record management

DigitalOcean DNS stores the records used by receivers; it does not choose your email service's SPF authorization, DKIM selector or signing identity. Hosting a website on a Droplet does not establish that DigitalOcean hosts its DNS or sends its mail. This guide covers publishing into an already approved, compatible DigitalOcean-hosted zone, not configuring a mail server or migrating nameservers.

Before you edit: confirm authority and preserve the baseline

Identify the sending service, the business mail flow, the visible From domain, and the exact DNS owners its setup requires. Obtain current values from that service's account or support team. A record copied from another organization's tutorial may be valid syntax but authorize the wrong sender.

Check which nameservers are authoritative for the relevant zone. Confirm the DigitalOcean team and zone match that delegation. A domain listed in your account can be an inactive copy; a subdomain may be delegated elsewhere. Inspect delegation rather than assuming all records below your registered domain belong in its parent zone.

DNSSEC boundary: DigitalOcean documents that its nameservers do not support DNSSEC-enabled domains and that DS-record creation is unavailable. If your current domain is signed or a signed delegation is involved, stop and have the domain's security owner resolve hosting compatibility. Do not disable DNSSEC, remove a registrar DS record or move nameservers as an incidental email-authentication fix. DigitalOcean DNS limits

Before an authorized change, retain the current owner, type, value and TTL of each affected record. Download a zone copy from Networking → Domains → the domain's … menu → Download zone. Keep a dated, minimal change plan alongside it. The export is a record inventory, not a promised one-click restoration feature. DigitalOcean zone export

Do not change inbound MX records, web addresses, verification tokens or unrelated DKIM selectors merely to publish outbound authentication. Check wildcard-dependent names too: adding a record can stop a wildcard answer applying at that hostname. DigitalOcean wildcard limitation

Map the complete DNS owner to the correct zone

Keep the complete public name separate from the editor entry. DigitalOcean's TXT Hostname uses @ for the zone apex and a prefix for a subdomain; TXT Value contains the record data. CNAME records have Hostname and Is an alias of fields. DigitalOcean field definitions

The following fictional names illustrate owner construction, not records to publish:

If news.example.com is delegated to another DNS host, make the change there. Do not create an ineffective parent-zone copy below the delegation. Avoid duplicating the suffix, such as _dmarc.example.com.example.com. For CNAME targets, use the complete provider-supplied hostname and inspect the saved result; do not substitute an IP address or your website address.

For the table's mail1._domainkey.news.example.com, a separately delegated news.example.com zone uses relative Hostname mail1._domainkey. If _domainkey.news.example.com itself is delegated, its relative owner is mail1. Preserve the existing NS delegation and other active selectors; use the actual selector supplied by your sender, not this naming example. DNS zone boundaries.

Publish or merge the SPF TXT policy

SPF normally evaluates the SMTP envelope MAIL FROM domain, visible in trusted receiver results as smtp.mailfrom. It does not evaluate the display name or automatically use the visible From domain. For a null reverse-path, SPF uses the HELO identity. A policy at example.com does not automatically authorize bounce.example.com. RFC 7208 identity rules

There is no universal DigitalOcean DNS SPF include. Obtain the actual sending service's required authorization and determine which envelope owner you control. If that service uses its own envelope domain, adding a guessed include at your apex will not change its alignment.

1. Query the intended owner for existing TXT records and save the full answers.
2. Identify the existing v=spf1 policy, if any. Inventory the corporate mail service, application senders and any other legitimate dependencies before changing it.
3. Prepare one combined policy at that owner. Add only the sender-approved mechanisms, before the terminal all mechanism; retain the established qualifier and authorized senders. Review a policy using redirect= with its owner rather than appending an all that changes its meaning.
4. Open the selected domain. For an existing policy, use its … → Edit record action. Otherwise choose Create a record → TXT.
5. Enter the correct Hostname, the complete reviewed SPF value and the approved TTL. Save, then perform the DNS checks below.

The one-policy rule applies at each evaluated owner, not just the root domain. Other TXT records can coexist. Several quoted character strings inside one TXT record are concatenated without inserted spaces and are not automatically duplicate policies. A 255-octet character-string limit is not a 255-character limit for the entire SPF policy. RFC 7208 record rules

If the existing SPF policy uses redirect=, reconcile its authorizations and terminal behavior with the DNS owner before changing it. Any all mechanism makes redirect ignored regardless of their order. Do not append all automatically: preserve the redirected senders and approved policy semantics through a reviewed redesign. SPF qualifiers describe authentication results, not guaranteed receiver delivery or rejection decisions. SPF all and redirect processing.

SPF permits at most ten evaluated DNS-dependent terms, including nested processing: include, a, mx, ptr, exists and redirect. It is not a count of just top-level includes or DNS packets. ip4, ip6 and all do not consume that term budget. Exceeding the limit produces permerror; blindly flattening provider ranges creates a separate maintenance risk. RFC 7208 processing limits

For an existing duplicate-policy problem, reconcile the approved authorizations into one policy rather than adding another sample record.

Publish the sender's DKIM record, then enable signing

Start at the sending service, not a generic key generator. Select the domain you want it to sign for and obtain its current public record set. Record the intended signing domain, every selector, each record type and its complete value. A two-selector service may require both records even when only one signs current messages.

For TXT, place the exact public value in TXT Value. For CNAME, place the exact delegation hostname in Is an alias of. Do not turn one type into the other. Never put the private signing key into DNS. A DKIM lookup is constructed from the signature's s= selector and d= signing domain: selector._domainkey.signing-domain. DKIM key retrieval

Inspect each owner before saving. A CNAME cannot coexist with ordinary TXT, A, MX or another conflicting record at the same name. If another service uses that selector, obtain a supported alternate selector rather than deleting the working record. A DKIM CNAME ultimately needs the appropriate public-key TXT answer; do not add an A record merely because web-oriented CNAME examples discuss address resolution. CNAME rules, DKIM key storage

After DNS is correct, return to the actual sender. Run its verification step and enable signing if required. Publishing in DigitalOcean alone does not activate the sender. Keep old working selectors until the service owner confirms their rotation and in-flight-message requirements are satisfied.

Publish DMARC without weakening existing protection

DMARC compares the visible From domain with authenticated identifiers. It passes when at least one SPF or DKIM result both passes and aligns. Relaxed alignment permits a shared organizational domain; strict aspf=s or adkim=s requires the respective authenticated domain to exactly match From. A valid provider-domain DKIM signature is not automatically aligned with your domain. Current DMARC standard, RFC 9989

Look up the applicable _dmarc owner and review parent-domain policy discovery before adding anything. An absent _dmarc.news.example.com record does not mean news.example.com is unprotected. A parent policy may apply. Adding a child p=none can weaken inherited enforcement.

Preserve existing policy, reporting destinations and alignment settings unless their owner approves a deliberate change. For a genuinely new deployment with no applicable established policy, an approved monitoring policy may be appropriate while senders are inventoried. Do not automatically replace quarantine or reject with a tutorial default, and do not enforce based on one successful test.

Only for a new monitoring deployment with no existing direct or inherited policy, this minimal illustrative TXT value expresses no quarantine/rejection request. It does not enable report collection by itself:

v=DMARC1; p=none

If approved aggregate reporting is being configured, append ; rua=mailto: followed by the actual approved report address, with no placeholder text left in DNS. Retain the existing reporting destination instead when one already applies. DMARC policy format

Publish the reviewed policy as TXT at the owner in the mapping table. Use only reporting addresses your organization controls or has approved. Do not copy another customer's rua, add failure reporting casually, or assume publishing p=none alone creates a useful monitoring program. Assign someone to review aggregate reports across the legitimate sending routes.

Compare the Organizational Domain of the aggregate-report URI's host with the Organizational Domain of the domain where the DMARC policy was found, which is not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as the policy domain is excepted; a different hostname alone does not make it external. Follow the report receiver's exact authorization instructions when needed. This protocol check is separate from the domain owner's approval to share report data with that recipient. RFC 9990 section 4.

Verify authoritative DNS, recursive DNS and actual mail

These are reader-run checks, not results observed for your domain. Replace all variables with the actual owners and a nameserver obtained from the relevant delegation. The selector placeholder must come from your sending service.

ZONE='example.com'
AUTH_NS='replace-with-authoritative-nameserver'
SPF_OWNER='example.com'
DKIM_OWNER='replace-with-selector._domainkey.example.com'
DMARC_OWNER='_dmarc.example.com'

dig NS "$ZONE"
dig @"$AUTH_NS" "$SPF_OWNER" TXT +norecurse
dig @"$AUTH_NS" "$DKIM_OWNER" CNAME +norecurse
dig @"$AUTH_NS" "$DKIM_OWNER" TXT +norecurse
dig @"$AUTH_NS" "$DMARC_OWNER" TXT +norecurse
dig "$SPF_OWNER" TXT
dig "$DKIM_OWNER" TXT
dig "$DMARC_OWNER" TXT

Repeat authoritative checks against each delegated server. Capture timestamps, status, authority flags, TTL and the entire answer set. For delegated DKIM, the source authoritative server can return only the CNAME; use recursive resolution or query the target's authority to verify its public key. An empty CNAME answer is normal for a direct TXT key. A timeout or SERVFAIL is not proof that a record is absent.

Accept DNS publication only when the expected owners and values agree, exactly one SPF policy is selected, required DKIM targets resolve, and the intended DMARC policy is discoverable. Compare authoritative results with recursive results. TTLs govern cache expiry, including previously cached absence; repeatedly saving a correct record does not accelerate old caches. DigitalOcean permits TTLs no lower than 30 seconds. DigitalOcean TTL limit

Then send a non-sensitive test through each actual application route you intend to use, to a mailbox you control. Inspect the receiving system's raw headers and its trusted Authentication-Results, not an untrusted header inserted by the sender. Authentication-results trust boundary

Establish which results were generated inside the receiving service's known processing boundary and how that service removes, ignores or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving-mail administrator to confirm the boundary. A familiar authserv-id string or header position alone is not proof. Ignore attacker-supplied or otherwise untrusted fields; obtain receiver-controlled diagnostic evidence when provenance is uncertain. Operational receiving-result trust.

For a branded-DKIM commissioning task, require the intended signature to both pass and align with the unchanged approved branded From, plus trusted receiver dmarc=pass for that From; the DMARC rule allowing either aligned mechanism is not a substitute. A DMARC pass through SPF alone does not prove that the DKIM work succeeded. Treat SPF fail, softfail or none as separate findings from an SPF pass that is merely unaligned. Investigate unexpected authorization, missing-policy and evaluation errors even when DKIM supplies DMARC. A green sender dashboard does not replace this message check. Authentication does not guarantee inbox placement.

For SPF temperror, investigate temporary DNS resolution/availability and retest after recovery. For permerror, examine duplicate policies, syntax and the nested term budget. Neither is cured by an unrelated DKIM pass. Keep the exact envelope identity and connecting source with the diagnosis. SPF result definitions.

Use the DKIM selector guide to pair the actual signature's s= and d= when locating its key; do not assume the DNS host supplies a selector.

Troubleshooting and controlled recovery

If a change causes an incident, pause further edits. Compare the baseline with the current zone and restore only the affected records after checking for intervening legitimate changes. Coordinate signer rollback with the sending-service owner; restoring DNS while the sender still uses a different key may prolong failure. Re-run authoritative, recursive and message checks after recovery.

Documentation review and testing boundary

No DigitalOcean account was accessed, zone exported or changed, nameserver moved, DNSSEC setting altered, customer DNS tested or message sent. The commands and acceptance criteria above are checks for the authorized operator to execute.