Omnivery domain authentication has two separate gates: domain vetting and DNS verification. Add the approved sending domain and data location, obtain its exact records from Domain Detail, publish the approved sending and receiving records, and wait for the domain to become Active. Then verify a controlled message from the intended application. A valid DNS record does not bypass vetting or prove delivered-message alignment. Omnivery domain setup, Domain Detail.
This guide covers an existing approved Omnivery account where the visible From domain exactly matches the configured sending domain. For example, a sending domain of news.example.com uses an approved address at news.example.com, not the parent example.com. It does not configure wildcard sending, optional parent-domain signing, new transactional-mode activation, a new API/SMTP integration or migration from another platform.
No customer account, DNS changes, support outreach or sending tests were performed. The reviewed pages do not expose a reliable publication/update date; the check date is not a vendor release date.
Choose the domain and data location deliberately
Confirm the intended application, message stream, visible From and domain administrator. Omnivery recommends separating streams using dedicated sending subdomains so the new route does not interfere with ordinary business email. For this guide, choose a domain whose inbound handling can also be assigned to Omnivery with the owner's approval. An isolated child domain is often easier to evaluate than a root domain already receiving employee mail.
The required receiving MX is consequential: it routes inbound messages for the sending domain, not merely a verification token. Do not replace a corporate mailbox service's MX to get an authentication check to pass. If the proposed domain cannot safely support the required receiving route, stop and agree a supported domain/routing design with the mail administrator and Omnivery before proceeding. Domain setup and stream separation, required receiving records.
Agree the data location before adding the domain. Omnivery says the domain name and data location cannot be changed later in Domain Detail. Do not pick the screenshot's Europe setting by habit, promise an in-place region migration, or register a replacement domain to evade an approval decision. Confirm the organization's existing data-handling requirements and authorized location.
Preserve the existing application route, credentials, DNSSEC, parent nameservers, mailbox records and working selectors. Record the approved starting configuration and dependencies so any later recovery is deliberate rather than a wholesale DNS reset.
Add the domain and allow for vetting
- In the existing account, open the Domain list from the left menu.
- Check whether the exact domain already exists. If so, inspect its Domain Detail instead of creating a duplicate.
- For an approved new entry, choose Add domain, enter the exact sending domain and select the approved data location.
- Do not enable Wildcard or Force DKIM authority to make an unrelated From address work. These controls appear in the public dialog, but this guide does not establish their broader authority or configuration requirements.
- Confirm the domain and location, then use Add domain. The new domain enters vetting. Official addition and vetting procedure.
Omnivery describes vetting as normally taking one to three working days, not a guaranteed deadline. DNS preparation can proceed during vetting, but successful DNS alone does not approve the domain. The provider states that rejected domains cannot reapply for vetting for twelve months. Do not repeatedly recreate an entry or use another account to bypass that decision; obtain an explanation through an approved support channel.
The documented progression is Vetting → Approved → Verification → Active, with a rejected branch. DNS verification occurs after approval, and the domain becomes Active when its required records validate. There is no separate universal Enable Signing button established by these instructions. Domain status.
Obtain and classify the actual DNS packet
Open Domain Detail and inspect the DNS records shown for the exact domain and location. Copy each record's full owner, type, complete value or target, and MX priority where applicable. The current documentation describes these components:
| Component | What it does | Required handling |
|---|---|---|
| SPF TXT | Authorizes sending infrastructure at the sending domain | Reconcile the current account-issued authorization into one policy |
| DKIM CNAMEs | Expose provider-managed public signing keys | Publish the issued aliases without guessing selectors or targets |
| Tracking CNAME | Routes an account-specific tracking hostname | Approve that exact destination before publishing; DNS does not authorize enabling tracking |
| Receiving MX | Receives remote bounces, unsubscribe mail, feedback and inbound messages processed by Routes | Approve the exact owner, priority and destination without displacing unrelated inbound service |
The public screenshot labels one section “Sending MX records,” but its individual rows are TXT and CNAME records. Use each row's actual record type, not that section heading. Its sample domain, selector identifiers, .dev destinations and MX priority are illustrations, not universal production settings. Omnivery record descriptions.
Omnivery documents two DKIM CNAMEs for an organizational-level domain, or four for a child domain. It describes the additional pair as optional organizational-domain signing for strict alignment. This guide uses the exact sending-domain/From match and does not configure the parent-From variant. Have Omnivery identify which issued pair belongs to the intended signing domain and clarify any optional parent-authority records before publishing them. Do not guess from the record count, blindly omit required rows, or grant parent-domain signing authority merely to finish a child-domain setup.
The provider's statement about mandatory strict DKIM alignment is its documented service requirement, not a universal claim that DMARC always requires strict alignment. Preserve the organization's actual DMARC policy and verify the intended signature on a received message.
Publish records at the correct authority
Find the authoritative DNS host, which need not be the registrar or website host. Check the approved routing plan before publishing MX or tracking records. A generated packet does not itself authorize new inbound destinations or web redirects. Leave inbound Routes, forwarding recipients and tracking settings unchanged unless separately approved.
Map owners carefully. An illustrative issued owner SELECTOR._domainkey.news.example.com may be entered as SELECTOR._domainkey.news in the parent example.com zone, or SELECTOR._domainkey in a separately delegated news.example.com zone. If _domainkey.news.example.com is delegated, use that authority. Inspect the resulting full owner so the DNS editor does not append the domain twice. Do not delete a delegation to make the record fit. DNS authority and delegation.
At every CNAME owner, check for an existing alias, TXT, A, AAAA or MX record. A CNAME cannot coexist with those ordinary records or a second target. Stop on a collision and arrange a supported alternative; do not overwrite another sender's selector or a live web hostname. Keep the complete supplied targets, and never upload or publish a DKIM private key. DNS record representation.
For Cloudflare, keep authentication aliases DNS-only rather than HTTP-proxied. Where the verifier requires a literal CNAME answer, turn the relevant per-record Flatten option off when available and ensure applicable zone-wide settings do not suppress it. Apex and same-zone target behavior can flatten automatically. Do not disable unrelated zone features globally; if the required answer cannot be preserved, stop and coordinate a supported configuration. Current Cloudflare flattening controls.
For the receiving MX, preserve the issued priority and target at the approved sending-domain owner. Do not assume that adding another MX beside existing corporate MX safely preserves delivery: priorities and fallback behavior affect where messages go. Resolve that routing design first.
Reconcile SPF and preserve DMARC
Omnivery says it constructs SMTP MAIL FROM using the sending domain and adds that domain's DKIM signature. SPF evaluates this envelope identity, not automatically the visible From. The chosen exact-match scope makes the expected domains explicit, but actual message evidence must confirm them. Omnivery domain alignment.
Use the current account-issued SPF value, not a remembered include from a screenshot. If the evaluated owner already has a v=spf1 TXT policy, merge the required authorization while preserving other legitimate senders and the approved terminal qualifier. Never publish a second SPF policy or replace established root SPF with a single-provider example. A child domain does not inherit parent SPF.
Check the limit of ten evaluated DNS-dependent terms, including nested processing, rather than counting only top-level includes. An all mechanism causes redirect to be ignored, and mechanisms after all cannot supply the intended authorization. Do not change -all to ~all as a routine workaround. No qualifier guarantees a recipient's delivery decision. RFC 7208.
Inspect the direct and applicable inherited DMARC policy for the intended From domain. Preserve existing enforcement, alignment settings and authorized report recipients. An empty query at a child _dmarc owner does not prove that no policy applies. Do not duplicate policies or downgrade inherited reject/quarantine to none to obtain a green status.
Only when no direct or applicable inherited policy exists, and the owner approves an appropriate monitoring-first introduction, a minimal first policy can be:
Type: TXT
Full owner: _dmarc.APPROVED_FROM_DOMAIN
Value: v=DMARC1; p=none
Replace the placeholder with the actual From domain. For news.example.com, the full owner is _dmarc.news.example.com, entered as _dmarc.news in the parent zone or _dmarc in the delegated child zone. This example requests no reports; do not use obsolete pct rollout instructions. Current DMARC policy standard.
Report sharing needs a separate privacy decision. Compare the destination's Organizational Domain with the Organizational Domain of the domain where the DMARC policy was found, including an inherited policy. A different Organizational Domain requires receiver-checked DNS authorization; a destination within that same Organizational Domain is excepted. Protocol authorization does not replace the owner's data-sharing approval. RFC 9990 section 4.
Confirm Active status and test the real stream
Compare every required owner with authoritative DNS and an independent resolver. These are templates, not executed results:
dig @AUTHORITATIVE_NAMESERVER CNAME ISSUED_DKIM_OWNER
dig TXT APPROVED_SENDING_DOMAIN
dig MX APPROVED_SENDING_DOMAIN
Use actual approved values and repeat for both intended DKIM aliases and the tracking alias. Expect exact account-issued targets, the approved SPF policy and the approved MX priority/target. A generic domain score or an IP response instead of a required alias is insufficient.
Return to Domain Detail and confirm that vetting was approved, all required records validate and the domain is Active. If approved DNS remains unverified, check owners, suffixes, conflicts and caching; ask support about the exact account/domain association rather than inventing a retry or activation control. Keep records after validation: Omnivery periodically checks them and relies on them for ongoing operation. Verification and persistent records.
Use only the existing authorized application and mail-stream mode for a harmless test to controlled consenting recipients. Do not trigger a payment, invoice, password reset or production campaign. Transactional mode requires a separate support-enabled configuration; domain authentication does not enable it. Do not enable journaling, third-party Bouncer validation, wildcard access, privacy changes or open/click tracking just to perform this check.
At the receiver, inspect results produced within its known processing boundary and its documented handling of externally supplied Authentication-Results. Header position or a familiar authserv-id string is not sufficient trust evidence. Ask the receiving administrator if necessary and ignore injected or untrusted results. RFC 8601 trust boundary.
Record visible From, MAIL FROM, the intended Omnivery signature's d= and s=, and trusted SPF/DKIM/DMARC results. For this exact-match route, require the intended signature to pass with d= exactly matching the intended From domain, and require trusted dmarc=pass. Confirm the expected envelope identity separately. A provider-rewritten From, unrelated valid signature or SPF-only DMARC pass is not proof this DKIM configuration works.
DMARC normally accepts either aligned SPF or aligned DKIM. Relaxed alignment compares Organizational Domains; strict adkim and aspf require exact domain matches for their respective identities. A child envelope does not strictly align with a parent From. This guide deliberately avoids that parent-From case. Raw DKIM versus aligned DKIM results.
Troubleshooting and questions
Why is DNS correct but the domain not Active?
Vetting and DNS verification are separate. Check the actual domain status and approval outcome. One to three working days is an estimate, not an automatic approval timer. Do not bypass a rejection by recreating the domain.
Why are there four DKIM records?
A child-domain packet may include an extra pair for organizational-domain signing. Confirm the intended signer and optional parent authority with Omnivery. This guide covers exact sending-domain/From matching, not parent-From or wildcard configuration.
Can I skip the receiving MX?
The provider documents receiving records as required for bounces, unsubscribe mail, feedback and Routes. Do not silently omit them, but do not publish them until their inbound destination is approved. If corporate mail conflicts, stop and resolve the domain/routing design.
What if SPF fails but DKIM supplies DMARC pass?
Investigate each result. fail concerns authorization for the evaluated envelope path; temperror requires checking temporary DNS/evaluation failures and retesting; permerror indicates problems such as duplicate policies, syntax or excessive lookup terms. Do not dismiss them because another authentication method passed.
What if signing is absent or the signature fails?
Check the actual application route, domain status, intended selector and public-key resolution. Investigate downstream message modification with the responsible administrators. Never disable required security controls to preserve a signature or guess a replacement public key.
Does Active guarantee inbox placement?
No. It establishes provider readiness, not receiver authentication or delivery placement. If a change disrupts service, pause the affected workflow where safe and coordinate recovery with the domain and application owners. Preserve keys, queued-message dependencies and required receiving routes until an approved recovery plan is agreed. Share only necessary redacted diagnostics with authorized support, not credentials or customer message bodies.