zingfit SPF, DKIM and DMARC setup, step by step

zingfit documents a provider-domain default for automated studio emails. Sending from your studio's domain is a separate, support-led arrangement. The retained public guide says this involves four DNS records, but does not supply a complete current record-issuance and signing-activation procedure. Request the actual records for your studio; do not invent four entries or treat an old SPF include as a complete DKIM setup. [1]

This guide helps you identify the route you use, prepare a precise support request and verify the resulting messages. It is not a complete custom-domain provisioning tutorial. No customer account, DNS change or delivered-message test was performed for this article. The retrieved default-domain article was identified by the research tool as a cached capture approximately 1.4 years old; its contents are documentary evidence, not confirmation of today's live service behavior. Confirm the applicable route with support before making changes.

First identify the email you are troubleshooting

A booking confirmation, an automated studio message and a Marketing Automation campaign are not automatically the same sending route. Record the product area, studio location and message type before changing settings. The default-domain statement in the cited article concerns automated zingfit studio emails; do not extend it to every product or message in an account. [1]

Open a received sample and distinguish:

• Display name: the friendly label a customer sees, such as your studio name.
• Visible From address: the address inside the message's From field. Its domain is central to DMARC.
• SMTP MAIL FROM: the envelope identity checked by SPF, usually represented by Return-Path in delivered mail. It can differ from visible From.
• DKIM signing domain: the d= value of a particular signature. Its selector is s=; the selector alone is not the authenticated domain.

Do not infer authentication from a familiar logo or display name. On the documented default route, your own DNS cannot repair a signature made using a provider-owned domain. A claimed branded-domain route must be assessed against the intended studio From domain, not declared successful merely because the service substituted its own domain. [4][5]

Review the studio identity without changing the sending route

The provider's sender-name article points to Admin > Configuration > Studios, then the edit icon for the relevant studio email. It describes handling multiple locations individually. [2] An authorized administrator can use this location to inspect the current identity and record which studio it belongs to.

Treat the friendly-name setting as presentation, not as a switch that activates SPF or DKIM. Do not change a production address, assume a mailbox exists, or apply a special address-formatting string based on this guide. Confirm the current interface and account-specific requirements before editing. If you only need to diagnose authentication, a received sample and a settings snapshot are enough to start.

Keep existing values and identify the service owner before making any approved edit. Avoid testing on real customer reservations or sending an unexpected message to a customer. Use a controlled recipient and an approved test workflow for the actual message category.

What to request for branded-domain sending

The official automated-email article directs interested studios to open a support ticket. The support guide lists support@zingfit.com and the Leave a message option in its account or knowledge-base widget. Routine domain setup does not require the urgent outage route. [1][3]

Ask the provider to confirm the exact product and studio scope before any DNS change. A useful request includes the intended public From domain, the relevant studio/location, the message category, and who administers authoritative DNS. Do not include passwords, private DKIM keys, customer lists or unnecessary raw headers.

Request a current configuration packet answering these questions:

1. Which account, studio and message flows does this configuration cover? Does Marketing Automation need separate setup?
2. What is each complete DNS owner name, record type and public value? Which entries are account-specific?
3. Which entry, if any, configures DKIM? What signing domain and selector should appear on a resulting message?
4. What is the actual envelope sender behavior, and is an SPF change at a studio-controlled owner necessary?
5. Who validates DNS and activates the branded identity or signing? How will that activation be confirmed?
6. What should remain unchanged, and what is the approved rollback if verification fails?

The published count of four records is not enough to answer these questions. It does not establish four DKIM records, four TXT records, a universal selector, an SPF owner, or a fixed activation sequence. Nor does this request checklist promise that every desired feature is available. Leave the custom route pending until the provider supplies a complete applicable procedure. [1]

Why the older SPF advice is not the complete answer

A separate official troubleshooting article recommends include:_spf.zingfit.com in an existing SPF policy. That page also contains an unrelated reference to Zendesk and older combined examples. [7] Keep it as historical documented guidance to clarify with support, not a reason to authorize another service or replace an existing policy wholesale.

An SPF include only has meaning within a policy evaluated for the relevant envelope domain. It does not publish a DKIM key, activate message signing, or prove alignment with the visible studio address. Do not add the include to your apex just because your studio email address uses that domain; first establish the actual route and provider instructions. [4][5]

If an approved packet requires SPF changes, retain one SPF policy at the evaluated owner, preserve legitimate existing senders and qualifiers, and assess the ten evaluated DNS-dependent-term limit, including nested evaluation. Do not copy an example that weakens an existing -all, creates a second policy, or adds unrelated mail-hosting infrastructure. A redirect modifier is ignored when an all mechanism is present. [4]

Review any proposed DNS changes before publication

This section is a safety checklist for a future provider-issued packet, not a substitute for that packet.

