Splio SPF, DKIM and DMARC setup, step by step

To authenticate a domain for Splio SMTP Relay, formerly Forward, give your existing Splio contact the intended sending domains and obtain the current DNS instructions for that service. Publish the approved records, configure the application’s secure relay connection, and wait for Splio’s separate confirmation that the service is available. Receiving credentials or successfully connecting does not mean messages have been cleared for delivery. Splio’s relay setup documentation makes this distinction explicit.

There is no universal Splio SPF include, DKIM selector or public key in that setup page. Your service-specific instructions are the source of those values. Finish with a controlled message through the actual relay: the intended DKIM signature must pass and align with your visible From domain, and the trusted receiver must report DMARC pass.

Confirm that this is the right Splio product

This guide covers an existing, approved native SMTP Relay service. It is not a purchase guide, a generic SMTP-provider substitution, or a walkthrough for Splio Marketing Automation, Mobile Wallets or unrelated products bearing similar names.

In particular, Marketing Automation has an Admin > Deliverability interface. Its separate deliverability settings documentation says manual changes take effect immediately and can require additional work by Splio. Do not use those controls as an assumed Relay activation procedure.

You need three responsible parties: the authorized owner of the sending application, the administrator of the authoritative DNS zone, and your existing Splio contact. The public Relay guide does not establish a universal plan name, region restriction or dashboard role. Confirm service entitlement and who may authorize its configuration before starting; do not create an account, upgrade a plan or switch a production application merely to follow this article.

Keep production dispatch paused during setup. Prepare a small synthetic message and a valid mailbox you control, with permission to receive it. Never use real customers, invoices, password resets, order confirmations or campaigns as authentication probes.

1. Get the exact domain setup from Splio

Tell your Splio contact which domains the existing Relay service will use. A dedicated child of your brand domain is usually preferable to repurposing a domain already used for staff mail or another sender. Confirm the visible From address, reply handling, anticipated envelope sender and signing domain together. A proposed name such as relay.example.com below is an illustration, not a Splio-required label.

Ask for the complete record instructions: type, full owner, value or target, MX priority where relevant, and any required TTL. Also establish which records apply to this account, who verifies them, and how you will receive the service-launch confirmation. Do not reconstruct missing values from the DNS of Splio’s own corporate domain or another customer.

The Relay documentation lists SPF, MX, tracking, DKIM, DMARC and Google Postmaster Tools among possible setup components. It does not specify a fixed number or identical bundle for every customer. Review each issued record against its purpose:

Splio’s separate DNS explanation discusses bounce and abuse/postmaster handling for Marketing Automation. That is useful context, not permission to copy its routing assumptions into Relay. Have Splio identify the exact purpose of your Relay MX records.

Stop if an instruction would repurpose an occupied hostname, redirect staff mail or overwrite an unrelated service. Obtain the domain owner’s approval for the exact destination and routing plan. Do not change the root MX, nameservers, DNSSEC or existing delegations to make an example fit. Google verification and tracking changes also deserve their own access and data-sharing review.

2. Publish SPF at the owner Splio actually uses

Use the DNS service named by the domain’s authoritative nameservers, which may differ from its registrar. First save the current records and identify any delegated child zones. Creating records in an inactive registrar DNS editor will not affect the answers receivers use.

SPF normally evaluates the SMTP MAIL FROM domain, not the visible From header; it also defines HELO checks for relevant cases. The envelope identity is therefore essential to deciding where an authorization belongs. Do not automatically add a Splio authorization to the apex merely because a message displays your company address. RFC 7208 defines the SPF rules.

For an issued SPF instruction:

1. Identify the full evaluated owner and its current TXT answers.
2. If it already has an SPF policy, merge only the approved authorization into that one policy. Preserve other legitimate senders and the existing intended qualifiers.
3. If it has no SPF policy, use the complete provider-issued value after the owner approves it.
4. Check the resulting policy, including nested mechanisms and redirects, against the limit of 10 evaluated DNS-dependent terms. This is not simply a count of include strings. Exceeding the limit produces permerror.
5. Keep mechanisms before the terminal all. A redirect modifier is ignored if an all mechanism is present anywhere in the policy; do not break a shared redirect-based design by casually appending all.

Do not publish a second v=spf1 record or replace an established policy wholesale. -all, ~all and ?all express different SPF results for unmatched senders; none guarantees delivery or rejection. Splio’s public Relay instructions do not authorize choosing a universal qualifier for your domain.

If the actual envelope domain is provider-controlled, have Splio confirm who maintains its SPF. Publishing a record on a different domain will not change the receiver’s SPF evaluation for that message.

3. Publish the issued DKIM record without changing its identity

Use the exact public DKIM material or alias supplied for your Relay service. Preserve the type, complete owner, selector and entire value. Do not generate a replacement key yourself, reuse a historical screenshot key or place a private key or SMTP password in DNS. For a TXT key, retain its tags and complete p= data; DNS-editor wrapping must not truncate the key or turn one logical record into several separate records.

