Apsis SPF, DKIM and DMARC setup, step by step

For the standard APSIS One sending route, leave SPF to APSIS and configure DKIM for your own From domain. Give APSIS your domain and chosen selector, publish the public TXT key supplied by its Delivery team, then ask the team to activate signing. Finish by checking a delivered message for a passing, aligned signature from your intended domain. Publishing the key alone does not complete setup. APSIS One authentication documentation

This guide describes documented configuration and a verification procedure; no APSIS account, customer DNS records or delivered campaign was tested.

Confirm APSIS One rather than APSIS Pro

This guide covers APSIS One email sending, not every product sold under the APSIS brand. Record the account, From address, campaign or automation workflow, and each domain you intend to use. Repeat acceptance checks for distinct routes instead of assuming that a successful newsletter proves every automated message works.

APSIS One documents a technical sender under apsisone.com, including account-specific subdomains, with SPF managed by APSIS. Its published workflow does not require adding an APSIS SPF include to your own DNS. Customer-domain DKIM supplies the aligned authentication path. A separately arranged custom envelope configuration needs its own confirmed instructions. APSIS One: SPF and technical sender

APSIS Pro is different. Its current documentation describes provider-configured SPF for newsletters but says some reports or opt-in confirmations can use the customer's technical sender domain. It recommends include:_spf.anpdm.com for those circumstances. That is not a reason to add the include for the standard One route. Confirm the product and actual envelope identity before applying a Pro instruction. APSIS Pro authentication documentation

Understand which identity each check authenticates

A message has several domain identities. Keep them separate in your implementation worksheet:

SPF normally evaluates the SMTP MAIL FROM domain. Adding an include at example.com does not change a message's envelope domain and cannot make apsisone.com align with an unrelated example.com From address. A root-domain policy is not automatically inherited by its subdomains. SPF identity and record selection

DMARC requires at least one passing aligned path: SPF or DKIM. Relaxed alignment compares organizational domains; strict alignment requires exact domain equality. For example, d=news.example.com and From example.com can align under relaxed rules, but not strict adkim=s. Sharing a suffix such as .com is never enough. Current organizational-domain discovery follows the DMARC specification, not a simple last-two-label comparison. DMARC alignment

Prepare the domain, selector and DNS owner

Identify the authoritative DNS administrator before requesting the key. Save existing records and TTLs for the proposed selector, the From domain and its applicable DMARC policy. Choose a selector that is not already used by another signing service. The selector distinguishes keys; it does not select a mailbox or redirect replies.

Use the domain that must appear in the signature's d= value. If the visible From is news.example.com, do not silently request a key for example.com, particularly where strict alignment is required. Ask the service owner to confirm the intended signing identity before DNS publication.

The generic DKIM lookup structure is:

DKIM owner = SELECTOR._domainkey.SIGNING-DOMAIN
Example only: campaign2026._domainkey.news.example.com

campaign2026 is an illustration, not an APSIS-mandated selector. Replace it with the selected and confirmed value. DKIM is a digital signature, not encryption of email contents. Only public-key material belongs in public DNS. DKIM signing and DNS lookup

Publish the supplied TXT key and complete activation

APSIS One's documented process is assisted: provide the From domain and selector; the Delivery team generates the pair and supplies the public key; publish that key as TXT; notify APSIS; APSIS activates signing on its mail server. The private key remains with APSIS. Each sending domain needs its own key. APSIS One DKIM setup

Use this worksheet, not a copied key from another account:

DNS editors differ in whether they append the zone name. For the example owner above:

• In the example.com zone, a relative-name editor expects campaign2026._domainkey.news.
• In a separately hosted news.example.com zone, it expects campaign2026._domainkey.
• An editor accepting absolute names needs the complete owner. Verify its handling of the terminal dot.

Never enter the whole name into an editor that appends it again, producing ...example.com.example.com. If news.example.com is delegated, publish in the authoritative child zone, not an inactive copy under the parent. A pre-existing CNAME at the exact selector owner conflicts with adding TXT there; resolve the naming collision rather than deleting another service's record.

Also preserve an existing _domainkey.news.example.com NS delegation. In that delegated zone, the example TXT owner is just campaign2026; publish the supplied key with that zone's administrator, not in an inactive parent copy. Do not remove the delegation or change MX, forwarding or DNSSEC for this TXT-key setup. DNS zone boundaries.

APSIS documents 2048-bit keys. Long TXT values may be represented as adjacent strings within one DNS TXT record. A DNS character-string is limited to 255 octets; the complete record may contain several strings. Use the provider's supported editor format, retaining every character of the supplied key. Do not create two independent records, trim the key, or add spaces inside the p= value. DNS TXT format, DKIM TXT concatenation

APSIS allows up to 48 hours for DNS propagation in its current guidance. Treat that as a cache/visibility allowance, not a signing-activation deadline: a wrong owner or incomplete key will not repair itself with time, and the Delivery team must still activate signing. APSIS publication and activation steps

