Should I add a Vuture SPF include to my root domain?

Not merely because you use Vuture. The current premium CRP workflow supplies a CNAME-based route. Apply a separate SPF change only when Vuture confirms the owner and requirement for your actual sending path; preserve existing authorized senders.

Can I use an existing website or mailbox subdomain for the CRP?

Vuture requires a subdomain unused for another purpose. A CNAME also cannot share its exact owner with website, mail or zone-delegation data. Choose and approve a supported unused name rather than overwriting existing service records.

Is DKIM available without Custom Return-Path?

The current Vuture DKIM procedure makes a CRP domain a prerequisite and identifies the feature as premium. That is a Vuture product requirement, not a universal rule for DKIM or DMARC.

Must both `vx` and `vx1` appear in every message?

No such requirement is documented. Publish the full current packet, then inspect the selector actually used by the intended passing, aligned signature. Do not remove the other issued record simply because one sample uses only one selector.

Does a verified domain guarantee delivery?

No. DNS publication and provider completion are configuration evidence. A trusted delivered-message test establishes authentication and alignment for that sample; recipient policy, reputation and other factors still affect delivery.

Vuture SPF, DKIM & DMARC Setup: Step-by-Step Guide

To authenticate Vuture marketing email with your domain, arrange its premium Custom Return-Path (CRP) and DKIM features with your account manager. Vuture supplies the DNS packet, checks your published records, configures the instance during an agreed pause in sending, and enables and tests DKIM. You then configure the intended From addresses and verify a newly delivered campaign message. Publishing DNS alone does not complete setup.

This guide covers Vuture’s native email-marketing service, not another Marigold product, employee mailbox service or external SMTP relay. Vuture CRP instructions

1. Confirm prerequisites and request the packet
2. Understand Vuture’s current DNS records
3. Publish the aliases without breaking existing DNS
4. Preserve DMARC and authorize reporting
5. Complete Vuture’s configuration and DKIM activation
6. Configure approved domains and container From addresses
7. Test the actual campaign identity
Troubleshooting
Changes, rollback and retirement
Frequently asked questions
Sources and verification limits

1. Confirm prerequisites and request the packet

Vuture identifies both CRP and DKIM as premium features and directs customers to their account manager. A Custom Return-Path domain is a prerequisite for Vuture’s DKIM implementation. Vuture supports DKIM on multiple CRPs; that does not make an existing CRP’s records reusable for a new domain or instance. Vuture DKIM procedure

Before changing DNS, agree on:

The Vuture instance and native campaigns being authenticated, and entitlement to CRP and DKIM. Obtain any commercial terms separately; no particular package name or price is assumed here.
An owned subdomain that is unused for any other purpose. Vuture suggests a name such as bouncevx.example.com, but the choice must fit your domain and routing plan.
The intended visible From addresses, affected containers, reply-handling arrangements and currently scheduled campaigns.
The person responsible for authoritative DNS, existing delegations and the domain’s DMARC policy.
A small no-sending maintenance window with Vuture, plus an approved rollback plan.

Send your chosen subdomain to the project manager or account manager. Ask for the complete packet for your instance: each record’s type, fully qualified owner, exact target and any additional instructions, together with the expected signing and envelope domains. Vuture’s documented sequence is to issue the required DNS records after you provide the subdomain. Do not construct account values from the examples below. CRP issuance and scheduling

Keep a dated export of the relevant DNS and current container From settings. Check that the selected subdomain is not already a website, mailbox route, delegated DNS zone or another vendor’s authentication domain. An occupied name is a reason to coordinate a different supported name, not to delete what is there.

2. Understand Vuture’s current DNS records

The current CRP procedure shows three CNAME formats: one for the CRP’s provider-managed SPF/MX route and two for DKIM. These are structural placeholders, not customer records. Use the exact issued packet if your account’s instructions differ, and resolve discrepancies with Vuture before proceeding.

Purpose: Custom Return-Path route
Type: CNAME
Owner: <CRP-FQDN>
Target: <INSTANCE-ID>.vx-email.com

Purpose: DKIM
Type: CNAME
Owner: vx._domainkey.<CRP-FQDN>
Target: <CRP-FQDN>.vuturedkim.com

Purpose: DKIM
Type: CNAME
Owner: vx1._domainkey.<CRP-FQDN>
Target: <CRP-FQDN>.1.vuturedkim.com

Vuture labels the first format “SPF record and MX records” but specifies a CNAME, not separate TXT and MX records at that owner. The alias points into Vuture’s managed route. Do not add TXT or MX beside it, replace your organization’s main MX records, or substitute a historical regional SPF include for this current CRP packet. Current record formats

