Centercode SPF, DKIM and DMARC setup, step by step

Centercode requires SPF authorization when its platform sends on behalf of your domain. Its documented infrastructure include is include:_spf.centercode.com; implementation-specific IP authorization is an alternative arranged with Support. DKIM is separately requested from Centercode, which supplies your public key for a cc._domainkey TXT record. After publication, confirm signing with Support and verify the actual message identities at a recipient. An SPF record alone does not establish DMARC alignment. Centercode’s technical guide

This guide covers mail sent by the Centercode platform using your organization’s domain. The official technical instructions apply to all editions. It does not configure your normal employee mailbox or an unrelated external mail service. No customer account, DNS configuration or delivered message was tested for this article.

Establish the domain and infrastructure before changing DNS

Write down the visible From address for each Centercode sending workflow you use, the domain your IT team will authorize, and the Centercode implementation involved. Do not assume your community’s website hostname is also its email domain. A site at beta.example.com could send from community@example.com or from a separate subdomain.

Have the following ready:

• A Centercode administrator who can identify the implementation and contact its Support team.
• The DNS administrator for each actual sending domain, including delegated subdomains.
• An export of the existing SPF, DKIM and DMARC records, with record owners, values and TTLs.
• A list of other legitimate services using those domains and a change window with a recovery owner.
• A controlled recipient mailbox for a later authorized message check.

Choose one authorization model deliberately. Centercode’s shared include follows its published infrastructure. The support-issued IP alternative narrows authorization to your implementation, but creates a maintenance obligation when the implementation moves. Do not substitute IPs found in a search result, another customer’s message or an old screenshot. Centercode’s infrastructure alternatives

Configure Centercode SPF without replacing existing senders

Understand what the include authorizes

The provider’s full example is:

v=spf1 mx include:_spf.centercode.com ~all

This is a provider example, not a replacement for every organization’s existing record. The Centercode-specific authorization is include:_spf.centercode.com. The mx mechanism additionally authorizes addresses associated with the domain’s mail exchangers; it is not required by SPF merely because a domain receives email. Keep or introduce it only when it matches your approved outbound architecture. Likewise, do not change an established -all to ~all just to match an example. Provider example, SPF mechanisms and qualifiers

SPF checks the connecting mail server against the domain used in SMTP MAIL FROM, normally exposed as the Return-Path after delivery. It does not authenticate the display name or visible From address. For a null reverse-path, SPF uses the HELO identity. Ask Centercode to confirm the envelope domain for your implementation, then compare it with the receiver’s smtp.mailfrom result. Publishing authorization at a visible From domain does not force Centercode to use that domain as its envelope sender. SPF identities

Merge the authorization safely

1. Find the authoritative DNS zone, not simply the registrar where the domain was purchased.
2. Look up the TXT records at the domain Centercode instructs you to authorize. Preserve unrelated verification TXT records.
3. If an SPF policy already exists, add the approved Centercode mechanism to that same policy before the final all. Preserve the other senders and intended qualifier.
4. If no SPF policy exists, inventory the domain’s legitimate envelope senders before creating one. Do not assume Centercode is its only sender.
5. Validate the resulting complete policy, including nested includes and any existing redirect= behavior. Do not make a mechanical merge into a redirect-based policy without reviewing its semantics. If any all mechanism is present, redirect is ignored regardless of its position; mechanisms after all are never tested. SPF all processing
6. Publish one SPF policy at that owner, then query public DNS and test a message later.

Illustration only, for a domain that already authorizes the example address and whose approved policy ends in -all:

Before: v=spf1 ip4:192.0.2.20 -all
After: v=spf1 ip4:192.0.2.20 include:_spf.centercode.com -all

192.0.2.20 is a documentation address, not a Centercode server. Never publish it as a real authorization.

A DNS owner must not publish multiple records beginning v=spf1. SPF also limits evaluation to ten DNS-lookup-causing terms, including nested include, a, mx, exists, ptr and redirect processing. It is not a ten-vendor allowance. A record can look short and still exceed the limit. SPF record selection and lookup limits

If IT chooses implementation-specific IPs

Request the current address or range through the chat inside your Centercode implementation or help@centercode.com. Confirm which workflows and infrastructure it covers, who will notify you of a move, and how overlap during a migration will be handled. Record the maintenance owner. Centercode explicitly warns that an infrastructure upgrade can require replacing the authorized IP. Do not manually flatten the shared include once and assume the result will stay current. Centercode service IP guidance

Request and publish Centercode DKIM

Centercode calls DKIM optional and available on request. That describes its setup process, not a promise that SPF-only mail satisfies your receiver requirements or security policy. For branded sending, configure and validate the intended aligned signature rather than relying on an accidental SPF-only DMARC pass.

1. Contact Centercode Support through the implementation’s chat or help@centercode.com. Identify the implementation and exact From domain. Ask for the public key, full DNS owner, signing domain, selector and any activation step for that implementation.
2. Receive the public key from Centercode IT. The documented selector is cc; the final key is customer-specific.
3. Publish the supplied public key as a TXT record at the specified owner. For example.com, the documented structure is:

Type: TXT
Owner: cc._domainkey.example.com
Value: v=DKIM1; k=rsa; p=PUBLIC_KEY_SUPPLIED_BY_CENTERCODE

4. Replace the placeholder with the complete supplied public key. Do not include angle brackets or literal explanatory quote marks around the key. Do not generate a different key independently: Centercode must hold the corresponding signing key.
5. Check the resulting public TXT record. If your DNS host splits a long value into quoted character strings, those strings must concatenate into the intended single record without missing characters or inserted whitespace, rather than being published as multiple independent keys. DKIM TXT storage
6. Ask Support to confirm that the domain and selector are enabled for your implementation, then verify a new message. The public guide does not name a self-service activation button or state that DNS publication alone switches signing on.