Under RFC 6376, the lookup combines the selector s= with _domainkey and signing domain d=. The following is a name-mapping example only. SELECTOR must be replaced with the actual issued selector, not published literally.

An editor that expects a full name may instead need the complete owner. Check the resulting public answer so it does not become ...example.com.example.com. Preserve existing NS delegations and other selectors. If the record is managed under a delegated namespace, coordinate with that namespace’s owner rather than deleting its delegation.

If the issued packet contains CNAMEs

This is conditional handling, not a claim that every Relay account gets CNAMEs. At a CNAME owner, do not add a conflicting TXT, A, AAAA, MX or second CNAME. If a TXT-only editor appears where the packet specifies CNAME, stop and resolve the authority or editor mismatch rather than changing the record type.

Keep authentication and verification aliases visible in DNS, not behind an HTTP proxy. On Cloudflare, use DNS only for those records, following its proxy guidance. Where Splio requires a literal CNAME answer, turn a relevant per-record Flatten control off, if available, and ensure the applicable zone setting does not flatten that alias. Coordinate changes to shared zone-wide settings; do not globally disable features without understanding other dependencies.

Cloudflare’s CNAME flattening instructions also explain mandatory apex and same-zone behavior. If that behavior cannot preserve a required alias answer, stop and arrange a supported design with the DNS owner and Splio. Do not invent a bypass switch, move nameservers or remove shared delegations. Tracking aliases may have additional application requirements; use their issued instructions rather than blindly applying a website’s proxy settings.

4. Preserve the domain’s DMARC protection

Check the policy applicable to the intended visible From domain, including inherited protection and adkim/aspf alignment modes. A missing TXT at a child’s own _dmarc name does not mean there is no applicable policy. Preserve the effective policy, including relevant parent sp behavior, and existing authorized reporting destinations.

Do not replace enforcement with p=none, add a weaker child override or relax strict alignment simply to make a new sender appear compliant. If Splio’s proposed identities cannot meet the current policy, resolve that with the domain owner and Splio before production use. RFC 9989 is the current DMARC specification.

Only when no direct or applicable inherited DMARC policy exists, and the owner approves a first-policy monitoring plan, an initial TXT value can be:

v=DMARC1; p=none

That example requests monitoring treatment; it neither enables DKIM nor automatically delivers reports. Publish one DMARC policy at the intended owner:

Use an approved monitoring process. Add rua only for a real authorized report destination, not a tutorial mailbox. When the report destination is in a different Organizational Domain from the domain where the policy was discovered, the report-generating receiver must perform the external-destination DNS authorization check. Destinations within the same Organizational Domain are excepted from that check; a different hostname alone is not the trigger. See RFC 9990 section 4. DNS authorization does not replace the owner’s privacy and data-sharing approval. Do not add obsolete pct rollout advice.

5. Configure the approved application’s secure Relay connection

Have the authorized application operator use Splio-issued credentials in the application’s approved secret store. Do not paste them into public DNS, screenshots, logs, command examples or third-party test websites. The native Relay source supplies these connection settings:

Use a client that supports the documented method, requires the secure connection and validates the server certificate. Do not send credentials before TLS is established or turn off certificate verification to clear an error. For a higher-level application, choose the corresponding supported settings; do not hand-build an insecure SMTP exchange merely to reproduce command syntax.

The source also documents ports 25 and 10587 as alternatives. They are not an instruction to disable encryption, open a firewall or switch ports without the responsible operator’s approval. If your client only supports a different authentication or security mode, resolve compatibility with Splio before connecting it to production.

Changing the application’s outgoing route can affect all messages it sends. Limit the change to the approved integration and preserve a record of its prior configuration. Do not silently enable a default-provider fallback or divert unrelated applications through this Relay.

6. Separate DNS checks, initial connection and launch approval

Check the issued records against authoritative answers and a public resolver after the relevant TTL/cache interval. Query the actual owners and types, not a guessed selector or the brand’s homepage. These are read-only examples with invented names, not commands against a customer account:

dig +short TXT relay.example.com
dig +short TXT SELECTOR._domainkey.relay.example.com
dig +short CNAME SELECTOR._domainkey.relay.example.com
dig +short TXT _dmarc.relay.example.com

Replace each name with the approved packet owner and use only the applicable DKIM query type. Compare complete returned values, not just whether an answer exists. An absent answer may indicate the wrong zone, duplication of the suffix, caching or the wrong type. A timeout/SERVFAIL needs DNS diagnosis, not repeated destructive edits. For issued MX or tracking records, also check the approved destination and priority where applicable.

Splio’s launch sequence has a separate gate: credentials open the customer-to-Splio connection, while initial messages remain blocked pending Splio’s checks. Splio then notifies the customer when the service is available. There is no documented universal green status or self-service Enable button for this workflow.