Vuture generates the DKIM key pair and states that it uses 2048-bit DKIM. Publish the issued public aliases, not a private key or a key generated by an unrelated tool. DKIM signs selected message content; it does not encrypt the email. Two published selectors support the provider’s configuration, but do not prove that every message carries two signatures. Vuture key generation and activation · DKIM standard

Does Vuture need an apex SPF change?

Not as a default step in this CRP workflow. SPF evaluates the actual SMTP MAIL FROM domain, or the HELO identity in the relevant cases, rather than automatically checking the visible From domain. Determine which identity the configured Vuture route actually uses before editing a root-domain policy.

If Vuture separately instructs you to amend a TXT SPF policy, confirm the exact owner and preserve one v=spf1 record there, including all legitimate senders and the owner-approved qualifiers. Audit the entire evaluation against the limit of 10 DNS-dependent terms, including nested include, a, mx, exists, ptr and redirect processing. It is not simply a limit of ten includes. An all mechanism makes redirect unused, so mechanically adding ~all or -all can remove existing authorization supplied through a redirect. SPF results influence receiver decisions but do not guarantee delivery or rejection. RFC 7208

3. Publish the aliases without breaking existing DNS

Map each full owner to the correct zone

Work at the authoritative DNS service, which may differ from the registrar. In a parent zone example.com, the illustrative CRP bouncevx.example.com would usually be entered as bouncevx; its DKIM owners would usually be vx._domainkey.bouncevx and vx1._domainkey.bouncevx. Some DNS interfaces accept full names instead. Inspect the saved expanded owner so it does not become bouncevx.example.com.example.com.

If _domainkey.bouncevx.example.com is separately delegated, its selectors belong with that delegated DNS operator, commonly as relative owners vx and vx1. Do not remove the NS delegation or publish unreachable duplicates in the parent. If bouncevx.example.com itself is a delegated zone apex, it already has required zone data and cannot simply become Vuture’s CNAME. Stop and coordinate a supported name or DNS design without disturbing the delegation.

At each exact CNAME owner, check for existing TXT, A, AAAA, MX, NS or another CNAME. Do not overwrite an occupied owner or add conflicting data. Keep unrelated selectors and other mail services intact. Confirm that the issued CRP destination is the provider-managed bounce route your organization approved, not a replacement for existing inbound mail or a new forwarding destination. DNS aliases and ownership

Keep literal CNAME answers available

Use DNS-only records, not an HTTP proxy. Where the DNS host offers a per-record Flatten control, turn Flatten off for each issued alias. Ensure applicable zone-wide settings do not flatten those aliases either. Coordinate a shared-setting change with the DNS owner; do not disable unrelated website features merely to follow this guide.

Cloudflare’s documentation distinguishes per-record flattening, a paid-zone “all CNAME records” setting, automatic apex flattening and same-zone target behavior. Same-zone targets can be flattened regardless of that setting. If mandatory apex or same-zone behavior prevents a literal issued CNAME answer, stop and agree on a supported configuration with Vuture and the DNS operator. Do not invent an unavailable switch, replace the alias with an IP address or remove a shared delegation. Cloudflare flattening behavior · DNS-only versus proxy

Check publication before requesting activation

Replace every uppercase placeholder below with your issued full owner or actual DNS server. These are read-only examples, not results from your domain. Repeat the CNAME checks for the CRP and both DKIM owners, using the correct authoritative server for each delegated zone.

dig @AUTHORITATIVE_NS CNAME ISSUED_FULL_OWNER +noall +answer
dig @RECURSIVE_RESOLVER CNAME ISSUED_FULL_OWNER +noall +answer
dig @RECURSIVE_RESOLVER TXT ISSUED_DKIM_FULL_OWNER +noall +answer
dig @RECURSIVE_RESOLVER TXT ACTUAL_MAIL_FROM_DOMAIN +noall +answer

Compare each complete owner and CNAME target with the packet, not just whether an answer exists. Follow the intended alias chain: DKIM must resolve to the provider’s usable public key, and the CRP must resolve through the provider-managed route as Vuture confirms. A loop, wrong tenant target, missing terminal record, DNS error or unexpected IP-only answer needs correction. A terminal key answer alone is not proof that your original CNAME owner is correctly published.

When authoritative and recursive answers disagree, inspect TTL and negative caching before repeatedly editing the record. A shorter new TTL does not erase an older cached answer. Keep the results and timestamps for Vuture’s verification; do not promise a fixed propagation time.

4. Preserve DMARC and authorize reporting

