Inxmail SPF, DKIM and DMARC setup, step by step

On this page: Product · Domain model · DNS · Activation · Verification · FAQs

Set up SPF and DKIM for Inxmail by registering your sending domain in the correct product, choosing delegation or an alias-based model, and publishing the exact records generated for that scenario. Wait for verification, then use that domain in the actual list, mailing or relay source. An authenticated domain that no mailing uses does not authenticate your production traffic.

This guide uses current official documentation; no account operation, DNS change, campaign or delivery test was performed.

Identify your Inxmail product and sending domain

Inxmail's current help covers several products through a shared sending-domain workflow, but their navigation and final sender settings differ. Do not reuse an old Inxmail Professional screenshot as a universal Commerce or Platform procedure. Current domain-creation instructions

For the new platform mailing editor, the sender address can be set during mailing approval. Verify the interface actually used by your account rather than changing a similar-looking field elsewhere. The current documentation maps these variants explicitly. Using the sender domain

Collect the product, tenant, visible From domain, expected bounce/envelope domain, DKIM signing identity, reply destination and DNS administrator. Save the current zone and policies. List all existing uses of the proposed subdomain, including tracking URLs, web content, corporate mail and other senders. A dedicated child such as newsletter.example.com reduces the risk of interfering with ordinary mail; it does not guarantee isolation from every reputation effect.

Choose the domain model with your DNS administrator

Inxmail recommends a dedicated subdomain and provides three scenarios. Pick the model before creating or publishing records. Choose the right scenario

Dedicated subdomain with delegation

Choose Optimal deliverability and enable Delegate domain to Inxmail. Enter the child domain intended for both sender and bounce identities. In Platform, select the relevant Newsletters & campaigns or Transactional mails tab.

Inxmail manages the delegated domain's DNS maintenance. Delegation changes authority over that child; do not replace the whole organization's nameservers or delegate a shared corporate domain casually. The domain owner must approve the boundary and understand which existing services would be affected. Use the generated delegation records, not guessed nameservers. Confirm the effective DMARC policy after delegation as well as the authority itself.

Before publishing the delegation, have the DNS owner approve the exact child namespace and complete issued NS target set, including existing services affected. Compare the full owner and every NS target at the parent authority and a recursive resolver with that approved set before activation. The generated packet alone is not routing authorization; stop on missing, extra or unapproved entries. Preserve root nameservers, DNSSEC and unrelated mailbox routing.

Dedicated subdomain via alias

Choose Optimal deliverability but leave delegation disabled. Enter the dedicated sender/bounce child domain. You retain responsibility for publishing and maintaining the required alias-based DNS setup, including policy maintenance. It is still a dedicated sending subdomain, not permission to make the company apex a CNAME. Use the exact names, types and targets generated for the chosen model.

Main domain or shared subdomain via alias

Choose Improved deliverability, then supply the sender domain and bounce domain. This model is for cases where the main domain must remain visible or the domain is also used outside Inxmail. Inxmail warns that it is more complex and recommends an already authenticated domain with quarantine or reject protection. Do not weaken such an existing policy to follow a generic “start with none” recipe. Preserve the SPF and DKIM arrangements of other systems. Domain creation and shared-domain considerations

A separate bounce child can satisfy relaxed SPF alignment when it shares the organizational domain with From, but not strict SPF alignment when the names differ. Aligned DKIM can independently satisfy DMARC. The product's “Full Domain Alignment” terminology also covers tracking links; that broader feature should not be confused with DMARC's specific identity checks.

Create the domain and a working reply destination

Register the domain inside Inxmail before publishing its DNS records. Open the product-specific Sending domains view, choose the appropriate scenario, enter the domain information and complete Create or Authenticate domain.

Supply the requested forwarding address as a real, existing mailbox outside the child being authenticated. For example, replies for newsletter.example.com could forward to an approved mailbox at example.com. Using the same authenticated child as the catch-all destination can create a forwarding loop. Check that replies actually reach the mailbox and apply any receiving-filter adjustments narrowly with the mail administrator; do not bypass all security checks. Domain creation and reply-forwarding instructions

Have the receiving-mail owner separately approve the exact forwarding mailbox and catch-all scope before saving or activating it. Compare the resulting destination with that approved plan and verify delivery using a controlled reply. If the issued scenario also requires MX routing, approve and verify its complete full-owner/numeric-priority/target set at authoritative and recursive DNS; do not infer universal MX values from another scenario.

Existing deployments may need a different migration path. The official Professional Smart Guide says that moving a previously stored sending domain to delegation may require a new sender domain or Support assistance to retain the old child. Do not delete and recreate a working domain merely because an older interface lacks the new option. Confirm current migration guidance for that tenant. Professional Smart Guide

Copy the generated DNS records after domain registration

Open the domain's Preview eye icon or Detail view and copy the full record set. Inxmail explicitly says the DNS records differ by scenario. There is no safe universal SPF include, DKIM selector, CNAME target or NS pair to paste across all accounts and products. Official DNS publication steps