Record the activation time and domain scope. During rotation, retain the old selector until the old signing route has stopped and the service owner has considered queued messages. A new key being visible is not a reason to remove every old selector.

Verify public DNS before testing mail

The following commands are read-only examples. Substitute your actual domain, selector and authoritative server. The example.com names do not represent a tested account.

# Identify the DNS authority, including any child-zone delegation.
dig +short NS example.com
dig +short NS news.example.com

# Ask the authoritative server for the exact selector owner.
dig @AUTHORITATIVE-NS campaign2026._domainkey.news.example.com TXT +noall +answer

# Compare a recursive answer after cached records have expired.
dig campaign2026._domainkey.news.example.com TXT +noall +answer

# Inspect the From-domain policy and any applicable parent policy.
dig _dmarc.news.example.com TXT +noall +answer
dig _dmarc.example.com TXT +noall +answer

Expect the complete issued key at the intended owner. Adjacent quoted strings returned by dig can belong to one TXT record; compare their concatenated content. An empty answer is not a successful test. Check the question name, authority, DNS response status and any CNAME, rather than assuming every missing answer is propagation. NXDOMAIN means the queried name does not exist in that answer; SERVFAIL warrants DNS/DNSSEC investigation.

A DNS-only DKIM checker can confirm key visibility and syntax. It cannot prove that APSIS is using the matching private key or that your campaign carries the intended signature. For an unknown selector, use a real message and the DKIM selector identification guide.

Accept the route only after a delivered-message check

After activation, use an authorized test recipient and the actual workflow being released. Open the original message or source at the receiving mailbox. Read the receiving system's trusted Authentication-Results, not an arbitrary similarly named header further down the message. Authentication-Results trust boundary

Establish which results were generated inside the receiving service's known processing boundary and how that service removes, ignores or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving-mail administrator to confirm the boundary. A familiar authserv-id string or header position alone is not proof. Reject attacker-supplied or otherwise untrusted fields; obtain the receiver's own diagnostic evidence when provenance is uncertain. Operational receiving-result trust.

Keep a small evidence record: date, route, From domain, envelope domain, every DKIM d=/s=, the receiver's individual results, and the effective DMARC alignment mode. Redact recipient details before sharing diagnostics outside your organization.

A fictional standard-route result might look like this:

From domain: news.example.com
SPF: pass for an account-specific domain under apsisone.com
DKIM: pass; d=news.example.com; s=campaign2026
DMARC: pass for news.example.com through aligned DKIM

This is an explanation, not a real header or a guaranteed APSIS identifier. It shows why provider-domain SPF can pass while remaining unaligned with the brand.

Accept the DKIM setup only when the intended branded signature both passes and aligns, the provider has confirmed activation, and DMARC passes under the effective policy. Do not accept a passing provider signature, or a DMARC pass obtained through some other path, as proof that your new branded key works.

The received From must remain the approved APSIS One brand identity. A rewritten provider From or an unrelated passing signature does not complete this custom-domain setup.

Also expect SPF to pass on a direct, unforwarded test. A pass with an unrelated provider domain is an alignment limitation, not an SPF error. An actual fail, softfail, permerror, temperror, or unexpected none requires investigation. For the provider-owned envelope, send the redacted header, time and route to APSIS support through your approved process. Do not repair APSIS-owned SPF by changing your apex record. Compare a direct sample with a forwarded sample before blaming the original sender; forwarding can change the connecting IP. SPF result definitions

Preserve DMARC protection and collect reports

Inspect the From domain's direct policy and any policy it inherits before creating a record. Do not replace established p=quarantine or p=reject, change alignment modes, or override a parent's protection with a child p=none merely to complete onboarding.

For an approved new monitoring deployment with no existing applicable policy, this is an example only:

Owner: _dmarc.news.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Use an authorized, monitored report destination, not the example mailbox. Publish one DMARC policy at the owner. p=none requests monitoring rather than DMARC-based quarantine or rejection; it does not turn failures into passes or guarantee delivery. DMARC policy, aggregate reporting

For the example full policy owner _dmarc.news.example.com, enter _dmarc.news in the parent example.com zone or _dmarc in a separately delegated news.example.com zone. For root From example.com, the full owner is _dmarc.example.com and the relative owner is _dmarc. Use the complete owner only in a field that accepts full names; preserve the existing authority and policy.

Compare the Organizational Domain of the aggregate-report URI's host with the Organizational Domain of the domain where the DMARC policy was found, which is not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as the policy domain is excepted; a different hostname alone does not make it external. Follow the reporting service's exact authorization instructions when needed. This protocol check is separate from the domain owner's approval to share report data with that recipient. RFC 9990 section 4.

Review aggregate reports for unexpected senders, signature domains and failures over normal campaign cycles. Include employee email, CRM, billing and other applications before tightening policy. RFC 9989 requires valid DKIM for domains publishing p=reject and highlights forwarding/list interoperability risks. It also removes the legacy pct tag; do not make a new rollout depend on that tag. The DMARC reporting guide explains how to separate raw authentication from aligned results.

Troubleshoot the failure you actually observed