Check the policy applicable to the intended visible From domain, including a direct record and applicable inherited policy. Preserve its protection, adkim and aspf alignment modes, and approved report destinations. A new CRP does not justify replacing an existing p=reject or p=quarantine policy with monitoring. Do not create duplicate DMARC records or a subdomain override that silently weakens inherited protection. DMARC policy discovery and alignment

Only if there is no direct or applicable inherited DMARC policy, the domain owner approves a first policy, and someone will monitor the rollout, a minimal initial record can be:

Type: TXT
Full owner: _dmarc.<VISIBLE-FROM-DOMAIN>
Value: v=DMARC1; p=none

For a visible From domain bouncevx.example.com, the full owner is _dmarc.bouncevx.example.com, usually entered as _dmarc.bouncevx in the example.com zone. This is a different owner from the CRP CNAME. For another From domain, use that domain’s actual DMARC owner and authoritative zone. The example contains no reporting address and does not itself request aggregate reports. Arrange approved reporting or another monitoring process before relying on it; it does not request quarantine or rejection.

If you add rua, obtain the domain owner’s approval for the recipient and data sharing. When the report destination’s Organizational Domain differs from the Organizational Domain where the policy was found, the report-generating receiver must perform the external-destination DNS authorization check. A destination within the same Organizational Domain is excepted, even when its hostname differs. Use the report service’s prescribed authorization records; DNS authorization does not replace your privacy decision. Aggregate reports can expose sending IPs, domain relationships and traffic patterns, so limit access and retention. Do not copy another organization’s report address or enable message-level failure reports casually. RFC 9990 section 4

5. Complete Vuture’s configuration and DKIM activation

After publishing the packet, notify the account manager or project manager. Vuture checks that the DNS is configured correctly. Then use the agreed window with no sending from the instance while Vuture configures and tests the Custom Return-Path. Coordinate queued and scheduled campaigns with the provider rather than assuming a DNS change pauses them automatically. CRP completion sequence

The DKIM procedure has its own completion steps: Vuture verifies the published public key, configures DKIM, tests it and informs you that setup is complete. Wait for that confirmation for the intended domain and instance. There is no documented customer signing toggle to invent, and a successful public lookup cannot replace this provider-side work. DKIM verification and completion

Do not resume the affected campaign schedule until the agreed configuration, From-address review and acceptance checks are complete. If the account packet or provider’s expected identities differ from your approved plan, resolve that difference before sending.

6. Configure approved domains and container From addresses

Vuture’s current procedure says only Vuture Administrators can configure approved domains and directs you to your Account Manager. Coordinate that work through Admin > System > Emails > Authorised From Domains rather than assuming every campaign user has access.

Add the approved domains, separating multiple entries with semicolons. Hide Unauthorised From Domains hides unapproved sending addresses from the Send dropdown. This control helps prevent an unintended From domain; it does not publish DNS or activate DKIM.

Then review the actual sending addresses:

Open Admin > Containers and users.
Select the root container and open Container Settings.
Find Send From Emails and configure the approved addresses and display names.
Review the individual containers used by your campaigns and select the intended approved From address when sending.

Vuture’s CRP instructions call for existing container From addresses to use the configured CRP domain. Do not assume that authenticating a bounce subdomain automatically authorizes every address at your parent domain. Agree on the intended identity with Vuture and verify the delivered result.

Copy to sub-containers makes the entries available more widely. Replace in sub-containers removes and replaces entries already configured there. Avoid blanket replacement: inventory existing senders and make deliberate container-level changes so another team’s campaign identity is not lost. Approved domains and container procedure

7. Test the actual campaign identity

After Vuture confirms completion, send a small authorized test through the native campaign and container you will use, to a controlled valid recipient. Repeat for materially different From domains, CRPs or sending paths. Use the original received message, not an edited forward or an employee-mailbox test.

Establish the receiver’s trust boundary

Use receiver-controlled authentication diagnostics, or have the receiving administrator establish which results were produced inside that service’s known processing boundary and how it strips or distinguishes externally supplied Authentication-Results. Ignore attacker-supplied or otherwise untrusted fields. A familiar authserv-id string, a header’s position, or a copied dkim=pass line is not sufficient proof. If the boundary cannot be established, obtain the receiving administrator’s diagnostics rather than declaring success. RFC 8601 section 7.1

Require the intended branded result

Record the actual visible From domain, SMTP MAIL FROM identity and each relevant DKIM signature’s paired d= and s= values. Read the receiver’s SPF, DKIM and DMARC findings against those same identities.

