GrowthZone SPF, DKIM and DMARC setup, step by step

For email sent by the GrowthZone AMS database, authorize include:clientemailspf.growthzoneapp.com in the appropriate single SPF policy, publish GrowthZone's seven current CNAME records, and preserve your effective DMARC policy. Then run VERIFY EMAIL DOMAIN DNS, inspect View Verification Results for the sending domain, and test a native message using the intended company From address.

The seven CNAMEs serve different purposes: two tracking records, one Sub SPF record and four DKIM selectors. They are not seven DKIM records, and a verified DNS screen does not prove that a delivered message has an aligned branded signature.

This guide covers native GrowthZone member communications and automated messages. It does not apply to ChamberMaster/MemberZone, which has a different procedure. Nor does it authenticate Outlook or other mailbox mail merely copied into GrowthZone's CRM. The official GrowthZone DNS table explicitly separates these products.

These are documentary instructions, not a claim that a customer account, DNS change or email test was performed.

On this page

• Confirm the product and sending domain
• Reconcile SPF without breaking other senders
• Publish the seven current CNAMEs
• Keep the effective DMARC policy
• Verify DNS inside GrowthZone
• Choose the intended From and test native mail
• Troubleshoot the failed check
• Frequently asked questions

Confirm the product and sending domain

Start with a company domain you control and an approved sender, such as members@example.com. Gmail, Yahoo and other public email-provider domains are not eligible for GrowthZone domain verification because you cannot add their DNS records. Do not use a warning bypass or rewritten sender as proof that your own brand is authenticated.

You need staff access to Marketing & Communication → Communication → Settings → Email Settings, plus an authorized DNS administrator. The retrieved GrowthZone instructions do not name a more specific role or paid-plan gate. Do not import ChamberMaster's support or edition requirements into this product. See the Email Settings overview.

Identify the actual authoritative DNS host, which may not be the registrar or website host. GrowthZone's nameserver guide explains the distinction through nameserver examples; those examples are not instructions to move your domain to those servers.

Before editing, save the existing SPF, DMARC, DKIM, CNAME and relevant NS records. Establish which applications depend on them. The manual DNS route does not require giving GrowthZone your DNS-host password, delegating account access, moving nameservers or changing receiving MX.

If the message originates in Outlook and is BCC'd to the database archive address, follow the mailbox provider's authentication procedure instead. GrowthZone's logging instructions state that this is only a received copy, not delivery by GrowthZone's servers.

Reconcile SPF without breaking other senders

GrowthZone's published authorization

For a sending domain with no existing SPF policy, GrowthZone publishes this baseline at the domain's apex, shown as @ or blank in many DNS panels:

Type: TXT
Owner for example.com: example.com
Value: v=spf1 mx include:clientemailspf.growthzoneapp.com -all

This is the provider's baseline, not a universal replacement for your current record. Publish it only after the domain owner confirms the intended senders and policy:

• include:clientemailspf.growthzoneapp.com authorizes the GrowthZone sending sources covered by that policy.
• mx authorizes addresses associated with the evaluated domain's MX hosts. It is not decorative, and receiving servers are not automatically intended outbound senders.
• -all returns SPF fail for sources not otherwise authorized. GrowthZone explicitly requires -all, rather than ~all, in its instructions. Neither qualifier guarantees what a recipient will deliver or reject.

If those assumptions do not fit the domain, reconcile the design with its DNS administrator and GrowthZone before publishing. Do not silently add mx, weaken a policy, or tighten it without inventorying legitimate mail.

If an SPF record already exists

The current provider table says to add this mechanism to the existing policy instead of creating another SPF record:

include:clientemailspf.growthzoneapp.com

Keep one v=spf1 TXT policy per evaluated owner. Preserve other legitimate authorizations, reconcile the qualifier with the owner, and place the GrowthZone include where it will actually be evaluated, normally before a terminal all. Do not paste the include after -all, add a second SPF record, or replace the entire policy with the baseline above.

An existing redirect= policy needs particular care. Any all mechanism makes SPF ignore redirect, even if redirect appears earlier in the text. Simply appending GrowthZone's requested -all can therefore remove the authorization supplied by the redirected policy. Have the administrator preserve those legitimate senders through an explicitly reviewed design, or resolve the provider requirement before proceeding. There is no safe universal string substitution for this case.

SPF permits at most 10 evaluated DNS-dependent terms, including nested terms reached through include and redirect. Count the actual evaluation path, not just visible includes. Review the budget before merging GrowthZone into a policy that already uses several services. RFC 7208 defines single-policy selection, the lookup limit and redirect behavior.

Do not confuse root SPF with Sub SPF

GrowthZone also requires the gzspf CNAME below. Its verification screen labels this Sub SPF. Keep it distinct from the root SPF TXT policy; configuring one does not mean the other can be omitted from the documented setup.

SPF checks the actual SMTP MAIL FROM identity, commonly reflected in the received Return-Path, not automatically the visible From. GrowthZone does not publicly promise one literal runtime envelope domain for every message. Observe smtp.mailfrom in trusted receiving results before deciding which SPF policy caused a failure.

