How to set up DMARC/DKIM/SPF for DigitalOcean
Published 4 Aug 2026
Updated 4 Aug 2026
15 min read
Summarize with
DigitalOcean stores the DNS records, while the system that sends the email supplies the SPF mechanisms, DKIM public key, DKIM selector, and custom Return-Path. DigitalOcean does not provide outbound email, and SMTP ports 25, 465, and 587 are blocked on Droplets by default. For most DigitalOcean applications, the app sends through a separate mail service over HTTPS, and that service's authentication values belong in the DigitalOcean DNS zone.
What DigitalOcean controls
A correct setup has two separate control points: DNS in DigitalOcean and message signing in the sending system. Publishing records alone does not make an application sign mail.
- DigitalOcean DNS: Publishes TXT and CNAME records for the domain.
- Sending system: Chooses the Return-Path, signs with the DKIM private key, and sends the message.
- Receiving system: Checks SPF and DKIM, then applies the DMARC policy.
- DMARC reporting: Shows which sources pass the domain match and which need work.
The control-panel path and field names below follow the DigitalOcean DNS guide. Use the values issued by the sending system instead of copying placeholder values.
Add your domain
Add the apex domain to DigitalOcean only when DigitalOcean is the authoritative DNS host. If the domain's NS lookup points elsewhere, publish every authentication record at that active DNS host. A record saved in an inactive DigitalOcean zone has no effect.
- Open networking: Sign in to DigitalOcean, select Networking, then open Domains.
- Add the apex: Enter example.com without a protocol, path, or mail subdomain, select the project, and add the domain.
- Copy the zone: Recreate existing A, AAAA, MX, CNAME, TXT, and CAA records before changing delegation.
- Delegate DNS: At the registrar, use ns1.digitalocean.com, ns2.digitalocean.com, and ns3.digitalocean.com.
- Confirm authority: Check the public NS and SOA responses before adding mail records.
Do not mix DigitalOcean nameservers with another DNS provider's nameservers. Split authority can return different records to different receivers. Keep the old zone active until the new delegation resolves consistently.
DigitalOcean Domains page with the add-domain form open
DigitalOcean automatically creates its NS records after the domain is added. That does not prove public delegation. The registrar must point the domain at the same three nameservers, and cached responses must expire.
The SOA answer confirms which zone is live. Run these checks against the apex domain and continue only when DigitalOcean appears in both answers.
Check the authoritative DNS zoneBASH
dig NS example.com +short dig SOA example.com +short
|
|
|
|
|---|---|---|---|
SPF | @ | Sender | Authorize IPs |
DKIM | selector | Signer | Publish key |
DMARC | _dmarc | Domain owner | Set policy |
Return-Path | bounce | Sender | Match SPF |
Authentication records to collect before editing DNS
Set up SPF
SPF authenticates the envelope sender, also called the Return-Path or MAIL FROM domain. Publish one SPF record at that exact domain. For an application that relays mail through a separate sender, use the sender's supplied include or custom Return-Path record. Do not authorize the Droplet IP when the Droplet never makes the SMTP connection.
- Find MAIL FROM: Read the sending system's custom Return-Path instructions or inspect a delivered test message.
- Choose the host: Use @ for the apex or the supplied label, such as bounce, for a subdomain.
- Merge senders: Keep one SPF TXT record per hostname and add every authorized mechanism to it.
- Count lookups: Keep SPF within the ten DNS-query limit; nested includes count.
- End deliberately: Use the sender's documented qualifier during setup and move to -all after the full source inventory is correct.
A direct Droplet sender with approved SMTP access, a static IP, and a custom bounce subdomain can use an IP mechanism. Replace the documentation address below with the real public sending IP. Most new Droplets cannot use this path because DigitalOcean blocks SMTP ports by default.
SPF record for an approved direct senderDNS
Host: bounce Type: TXT Value: v=spf1 ip4:203.0.113.10 -all
A custom Return-Path under example.com gives SPF a matching organizational domain under relaxed DMARC evaluation. DigitalOcean supports the needed TXT or CNAME records, but the sending system must actually use that Return-Path.
In DigitalOcean, open Networking, Domains, and the domain. Select Create a record, choose TXT, put the short host label in Hostname, paste the full SPF string in TXT Value, set a short TTL while testing, and create the record.
Adding an SPF TXT record in DigitalOcean DNS
Wait at least the record TTL, then query the full Return-Path hostname. If the record is on bounce.example.com, checking only example.com can report the wrong result.
The checker below catches duplicate SPF records, invalid mechanisms, lookup overflow, and syntax faults. Enter the hostname where the SPF record is published.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
SPF can fail without failing DMARC
Some sending systems cannot use a Return-Path under the visible From domain. In that case, do not invent an SPF record for the visible From domain. Expect SPF domain-match errors and make DKIM pass with a signing domain under the visible From domain. DMARC passes when either SPF or DKIM passes and its authenticated domain matches. DigitalOcean can support a custom Return-Path record, but the external sender must support using it.
Set up DKIM
DKIM requires the sending system to sign each message with a private key. DigitalOcean only publishes the matching public key. Generate or enable DKIM where mail is sent, copy the exact selector and DNS value, then add the requested TXT or CNAME record in DigitalOcean.
- Enable signing: Turn on DKIM in the real sending system before editing DNS.
- Use a strong key: Select 2048-bit RSA when supported and keep the private key off DNS.
- Copy the selector: For selector do2026, the DigitalOcean host is do2026._domainkey.
- Publish one type: Create the supplied TXT or CNAME record, never both at the same selector.
- Confirm the signature: Send a new message and confirm the header.d domain matches the visible From domain under DMARC rules.
TXT public key
The sending system gives a value beginning with v=DKIM1 and a public-key parameter. DigitalOcean stores it as TXT.
- Host: Use selector._domainkey without the apex suffix.
- Value: Paste the complete public key without line breaks added by a document editor.
CNAME delegation
The sending system gives a target hostname and manages the public key behind it. DigitalOcean stores the alias as CNAME.
- Host: Use the exact selector label supplied by the sender.
- Target: Paste the full destination hostname and keep any required trailing period.
In DigitalOcean, select Create a record and choose the record type supplied by the sender. DigitalOcean appends the zone name to the Hostname field, so enter only the selector label unless the interface preview proves otherwise.
A long 2048-bit TXT key must remain complete. Do not remove characters, paste the private key, or publish quotation marks unless they are part of the sender's exact DNS instructions.
Adding a DKIM public key in DigitalOcean DNS
After the record resolves, tell the sending system to verify the domain if it requires a verification step. A green DNS status does not prove that outgoing messages contain a DKIM-Signature header.
Query the full selector, then send a fresh test. The DNS result and message header must use the same selector and signing domain.
Verify the DKIM selectorBASH
dig TXT do2026._domainkey.example.com +short
Prefer DKIM as the durable DMARC path
A valid DKIM signature often survives forwarding when SPF does not. Use a signing domain under the visible From domain, rotate selectors without reusing old private keys, and retain the prior public key until delayed mail has cleared.
Set up DMARC
Start a new domain at p=none with aggregate reporting. Publish the exact record v=DMARC1; p=none; rua=mailto:dmarc@example.com at _dmarc.example.com, replacing only the report mailbox. If the domain already uses p=quarantine or p=reject, keep that enforcement level and fix sources without downgrading it.
Starting DMARC TXT recordDNS
Host: _dmarc Type: TXT Value: v=DMARC1; p=none; rua=mailto:dmarc@example.com
- Prepare reports: Create a working mailbox or DMARC report destination before publishing rua.
- Use one record: Remove duplicate _dmarc TXT records because receivers cannot choose between them.
- Create the TXT: In DigitalOcean, use Hostname _dmarc and paste the policy in TXT Value.
- Use a short TTL: Set 300 seconds during rollout, then raise it after the record is stable.
- Check syntax: Validate the public record before waiting for aggregate reports.
Use the DMARC record generator when adding tags such as subdomain policy or strict domain matching. Keep the first deployment minimal so troubleshooting stays clear.
Adding a p=none DMARC record in DigitalOcean DNS
DMARC evaluates the visible From domain. It passes when SPF passes for a matching MAIL FROM domain or DKIM passes for a matching signing domain. It does not require both paths to pass.
The DNS host has no effect on the authentication result. DigitalOcean can publish the policy, but the application and its sending system determine the message domains that receivers evaluate.
|
|
|
|
|
|---|---|---|---|---|
Pass | Yes | Fail | No | Pass |
Fail | No | Pass | Yes | Pass |
Pass | No | Pass | No | Fail |
Fail | No | Fail | No | Fail |
DMARC pass logic under relaxed domain matching
Run a public lookup after the TTL. The DMARC checker should return one parsed policy with no duplicate-record or syntax error.
A p=none policy collects data but does not request quarantine or rejection. That observation period is useful only when the reports are reviewed and every legitimate source is classified.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Do not downgrade an enforced domain
If DigitalOcean already publishes p=quarantine or p=reject, keep it. Fix legitimate failing sources with DKIM, a matching Return-Path, or removal of obsolete senders. Dropping to p=none weakens protection for the whole domain.
Verify and troubleshoot
Verify DNS and a real delivered message. DNS checks prove publication; message headers prove that the sending system used the expected Return-Path, DKIM selector, signing domain, and IP.
- Wait one TTL: Do not diagnose cached data before the previous record has expired.
- Query each host: Check the SPF hostname, DKIM selector, and _dmarc hostname separately.
- Send a fresh test: Use the production application path so the test exercises the real sender configuration.
- Read results: Inspect Authentication-Results for SPF, DKIM, and DMARC status plus their evaluated domains.
- Check reports: Confirm the source IP appears in aggregate reports with the expected disposition.
Query the public authentication recordsBASH
dig TXT bounce.example.com +short dig TXT do2026._domainkey.example.com +short dig TXT _dmarc.example.com +short
The email tester is the quickest end-to-end check. Send the requested message through the DigitalOcean-hosted application, then inspect the resulting authentication diagnosis.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
A healthy result normally shows SPF pass for the MAIL FROM domain, DKIM pass for the header.d domain, and DMARC pass for the visible From domain. SPF or DKIM can fail while DMARC still passes through the other matching method.
When SPF passes but DMARC fails, compare the MAIL FROM domain with the visible From domain. When DKIM passes but DMARC fails, compare header.d with the visible From domain. Under relaxed matching, the organizational domains must be the same.
Expected header evidence
- SPF result: Pass for the actual MAIL FROM domain.
- DKIM result: Pass for the selector and header.d used by the signer.
- DMARC result: Pass for the visible From domain through at least one method.
- Source IP: Match the real connecting server, not automatically the Droplet.
Common DigitalOcean faults
- Inactive zone: The public NS records point away from DigitalOcean.
- Doubled domain: The full domain was entered where DigitalOcean expected a short host label.
- Duplicate SPF: Two v=spf1 TXT records exist at one hostname.
- Missing signing: The DKIM public key exists, but the sender adds no signature.
For a permitted direct sender, also verify forward-confirmed reverse DNS. Name the Droplet with a valid mail hostname such as mail.example.com, publish an A record for that hostname to the Droplet IP, and use the same hostname in SMTP EHLO. DigitalOcean derives the PTR record from a valid fully qualified Droplet name.
DigitalOcean does not let the DNS page create an arbitrary PTR for a Droplet. Renaming the Droplet to a valid fully qualified hostname updates the PTR, while the operating-system hostname must be changed separately.
Renaming a DigitalOcean Droplet to set its PTR hostname
A DNS fix cannot open blocked SMTP ports
If a Droplet cannot connect on ports 25, 465, or 587, changing SPF, DKIM, DMARC, or PTR does not restore the connection. Use the application's approved relay path. Authentication work begins after the message can leave through that path.
Get alerted when it breaks
DNS checks are snapshots. A sender can rotate infrastructure, stop signing, change a Return-Path, exceed the SPF lookup limit, or introduce a new source after the initial setup. Continuous DMARC reporting is what catches those changes. Suped is our DMARC reporting and email authentication product, and it is the best overall fit for this workflow because it converts raw aggregate data into source-level issues and concrete fix steps.
- Detect changes: Real-time alerts flag authentication failures and policy changes before a weekly manual review.
- Identify sources: DMARC data is grouped into verified and unverified senders with the failing method exposed.
- Fix the cause: Automated issue detection gives steps for SPF, DKIM, policy, and domain-match failures.
- Watch reputation: Blocklist and blacklist monitoring connects domain and IP reputation with authentication health.
- Scale ownership: The multi-tenant dashboard keeps many domains and client organizations in one operational view.
Use ongoing DMARC monitoring to track the source IP, message count, SPF result, DKIM result, and DMARC disposition for DigitalOcean-hosted applications. A sudden new IP or a collapse in DKIM pass rate needs investigation before policy enforcement advances.
Manual DNS checking
- Coverage: Confirms the record visible at the moment of the lookup.
- Context: Does not show which real sources used the record.
- Response: Depends on someone remembering to run another check.
- Scale: Becomes difficult across many domains and sending teams.
Suped monitoring
- Coverage: Processes DMARC reports continuously and tracks policy health.
- Context: Connects each source with its SPF and DKIM result.
- Response: Sends alerts and provides targeted remediation steps.
- Scale: Supports multi-domain, MSP, and multi-tenant operations.
Suped also brings hosted SPF, SPF flattening, hosted DMARC, hosted MTA-STS, authentication diagnostics, and deliverability insights into the same workflow. That matters when a DigitalOcean application has multiple mail paths owned by different teams.
Alert on changes that need action
Prioritize a new unverified source, a sharp authentication drop, a modified DMARC policy, SPF lookup overflow, DKIM selector failure, and blacklist or blocklist entries affecting the sending IP. Avoid alerts for isolated forwarding failures when DKIM keeps DMARC passing.
Secure your domain with p=reject
Move to p=reject only after every legitimate source has a reliable DMARC pass through SPF or DKIM. The safest sequence is p=none for discovery, p=quarantine for controlled enforcement, then p=reject when legitimate failures are resolved. Domains already at quarantine or reject should stay there while individual sources are repaired.
- Inventory sources: Classify every recurring IP and sending service in aggregate reports.
- Fix legitimate mail: Make at least one authentication method pass with a matching domain for each source.
- Remove old senders: Delete obsolete SPF mechanisms and revoke unused DKIM keys.
- Stage enforcement: Apply quarantine to a controlled percentage, review a full business cycle, then increase coverage.
- Apply rejection: Publish p=reject at full coverage and continue monitoring after the change.
DMARC enforcement stagesDNS
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@example.com v=DMARC1; p=reject; rua=mailto:dmarc@example.com
Publish only one of these values at a time. Keep the same rua destination so the data stays continuous across policy changes. A staged percentage reduces the blast radius, but receivers do not all apply pct identically, so monitoring still needs to detect legitimate failures.
|
|
|
|---|---|---|
p=none | Discovery | Sources known |
quarantine | Test policy | Valid mail passes |
p=reject | Block abuse | Monitoring active |
Go or no-go checks for each policy
Suped's hosted DMARC is the practical way to stage this change for most teams. It keeps policy controls, reporting, source health, automated issue detection, and real-time alerts together, so a failing source is visible before the next enforcement step.
p=reject readiness gate
Move to rejection when all approved high-volume sources pass DMARC, low-volume business systems have been exercised, forwarding is covered by DKIM where possible, report volume has stayed stable for a full operating cycle, and someone owns alerts after the change.
After publishing p=reject, test each DigitalOcean-hosted application again. Keep old DKIM selectors available during key rotation, watch for newly deployed app components, and investigate any legitimate source that starts receiving a reject disposition.
- Keep reporting: Retain rua at p=reject because new sources and configuration drift still happen.
- Protect subdomains: Set an explicit sp policy when subdomains need different treatment.
- Rotate keys: Create a new selector, verify signatures, then retire the prior private key.
- Review changes: Treat every new mail integration as an authentication change before deployment.
DigitalOcean setup FAQ
These are the points that most often cause confusion when DigitalOcean hosts the application or DNS zone but another system handles outbound email.