Make a record ledger with each generated owner, type, value or target, DNS zone and responsible administrator. For each item:

1. Identify whether it belongs at the parent zone, a delegated child or an existing nondelegated zone.
2. Publish the supplied type and complete value. Do not turn a CNAME into TXT or copy only a fragment of a public key.
3. Resolve owner conflicts with the administrator before making a change. Keep unrelated mailbox MX, verification TXT and existing DKIM selectors intact.
4. Query the public owner and verify it against the generated set.
5. Wait for Inxmail's validation and diagnose any remaining record-specific warning.

For delegation, verify the child authority and the authentication records served there. For alias mode, verify both the alias and its resolving target. If an SPF TXT update is generated at a shared owner, combine required authorizations with the existing policy rather than creating a duplicate. Do not replace account records with static dispatch IPs copied from an allowlisting paragraph: receiving-server allowlisting and sender authentication solve different problems.

For an illustrative issued owner SELECTOR._domainkey.news.example.com, a suffix-appending editor for example.com uses SELECTOR._domainkey.news; one for a separately delegated news.example.com zone uses SELECTOR._domainkey. If _domainkey.news.example.com itself is delegated, use relative SELECTOR in that zone. A full-name field takes the complete issued owner. Replace the placeholder with the actual account selector, preserve existing NS delegations and active selectors, and publish with the actual authority rather than adding an inactive parent-zone copy. DNS zone boundaries.

Where the issued authentication or return-path records require literal CNAME answers, use DNS-only aliases returning the exact targets, without an HTTP proxy or flattening hiding them. Turn the relevant per-record Flatten control off when available and ensure applicable zone settings preserve those aliases. Cloudflare documents that flatten-all cannot be overridden per record, apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are conditional DNS-host behaviors, not assumed controls in every panel. If mandatory apex/same-zone behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration with the DNS owner and sender. Do not blindly change the whole zone or remove an existing delegation. CNAME verification, flattening controls and limits.

SPF checks the SMTP MAIL FROM domain (the envelope sender), not simply the visible From address. For an empty reverse path, SPF uses the HELO identity. A parent SPF record does not automatically authorize a subdomain. Identify the owner from the route and receiver evidence before editing DNS.

Publish only one SPF TXT policy at each owner. Merge authorized senders into that policy, preserve unrelated TXT records, and retain the existing terminal qualifier unless the domain owner separately approves a change. The limit is 10 evaluated DNS-query-causing terms, including nested includes and redirects, not ten visible services. Terms such as a, mx, include, exists and ptr consume the budget; ip4, ip6 and all do not. Evaluate the resulting policy, including nested dependencies, before publication. Do not replace a provider's managed include with a one-time snapshot of its IPs. RFC 7208

If the existing SPF policy uses redirect=, reconcile its authorizations and terminal behavior with the DNS owner before changing it. Any all mechanism makes redirect ignored regardless of their order. Do not append all automatically: preserve the redirected senders and approved policy semantics through a reviewed design. SPF all and redirect processing.

Activate the domain in every real sending route

A green or Ready result is the prerequisite to use the domain, not evidence that every mailing has adopted it. Professional and Commerce can show green with a yellow warning when SPF and DKIM are configured but DMARC is not. Platform distinguishes Ready, Check records and Not possible; Check records indicates limitations, not full readiness. Resolve warnings rather than treating any permission to send as completion. Official status meanings

Update each list's sender address, transactional mailing setting and relevant relay source to use the authenticated domain. For an authenticated child newsletter.example.com, a sender such as news@newsletter.example.com uses that child; news@example.com does not. Confirm replies and bounces separately. Do not silently change a business-visible sender identity without agreement.

For Professional's broader Full Domain Alignment, website-link and tracking-link settings also need the intended domain. With one subdomain, the documentation describes central configuration; with several, review settings per list, including future lists. New Xperience's full-link setup refers to Professional settings. Link-domain activation has separate timing, and the documentation gives differing business-day estimates, so verify actual readiness rather than promise a fixed deadline. Test HTTPS website links and tracked links before a live campaign. These checks supplement, but do not replace, email authentication. Using domains and mailing links

Preserve or establish the applicable DMARC policy

DMARC succeeds when either SPF passes with an aligned envelope domain or DKIM passes with an aligned signing domain. Under relaxed alignment, the authenticated and visible From domains share an organizational domain; under strict aspf=s or adkim=s, they must match exactly. Reply-To, SMTP login and a link-tracking hostname are not substitutes for these identifiers. Current DMARC standard, RFC 9989

Before adding a record, inspect the visible From domain's DMARC policy and any applicable inherited policy. Preserve existing enforcement, alignment and reporting choices. Do not add a child p=none record merely to escape a parent's quarantine or reject policy.