Publish the seven current CNAMEs

For a new setup, the official DNS table gives these exact product-published aliases. The left-hand names are relative to the domain being configured; the right-hand targets are literal hostnames:

Type: CNAME
Name: gztrack1
Target: clientemailtracking1.growthzoneapp.com
Type: CNAME
Name: gztrack2
Target: clientemailtracking2.growthzoneapp.com
Type: CNAME
Name: gzspf
Target: clientemailsubspf.growthzoneapp.com
Type: CNAME
Name: gz._domainkey
Target: dkim1.growthzoneapp.com
Type: CNAME
Name: gz2._domainkey
Target: dkim2.growthzoneapp.com
Type: CNAME
Name: gz3._domainkey
Target: dkim3.growthzoneapp.com
Type: CNAME
Name: gz4._domainkey
Target: dkim4.growthzoneapp.com

The gztrack1 and gztrack2 aliases support tracking, gzspf supports the provider's Sub SPF arrangement, and the four _domainkey aliases point to provider-managed DKIM data. Publish all seven current aliases for a new setup. Do not assume every message will carry four signatures just because four selectors are published.

Map owners into the authoritative zone

For domain example.com, the first DKIM owner is gz._domainkey.example.com. A DNS panel editing the example.com zone may expect only gz._domainkey; a panel expecting full names needs the complete owner. Check its saved result to avoid .example.com.example.com.

For a separately configured child domain, map the full owner into its actual zone. For example, gz._domainkey.news.example.com is relative gz._domainkey.news in the parent example.com zone, but gz._domainkey in an authoritative delegated news.example.com zone. Confirm the domain shown by GrowthZone before publishing at a child rather than the root.

An NS delegation for _domainkey.example.com can place its selectors under another DNS administrator. Publish in that authoritative namespace, often using gz as the relative owner there. Do not delete the delegation or add an ineffective parent-zone copy. Preserve unrelated selectors and shared dependencies.

Keep CNAMEs literal and conflict-free

Do not place TXT, A, AAAA, MX or a second CNAME at an existing CNAME owner. If a GrowthZone owner is occupied, have the DNS administrator and GrowthZone resolve the conflict before replacing anything. RFC 1034 section 3.6.2 defines the alias restriction.

Publish targets as hostnames without https:// or paths. Do not replace a DKIM CNAME with the public TXT key it resolves to today; provider-managed rotation may depend on the alias. Private signing keys are not needed or published.

On Cloudflare, use DNS only for these authentication and verification aliases. Confirm that flattening does not hide their literal CNAME answers. Per-record flattening should be off where applicable, but zone-wide flattening, apex behavior and same-zone-target behavior can override that expectation. Resolve the specific record behavior with the DNS administrator instead of making an unreviewed global change. See proxy status and CNAME flattening controls.

Existing legacy records are not automatically obsolete

GrowthZone says the earlier mmptrack1, mmptrack2, mmpspf and s1 through s4 selector arrangement still works, but should not be used for first-time setup. Leave a functioning legacy set intact until a route-aware migration has been agreed. Do not delete it solely because a current tutorial lists gz names.

Keep the effective DMARC policy

GrowthZone's baseline table includes v=DMARC1; p=none; sp=none;, while the verification screenshot recommends a shorter p=none example. Neither is an instruction to downgrade an existing policy.

Determine the effective policy for the intended From domain, including applicable ancestor policy. Preserve current enforcement, subdomain policy, alignment settings and authorized report destinations. An empty child _dmarc lookup alone does not establish that there is no inherited policy. A timeout or SERVFAIL is not policy absence. RFC 9989 defines current policy discovery and alignment.

Only if no direct or inherited DMARC policy applies, and the owner approves initial monitoring with a review plan, this minimal first policy is appropriate for From example.com:

Type: TXT
Full owner: _dmarc.example.com
Relative name in example.com: _dmarc
Value: v=DMARC1; p=none

For From news.example.com, use _dmarc.news.example.com: relative _dmarc.news in the parent zone or _dmarc in its separately delegated child zone. Do not create a second policy or override inherited enforcement to match a checker recommendation. If GrowthZone flags a valid stricter policy, investigate the specific result with support rather than weakening it.

This minimal policy has no rua, so it does not request aggregate reports. Add a recipient only after approving its access, retention and data-sharing arrangements. Reports can reveal sending infrastructure and traffic patterns.

Under RFC 9990 section 4, compare the Organizational Domain where the policy was found with the Organizational Domain of the report URI's host. When they differ, report-generating receivers must check DNS authorization. A destination within the same Organizational Domain is excepted, even if its hostname differs. An external recipient normally provides a v=DMARC1 authorization at POLICY-DOMAIN._report._dmarc.REPORT-DESTINATION-HOST; obtain its exact values from the reporting service. This protocol authorization does not replace the organization's privacy decision.

Verify DNS inside GrowthZone

First compare public DNS with the intended records. These are read-only templates; replace uppercase placeholders with actual full names and server addresses:

