WhatCounts Email Marketing SPF, DKIM and DMARC setup, step by step

WhatCounts documents a support-assisted authentication workflow: create the approved branded subdomain CNAME, request your domain-specific DKIM record, publish it, and ask the appropriate Onboarding Manager to verify DNS and configure the account's Base URL and Bounce Host. Then use the issued Bounce Address in the intended List settings and test that actual sending route. The standard and OSG CNAME targets differ; do not combine them. Standard DNS setup · OSG DNS setup

This guide covers those two documented native WhatCounts routes. It does not supply a universal DKIM key, a generic apex SPF include or permission to replace your mailbox service. Support-led issuance and activation are part of the procedure, not missing steps to improvise in DNS.

Choose the account route and approve the design

Confirm with your account owner or Onboarding Manager whether the standard or OSG instructions apply. Do not infer the branch from a screenshot or try both targets until one validates.

Both sources allow a subdomain name other than their illustrative response. Choose an unused, owner-approved name. This alias is used for branded tracking URLs and bounce handling, including processing replies. Obtain the routing owner's separate approval of the exact full owner and target and the intended bounce/reply handling before publication. Receiving a provider packet does not authorize redirecting an existing service or sharing replies with an unintended recipient. Standard scope · OSG scope

Preserve the approved DNS, sender, List and routing baseline. Identify the actual authoritative zone, existing selectors, NS delegations, direct and inherited DMARC policy, and other applications sharing these resources. No parent nameserver, mailbox MX, DNSSEC, credential or account-security change is part of this authentication recipe. The public procedures do not establish a universal plan or named in-app permission; coordinate with the people authorized for your account and DNS.

1. Publish only the approved branded CNAME

Create the CNAME at the selected unused subdomain, pointing to the target for the confirmed account branch. For a hypothetical approved response.example.com, a panel managing example.com generally takes relative owner response. If that full name is already a separately delegated zone, stop and coordinate its design: its apex NS/SOA requirements cannot simply be replaced by a CNAME.

At a CNAME owner, do not add TXT, A, AAAA, MX or another CNAME. Do not remove an existing delegation or production record to make a tutorial fit. Reconcile the complete proposed owner/target with the authorized design and compare it at authoritative and recursive DNS before provider activation. DNS aliases

Use DNS-only, not HTTP proxy or redirect, for these service aliases. Where WhatCounts needs a literal CNAME answer, turn a relevant per-record Flatten control off when available and ensure applicable whole-zone settings do not suppress it. Check mandatory apex and same-zone behavior too. If the DNS host cannot preserve the required literal answer, stop and coordinate a supported configuration rather than inventing a switch or disabling shared behavior globally. Cloudflare's specific controls are not universal DNS-panel labels. Cloudflare CNAME flattening

Read-only checks, with all uppercase placeholders replaced:

dig @AUTHORITATIVE-NS CNAME APPROVED-BRANDED-OWNER
dig @RECURSIVE-RESOLVER CNAME APPROVED-BRANDED-OWNER
dig @RECURSIVE-RESOLVER TXT RESOLVED-SPF-TARGET

Compare the full alias, not just whether a response exists. Inspect the target's applicable SPF data as part of authentication validation; do not assume the CNAME itself is a literal SPF TXT policy. Preserve exact account-approved routing, and stop if the observed target differs from the selected standard or OSG design.

2. Request and publish the domain-specific DKIM record

After the branded CNAME exists, request the DKIM record from WhatCounts. The official standard and OSG instructions show a TXT public-key record and state that WhatCounts sends the record with DNS instructions. Use your issued owner and complete public value, not the example key1 selector or sample RSA key. Do not generate an unrelated key or add DKIM CNAMEs from another platform's guide. Standard DKIM issuance · OSG DKIM issuance

Use the actual selector in these illustrative DNS-name mappings:

These rows explain authority and relative names; they do not authorize a new delegation or resolve a conflicting branded CNAME design. The DKIM selector is a separate full owner below _domainkey, not a TXT record placed on the branded CNAME owner itself. Preserve existing delegations and other selectors. If current records conflict with the issued packet, stop and have the DNS owner and Onboarding Manager reconcile them.

Keep the complete tagged TXT value intact. DNS providers may split long TXT data into multiple character strings within one record; that is different from publishing multiple competing DKIM records. If the UI truncates or rejects the supplied key, stop and use a provider-supported entry method with the DNS owner. Never shorten the key, change its cryptographic contents or publish a private key. DKIM key records

dig @AUTHORITATIVE-NS TXT ISSUED-DKIM-OWNER
dig @RECURSIVE-RESOLVER TXT ISSUED-DKIM-OWNER

Compare the full usable public key against the issued packet after accounting for normal TXT-string concatenation. Record existence alone does not prove that WhatCounts is signing with it.

3. Have the Onboarding Manager activate the account configuration

When DNS is ready, contact the branch-appropriate Onboarding Manager. The official sequence says the manager verifies the setup and performs the account configuration needed for a branded Base URL and Bounce Host. Wait for confirmation and the issued Bounce Address; do not infer account activation from a DNS checker. Standard provider handoff · OSG provider handoff

Ask the account owner to reconcile that confirmation with the approved sender domain, branded routing and reply-handling design. No unrequested sender change, account expansion, credential creation or forwarding change is implied by this handoff.

4. Configure the intended List with the issued addresses

