Provider documentation checked on 8 November 2026. Account-specific values, current product scope and provider activation remain deployment prerequisites.
Scope the guide to Apsis One
References: RFC 9989 §4.4.
The source for this guide is the Apsis One email-authentication article. It says the technical sender domain is apsisone.com, with SPF already configured in Apsis DNS, while the visible From domain belongs to the customer and is authorized through DKIM. Therefore the documented route requires no Apsis SPF addition to your own DNS. This is not a claim about every legacy Apsis product or an account with a separately negotiated custom envelope route.
For the documented default route, SPF passing for apsisone.com does not align with an unrelated customer From domain. Customer-domain DKIM is the route's documented DMARC path. Identify every From domain used by campaigns and assign a marketing owner, a DNS administrator and an Apsis contact. The owner approves which brands/domains may send, the DNS administrator publishes public-key records, and the Apsis Delivery team generates keys and activates signing. A DNS update alone is not the final activation step.
Publish the key and complete activation
References: RFC 6376 §3.6.2.2, RFC 1035 §3.3.14.
- Give your Apsis Consultant or Delivery team the From domain and the selector you propose to use. Choose a selector that does not collide with another active service or key at that domain. Do not invent a private key or request that it be sent to you.
- Apsis generates the key pair and supplies the public key. Publish its supplied TXT value at the exact owner name, conventionally selector._domainkey.your-domain. These words describe the structure, not literal values to paste into DNS.
- Verify how your DNS provider accepts long TXT data. A TXT resource record can contain multiple character strings; each is limited to 255 octets. Apsis documents 2048-bit keys and splitting the value across strings. Preserve the complete key within one TXT record, using the DNS provider's supported entry format, rather than creating multiple independent key records or inserting spaces into the key material.
- Check the authoritative answer against the supplied public key, then tell Apsis that publication is complete. Apsis must activate DKIM signing on its mail transfer agent. Record the team's confirmation and the activation time.
- Repeat for every sending domain. The Apsis guide calls for a separate key per domain. Verify each domain with a fresh campaign test after activation rather than reusing one brand's evidence to approve another.
Separate provider guidance from protocol guarantees
References: RFC 9989 §5.3.5, RFC 9989 §5.3.6.
The Apsis article emphasizes that DKIM is essential for its default route and warns about tightening DMARC before setup. Follow that operational dependency, but do not turn it into a claim that DMARC universally requires both SPF and DKIM. RFC 9989 defines acceptance through an aligned passing SPF or DKIM path. Nor does p=none guarantee delivery, or p=reject guarantee that every receiver rejects every failing message: local handling and other filtering can apply.
If signing is missing after Apsis confirms activation, confirm the exact campaign/account, From domain and selected route with the Delivery team. If the signature is present but fails, compare d= and s= with the published owner, check that the key is complete and confirm that the provider has not rotated it. A successful online key lookup is useful but does not establish that the production message carries that signature. Do not add Apsis to a customer-domain SPF record to repair this documented unaligned-envelope route; first fix the domain's DKIM setup and activation.
Provider procedure and scope: Apsis One email authentication and safe sending.
Verify the message, not only the DNS
References: RFC 9989 §4.4, RFC 6376 §6.
Use a controlled recipient you administer and send through the exact production workflow. Preserve the raw message and trusted receiving system's Authentication-Results, together with the workflow, sending domain, timestamp and account identifier. A green DNS result proves record visibility, not that the service signed this message or that the receiver accepted an aligned identity. No live account, DNS lookup or received message has been tested for this guide; the following is a collection worksheet, not a claimed successful result.
- Visible RFC5322.From domain: Is this the intended customer-facing identity?
- Envelope/Return-Path and receiver SPF result: Which domain did the receiver actually evaluate, and did it pass?
- Every DKIM signature's d= and s=: Which signing domain and selector were used, and which signature passed?
- Receiver DMARC result and evaluated policy: Does a passing SPF or DKIM identity align with the From domain?
- Workflow, timestamp and raw message: Can another administrator reproduce and review the exact route?
SPF authenticates the envelope identity, not simply the visible From address. DKIM verifies a signature associated with its d= domain; it does not encrypt the message. DMARC needs at least one passing, aligned authentication path. Under strict alignment, the relevant domains must match exactly; relaxed alignment follows the organizational-domain rules in RFC 9989. Do not infer alignment from a provider-domain SPF pass or from an unrelated passing DKIM signature. Use the receiver's trusted results rather than arbitrary Authentication-Results headers carried inside the message.
Release, troubleshoot and recover
References: RFC 7208 §4.6.4.
Before making changes, record the current DNS values, TTLs, sender settings and a named rollback owner. Check authoritative DNS first, then a recursive resolver after relevant cached data expires. A missing record can mean an incorrect owner name, a duplicated domain suffix, the wrong authoritative zone or a stale cache. Never create a second SPF policy at the same owner name. When editing an existing policy, preserve legitimate senders and evaluate the complete nested lookup budget against RFC 7208’s ten-term limit for evaluated include, a, mx, ptr, exists and redirect terms, including nested processing. This is not a simple count of visible includes or raw DNS packets.
If DKIM passes but DMARC fails, compare the passing d= domain with the actual From domain and the published alignment mode. If DKIM is absent, investigate provider activation and route selection before repeatedly replacing the key. If authentication passes but delivery remains poor, inspect rejection responses, suppression state, reputation and recipient filtering separately. Authentication is not an inbox-placement guarantee, and a DMARC policy expresses requested handling rather than a promise of every receiver's decision.
Do not tighten the whole domain's DMARC policy based on this one integration. Inventory and verify other legitimate senders first. Release only after the DNS owner and service owner review a fresh message for every intended route. If the change fails, pause the affected flow or return to a previously tested supported route; restore only the records changed in this operation. Keep old selectors during a planned rotation until the old route has stopped signing and queued mail has been considered. Remove retired provider permissions only after confirming that no other active application depends on them.