Intended DKIM: the Vuture-configured signature must be present, pass verification and align with the intended visible From under the applicable adkim mode. An unrelated provider signature passing is not enough.
DMARC: require trusted dmarc=pass for that intended From domain. DMARC can pass through aligned SPF or aligned DKIM, but a pass through SPF alone does not prove this DKIM setup works.
SPF independently: inspect the result for the actual MAIL FROM domain. Investigate none, fail, softfail, temperror and permerror even if aligned DKIM supplies a DMARC pass. A passing but unaligned SPF identity is a different problem from failed SPF authorization.
Sender identity: confirm the message did not silently change to a provider-owned From address. A rewritten provider identity passing DMARC is not successful authentication of your intended brand.

Under relaxed alignment, the authenticated domain and From domain may share an Organizational Domain. Strict alignment requires an exact domain match: bouncevx.example.com and example.com are not identical. Read the actual adkim and aspf policy and delivered identities; a custom return-path does not automatically guarantee strict alignment. DMARC alignment

For DNS diagnosis, query the selector with the d= from the same signature, not automatically with the visible From domain. EmailAuth’s guide to finding the DKIM selector from a received message explains that pairing and how to interpret multiple signatures. Preserve the observed selector during a rotation investigation rather than assuming both published selectors must appear.

Keep a redacted acceptance record with the instance, container, From domain, provider completion time, DNS observations and trusted receiver results. Do not upload private message bodies or recipient lists to a public checker. Review approved aggregate reports as they arrive to identify other sources; one passing sample does not validate every campaign or guarantee inbox placement.

Troubleshooting

Vuture cannot verify a record

Compare the issued full owner and target with the authoritative answer. Check duplicate suffixes, the wrong DNS provider, a child-zone or _domainkey delegation, conflicting records, proxying and flattening. Then compare recursive answers for caching. Do not replace a CNAME with a copied terminal TXT key to make a checker green.

DNS is correct but the intended DKIM signature is absent

Confirm that Vuture completed DKIM configuration and testing for this CRP and instance. Check the actual container and selected From address. Publishing a key, adding an approved domain and choosing a sender are separate from enabling the signing service.

DKIM fails or passes without alignment

For a failed signature, preserve the actual d=/s= pair and receiver error. Investigate a wrong key target, incomplete rotation, DNS errors or message changes on a downstream route. For a passing unaligned signature, review the intended signing domain and From selection with Vuture. Do not lower DMARC protection or broadly bypass a spam filter to hide either failure.

DMARC passes, but SPF has an error

Inspect the envelope identity and the CRP route rather than adding Vuture to the root SPF blindly. permerror can indicate multiple policies, malformed syntax or an exceeded lookup budget; temperror indicates a temporary evaluation problem. fail or softfail requires checking authorization for the actual sending route. Preserve other senders while the DNS owner and Vuture resolve the specific cause. SPF evaluation

The desired sender disappeared or another container changed

Review the Authorised From Domains list and Hide Unauthorised From Domains setting. Check whether a bulk sub-container replacement removed an existing address. Restore only the approved entries from the saved configuration, with the responsible administrator, instead of allowing every domain.

Replies or out-of-office messages are not forwarded

Do not treat missing auto-replies as evidence of SPF or DKIM failure. Vuture’s current sunset notice says its legacy auto-forwarding functionality is permanently discontinued. Do not plan a new CRP around that old forwarding mechanism or re-enable it as a workaround. Confirm current human-reply handling separately with Vuture and the mailbox owner. Vuture forwarding sunset

Changes, rollback and retirement

For a failed cutover, pause affected campaigns and coordinate rollback with Vuture. Restore only the owner-approved prior configuration after confirming the provider’s active CRP and signer. Reverting DNS while Vuture still signs with the new key can worsen the failure; deleting new records immediately can affect queued or delayed messages.

For rotation, retain old public selectors for the provider-agreed transition period and test the newly emitted selector. Before retiring a CRP, inventory all instances, containers, campaigns and delegations that depend on it. Remove only confirmed unused records after provider deactivation and owner approval, without weakening DMARC or removing another sender’s DNS. Keep the configuration and change history available for later message investigations.

Sources and verification limits

The older 2018 CRP PDF was treated as historical context, not authority for current forwarding or DNS configuration. Protocol and DNS-host references govern the safeguards where a vendor’s introductory explanation is simplified or inaccurate.

This is a documented setup procedure, not confirmation that a particular account is enabled or a domain is correctly configured. Complete the authorized provider, DNS and real-message checks for your own instance before relying on the setup.

Vuture SPF, DKIM and DMARC setup, step by step

On this page