Only if there is no established applicable DMARC policy, and the domain owner approves a monitored first deployment, create one TXT record at _dmarc.example.com for a From domain of example.com. For newsletter.example.com, the corresponding owner is _dmarc.newsletter.example.com. These are examples, not your account's names. After creating and approving a real reporting mailbox, a monitoring example is:

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

For a DNS editor opened on the example.com zone, the relative owner is _dmarc for the apex policy or _dmarc.newsletter for newsletter.example.com. If the editor is opened directly on the newsletter.example.com child zone, use _dmarc there. Confirm the resulting fully qualified name. Replace the reporting address with the approved destination. Check that it accepts reports and that your team can process them.

Compare the Organizational Domain of the aggregate-report URI's host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as the policy domain is excepted; a different hostname alone does not make it external. Obtain the reporting operator's exact authorization instructions when required. This protocol check is separate from the domain owner's approval to share report data; agree access, retention and privacy. RFC 9990 section 4.

Monitoring does not request quarantine or rejection of spoofed mail, and does not guarantee delivery. Assess every legitimate sender, including low-frequency billing and automated systems, before the owner approves stronger enforcement. Do not use the obsolete pct tag as a current percentage-rollout control. Failure reports are a separate, potentially sensitive data flow: omit ruf unless there is an approved need and privacy review. RFC 9989, Failure reporting, RFC 9991

For a delegated Inxmail child, coordinate policy changes with the party serving the authoritative zone. The first-policy example is not a command to publish a competing TXT record in the parent or override a provider-managed policy. In alias mode, the official documentation assigns ongoing DNS and DMARC maintenance to you; record who will review it.

Verify public DNS and a delivered message separately

Replace every example name below with the actual envelope domain, signing domain, selector and visible From domain. These commands read DNS; they do not activate signing or send mail.

dig +short NS example.com
dig +short TXT example.com
dig +short TXT selector._domainkey.example.com
dig +short CNAME selector._domainkey.example.com
dig +short TXT _dmarc.example.com

Check the authoritative server as well as a public recursive resolver. For example, replace ns1.example.net with a real authoritative nameserver and use dig @ns1.example.net TXT example.com. Compare with dig @1.1.1.1 TXT example.com. For a delegated subdomain, query its actual authority. Wait for relevant positive and negative cache lifetimes, then recheck discrepancies.

Acceptance requires one valid SPF policy at the envelope owner, the exact supplied DKIM public record at the message's selector owner, and the intended DMARC policy. TXT data may be divided into multiple quoted character strings within one record; that is different from publishing competing SPF records. DNS editors may append the zone automatically: check that a full owner did not become selector._domainkey.example.com.example.com. A CNAME cannot coexist with other ordinary record data at the same owner. Resolve a conflict with the administrator rather than deleting an unrelated record.

Next, send a fresh representative message through the actual production route to an independent mailbox you control. Open its raw source and use the Authentication-Results added by the trusted receiving system, not arbitrary header text supplied by a sender. RFC 8601

Establish which results were generated inside the receiving service's known processing boundary and how it removes, ignores or distinguishes externally supplied Authentication-Results. Use receiver-controlled diagnostics or have the receiving-mail administrator confirm its documented handling. A familiar authserv-id string or header position alone is not proof. Ignore attacker-supplied or otherwise untrusted fields; obtain authenticated receiving-system evidence when provenance is uncertain. Receiver-result trust.

For this branded DKIM setup, require the intended Inxmail signature to report dkim=pass and align with the unchanged approved branded From under the effective adkim policy, together with trusted receiver dmarc=pass for that From. Record the expected and observed d= and s=. A rewritten provider From, unrelated passing signature or SPF-only DMARC pass does not complete the intended DKIM deployment. DMARC itself permits either aligned passing method; this is the commissioned signer’s acceptance gate.

Diagnose SPF at the actual envelope owner independently even when aligned DKIM supplies DMARC. For fail or softfail, compare the observed connecting source and MAIL FROM identity with the approved authorization and sending route. For permerror, check duplicate SPF policies, malformed syntax and the full nested DNS-dependent term budget. For temperror, investigate temporary DNS resolution or availability failures and retest after recovery. A provider-owned SPF pass without alignment is different from these failures; escalate errors for provider-owned identities to that sender rather than editing unrelated apex DNS. SPF result definitions.

Repeat for each real sender path, including aliases, applications and forwarded mail where relevant. Inspect delivery or bounce evidence separately: an authentication pass cannot guarantee inbox placement, and a successful SMTP submission only proves the server accepted the submission. Preserve redacted headers and timestamps for troubleshooting, without uploading private message content to a public analyzer.

Inxmail notes that isolated delivery issues can occur in the first 72 hours after setup. Treat this as a transition warning, not a reason to disregard an explicit wrong-owner, missing-key or alignment failure. Test a representative campaign and transactional route separately, plus reply forwarding and bounce handling. DNS setup notes

Troubleshoot Inxmail by domain model