• Confirm where the domain's authoritative DNS is hosted. The registrar and DNS host may differ.
• Map each full owner name into the correct zone. A separately delegated child zone or delegated _domainkey namespace can change where a record belongs. Preserve existing delegations. For example, an illustrative owner studio._domainkey.mail.example.com is entered as studio._domainkey.mail in the example.com zone, studio._domainkey in a separately delegated mail.example.com zone, or studio in a separately delegated _domainkey.mail.example.com zone, if the DNS editor appends that zone suffix. These are owner-mapping examples, not zingfit-issued records; never remove a delegation to imitate them.
• Preserve exact provider-issued types and complete public values. Do not copy another studio's selector or key, generate an unrelated private key, or truncate a TXT value.
• Stop on an owner-name conflict. A CNAME must not coexist with other data at its owner; do not delete existing records to force it in. Ask the provider and DNS administrator for the correct resolution. [8]
• If the packet uses CNAMEs for authentication, publish them as DNS-only, not HTTP-proxied. Turn off per-record flattening where available if the provider needs the literal CNAME response. Check zone-wide, apex and same-zone behavior too: disabling one switch may not preserve that literal answer. If mandatory flattening or an apex restriction prevents the required response, stop and obtain a provider-approved alternate owner or design. Do not change zone-wide behavior or unrelated records merely to force the tutorial to fit.
• Preserve direct and inherited DMARC enforcement and existing authorized report destinations. Do not downgrade to p=none to make a failing route appear deliverable.

Changing MX, parent nameservers, DNSSEC or account credentials is not implied by a request to authenticate outgoing studio mail. A new reporting recipient is also a separate data-sharing decision, not a default requirement of this guide. If a DMARC aggregate-report destination is in a different Organizational Domain from the policy domain, the report-generating receiver must check the required DNS authorization; destinations within the same Organizational Domain are excepted. That protocol check does not replace the domain owner's privacy approval. [9]

Verify the message, not just the DNS record

After an authorized configuration is completed and the provider confirms its activation, obtain a controlled sample through the intended studio workflow. There is no universal test-send button established here. Agree the test with the studio administrator so it does not create real bookings, charges, subscriptions or customer notifications.

Inspect results supplied by the receiving infrastructure your mail administrator trusts. A sender can insert an Authentication-Results header; its position or a familiar authserv-id alone is not proof of trust. Establish the known receiving processing boundary and its documented handling of externally supplied results, such as stripping or segregating untrusted headers, before relying on an asserted pass. [6]

Record the actual From address, message category, studio, timestamp and message identifier. Then check:

1. SPF: the receiver's result and evaluated MAIL FROM domain, or HELO for a null reverse path. For fail, compare the actual sending IP and evaluated identity with the authorized route. For temperror, investigate transient DNS/receiver failures and recheck when resolved rather than adding broad authorization. For permerror, inspect malformed or multiple SPF policies, invalid mechanisms and evaluated lookup limits; repair the specific policy defect instead of weakening DMARC. A DKIM-based DMARC pass does not make these SPF defects disappear.
2. DKIM: the result for the intended provider signature, keeping its d= domain and s= selector together. The presence of a signature is not a pass.
3. Alignment: compare the authenticated identity with the actual From domain. Relaxed alignment uses the same Organizational Domain; strict alignment requires an exact domain match, under the applicable aspf or adkim mode.
4. DMARC: require a trusted receiver pass. For a newly configured branded DKIM route, additionally require the intended DKIM signature to pass and align with the intended studio From. An SPF-only DMARC pass does not prove DKIM works. [4][5]

See raw DKIM results versus aligned DKIM policy results for the difference between a valid signature and an aligned signature.

A public DNS lookup, provider-side verification and actual message signing are separate observations. Keep evidence for each rather than marking the route complete after the first green check. A passing result is not an inbox-placement guarantee or proof that message content is safe.

Troubleshooting the common ambiguities

The display name changed, but the domain did not. That is not necessarily a failure. Friendly-name presentation and branded-domain sending are different tasks. Check the actual address and support-approved route.

Support mentions four records, but you cannot find their values. Request the current studio-specific packet. Do not derive it from corporate DNS, another customer's records or an assumed underlying mail provider.

You added the old SPF include but DKIM still fails. SPF does not repair DKIM. Inspect the intended signature and ask support to confirm its signing identity, DNS lookup and activation state. Avoid adding further speculative records.

A default-domain message fails authentication. Preserve studio DNS and provide support with the category, time and minimally necessary sanitized diagnostics. Establish who controls the failing identity before proposing changes.

Authentication passes but the message is missing. Check receiver quarantine, logs and the actual event that should trigger the message. Do not weaken authentication or blanket-allowlist all mail as a first response.

Sources and scope

1. zingfit: Using your studio's email address with automated zingfit emails. Relevant full operative body reviewed; default From, support ticket and four-record statement.

2. zingfit: How can I change the sender name for my studio email?. Studio settings location and friendly-name distinction.

3. zingfit: Contacting zingfit Support. Current documented support channels and urgent-support scope.

4. RFC 7208: SPF. Envelope identities, policy evaluation and DNS-dependent-term limits.

5. RFC 9989: DMARC. Alignment, authenticated identities and policy evaluation.

6. RFC 8601: Authentication-Results. Receiver reporting and trust boundaries.

7. zingfit: How do I prevent System Emails from being flagged as Spam?. Older SPF advice, retained with its limitations rather than treated as complete domain authentication.

8. RFC 1034, section 3.6.2. CNAME alias constraints.

9. RFC 9990, section 4. External aggregate-report destination authorization and same-Organizational-Domain exception.