Ventraip SPF, DKIM and DMARC setup, step by step

For VentraIP Business or Dedicated Email Hosting, obtain the DKIM TXT record from VIPcontrol → My Services → Email Hosting → Manage → DKIM record. Publish the exact Hostname and Content (TXT) at your authoritative DNS provider. VentraIP says DKIM is already enabled for Dedicated Email Hosting; its documented SPF example is v=spf1 +a +mx +include:spf.email-hosting.net.au ~all. DKIM record instructions, signing status and Business Email SPF.

Use this guide for that mailbox product, whether VentraIP or another company hosts DNS. Do not use it for cPanel-hosted outbound mail, Google Workspace or a self-managed server. Those products can appear in the same provider account while using different signing controls and authorization records.

Identify the service before editing DNS

Open the email service in VIPcontrol and confirm its product and domain. VentraIP's management article places the domain under My Services → Email → Email Hosting → Manage and exposes account information through Service details. The dedicated DKIM article uses My Services → Email Hosting → Manage. Both refer to the email-hosting service, not the domain's web-hosting package. Service-management guide.

Have these prerequisites ready:

• An existing Business/Dedicated Email Hosting service and mailbox for the intended domain.
• Authorized VIPcontrol access to retrieve that service's DKIM data.
• Access to the current authoritative DNS provider, which may be external.
• The intended visible From address and an inventory of mail clients, webmail and applications that submit through this service.
• A saved copy of existing DNS records and a controlled external receiving mailbox for verification.

Use the service's actual connection settings for a mail client or application. Do not infer its SMTP hostname from an MX record or from spf.email-hosting.net.au. MX describes incoming delivery; an SPF include identifies an authorization policy. Neither is necessarily the submission server.

If the service is Google Workspace, use the Google Workspace authentication guide. If cPanel sends the message, its Email Deliverability workflow is separate. A cPanel DNS editor can still host records for Business Email, but that does not make cPanel the sender.

Understand the VentraIP SPF example

The current Business Email documentation gives this TXT value:

v=spf1 +a +mx +include:spf.email-hosting.net.au ~all

The source table places it at the mail domain's apex, shown as @ or the domain name. The correct entry in an actual DNS form depends on the editor. In the current VIPcontrol DNS editor, blank Hostname means the root domain. Business Email record table and current VIPcontrol field rules.

The mechanisms authorize different infrastructure:

• a can authorize addresses returned for the evaluated domain's address records. Consider both IPv4 and IPv6 as applicable.
• mx can authorize addresses of that domain's MX hosts.
• include:spf.email-hosting.net.au uses VentraIP's published policy to authorize the documented email service.
• The explicit + qualifiers mean pass and can be omitted without changing those mechanisms' meaning.
• ~all returns softfail for unmatched senders. It does not guarantee delivery, junk placement or rejection.

The a and mx terms deserve a decision, not a blind copy. A domain's website could be behind a CDN, and its MX records could point to an inbound gateway unrelated to outbound submission. Adding those mechanisms can authorize infrastructure beyond the mailbox service. Confirm which addresses would be authorized and whether that matches the domain owner's intended sending policy.

For an existing multi-sender domain, add the necessary VentraIP authorization to the one existing SPF policy while preserving other legitimate services. Do not replace the whole policy with the provider example, add a second v=spf1 TXT record or silently change its final qualifier. If you are unsure whether a or mx is needed, resolve the actual route with the service owner rather than treating a broader policy as a repair. SPF mechanisms and evaluation.

Check the actual envelope domain and lookup budget

SPF normally authenticates SMTP MAIL FROM, not the visible From address. A delivered message's trusted smtp.mailfrom result identifies the domain the receiver evaluated. A provider-owned envelope cannot be fixed by changing your root SPF, and a subdomain does not inherit its parent's SPF. For a null MAIL FROM, SPF can evaluate HELO instead.

VentraIP's reviewed procedure does not document a configurable custom Return-Path or guarantee the exact envelope identity of every mailbox route. Inspect it on a fresh message rather than promising SPF alignment from the apex record alone.

