Vultr SPF, DKIM and DMARC setup, step by step

No customer account, DNS change or sending test was performed.

Use Vultr DNS to publish authentication records issued by your email sender. Do not look for a universal “Vultr SPF include” or a Vultr-generated DKIM key just because your DNS or virtual server is hosted there. This guide covers an existing authoritative Vultr DNS zone, not installing a mail server or moving your domain's nameservers.

SPF authorizes sending infrastructure. DKIM lets a receiver verify a message signature. DMARC checks whether a passing identity matches the domain people see in From. Publishing their records is one stage of setup; the sending service must also use the intended identity and sign actual messages.

Before changing anything

Confirm that you control the domain and have permission to edit its DNS in the correct Vultr account. Obtain your email provider's current authentication instructions for the actual account, sending domain, product and region. Save the complete record types, names, values and any activation steps. A screenshot from someone else's account is not your record packet.

Identify the authoritative zone, not merely the company that registered the domain. Vultr's domain provisioning documentation identifies its nameservers as ns1.vultr.com and ns2.vultr.com. An existing zone in the console is not proof that the public domain delegates to it. Check the live authority before editing. A separately delegated child may have different DNS ownership from its parent.

If another provider is authoritative, make the changes there or plan a separate, approved migration. Do not change nameservers, MX, DNSSEC, forwarding or mail routing merely to follow this guide. Those changes can affect the website and inbound email as well as authentication.

Record the existing values and TTLs at every affected owner. Keep a change log with the approved before-and-after values, owner, timestamp and person responsible. Preserve existing selectors, verification tokens, legitimate SPF senders and direct or inherited DMARC policy.

Where to add records in the Vultr Console

Vultr's current record-management instructions, describe this Console flow:

1. Open Products, expand Network, and choose DNS.
2. Select the existing domain zone.
3. Choose the issued record Type. Enter the owner in Name and the supplied value in Data.
4. Keep the appropriate TTL in seconds or use the provider-approved value. Priority is not an SPF/DKIM TXT setting.
5. For a new, nonconflicting record, use Add Record under Actions.

Do not use Add Record to create a second SPF policy at an owner that already has one. The cited Console instructions show Add and Delete, but do not document an existing-record edit control. Before changing existing SPF, obtain the confirmed account or Vultr-support workflow for updating that record. Stop if you cannot establish that you are modifying the intended record rather than adding another. This guide does not recommend deleting a working policy before preparing its replacement.

After saving, inspect the resulting full name and authoritative DNS answer. A successful console save does not establish correct publication or successful email authentication.

Map the issued name to the right zone

Think in full DNS names first. For example, the full DKIM owner could be selector._domainkey.example.com. The selector in this example is illustrative: replace it with the sender's issued selector, not an arbitrary word.

When the editor uses names relative to its selected zone, the mapping is:

For a zone-root policy, use the editor's apex representation and confirm the resulting owner is the zone name. Do not assume every DNS interface treats blank, @ and a full name interchangeably. The decisive check is the complete saved owner and its DNS answer, not what looks plausible in a text box. Avoid duplicated suffixes such as example.com.example.com.

If _domainkey or a child domain is delegated, coordinate with its administrator. Do not remove existing NS records to force a new record into the parent zone. A record below a delegation must be published through the authority that actually serves it.

Publish SPF without breaking existing senders

First determine the real SMTP MAIL FROM domain used by your sender, normally reflected in the delivered Return-Path. SPF evaluates that identity, or HELO in the relevant cases, not automatically the visible From address. Adding a service to apex SPF cannot fix an unrelated envelope domain.

Use the sender's documented authorization for that route. There is no universal value to infer from DNS hosting. If you operate your own mail server, authorization must match its actual approved outbound infrastructure, not every IP associated with your Vultr account.

At the evaluated owner, publish one TXT record starting v=spf1. If a policy exists, incorporate only the required legitimate authorization while preserving the other valid senders and intentional qualifiers. Do not add a second policy or replace the existing one with a tutorial example. Other, unrelated TXT records can coexist at that owner.

An SPF policy is not merely a list of includes. Evaluate its complete path against the ten DNS-dependent-term limit, including nested mechanisms and redirects. ip4 and ip6 do not consume that particular budget; other SPF limits still apply. An all mechanism causes redirect to be ignored. Do not add a or mx simply because they appear in a sample: that may authorize infrastructure which should not send mail.

Keep the established -all, ~all or other intentional behavior unless a separate policy change is approved. Qualifiers affect SPF results; they do not guarantee that a recipient will accept or reject a message. See RFC 7208.

Publish the complete DKIM record packet

The sending service or your authorized mail-server administrator supplies the selector, signing domain and public DNS records. Vultr DNS stores those records; adding them does not turn on signing inside a separate mail application.

