Begin with the client domain, not a copied record
Instiller's agency-oriented sending model makes domain ownership a practical deployment concern. Its acceptable-use policy requires SPF and DKIM and calls for custom sending and click domains for each client. Authentication work should therefore start with a named client, sending domain and responsible DNS administrator, rather than an agency-wide example copied into every zone. Instiller sending requirements.
This guide covers email campaigns sent through Instiller. It does not establish an identical setup for every white-label deployment, transactional integration or custom envelope option. Capture the existing From address, sending workflow, click-tracking domain and known bounce handling. These identities may serve different purposes; a working tracking hostname is not proof that the message itself is authenticated.
Ask the provider managing the account to confirm the full record set and the intended signing and envelope domains. Save that response with the planned change. If the DNS is owned by the client, agree a maintenance window and avoid accepting a screenshot of an unsaved editor as completion evidence.
Obtain and publish DKIM deliberately
Instiller's DKIM article tells hosted-service users to obtain the required public key from their provider. It describes TXT records beneath the selector's _domainkey name and distinguishes root-domain and subdomain placement. It does not give a universal account selector or a complete production key for every customer. Instiller DKIM guidance.
Request the selector, full owner, record type, complete public-key value, activation requirement and rotation procedure. Publish only the public material supplied for the approved domain. Do not generate a replacement key locally unless the provider specifically supports that workflow: a new public key is useless if the sending service still signs with a different private key.
Before publishing, check existing records at the selector name and determine how the DNS host represents long TXT data. Ensure that the final DNS answer preserves the entire key without inserting unintended characters. The public article discusses older key-size and rotation guidance; ask for the account's current supported settings rather than treating those historical statements as a modern security baseline. DKIM record guidance.
Reconcile SPF and DMARC for the actual route
The first-party SPF article says the policy depends on the sending IP ranges and labels its record as an example. Obtain the current authorization for this account instead of publishing the example address range. Keep one SPF policy at each relevant owner and preserve other legitimate senders. Instiller SPF guidance.
SPF is checked against the SMTP envelope identity. Ask explicitly whether the intended campaign uses the client domain, a client subdomain or a provider domain there; the retrieved public setup does not prove that choice for a live account. Account-specific confirmation is especially important when a partner operates the service or several client domains coexist.
DMARC evaluates whether a passing SPF or DKIM domain aligns with the visible From domain. Both technologies can pass while neither aligns. Conversely, one aligned passing path can satisfy DMARC, even though Instiller separately requires both technologies operationally. Its bulk-sender guidance also identifies alignment and a DMARC policy as requirements. Instiller bulk-sender guidance and DMARC.
Plan enforcement across every legitimate sender using the domain. A new campaign integration does not justify replacing an existing quarantine or reject policy with monitoring, nor does successful DNS publication justify raising enforcement without reviewing other mail sources.
Accept the campaign with message evidence
Original test plan: send a small, harmless campaign through the exact client workflow to controlled external recipients. Capture the time, client account, From domain, Return-Path, trusted SPF identity and result, all DKIM d=/s= pairs, and trusted DMARC result. Compare those observations with the provider's promised configuration. Confirm that reply and bounce handling still reach their intended destinations.
If the key is not found, check selector spelling, subdomain placement and public DNS answers. If the signature fails, involve the provider with a redacted message source rather than replacing arbitrary keys. If authentication passes but alignment fails, ask which supported identity setting must change. Pause the new client sender until the cause is understood, retaining the previous approved configuration for rollback.
No live Instiller account, DNS publication or campaign was tested. Current account-specific records, envelope behavior and end-to-end results remain evidence gaps, with human SME approval still required.
Hand off one client record at a time
Use a separate proposed acceptance card for each client: provider contact, sending domain, issued selector and key, SPF owner and authorization, expected envelope, activation requirement and test workflow. Record promised identities separately from observed ones. A missing provider response leaves the affected client on hold; it does not justify borrowing another client’s key or broadening shared SPF. No card is completed for a real account in this article.