The complete SPF evaluation must remain within ten DNS-lookup-causing terms, including evaluated nested includes, a, mx, exists, ptr and redirect where used. This is not simply ten includes in your visible TXT string. Avoid adding another lookup-heavy policy without checking the expanded dependency chain. Invalid syntax, duplicate policies or an exceeded limit can produce permerror; transient DNS problems can produce temperror. An all mechanism prevents redirect from taking effect. SPF lookup limits.

Retrieve the DKIM record issued for your service

Follow the dedicated Email Hosting procedure:

1. Sign in to VIPcontrol.
2. Open My Services → Email Hosting.
3. Choose Manage next to the correct email service.
4. Scroll to DKIM record.
5. Copy Hostname and the complete Content (TXT) for that account and domain.

VentraIP documents TXT as the record type and 3600 seconds as the DKIM TTL. Its example hostname is axigen._domainkey.your-domain-name-here.com, but it expressly labels that as an example and tells customers to obtain their own value from VIPcontrol. Do not assume every service uses axigen, and never copy another domain's public key. Exact retrieval procedure.

Publish the complete supplied public record, including its DKIM tags and full key. Do not paste only the opening tags, shorten the value at an ellipsis or replace it with the output of an unrelated key generator. If a DNS editor splits long TXT data into several quoted character strings, they must remain parts of one logical TXT record that reconstructs the complete supplied value. A second independent TXT key record at the same selector is not the same thing. DKIM key records.

Publish at the authoritative DNS provider

First inspect the domain's delegated nameservers. Edit the active zone, not whichever DNS interface is easiest to open. Save the current record set and preserve incoming MX, website records, unrelated TXT verification and other senders' selectors.

When VIPcontrol manages the active DNS

The current DNS-management instructions use this route:

1. Open Domains in VIPcontrol.
2. Select DNS for the domain.
3. Use the plus control to add a genuinely new record, or the pencil to edit an existing approved record.
4. Select TXT under Type.
5. Enter the appropriate relative Hostname, the complete Value and the TTL.
6. Save the intended change and inspect the resulting full owner and value.

Use a blank Hostname for an apex SPF record. For an issued DKIM owner of axigen._domainkey.example.com in the example.com zone, the relative Hostname would be axigen._domainkey. Use that label only if it is actually the account-issued selector. VIPcontrol DNS editor.

Do not use Apply DNS Preset just to repair one authentication record. A service preset can add incoming-mail records or replace a carefully maintained multi-sender setup. Make the smallest authorized change.

When another provider or delegated zone manages DNS

VentraIP explicitly allows publication at a third-party DNS host and links a separate cPanel DNS-editor procedure. Use the actual provider's field rules. Some forms take relative names; others accept complete names. Always verify the resulting fully qualified owner so the zone suffix is not appended twice.

If the issued owner is selector._domainkey.news.example.com, its relative name in example.com is selector._domainkey.news. In a separately delegated news.example.com zone, it is selector._domainkey. If _domainkey.example.com itself is NS-delegated, the key belongs at the authority answering for that namespace, not an ineffective parent-zone TXT entry.

Preserve existing delegations and selectors. If the issued TXT owner already has a CNAME or another sender's key, resolve ownership or a supported selector change before proceeding. Do not delete a working delegation or existing sender's record to force a save. This documented DKIM branch uses TXT, so there is no reason to introduce an HTTP proxy or CNAME-flattening change.

Distinguish enabled signing from successful authentication

VentraIP's DKIM explanation says Dedicated Email Hosting already has DKIM enabled, although additional setup may be needed. That makes record retrieval and publication the documented customer task; it does not establish that your particular message has passed DKIM. The cPanel activation instruction on the same page belongs to another sending product. Provider signing distinction.

Do not invent a second Business Email signing switch or repeatedly regenerate a working key. After publication, check the actual signature on a newly delivered message. If the expected signature is missing or uses an unexpected domain, confirm the selected service and sending route before changing DNS again.

Retain DMARC policy and set up reporting safely

Check the visible From domain for an existing DMARC policy and any applicable inherited policy. Retain its enforcement, alignment modes and approved report destinations. Provider onboarding should not silently downgrade a parent policy or replace a working record with p=none.

Only where no direct or inherited policy applies, and the owner approves a monitored rollout, a first record can use this illustrative form:

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