For TXT DKIM, preserve the complete tagged public value, including the entire public key. Do not publish a private key, a clipped screenshot value, an empty p= value or a different tenant's key. A long TXT record may be represented by multiple quoted character strings within one DNS record; these are not separate competing DKIM records. Verify that the concatenated result matches the supplied value.

For CNAME DKIM, preserve the issued type, full owner and destination. Do not convert the alias into an A record or insert the destination's current public key as a substitute. At a CNAME owner, do not add conflicting TXT, A, AAAA, MX or another CNAME. If there is already a record or delegation, resolve ownership and dependencies before replacing anything. RFC 2181 section 10.1 explains the CNAME constraint.

If any DNS layer offers HTTP proxying or CNAME flattening, ensure the required alias remains a literal CNAME answer when the sender requires one. Disable an applicable per-record flattening option if available, and examine zone-wide, apex and same-zone behavior that could hide the alias. This is a conditional compatibility check, not a claim that Vultr exposes a particular proxy or flattening switch. Do not make an unrequested global setting change. If mandatory behavior cannot preserve the issued answer, stop and coordinate a supported configuration.

Return to the sending product after DNS publication. Complete its own domain verification and signing activation steps. A generic DNS-host article cannot invent those account-specific controls. Preserve older selectors while they are still needed for in-flight messages or other approved senders.

Publish DMARC only with the right policy decision

Read the existing direct policy and any applicable inherited policy first. Preserve their protection and authorized report destinations. Do not replace a working enforcement policy with monitoring, create duplicate DMARC records or copy a reporting mailbox from a public example.

Only if no applicable policy exists and the domain owner approves a monitoring plan, a minimal first-policy example is:

Full owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none

Replace example.com with the actual policy domain. In an example.com zone the relative owner is _dmarc; in a parent zone for news.example.com, use _dmarc.news. This minimal example does not request reports. Add an authorized rua destination only as part of an agreed reporting and privacy plan. Monitoring is not an enforcement outcome.

For a report destination in a different Organizational Domain, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain is excepted. A different hostname alone does not determine this distinction. Follow RFC 9990 section 4; DNS authorization does not replace the owner's permission to share report data. Current policy and alignment behavior are defined in RFC 9989.

Verify publication, then verify a real message

Replace all example domains and selectors below before use. These are read-only query shapes, not fabricated successful results:

dig NS example.com
dig TXT example.com
dig CNAME selector._domainkey.example.com
dig TXT selector._domainkey.example.com
dig TXT _dmarc.example.com

Query the actual authoritative server as well as a public recursive resolver. For example, add @AUTHORITATIVE_SERVER using the server that really serves that zone. Match the full owner, type, target or concatenated TXT data against the approved packet. Check all issued selectors. Cached answers can remain until their TTL expires; a fixed waiting period is not proof that the change is correct. Distinguish an empty answer from NXDOMAIN, SERVFAIL or a timeout.

Next send a controlled test through the intended production application and route to a valid recipient you control. Inspect receiver-generated Authentication-Results inside that receiving service's known processing boundary. Use its documented handling of externally supplied result headers to establish trust. A familiar authserv-id, a high position in the header or a copied results field is not sufficient evidence; ignore attacker-supplied or otherwise untrusted fields. See RFC 8601 section 7.

For newly configured branded DKIM, require the intended provider signature to pass, its signing d= domain to align with the intended visible From under adkim, and the trusted receiver to report dmarc=pass. SPF-only DMARC success does not prove DKIM works. A rewritten provider-owned From address is not successful authentication of your brand.

SPF alignment compares the authenticated MAIL FROM domain with From under aspf. DKIM alignment compares its signing domain under adkim. Relaxed alignment allows the same Organizational Domain; strict alignment requires exact domains. Thus bounce.example.com and example.com can align under relaxed SPF but not strict SPF. Do not promise strict alignment simply because a sender offers a branded child envelope domain.

For more detail, read raw versus aligned DKIM results. A message's valid signature and its contribution to DMARC are separate questions.

Troubleshoot the failed layer

Do not change inbound MX records to troubleshoot outbound authentication unless a separately reviewed sender setup genuinely requires a routing change. Do not turn off DNSSEC to hide a validation failure.

Rollback and ongoing maintenance

If a change is wrong, use the saved before-state to plan restoration of only the affected record. Because the cited Console guide does not specify an existing-record edit control, obtain the confirmed account or Vultr-support restoration workflow before proceeding. Do not delete the entire zone, all TXT records or shared selectors. Retest authoritative DNS and an intended-route message after correction. Where a selector is shared or rotated, coordinate retirement with the sending administrator rather than guessing that an old record is unused.

Repeat checks when senders, outbound IPs, keys, DNS authorities or application routes change. Keep report evidence and controlled message samples without exposing private message content or credentials.