Swift Digital SPF, DKIM and DMARC setup, step by step

In Swift Digital Suite, an administrator adds a sending domain under Administration → Account Settings → Domains, verifies ownership and opens its Deliverability setup instructions. Publish the domain-specific records, configure the approved custom return path, then test a controlled message through Email Composer. A verified domain or green DNS status is not by itself proof of aligned DKIM on delivered mail. Current Suite setup procedure.

On this page

• Scope and preparation
• Add and verify the sending domain
• Obtain the complete DNS instructions
• Publish both DKIM aliases at the right owners
• Configure SPF and the custom return path
• Handle DMARC separately
• Verify DNS and a controlled delivered message
• Troubleshooting and recovery
• Frequently asked questions
• Sources and verification limits

Scope and preparation

This guide covers the current Swift Digital Suite sending-domain workflow, including the two DKIM selectors and custom return path shown in its official instructions. It is not a generic Swift-branded product guide, a mailbox-hosting setup or a reason to replace an existing older selector. The public instructions require Suite administrator access and authority to modify the sending domain’s DNS. They do not establish universal plan or regional availability for every account.

Coordinate the domain owner, DNS administrator, Suite administrator and campaign owner. Choose an owned or controlled sending domain that matches the intended From address. A branded account-interface subdomain is a separate setting from sending-domain authentication. Do not change that interface route, parent nameservers, DNSSEC, credentials or employee-mail MX records as a side effect of this process.

Before starting, save existing sender identities, direct and inherited DMARC policy, SPF authorizations, DKIM selectors, DNS delegations and bounce routing. Check whether proposed names already serve another system. Record an owner-approved recovery plan, including queued campaigns and shared key dependencies.

Add and verify the sending domain

1. As a Suite administrator, open Administration → Account Settings → Domains.
2. Choose Add New Sending Domain, enter the approved domain and select Save Sending Domain.
3. Use the ? in its Verified column. Choose one of the documented ownership-verification methods, not both by default.

For DNS verification, select Generate DNS Token, publish the exact generated TXT at the indicated domain owner, compare the public answer with that token, and choose Check DNS & Verify. The verification TXT is distinct from an SPF policy. A domain such as news.example.com uses relative name news in the parent zone or the DNS host’s apex convention, often @ or blank, in a delegated news.example.com zone. If the full owner is example.com, use the documented apex input in that zone.

Alternatively, enter the authorized address in Email Verification, choose Send Verification Email, and use the expected Verify sending domain link from the matching request. Do not reuse a screenshot link or forward it to another service. No email request, token publication or verification was performed for this article. Ownership-verification steps.

Obtain the complete DNS instructions

Use the Info icon in the domain’s Deliverability setup instructions column. The modal contains its records; Download PDF supplies a copy for the authorized IT team. Copy the actual account instructions rather than another account’s screenshot.

The official illustrated configuration includes:

• Two DKIM CNAMEs, with selectors dkim1 and dkim2.
• SPF authorization using include:spf.swiftdigital.com.au at the specified sending-domain owner.
• DMARC at the sending domain’s _dmarc owner.
• A custom-return-path owner with an MX destination and a separate SPF TXT policy.

The illustrated DKIM targets are dkim1.swiftdigital.com.au and dkim2.swiftdigital.com.au. Treat these as the documented illustration and confirm your current packet before publication. Its note says to keep an existing plg selector active for older domains. Do not delete it just because new selectors are available; resolve any missing legacy instructions with verified Swift Digital Support. Actual setup modal.

The setup prose broadly mentions CNAME/TXT for custom return paths, but the decisive record table and linked test procedure specify MX plus TXT for the illustrated route. Follow the complete current account packet, not a guessed alias. The screenshot does not show an MX priority: obtain the required priority from the actual account instructions or Support before publishing; do not invent one.

Publish both DKIM aliases at the right owners

For a sending domain news.example.com, the illustrated full owners are:

dkim1._domainkey.news.example.com
dkim2._domainkey.news.example.com

In the parent example.com zone, their relative names are dkim1._domainkey.news and dkim2._domainkey.news. In a separately delegated news.example.com zone, use dkim1._domainkey and dkim2._domainkey. If _domainkey.news.example.com itself is delegated, its administrator publishes relative owners dkim1 and dkim2. For an apex sender example.com, use dkim1._domainkey and dkim2._domainkey in that parent zone.

Check the resulting full names so a DNS interface does not append the zone twice. Preserve NS delegations and existing shared selectors. At each CNAME owner, resolve conflicting TXT, A, AAAA, MX or other CNAME records rather than stacking incompatible records or deleting an unrelated service. Do not paste a TXT key beside the alias, generate an unrelated signing key or disclose private keys.

Use DNS-only where the DNS host offers HTTP proxying. If validation requires literal CNAME answers, turn the relevant per-record Flatten control off when available and ensure applicable zone-wide settings do not suppress those aliases. Cloudflare has separate apex and same-zone behavior. Do not globally change shared settings without reviewing consequences; where mandatory behavior cannot preserve the required answer, stop and coordinate a supported design. Cloudflare’s exact flattening setup reference.

Configure SPF and the custom return path

SPF checks the actual SMTP MAIL FROM identity, or the relevant HELO identity in cases such as a null reverse path, not automatically the visible From address. Swift Digital’s documented custom return path makes the bounce identity configurable; publishing the sending-domain SPF does not prove that the actual envelope identity is aligned. SPF identities.

