Taximail by Orisma SPF, DKIM and DMARC setup, step by step

In Taximail, first verify access to your sender domain, then open Settings → Verified domains → View setup instructions. Choose the approved bounce and link subdomains, publish the complete account-issued DNS packet, and click Authenticate domain only after all record checks pass. Finally, test a controlled message: DNS validation alone does not prove that the intended Taximail signature passes and aligns with your unchanged From address. Taximail authentication instructions.

On this page

• Scope and preparation
• Verify access to the domain
• Obtain and approve the DNS packet
• Map and publish the records safely
• Review SPF at the actual envelope owner
• Handle DMARC separately
• Validate DNS, activate and test a real message
• Troubleshooting and recovery
• Frequently asked questions
• Sources and verification limits

Scope and preparation

This guide covers Taximail by Orisma’s documented sender-domain authentication workflow for its hosted campaign service. Domain ownership verification is also documented for transactional sending, but that does not establish that every API, SMTP or automation path automatically uses the same signing configuration. Test each intended path separately; this guide does not configure employee mailboxes or another SMTP provider.

Use an organization-controlled domain and an accessible address on it, with the domain owner’s permission. Taximail says free-provider addresses can be used as senders but cannot be configured with custom SPF and DKIM through this process. Do not mistake shared provider authentication for branded authentication. The public procedure does not establish a universal plan entitlement, regional packet or exact permission role: confirm access to the relevant settings in your actual account. Sender-domain prerequisite.

Coordinate the account operator, domain/DNS owner, campaign owner and mail-routing administrator. Save existing DNS, active sender identities, direct and inherited DMARC policies and a rollback plan. Identify delegated namespaces, shared selectors and services using the proposed bounce and link names. Do not change parent nameservers, DNSSEC, credentials or existing inbound mail routes simply to match an illustration.

Verify access to the domain

1. Open Settings → Verified domains and the add button at the bottom right.
2. Enter an accessible email address ending in the domain you are authorized to use. Choose Send Verification Email.
3. Open the expected Verify your own domain message. Either use its Verify Domain link or enter its nine-digit code into the matching Taximail verification screen and choose Verify Code.
4. If it does not arrive, inspect the intended mailbox’s spam folder or use Resend email. The documented alternate-address option is Fill in your another email address; use another address you are authorized to access.

Only use a fresh code or link issued for your own matching verification request. Do not copy a code from a screenshot or disclose it to another service. No verification message was requested or code submitted for this article. This step confirms domain access, not DNS publication or delivered-message DKIM. Official domain-verification procedure.

Obtain and approve the DNS packet

Under Settings → Verified domains, select View setup instructions for the intended sender domain. Choose or enter:

• Bounce detection subdomain, used for bounce handling and the Return-Path shown in Taximail’s illustration.
• Link & Content URL, used for redirects and image URLs in email content.

Choose Confirm, then confirm the popup. The account displays its complete required DNS records. Save that packet and compare every full owner, type and value with the authorized plan before publication. Official authentication procedure and illustrations.

The official illustrated packet contains a bounce-owner SPF TXT, an MX with priority 10, an A record, a DKIM CNAME at mail._domainkey.bounce, a tracking CNAME and additional partly masked TXT/CNAME records. Some values are intentionally hidden. It is not a complete reusable configuration, and its IP address is not a universal Taximail destination. Obtain every value from your account rather than reconstructing the hidden rows.

Separately approve routing consequences: compare the exact MX destination and priority, A address, tracking target and full owners with the mail/web owners’ authorized routing plan. A copied packet is not authorization to reroute inbound mail, bounce handling or existing links. Use unused approved names or coordinate a migration. Although the public page describes adding records as non-disruptive, that assumes there are no conflicts; never overwrite an existing service on that basis.

Map and publish the records safely

For an illustrative sender domain example.com and approved bounce label bounce, the full bounce owner is bounce.example.com. Enter bounce in the parent zone, or the DNS host’s apex input, often @ or blank, if bounce.example.com is a separately delegated zone. An account-issued apex TXT at example.com uses that DNS host’s apex input in the parent zone. Keep verification TXT values distinct from SPF.

For the illustrated DKIM owner mail._domainkey.bounce.example.com:

• In the example.com zone, enter mail._domainkey.bounce.
• In a separately delegated bounce.example.com zone, enter mail._domainkey.
• In a separately delegated _domainkey.bounce.example.com zone, its administrator enters mail.

For a selected link owner such as go.example.com, enter go in the parent zone. These are owner-mapping examples, not instructions to choose these labels. Use the complete account-issued owners and targets, including any additional validation records. Do not double the zone suffix or delete existing NS delegations.

At a CNAME owner, do not add another CNAME or conflicting TXT, A, AAAA or MX records. The illustrated bounce owner can carry its issued TXT, MX and A together; the DKIM alias is a different owner. Do not mistakenly place its CNAME at the bounce owner itself. Preserve complete public keys when supplied through an approved alternate workflow; never generate unrelated keys or expose private keys.

Use DNS-only rather than HTTP proxying for required authentication aliases. Where Taximail requires literal CNAME answers, ensure flattening does not conceal them. On Cloudflare, disable the relevant per-record Flatten control when available and check applicable zone-wide behavior. Apex and same-zone targets have separate rules. Do not make an unapproved global change affecting other services; if mandatory behavior cannot preserve the required alias, stop and coordinate a supported configuration. Cloudflare flattening guidance.

Review SPF at the actual envelope owner

SPF evaluates SMTP MAIL FROM, or HELO in applicable cases such as a null reverse path, not automatically the visible From address. Taximail’s subdomain illustration associates the selected bounce domain with Return-Path. Verify the actual identity in delivered mail rather than assuming every route uses the same one. SPF identities.

The illustrated bounce SPF uses include:smtp.txmsv.com with a softfail qualifier, but your current account packet governs. Do not paste that policy at the parent domain merely because it appears in From. At each required SPF owner publish only one v=spf1 policy, preserving existing legitimate authorization and intentional qualifiers. If the owner already has a policy, its administrator must integrate the required authorization deliberately. Never stack a second policy or put TXT beside a CNAME.

Count all evaluated DNS-dependent terms, including nested evaluation, against the limit of ten, not merely ten written includes. Do not append mechanisms after a terminal all; redirect is ignored when all is present. A qualifier does not dictate a receiver’s final delivery decision. SPF lookup budget, redirect semantics.

Handle DMARC separately

Inspect direct and applicable inherited policies before creating anything. Retain existing enforcement, alignment modes and approved report destinations. DNS authentication setup is not permission to downgrade an existing policy.

Only when there is no applicable policy, the domain owner approves and a monitoring plan is appropriate, an initial policy can use:

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

For example.com, the relative name in that zone is _dmarc. For a sender domain news.example.com, the owner is _dmarc.news.example.com: enter _dmarc.news in the parent zone or _dmarc in a delegated child zone. Do not duplicate the policy. This minimal example does not itself arrange report collection. DMARC policy location and discovery.

If you add aggregate reporting, obtain approval for the destination and purpose, provision the approved recipient and monitor report receipt. Compare the report URI’s destination-host Organizational Domain with that of the domain where the policy was found, not automatically the visible From domain. When those Organizational Domains differ, the report-generating receiver must check DNS authorization. The same-Organizational-Domain case is excepted, even where the individual hostnames differ. This protocol check does not replace the owner’s data-sharing and privacy decision. Never copy someone else’s report address. RFC 9990 section 4.

Plan enforcement across all legitimate senders, not only Taximail. Review reports and forwarding or mailing-list paths before tightening policy. RFC 9989 section 7.4 warns of indirect-flow disruption and requires valid DKIM rather than sole reliance on SPF for p=reject domains. General-user domains whose users participate in mailing lists need that specific risk assessment. Do not use obsolete pct rollout instructions. DMARC interoperability considerations.

Validate DNS, activate and test a real message

Compare the authoritative answers and a public resolver with every approved row of the account packet. The following uses illustrative names and placeholders, not fabricated successful results:

dig @AUTHORITATIVE-NS TXT bounce.example.com
dig @PUBLIC-RESOLVER-IP TXT bounce.example.com
dig @PUBLIC-RESOLVER-IP MX bounce.example.com
dig @PUBLIC-RESOLVER-IP A bounce.example.com
dig @AUTHORITATIVE-NS CNAME mail._domainkey.bounce.example.com
dig @PUBLIC-RESOLVER-IP CNAME mail._domainkey.bounce.example.com
dig @PUBLIC-RESOLVER-IP TXT ACCOUNT-ISSUED-DKIM-TARGET
dig @PUBLIC-RESOLVER-IP CNAME go.example.com