The provider establishes the support-led key workflow; the public/private-key relationship and selector lookup follow the DKIM standard. Centercode DKIM instructions, DKIM key retrieval

Before adding the record, inspect cc._domainkey for an existing key or CNAME. Do not overwrite a selector another live sender uses. Ask Support for a coordinated solution if there is a collision. DNS interfaces may append the zone name automatically: enter cc._domainkey in such an interface, not a name that becomes cc._domainkey.example.com.example.com. Publish public DNS material only; never put private signing keys or account credentials in DNS.

For an approved signing domain mail.example.com, the full documented-selector owner is cc._domainkey.mail.example.com. Map that full name to the zone actually authoritative for it:

These are name translations, not account-issued keys. An editor requiring a full name must produce that same full owner without doubling the suffix. Preserve existing NS delegations, selectors and shared dependencies; do not publish an inactive parent-zone copy or remove a delegation to bypass it. Do not change MX, parent nameservers or DNSSEC as a side effect. A TXT record cannot coexist with a CNAME at the same owner. The native Centercode route here is TXT; an alternate record type requires specific supported instructions, not a guessed alias.

Keep DMARC under the domain owner’s control

DMARC connects the visible From domain with an authenticated identifier. A message passes when at least one of these paths passes and aligns:

• SPF passes for an envelope domain aligned with the From domain.
• DKIM passes for a signing domain, the signature’s d=, aligned with the From domain.

Relaxed alignment, the default when the relevant tag is absent, permits the same organizational domain. Strict aspf=s or adkim=s requires exact domain equality for that mechanism. Thus bounce.example.com and example.com can align under relaxed SPF but not strict SPF. For hypothetical From community@example.com, a passing intended d=mail.example.com signature aligns relaxed but not strict, assuming Organizational Domain example.com; d=example.com aligns in both modes. This is an identity example, not a measured Centercode result. DMARC alignment

Inspect the existing policy for the actual From domain and any applicable parent policy before changing anything. Preserve an established quarantine or reject policy, its reporting destinations, and its alignment settings. Do not create a second record or weaken enforcement simply because Centercode has been added.

Only if no direct or applicable inherited policy exists and the domain owner approves a monitoring plan and report destination may a TXT policy at _dmarc.example.com have this illustrative form:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Replace the example domain and mailbox with the actual approved values; replace only the mailbox address after the existing mailto:, not a complete URI. In the example.com zone this full owner is relative _dmarc. For a child From domain mail.example.com, the full owner is _dmarc.mail.example.com: use relative _dmarc.mail in the parent zone or _dmarc in a separately delegated mail.example.com zone. A delegated _domainkey zone does not contain the DMARC owner. p=none requests monitoring rather than DMARC-based quarantine or rejection; it is not a deliverability guarantee. Plan enforcement after all legitimate senders have been assessed. An aggregate-report destination in a different Organizational Domain from the domain where the DMARC policy was found requires the report-generating receiver to check authorization in the destination’s DNS. A destination within the same Organizational Domain is excepted; a different hostname alone is not the trigger. Have the reporting operator supply and confirm authorization for the actual policy domain. RFC 9990 section 4 This protocol check is separate from the owner’s approval of data sharing, access and retention. Do not enable failure reporting without its own privacy review. DMARC policy, external reporting authorization

Validate public DNS and delivered messages separately

First check the published records

Substitute your actual domain, authoritative nameserver and support-confirmed selector. These are lookup examples, not commands already run on your behalf:

dig +short NS example.com
dig @ns1.example.net TXT example.com +noall +answer
dig +short TXT example.com
dig +short TXT cc._domainkey.example.com
dig +short TXT _dmarc.example.com

Check that authoritative and recursive results agree after relevant TTLs expire. Find one SPF policy containing your approved authorization, the exact DKIM public key at the supplied owner, and the intended DMARC policy. An empty answer can mean a wrong owner, wrong zone, missing record or caching; it does not prove the service cannot sign. Query the actual envelope domain too if it differs from the example’s apex.

Then test the actual Centercode workflow

Once the configuration is approved, send through the workflow being accepted, such as the community mail or recruitment flow your team uses. Use harmless content, not participant feedback, confidential product details or community-member data. Deliver directly to a controlled external mailbox before investigating forwarded copies. A message sent manually from an employee inbox does not test Centercode.

Use results produced inside the actual receiving service’s known processing boundary. Ask its administrator or consult its documentation to establish which component authenticated the message and how externally supplied Authentication-Results fields are removed or isolated at ingress. Correlate the result with that service’s original-message view or authenticated trace. A familiar authserv-id or header position alone is not proof. Ignore untrusted fields; if provenance remains unclear, leave acceptance open and obtain the receiver’s trace. Forged authentication-result fields, RFC 8601 section 7.1

Read the full received headers and capture:

For a DKIM rollout, require the intended branded DKIM signature to pass and align under current adkim, plus the trusted receiver’s dmarc=pass for the intended From. A rewritten provider-domain From does not authenticate the intended brand. A provider-domain signature or DMARC pass supplied only by SPF does not prove that your Centercode DKIM setup works. Equally, a DKIM-based DMARC pass does not justify ignoring spf=fail, softfail, permerror or temperror. Diagnose those independently. Trusted authentication results, DMARC evaluation

Troubleshoot the result you actually see

Preserve your previous DNS export and the new observations. Recover only the affected changes in coordination with IT and Centercode. Do not delete other senders’ records or remove DMARC protection as a first response.