Source review dated 8 November 2026. This is documentary guidance; account, DNS and received-message acceptance tests below have not been executed.
Resolve the published-record risks first
inwise documents a campaign-domain workflow covering ownership verification, SPF, DKIM and sender-address selection. Its public SPF example joins the include domain directly to -all without a separating space. Treat that example as a documentation defect, not a production-ready value. Its DKIM section also publishes a static public key. Confirm the account's current selector and key with inwise before deploying that historical example. inwise domain authentication.
This guide covers campaigns sent from a customer domain in inwise. It does not establish the same records for an on-premises installation, separate transactional service or custom Return-Path capability. Record the account, campaign workflow, intended From address and existing sender profiles. Name a campaign owner and a DNS administrator, and preserve the current working configuration.
Create a brief approval worksheet before making changes. It should identify which zone will be edited, which existing records must remain, the provider-approved values and the test that will determine success. Record unresolved details as questions for the provider instead of filling them with plausible-looking DNS values.
Verify ownership and obtain current signing details
The documented path is Account Settings > Email Sending > Domain Authentication. Add the domain, provide the verification mailbox and complete the emailed code check. After successful record validation, update the sender address and choose it in the relevant sending profile or campaign. The published DKIM design uses a TXT record with selector idk; confirm that it remains the account's approved design. Domain setup and sender selection.
Mailbox verification establishes access to that mailbox. It does not establish that the outgoing server is signing with the expected key or that receivers accept its messages. Keep the verification step separate from DNS evidence and the final delivery test.
For DKIM, obtain the complete owner, record type, key value and activation requirements. Confirm how the DNS host handles relative names and long TXT content. A copied example domain, truncated key or accidental line-break character can invalidate the intended record. Do not overwrite an existing selector until its owner and dependent sending flows are understood.
Correct SPF syntax without replacing other senders
The documented authorization is include:spf.inwise.com. Reconcile that mechanism into the applicable existing SPF policy, with whitespace separating mechanisms, rather than publishing the malformed full example or creating a second SPF record. Retain the domain's approved terminal policy and other legitimate senders. inwise SPF instructions and SPF syntax.
For clarity, include:spf.inwise.com and -all are separate SPF terms. Their concatenation is not an equivalent policy. A correctly formatted include still needs review: nested lookups count toward SPF's DNS-querying-term limit, and authorization belongs at the domain actually evaluated for SPF. Check the complete record rather than judging one added fragment in isolation.
The public setup does not demonstrate the envelope identity of a live campaign. Inspect the delivered Return-Path and receiver SPF identity before claiming SPF alignment. DKIM's d= domain provides another possible alignment path. DMARC compares a passing authentication domain with the visible From domain according to the applicable alignment mode. DKIM and DMARC.
Manage DMARC as a domain-wide control. Inventory employee mail, transactional messages and other campaign systems before increasing enforcement. Avoid weakening a working policy solely because a new service has not been configured correctly. A passing authentication result also does not guarantee inbox placement; recipient preferences and other filtering decisions still matter.
Verify the selected campaign sender
Original acceptance plan: after the account's record checks succeed, send a harmless campaign to controlled external recipients using the exact profile intended for production. Record the workflow, time, visible From domain, Return-Path, trusted SPF identity and result, all DKIM d=/s= pairs and trusted DMARC result. Verify the reply destination and retain the message source securely.
Compare the observations with the approved configuration. If a campaign uses an old sender profile, correct the profile before changing DNS again. If the receiver cannot find a DKIM key, inspect the observed selector and published owner. If SPF errors, check record duplication, whitespace and lookup cost. If authentication passes but DMARC fails, investigate alignment rather than randomly replacing keys.
Pause the new sender rollout on failure and restore only the changes made for this deployment. No live inwise account, DNS publication or received campaign was tested. Current key confirmation, envelope behavior, end-to-end evidence and human SME approval remain necessary before production acceptance.