After WhatCounts provides the Bounce Address, apply the approved List configuration for the actual campaign route. Keep the intended From address, Reply-to Address and Bounce Address distinct.

The documentation's literal ??EMAIL_REF?? token belongs only in a WhatCounts Bounce Address used in the Reply-To and Bounce Address fields. It is not a token to insert into the From address or an ordinary reply mailbox. Preserve the complete address issued for your account and validate its intended handling with the routing owner; do not copy the source's illustrative local part or malformed display-address punctuation as a working value. List configuration and token scope

Check that the actual List values match the approved full addresses and processing destinations before saving or activating them. A mailbox or domain merely existing is not approval for it to receive replies. Do not reuse this configuration automatically across unrelated Lists or sending identities.

Understand SPF and alignment before testing

The WhatCounts workflow uses the branded CNAME and provider-managed configuration for its documented authentication route. It does not give a universal apex TXT include to paste into every customer's DNS. SPF evaluates actual SMTP MAIL FROM, or HELO where relevant, not automatically visible From. Inspect the delivered route's envelope and the policy it resolves to.

If an independently approved change to an applicable SPF TXT owner is needed, keep one v=spf1 policy there, retain other legitimate authorizations and preserve intended qualifiers. Ten evaluated DNS-dependent terms include nested mechanisms/modifiers, not simply ten includes. An all mechanism causes redirect to be ignored. Do not alter an unrelated apex policy or promise inbox placement from an SPF qualifier. SPF evaluation

For an approved TXT policy at example.com, its full owner maps to the root field, often @, in that zone. For news.example.com, it maps to relative news in the parent or the root field in a separately delegated child zone. These are conditional owner examples, not extra TXT records to add to the branded CNAME owner.

5. Verify a controlled message from the actual List

After provider confirmation, send a controlled message through the actual approved WhatCounts workflow, using the unchanged intended From address and a valid test recipient. Do not substitute a message sent directly from your ordinary mailbox.

Establish the receiving service’s known processing boundary and its documented treatment of externally supplied Authentication-Results: removal, ignoring or clear separation from its own results. Use only results generated inside that trusted boundary. Header position or a familiar authserv-id string alone is not proof; an attacker can insert convincing-looking fields. If provenance is unclear, use an administrator-verified message trace instead. Authentication-Results trust model

Acceptance requires all of the following:

• The intended WhatCounts-issued signature matches the active configured d= signing domain and s= selector, and the trusted receiver reports dkim=pass for that signature.
• That signing domain aligns with the unchanged approved visible From domain under the effective adkim mode. A different aligned signer, a provider-rewritten From or SPF-only DMARC success does not complete WhatCounts branded DKIM setup.
• The trusted receiving system reports dmarc=pass for that intended From domain.
• SPF is checked separately against the actual smtp.mailfrom identity. Diagnose authorization fail or softfail, transient DNS temperror, and policy/duplicate-record/lookup-budget permerror separately even when aligned DKIM supplies DMARC’s pass.

Relaxed alignment permits matching Organizational Domains; strict alignment requires exact domain equality. Under aspf=s, a child envelope domain such as bounce.example.com does not align with From domain example.com, even if SPF passes. Under adkim=s, a child signing domain likewise does not align with its parent From domain. Use the issued and actually observed WhatCounts bounce identity. A branded child envelope does not guarantee strict alignment with a parent From domain. DMARC identifier alignment · Why a custom MAIL FROM affects SPF alignment

Preserve DMARC and approve reporting separately

Check both direct and applicable inherited policy before creating anything. Do not downgrade an existing policy, duplicate it, remove approved report destinations or automatically follow a generic progression to enforcement. A single passing WhatCounts sample does not inventory your other legitimate senders.

Only when no direct or applicable inherited policy exists, and the domain owner explicitly approves an initial monitoring policy with an appropriate review plan, this minimal TXT value can be considered:

v=DMARC1; p=none

For example.com, the full owner is _dmarc.example.com, relative _dmarc in the example.com zone. For news.example.com, the full owner is _dmarc.news.example.com, relative _dmarc.news in the parent zone or _dmarc in a separately delegated news.example.com zone. An explicit child policy can override inherited behavior, so do not add it casually. No reporting address is included in this example; an approved monitoring plan must still establish who reviews the relevant authentication evidence.

If reports are desired, use only an actually provisioned, owner-approved and monitored destination. When the report URI host’s Organizational Domain differs from the Organizational Domain of the domain where the DMARC policy was found, the report-generating receiver checks DNS authorization. A destination within that same Organizational Domain is excepted; a different hostname alone is not enough to require external authorization. This protocol check does not replace permission to share potentially sensitive report data with the recipient. RFC 9990, section 4

Troubleshooting and safe recovery

Preserve the prior approved DNS and List configuration before changes. Coordinate recovery with the account, routing and campaign owners; pause only affected sends if approved. Restore a known approved route only after checking current key, queued-message and shared tracking dependencies. Do not deliberately break authentication or use a real customer campaign to test. Retest the failed route and a known-good control with authorized recipients. Consent, working unsubscribe and appropriate launch/warm-up planning remain separate campaign-owner responsibilities.

Documentation review and testing boundary

Their captured bodies did not display a publication or update date. Record issuance, target differences, manager activation and List fields are established by the source text; no visual inspection of its illustrative Gmail-result screenshot is claimed. No account access, DNS edit, Support contact, test send, customer campaign or live deployment was performed.