The official sample uses v=spf1 include:spf.swiftdigital.com.au ~all. At each required owner, integrate the required authorization into the one existing SPF policy while preserving legitimate senders and intentional qualifiers. Do not create duplicate SPF, replace an established policy blindly, or add TXT beside a CNAME. Other unrelated verification TXT records can remain.

Map a full SPF owner example.com to the DNS host’s documented apex input in that zone. For news.example.com, use news in the parent zone or the apex input in its delegated child zone. For bouncer.news.example.com, use bouncer.news in the parent zone or bouncer in the news.example.com child zone.

Count all evaluated DNS-dependent terms, including nested evaluation, against the limit of ten, not simply ten includes. Preserve the intended policy structure: do not append mechanisms after terminal all; redirect is ignored when all is present. SPF qualifiers do not guarantee final delivery decisions. Lookup limits, redirect processing.

For the custom return path, choose a dedicated unused owner approved by the routing administrator. The illustrated bouncer.news.example.com pattern is a child of the sending domain. Compare the exact MX owner, priority and destination with the authorized routing plan before publishing. The example destination is bouncer.swiftdigital.com.au, but the complete actual packet governs. Do not replace apex MX or existing bounce handling just to match the example. Publish its separate required SPF TXT as well. Current record table, official return-path tests.

After the DNS work, choose Done to refresh the domain list and inspect the individual DKIM1, DKIM2, SPF and DMARC statuses. Open the sending domain’s edit modal, enter the exact approved custom return path, and select Save Sending Domain. Confirm the saved value appears in the list. A green ownership check is not a substitute for these deliverability checks. Return-path edit panel.

Handle DMARC separately

Inspect direct and applicable inherited policies before creating anything. Retain existing enforcement, alignment modes and approved report destinations. The Suite screenshot’s strict quarantine example is not a safe universal default, and the prose’s monitoring example is not a reason to downgrade existing protection.

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 Swift Digital. 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.

Verify DNS and a controlled delivered message

Compare actual authoritative answers and a public resolver with the approved full packet. These are placeholder commands, not successful results:

dig @AUTHORITATIVE-NS CNAME dkim1._domainkey.news.example.com
dig @PUBLIC-RESOLVER-IP CNAME dkim2._domainkey.news.example.com
dig @PUBLIC-RESOLVER-IP TXT ACCOUNT-ISSUED-DKIM-TARGET
dig @PUBLIC-RESOLVER-IP TXT news.example.com
dig @PUBLIC-RESOLVER-IP MX bouncer.news.example.com
dig @PUBLIC-RESOLVER-IP TXT bouncer.news.example.com
dig @PUBLIC-RESOLVER-IP TXT _dmarc.news.example.com

Replace the authoritative server, resolver address, owners and DKIM target with the real values. Query both selectors through both authoritative and recursive resolution when troubleshooting. Follow each alias to a usable DKIM public-key TXT, not merely a present CNAME. Compare the bounce MX’s exact priority/destination and its SPF separately. The vendor allows 24–48 hours for propagation, but incorrect owners or conflicts need correction, not just waiting. Official DNS and message tests.

For a controlled test, the authorized operator opens Email Composer, creates harmless test content, chooses Publish, sets the intended domain’s From address and selects a controlled valid recipient. The final Publish sends the message: inspect its audience before proceeding and never use the tutorial’s example recipient. Open the original received headers, using Show original where available. Test every intended sender and real production route; one Composer test does not prove all automation/API paths. No live send was performed here.

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 Swift Digital 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

Verified is checked but DKIM is not: ownership verification and authentication records are separate. Inspect the domain-specific delivery instructions, both selectors, exact DNS owners and targets, delegation, proxy and flattening behavior. Do not remove a working legacy plg selector to force a new green status.

DNS passes but the intended signature is absent: confirm the actual From domain selected in Composer and the saved domain configuration. Preserve the evidence and ask verified Support to resolve the mismatch; do not invent a signing toggle or accept a provider-owned From rewrite as branded success.

SPF fails or errors: identify the actual MAIL FROM and the policy evaluated for it. A fail differs from transient temperror and persistent permerror, such as invalid syntax, multiple policies or an exceeded lookup budget. Investigate each even if DKIM supplied DMARC pass. SPF result definitions.

A custom return path does not strictly align: bouncer.news.example.com is not identical to news.example.com. Do not copy aspf=s from the screenshot expecting that child to supply strict SPF alignment. Assess the actual passing DKIM signature and policy before changing alignment modes.

A change disrupts mail or campaigns: with the affected owners’ approval, pause only the affected campaign/route and restore the known-good approved configuration. Preserve queued-message keys and shared SPF/selector dependencies. Keep a failed sample and retest the failed path plus a known-good path after recovery. Never weaken DMARC or reroute unrelated mail as a shortcut.

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

Sources and verification limits

The full current Suite setup and test articles were read, along with the actual record-table and custom-return-path edit images. Those are source labels, not dates of customer implementation.

No account operation, DNS mutation, verification email, message send, live mailbox test, CMS visual rendering or publication was performed. Current account entitlements, generated values, MX priority, existing-route dependencies and actual signing remain implementation checks. The instructions are not an inbox-placement guarantee.