Coordinate any prelaunch trial with Splio. Use only the approved synthetic message and controlled recipient, with no real personal or financial content and no hidden CC/BCC recipients. Initial held messages may subsequently be released, so a queue is not a harmless test sink. Keep business dispatch disabled and ask how queued tests will be handled before launch. An SMTP acceptance response alone is neither recipient delivery nor permission to release a campaign.

Obtain the separate availability confirmation for the intended service and domains. Then perform the controlled acceptance check below before authorizing production volume. Do not infer launch from DNS publication, a valid password or an unrelated Marketing Automation status.

7. Prove the intended identity on a delivered Relay message

Use the actual application and native Splio Relay route, with the intended approved From address. A message sent from a staff mailbox, another SMTP service or a fallback provider does not test this configuration. Do not trigger a real purchase, booking, payment or customer workflow to generate a sample.

Open the delivered message’s full headers in the receiving service. Use authentication results produced inside that service’s known receiving boundary. Verify its documented handling of externally supplied Authentication-Results, or have its administrator identify the internal result or trusted log entry. A familiar authserv-id, a topmost header or a pasted result can be forged and is not enough. Ignore untrusted result fields. RFC 8601 explains this trust requirement.

Record the following without exposing credentials or unrelated recipient data:

• The actual visible From domain, and whether it remained the intended brand identity.
• The intended Splio DKIM signature’s d= domain, s= selector and receiver result.
• The SPF result and actual smtp.mailfrom identity, together with the envelope/Return-Path observed on this route.
• The trusted receiver’s DMARC result and the applicable alignment modes.

Acceptance requires the intended DKIM signature to pass and align, plus trusted dmarc=pass for the intended From. A provider-domain signature or a rewritten provider From is not proof that your brand’s configuration works. A DMARC pass supplied by aligned SPF alone does not close a broken DKIM setup. For multiple signatures, keep each domain, selector and result together; the EmailAuth explanation of raw versus aligned DKIM results shows why a raw pass can still be unaligned.

Under relaxed alignment, authenticated and visible-From domains may share the same Organizational Domain under the applicable discovery rules. Under strict alignment, the relevant domains must match exactly. For example, an envelope under bounce.example.com and From under example.com are not strictly SPF-aligned. The public Relay page does not promise a universal Return-Path or strict-alignment outcome; confirm the issued identities and actual message.

Inspect SPF separately even if DKIM carries DMARC. fail indicates the evaluated policy did not authorize that sender, temperror a temporary evaluation problem, and permerror a permanent policy/evaluation defect such as duplicate policies or exceeded limits. Repair the actual failure rather than treating all three as propagation delay. Authentication success does not guarantee inbox placement, message safety or universal delivery.

Troubleshooting without changing the wrong service

Splio documents optional X-Splio- headers, including reporting groups, pools, tracking and a specially configured blacklist-bypass option. These are not SPF/DKIM activation controls. Leave them unchanged for this task. In particular, do not enable X-Splio-filteroff or change complaint/unsubscribe handling. Resolve test-recipient eligibility through the approved process instead.

When escalating through the existing Splio contact, supply the affected service/domain, exact public-record mismatch, time and a sanitized message identifier or authentication excerpt. Keep passwords, tokens, private keys and customer content out of ordinary support evidence. Share only what is authorized and necessary.

Rollback and maintenance

If acceptance fails, pause the affected application’s new dispatch and coordinate held-message handling with Splio. Do not assume that removing a DNS record cancels queued mail. Establish whether any accepted messages remain pending before retrying, to avoid duplicate delivery.

Restore a prior application route only if it remains approved and its authentication is known to work. For DNS, restore only the changes you own after checking dependencies. Keep selectors and bounce/tracking records needed by queued messages, old links or other integrations until the responsible owners confirm they can be retired. Never undo a shared delegation or relax DMARC as a quick rollback.

Retain the approved packet, change history and sanitized acceptance evidence. Recheck the intended route after a signing-key rotation, domain change, relay reconfiguration or content-processing change. Review authorized aggregate reports over time; one successful message does not establish coverage for every application or future send.

Sources and documentation check

Splio’s Relay page displayed the relative label “Updated about 1 year ago”; no absolute native-page publication/update date was established. Those dates are distinct from this guide’s check date.

• Splio: SMTP Relay setup, operative native connection, domain handoff and launch sequence.
• Splio: understanding email authentication through DNS, Marketing Automation context, not a Relay record recipe.
• Splio: deliverability settings and 2FA, separate-product boundary.
• RFC 7208, RFC 6376, RFC 9989, RFC 9990 and RFC 8601, protocol and receiving-result rules.

This is a documentary setup guide. No customer account, DNS change, credential configuration or message delivery was performed to produce it.