Ometria authenticates a customer sending domain with an Ometria-issued DKIM TXT record and a Return-Path CNAME that also supplies SPF authentication. Publish the records assigned to your account, have Ometria verify the DKIM record, and check a newly delivered message. Do not invent an Ometria SPF include or add a second SPF policy at your root domain. The tracking CNAME is a separate requirement. Ometria's onboarding requirements.
This guide covers Ometria's managed email-sending setup, including the DNS dependencies needed before broadcast and automation campaigns use your domain. It does not configure employee mailboxes or authorize a rebrand. The public onboarding guide was updated on November 4, 2026; its linked detailed setup instructions require an Ometria sign-in. Your onboarding contact supplies the account-specific names and values.
Before you change DNS
Choose the exact domain that recipients will see in From and agree its configuration with Ometria. Record the account, sending domain, tracking domain, Return-Path domain, DNS owner and person responsible for approving activation. If several brands share the account, keep a separate record set for each configuration.
You need access to the authoritative DNS service, Ometria's assigned records and a controlled external recipient mailbox for eventual testing. Being able to edit a campaign's From field is not sufficient: Ometria's broadcast settings require the domain to be configured in its back end. Administrators can manage email defaults under Channel settings. Channel settings.
Export the existing zone or save the relevant records before editing. Inventory employee mail, ecommerce receipts, support platforms and other marketing senders. Check whether the proposed tracking and Return-Path names already have records or serve another application. Do not replace a live name merely because a tutorial uses it.
For an existing domain, preserve its SPF, DKIM selectors, MX records and DMARC policy unless the responsible owners approve a specific change. A website host, registrar and authoritative DNS provider may be three different companies. Make the change where the authoritative nameservers serve the zone, not wherever the domain was purchased.
Understand the Ometria record set
Ask Ometria for the complete list, with each record's purpose, type, fully qualified owner and value. The following describes roles, not values to paste:
- DKIM TXT: Publishes Ometria's public signing key beneath the assigned selector and signing domain. Ometria must verify it before the sending domain can be used.
- Tracking CNAME: Connects the assigned tracking hostname to Ometria's destination. The documented naming pattern is
clickom.domain.com; your assigned hostname and target govern. - Return-Path CNAME: Routes bounce and complaint handling. Ometria illustrates
emailom.domain.comand states that this record also provides SPF authentication. - Sending-domain A or AAAA: Ometria recommends a website address for the exact sending domain. Obtain the correct address from the website host, not from an Ometria mail-server IP guess.
- Sending-domain MX and DMARC coverage: Check the receiving-mail arrangement and applicable policy. These serve different purposes from the Return-Path CNAME.
These requirements come from Ometria's current onboarding document. Do not turn the examples into a universal record template. In particular, an MX record for the sending domain does not belong at a CNAME owner used for bounce handling.
DKIM key material is account-specific. Copy the complete TXT data without adding line breaks inside the key or substituting a key from another sender. If the DNS interface has a 255-character input limit, ask whether it supports multiple character-strings in one TXT resource record. A split display is not necessarily a broken key, but two independent key records at one selector are not the solution. The verifier reconstructs the key from the TXT record. DKIM key retrieval.
Publish the records without disturbing shared DNS
Work from the full owner name first, then translate it into the DNS host's input convention. For example, the fictional owner key1._domainkey.mail.example.com is entered as key1._domainkey.mail in a zone editor that appends example.com, or as key1._domainkey in a separately delegated mail.example.com zone. An interface requiring a full name needs the complete owner. Verify the resulting name publicly rather than assuming the editor appended the right suffix.
If a child zone is delegated, records inside it belong on that child zone's authoritative servers. Do not add another copy in the parent and expect resolvers to use it. Conversely, do not move nameservers or delegate a subtree merely to install these records. First establish where Ometria's assigned owners actually reside.
A literal CNAME must remain visible as a CNAME. Where your DNS provider offers an HTTP/CDN proxy, keep the authentication and Return-Path aliases DNS-only. Check both per-record flattening and any zone-wide setting that flattens all CNAMEs. Flattening can substitute addresses for the alias that a verification service expects to find. Cloudflare's CNAME flattening warning.
Make the narrowest approved adjustment. Disabling a zone-wide proxy, changing nameservers or altering flattening for unrelated website records can affect other teams. If the required owner is a zone apex, or shares its name with MX, TXT or address records, stop and resolve the design with the DNS owner and Ometria. A normal CNAME cannot coexist with ordinary data at the same owner, including the SOA and NS records at a zone apex. Do not delete those dependencies to force the alias into place. DNS CNAME rules.
For sending-domain A/AAAA and MX records, retain working website and receiving-mail configuration. If they are absent, coordinate suitable records with the hosting and mail teams. Ometria also recommends monitored postmaster and abuse addresses. Clarify how those contacts will work for a provider-managed bounce domain rather than placing an MX alongside its CNAME.
How SPF and alignment work with Ometria
SPF checks the SMTP envelope sender, normally visible in a delivered message's Return-Path. It does not automatically evaluate the domain in the human-visible From address. With Ometria's documented setup, the assigned Return-Path CNAME leads to the provider-managed SPF arrangement. Publishing a new SPF TXT record at example.com would not repair a broken alias at a different envelope domain. SPF identity and evaluation.
Keep these two questions separate:
- Did SPF authenticate? The trusted receiver should report the actual
smtp.mailfromidentity and SPF result for a direct sample. - Did that authenticated identity align? Compare its domain with From under the applicable
aspfmode.
For a fictional message from offers@example.com, a passing envelope identity at emailom.example.com can align under relaxed mode if both share the applicable organizational domain. It does not align under strict mode because the domain names are different. A provider-owned envelope domain outside that organizational boundary would not align merely because you use the provider. The emitted identity must be inspected; the naming pattern alone is not a delivery test.
Do not dismiss spf=fail, temperror or permerror because DKIM happens to pass. Investigate the actual envelope owner, alias, current authorization and DNS responses. A passing but unaligned SPF result is a different finding from SPF failure.
If another authorized change requires editing an SPF TXT policy, keep one v=spf1 record at that owner and preserve existing legitimate mechanisms. The limit is ten DNS-querying terms evaluated across the complete SPF path, including nested includes and redirects, not ten visible includes or ten TXT records. Do not manually freeze provider addresses to evade the limit without a maintenance plan. SPF publication and lookup limits.
Preserve DMARC policy and reporting
DMARC evaluates the visible From domain. It can pass through either an aligned SPF pass or an aligned DKIM pass. Relaxed alignment uses the applicable organizational-domain relationship; strict alignment requires identical domains. For a branded Ometria setup, require the intended Ometria DKIM signature to pass and align, as well as dmarc=pass. A pass supplied only by SPF does not prove the new DKIM configuration works. Current DMARC standard, RFC 9989.
Inspect _dmarc at the exact From domain and the applicable inherited policy before adding anything. Under current policy discovery, an explicit valid From-domain policy takes precedence; otherwise the organizational-domain or applicable public-suffix policy can govern. Preserve relevant p, sp, np, alignment and reporting settings. Do not overwrite an inherited enforcement policy with a new child p=none record simply to get a green status.
If there is no applicable policy, agree a monitored rollout with the domain owner. p=none requests monitoring rather than enforcement, but it does not request aggregate reports without rua. Do not jump to enforcement based on one Ometria test; other senders and forwarding paths need assessment. For a practical comparison before changing modes, see EmailAuth's strict and relaxed alignment guide.
Only when no direct or inherited DMARC policy applies, an approved monitoring-only starting record is:
Type: TXT
Full owner for From example.com: _dmarc.example.com
Value: v=DMARC1; p=none
For a separately approved From domain mail.example.com, its direct policy owner would be _dmarc.mail.example.com. In a suffix-appending example.com zone, enter _dmarc for the root example or _dmarc.mail for the child example. In a delegated mail.example.com zone, enter _dmarc for that child's direct policy. Use the full owner if the editor requires it. These are fictional naming examples, not instructions to add both records. Publish one DMARC policy at the applicable owner; edit an existing policy rather than adding a duplicate. To request aggregate reports, append ; rua=mailto: followed by your actual approved reporting address to that same value. Do not use an example mailbox, and complete external authorization where required.
Keep approved report destinations. Where the report destination's organizational domain differs from the policy domain's organizational domain, arrange the external reporting authorization required by RFC 9990. Obtain the reporting service's exact authorization instructions and approval to share domain-level authentication data. Do not paste a sample mailbox or send reports to an unapproved third party. Aggregate reporting and more detailed failure reporting have different privacy implications. DMARC aggregate reporting and external destinations.
Verify public DNS, then obtain Ometria activation
Use the assigned names in these read-only commands. Capitalized tokens are placeholders, not literal hostnames and not results from a customer environment:
dig +short NS YOUR_ZONE
dig @YOUR_AUTHORITATIVE_NS DKIM_OWNER TXT +noall +answer
dig @YOUR_AUTHORITATIVE_NS RETURN_PATH_OWNER CNAME +noall +answer
dig @YOUR_AUTHORITATIVE_NS TRACKING_OWNER CNAME +noall +answer
dig @1.1.1.1 DKIM_OWNER TXT +noall +answer
dig @1.1.1.1 RETURN_PATH_OWNER CNAME +noall +answer
dig @1.1.1.1 RETURN_PATH_OWNER TXT +noall +answer
dig +short TXT _dmarc.YOUR_FROM_DOMAIN
Compare authoritative answers and at least one public recursive resolver. Check all required records, including the sending-domain A/AAAA and MX where applicable. The Return-Path TXT query should follow the alias to the SPF data; an authoritative server may show only its local CNAME, while a recursive resolver follows the chain. Follow any target explicitly if the tool does not resolve it. An empty response deserves inspection of response status, delegation and negative-cache timing, not an immediate duplicate record.
Ask Ometria to confirm successful DKIM verification and domain availability. Publicly correct DNS is necessary, but does not substitute for Ometria's activation gate. No general propagation timer proves completion.
Then set the intended broadcast and automation defaults in Channel settings and save. Check campaign-level From values as well. The Reply-To can differ from From, but it should reach a monitored mailbox; it does not provide DMARC alignment. From and Reply-To behavior.
Validate delivered messages from each live route
Have the authorized account owner send a representative broadcast and automation message to a controlled external mailbox. If transactional email uses this domain, validate that route separately. A preview or one campaign cannot certify every route.
Read the final recipient's raw message or trusted message trace. Use authentication results added by receiving infrastructure you control or trust. An attacker can prepend Authentication-Results, even with a convincing authserv-id. If the receiver cannot distinguish or remove untrusted fields, use an independent trusted mailbox or trace. Authentication-Results trust boundary.
Record the visible From, envelope domain, intended DKIM d= and selector s=, receiver-reported SPF/DKIM/DMARC outcomes and alignment modes. Query SELECTOR._domainkey.SIGNING_DOMAIN for the selector actually used, not merely the selector you expected.
Accept the branded route only when the chosen From is correct, the intended Ometria signature passes and aligns, DMARC passes, and expected SPF behavior is understood without unexplained faults. Also check that tracking links resolve and bounce handling uses the intended domain. Those are operational checks, not proof of DKIM. Authentication does not guarantee inbox placement, recipient engagement or message safety.
Troubleshooting and frequently asked questions
Why is Ometria still refusing the sending domain?
Confirm that Ometria has verified the DKIM record, not just that someone saved it in DNS. Check the exact selector owner, full key, authoritative zone and active domain configuration. Provide sanitized DNS answers and the assigned record set to Ometria rather than adding random SPF includes.
Should I add an Ometria SPF include at my root domain?
The documented onboarding route supplies SPF through the Return-Path CNAME. Follow the assigned records. Do not add a guessed root include, and do not copy Ometria's own corporate SPF policy. If support gives account-specific instructions that differ, establish the exact envelope owner and reason before changing shared SPF.
Tracking works, but DKIM fails. Is authentication finished?
No. The tracking CNAME, Return-Path alias and DKIM TXT have distinct jobs. Compare the failing signature's selector and domain with the published key and ask whether the active sender is using the intended Ometria configuration.
Can I replace a conflicting record or disable flattening for the whole zone?
Not safely without checking dependencies. A conflicting name may belong to another sender, a website or a delegated zone. Resolve the particular owner and setting with the DNS administrator. Use an alternative Ometria-approved hostname if needed.
What changes during a rebrand?
Ometria asks customers to contact their representative at least eight weeks ahead. A new sending domain, click-tracking domain and bounce domain need coordinated setup and verification. Plan the campaign transition and warm-up; retain the old route while it is still used. Changing the default From does not prove existing campaigns switched. Ometria's rebranding guidance.
Does DMARC passing mean the entire account is ready?
No. It describes one message's result. Keep evidence for every relevant brand and send type, then monitor representative traffic and approved aggregate reports for unexpected identities or failures.
This guide is based on public vendor documentation and standards. No customer account configuration, customer DNS change, sending test or live delivery validation was performed.