Substitute the actual authoritative server, chosen public resolver, full owners and DKIM target. Follow the DKIM alias to a usable public-key TXT, not just a present CNAME. Compare the exact MX priority/destination, A address, SPF policy and remaining validation/tracking values with the approved packet. Respect the actual authoritative boundary if a child namespace is delegated.

Return to the intended domain’s setup screen. Once all checks pass, click Authenticate domain to confirm. The official DNS illustration warns that validation times out if it is not completed within 72 hours of generation; request new domain verification when that happens and use the fresh instructions. Its displayed calendar deadline belongs to the illustrated account, not yours. Taximail validation and activation.

Have the authorized campaign operator send harmless test content to controlled valid recipients through the intended production path. Check original received headers, not a forwarded body. Repeat for each intended domain and transport; a campaign result does not establish API or SMTP behavior. No customer message was sent for this guide.

Identify results produced inside the receiving service’s known processing boundary and its documented treatment of externally supplied Authentication-Results. Neither header position nor a familiar authserv-id string alone proves authenticity. Ignore attacker-supplied result fields; consult the receiving administrator when provenance is uncertain. Authentication-Results trust boundary.

Require all of the following before approving branded DKIM:

1. The delivered visible From remains the approved intended address, not a provider-owned rewrite.
2. The intended Taximail signature is present, with its d= and s= recorded together and trusted receiver dkim=pass for that signature.
3. Its passing signing domain aligns with the intended From under the applicable adkim policy.
4. The receiver records dmarc=pass for that intended From domain.
5. The actual SPF identity and result are recorded, with failures and errors investigated even if DKIM supplied DMARC pass.

Strict alignment requires exact domain equality; relaxed alignment permits the applicable same-Organizational-Domain relationship. A child envelope domain is not strict SPF alignment with its parent. A generic DMARC pass via SPF does not prove branded DKIM. Keep multiple signatures and their outcomes separate. Raw versus aligned DKIM results.

Troubleshooting and recovery

Verification email missing: check the actual address, spam folder and documented resend path. Domain-access verification must complete before custom DNS authentication; publishing records alone does not substitute for it.

Record checks fail: compare all current account rows, including masked rows that require real account values. Check the authoritative zone, duplicated suffixes, owner conflicts, delegation, DNS-only settings and flattening. Do not keep waiting after the account has entered its documented validation-timeout state.

All checks pass but the intended signature is absent: confirm you clicked Authenticate domain, selected the right sender domain and tested the intended route. Ask verified Taximail Support to resolve a signing mismatch; do not invent another activation switch or accept shared provider identity as the branded outcome.

SPF fails or errors: inspect actual MAIL FROM authorization. fail is not the same as a transient temperror or a persistent permerror caused by problems such as malformed syntax, multiple SPF policies or excessive evaluated DNS terms. Investigate and retest these even if aligned DKIM supplied DMARC pass. SPF result meanings.

DKIM passes but DMARC fails: compare the passing signature’s d= with the unchanged From under the actual alignment policy. The illustrated selector owner is beneath a bounce subdomain; do not infer exact-domain alignment with the parent or claim a universal signing identity from that screenshot.

Mail, bounce handling or tracking breaks: obtain the affected owners’ approval to pause the affected campaign or route and restore the last known-good approved configuration. Preserve shared selectors, queued-message dependencies and working authorizations. Retain a failed sample, then retest both that path and a known-good path. Do not remove unrelated DNS or weaken DMARC as a shortcut.

Before launch, the campaign owner should also verify audience permission, working unsubscribe handling and appropriate sending practices. Authentication cannot guarantee inbox placement.

Sources and verification limits

The full rendered public authentication procedure, domain-verification procedure, and five linked workflow/DNS illustrations were read. No publication or update date was established for those procedures. Old dates in illustrative screenshots are not their publication dates.

No account login, verification email request, code submission, DNS mutation, actual send, mailbox test, live CMS render or publication was performed. Account entitlements, permissions, current generated records and signing behavior remain checks for the authorized implementation team. This guide does not promise that every Taximail transactional or SMTP route inherits the campaign configuration.