dig @AUTHORITATIVE_DNS_SERVER FULL_CNAME_OWNER CNAME +noall +answer
dig @PUBLIC_RESOLVER FULL_CNAME_OWNER CNAME +noall +answer
dig @PUBLIC_RESOLVER DKIM_TARGET_HOSTNAME TXT +noall +answer
dig @PUBLIC_RESOLVER CONFIGURED_DOMAIN TXT +noall +answer
dig @PUBLIC_RESOLVER _dmarc.FROM_DOMAIN TXT +noall +answer

Repeat the CNAME checks for all seven owners. Compare exact targets and follow DKIM aliases to public keys. Inspect the complete SPF policy rather than searching only for the GrowthZone include. Allow for cached old or negative answers. If answers are empty, remove +noall +answer to see response errors and authority information.

Then follow Verify DNS:

1. Open Marketing & Communication → Communication → Settings → Email Settings.
2. Find the DNS section and select VERIFY EMAIL DOMAIN DNS after the records have propagated.
3. Open View Verification Results for each intended sending domain.
4. Compare Discovered Value, Recommended Value and Result Description for the returned checks. The documented screen separates Sub SPF, tracking and all four DKIM selectors.
5. Resolve failed records and repeat verification. Treat policy recommendations in the context of the existing SPF and DMARC design, not as permission to replace it.

There is no additional signing toggle or mandatory support activation documented in this GrowthZone procedure. Do not invent one. Conversely, a Verified status is a DNS checkpoint, not a delivered-message authentication result.

GrowthZone documents periodic annual rechecks. Staff can optionally subscribe to Email Domain Verification Pass/Fail notifications. That is a separate monitoring choice, not a prerequisite or a subscription performed by this guide.

Choose the intended From and test native mail

For automated messages, open the same Email Settings page, enter a monitored organization address in Default From Email Address, then click Done, following the default-From procedure. This changes the default automated sender, so coordinate its effect before saving. Check the From selected for member communications separately; do not assume the automated default governs every route.

After authorized deployment, send a controlled native GrowthZone message to recipients whose original headers you can inspect. Test relevant automated and staff-sent routes with their intended From domains. Do not use an Outlook message merely logged in the database as your GrowthZone test.

Accept the branded DKIM setup only when the received message shows all of these:

• The intended company domain in the actual visible From, not only the display name or Reply-To.
• The intended GrowthZone signature's d= signing domain and s= selector, taken from the same DKIM-Signature field.
• A trusted receiver's dkim=pass for that intended signature, with the signing domain aligned to the intended From.
• A trusted receiver's dmarc=pass for the From domain.
• A separately recorded SPF result and actual smtp.mailfrom identity, with any authorization or evaluation fault still investigated.

Use EmailAuth's selector guide to map the observed signature to SELECTOR._domainkey.SIGNING-DOMAIN. Multiple signatures require individual interpretation; do not mix a selector from one with the domain from another. DNS publication does not itself prove a message was signed, as the DKIM specification makes clear through its separate signing and verification operations.

Relaxed alignment compares Organizational Domains; strict adkim=s or aspf=s requires exact domain equality for that mechanism. A hypothetical MAIL FROM gzspf.example.com can relaxed-align with From example.com, but not strictly match it. This is an alignment illustration, not a claimed universal GrowthZone envelope identity.

A DMARC pass supplied only by SPF does not prove branded DKIM works. A provider-rewritten From is also not success for the intended brand. Trust only Authentication-Results generated or verified by your receiving infrastructure: a matching authserv-id string or header position alone cannot exclude forged results. If that distinction is unavailable, use an administrator-verified trace or another controlled receiving system. See RFC 8601.

Troubleshoot the failed check

• Not eligible for verification: check whether the sender uses a public mailbox-provider domain. Select an approved company domain you control. Do not count a fallback rewritten identity as company-domain authentication.
• CNAME check fails: compare the full owner, authoritative zone, exact target and any delegation. Check for suffix duplication, conflicts, proxying, flattening and stale caches before changing unrelated records.
• SPF verification fails: confirm one policy, an effective GrowthZone include, the owner-approved qualifier and the evaluated lookup budget. Revisit any redirect that an all mechanism disabled. Root SPF and the gzspf alias are separate checks.
• DNS verifies but DKIM is missing or fails: confirm the native sending route and selected From, then query the actual signature's selector and domain. If DNS is correct, investigate signing or message modification with GrowthZone and the receiving administrator.
• DKIM passes but DMARC fails: inspect the passing signature's alignment under the effective adkim setting. A valid but unrelated signing domain does not authenticate the branded From. Repair the route instead of reducing enforcement.
• DMARC passes but SPF does not: investigate SPF separately. fail and softfail concern authorization; temperror indicates transient evaluation trouble; permerror can involve syntax, duplicate policies or excessive DNS-dependent terms. A passing but unaligned SPF identity is a different condition.
• Authentication passes but delivery disappoints: examine recipient consent, reputation, content and receiving filters. Authentication does not guarantee inbox placement.