Choose an approved working reporting address instead of copying the example. Publish TXT at _dmarc.example.com. In VIPcontrol's example.com zone, Hostname is _dmarc. For _dmarc.news.example.com, use _dmarc.news in the parent zone, or _dmarc in the delegated child zone. Do not publish DMARC at the blank apex. DMARC policy and discovery.

If the aggregate-report destination and the domain where the DMARC policy was found have different Organizational Domains, the report-sending receiver must verify DNS authorization for the destination to receive those reports. The external-authorization check is not required when they share the same Organizational Domain. Obtain the reporting service's exact destination and authorization procedure. External-destination verification. Reports expose infrastructure and authentication patterns; approve recipients, access and retention. Failure reports can reveal more detailed message information and should not be enabled casually. Reports and monitoring are not delivery guarantees. Aggregate reports and failure reports.

Verify the record and a real sending path

These are example checks, not results from a tested account. Replace the domain, authoritative server, envelope owner and selector with the actual values:

dig +short NS example.com
dig @ns1.dns-host.example TXT example.com +noall +answer
dig @ns1.dns-host.example TXT actual-selector._domainkey.example.com +noall +answer
dig @1.1.1.1 TXT actual-selector._domainkey.example.com +noall +answer
dig @1.1.1.1 TXT actual-envelope.example.com +noall +answer
dig @1.1.1.1 TXT _dmarc.example.com +noall +answer

Check all authoritative nameservers and follow any delegated namespace to its actual authority. Confirm the complete logical DKIM TXT value and a single SPF policy at the evaluated owner. Compare recursive answers after allowing for the previous TTL. A wrong owner or SERVFAIL needs diagnosis, not an automatic propagation wait.

Send a newly authorized message to a controlled external mailbox through each intended production route. Open the raw source and use Authentication-Results generated within that receiver's trusted processing boundary. Position in the header or an authserv-id matching a familiar name does not alone make a result trustworthy. Authentication-Results specification.

For the new branded DKIM configuration, require:

• The intended visible From address has not been replaced with a provider address.
• The intended VentraIP signature uses the expected signing domain d= and actual selector s=.
• The trusted receiver reports that signature as dkim=pass, with a signing domain aligned to visible From under the current policy.
• The trusted receiver reports dmarc=pass, with the aligned passing mechanism identified.

Relaxed alignment permits an organizational-domain match; strict alignment requires an exact match. A passing signature from an unrelated provider domain is insufficient. A generic DMARC pass supplied by SPF cannot certify that the intended DKIM setup worked. Likewise, a child MAIL FROM domain can satisfy relaxed SPF alignment while failing strict alignment.

Inspect SPF even when DKIM supplies the DMARC pass. Compare direct-route fail or softfail with the sending IP and actual envelope policy; investigate permerror for duplicates, syntax and lookups, and temperror for DNS problems. Test forwarded mail separately instead of broadening SPF to authorize every forwarding server.

Troubleshooting and rollback

No DKIM record appears in the service screen. Confirm the selected domain and Business/Dedicated Email product. Do not substitute the Google Workspace example on the same help page or create an assumed axigen key. Ask the service administrator to obtain the actual issued record.

The DNS editor rejects the key. Check for a conflicting CNAME, an occupied selector or a value-length limitation. Preserve the full logical TXT value; do not truncate it. Resolve the editor's supported long-TXT format before saving.

DNS looks correct but DKIM fails. Compare the message's actual s= and d= with the queried owner. A different route, stale signing key or post-signing message modification can produce a failure even when one public key is present.

Adding SPF unexpectedly authorized the website or gateway. Review the a and mx mechanisms against actual DNS. Restore or revise only the affected SPF policy after checking other senders and concurrent changes; do not use +all as a workaround.

A needed change must be reversed. Restore only the faulty record from the saved state. Coordinate key removal with signing and queued-mail lifetimes. Recheck the affected route and unrelated senders, rather than resetting all DNS to a template.

Documentation and testing limits

No customer account, DNS modification or test send was performed. This guide does not certify actual account configuration, delivered-message results, CMS rendering, publication, indexing, ranking or inbox placement.