What SPF record does Spark CMS use?

There is no safe universal value to copy. Request the current SPF authorization and custom return-path records assigned to your Spark CMS deployment from Market Creations, then merge the authorization into the domain's single SPF record.

Can Spark CMS use a matching return path for SPF?

Yes. Ask Market Creations for the account-specific custom return-path DNS records, publish them exactly, and confirm in a delivered message that the Return-Path shares the organizational domain used by the From address.

Why does DMARC pass when Spark CMS SPF fails?

DMARC needs one domain-matched method to pass. If Spark CMS applies a valid DKIM signature whose d= domain matches the From domain, DMARC can pass even when SPF fails or its return path does not match.

Which platform sends email with Market Creations rDNS hostnames?

Spark CMS is one likely source because Market Creations operates the platform and related hosting infrastructure. An rDNS suffix alone is not proof. Match the source IP, return path, DKIM domain, and a known Spark CMS test message before classifying the traffic.

Should I weaken p=reject while adding Spark CMS?

No. Keep an existing p=reject or p=quarantine policy. Configure DKIM with a matching domain and the custom return path, test Spark CMS, and use DMARC data to confirm passes before treating the source as complete.

Learn

DMARC

How to set up DMARC/DKIM/SPF for Spark CMS

Matthew Whittaker

Co-founder & CTO, Suped

Published 21 Sep 2026

Updated 21 Sep 2026

10 min read

Summarize with

Spark CMS email authentication setup for SPF, DKIM, and DMARC

Spark CMS can send website form submissions and automated notifications using your domain. The working setup has an authenticated From domain, a Spark CMS return path under the same organizational domain, a valid DKIM signature, and a DMARC record. Market Creations does not publish one universal SPF include or DKIM selector for every customer, so copy the DNS values issued for your Spark CMS site rather than borrowing records from another domain.

I treat every provider-issued value as deployment-specific and verify the result in a message generated by the real Spark CMS workflow. That prevents a correct-looking DNS record from hiding the wrong signing domain or return path.

Use account-specific records

Do not publish a guessed IP address, SPF include, DKIM selector, or return-path target. Ask the Spark CMS support team for the current values assigned to your site, because infrastructure and configuration can differ between deployments.

Add your domain

Start with the exact domain that appears after the @ in the From address used by Spark CMS. Domain authentication is normally coordinated with Market Creations because the public Spark CMS material does not document a self-service domain-verification screen.

Choose the From domain: Use a domain you control, such as example.com or a dedicated subdomain. Do not use a personal mailbox domain.
Open a support request: Ask Market Creations to add the domain to your Spark CMS deployment and enable custom-domain authentication. Include the Spark CMS site name and intended From address.
Request every DNS value: Obtain the SPF authorization, DKIM selector and target or public key, plus the custom return-path records. Ask whether any value is unique to the site.
Confirm domain matching: Require the return-path domain or DKIM signing domain to share your From domain's organizational domain. Spark CMS supports a matching return path, so request it rather than accepting an unrelated bounce domain.
Publish and verify: Add the supplied records at the authoritative DNS provider, then ask Market Creations to rerun verification before changing live form notifications.

Keep the authentication records separate from the website's A or CNAME record. Changing mail-authentication TXT and CNAME records should not move the website, but overwriting an existing SPF record can break other senders.

I recommend having the DNS owner and the Spark CMS contact present for the change. One person can confirm the published values while the other triggers vendor-side verification.

Control	DNS name	Purpose
SPF	Root	Authorize sender
DKIM	Selector	Sign messages
Return path	Custom host	Match SPF domain
DMARC	_dmarc	Policy and reports

Values to request for the Spark CMS sending domain

Before the switch, record the current From address and submit one test form. Save the delivered message headers as a baseline. This makes it easier to prove which return path and DKIM domain changed after verification.

Set up SPF

SPF checks the envelope sender, also called the return path. Spark CMS supports a matching return path, so the preferred setup uses a Spark-provided custom return-path subdomain under your organizational domain.

Inspect the current record: Check the root domain for an existing SPF TXT record before making changes. A domain must have only one SPF record at a given hostname.
Add Spark authorization: If Market Creations supplies an include mechanism or IP range, merge it into the existing record before the final all mechanism. Never publish a second SPF record.
Configure the return path: Publish the exact CNAME, MX, or TXT records supplied for the custom return-path host. Do not improvise the record type.
Count DNS lookups: Keep SPF within the ten-lookup limit. Includes, redirects, MX mechanisms, and some nested records consume lookups.

Illustrative merged SPF structureDNS

v=spf1 include:<spark-include> include:<other-sender> ~all

Replace both placeholders with real values. Keep every legitimate sender in one record, and remove old mechanisms only after confirming they are unused.

Run the checker after DNS propagation. It should return one syntactically valid record and no lookup-limit error.

SPF checker

Find SPF syntax issues, lookup limits, and weak records.

?/16tests passed

A raw SPF pass is not enough for DMARC. In a received Spark CMS message, compare the return-path domain with the visible From domain. They must share the same organizational domain under relaxed DMARC matching.

Some sending sources cannot use a custom return path. Those sources can show SPF domain mismatch errors without causing DMARC failure when DKIM passes with a matching domain. Spark CMS supports a custom matching return path, so that fallback should not be necessary here, but DKIM still provides an independent pass path.

Set up DKIM

DKIM is the most reliable authentication path for forwarded messages because the signature survives forwarding when the message is not modified. Use only the selector and DNS value assigned to your Spark CMS deployment.

Get the selector: Ask Market Creations for the complete record name, record type, and value. A selector copied from another Spark CMS customer will not validate your messages.
Publish it exactly: Add the supplied CNAME or TXT record. Enter only the host portion if your DNS control panel automatically appends the domain.
Avoid proxying: If the DNS provider offers HTTP proxying for CNAME records, leave the DKIM record in DNS-only mode.
Trigger verification: After the record resolves publicly, ask Market Creations to verify the domain and activate signing. DNS publication alone does not prove Spark CMS has started signing.
Check domain matching: In a delivered message, the DKIM d= domain must share the organizational domain used in the From address. A DKIM pass with an unrelated d= value does not satisfy DMARC.

DKIM details to copy from Spark CMS supportDNS

Host: <selector>._domainkey.example.com
Type: CNAME or TXT
Value: <Spark-provided-value>

Do not split, quote, or rewrap a CNAME target. For a TXT public key, the DNS provider can split a long value into quoted chunks internally, but the public lookup must return one continuous value.

Send a fresh form submission after activation. Check Authentication-Results for dkim=pass and confirm that header.d shares the From domain's organizational domain under relaxed DMARC matching.

A valid record is only half the test

The decisive evidence is a newly delivered Spark CMS message with dkim=pass and a matching signing domain. A public key in DNS can be valid while the platform still signs with the wrong domain or does not sign at all.

Set up DMARC

DMARC passes when SPF or DKIM passes and the passing identifier matches the visible From domain under DMARC rules. I start at p=none while collecting reports. If the domain already uses p=quarantine or p=reject, keep that policy and fix Spark CMS without weakening enforcement.

Check for DMARC: Look up the TXT record at _dmarc.example.com. Edit the existing record if one exists. Never publish two DMARC records.
Create the record: Use the DMARC record generator if you need help formatting the tags, then publish one TXT record at _dmarc.
Start with monitoring: Use p=none on a domain without enforcement. Keep an existing quarantine or reject policy unchanged.
Receive aggregate data: Make sure the rua mailbox or reporting service accepts DMARC XML reports. A normal inbox quickly becomes impractical.

Starter DMARC recordDNS

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

Replace example.com with a reporting address you control. When connecting a reporting platform, use the rua value it supplies and complete any external-destination authorization it requires.

Check the published record after DNS propagation. The result should show one record, a valid policy, and a valid aggregate-report destination.

DMARC checker

Look up a domain's DMARC record and catch policy issues.

?/7tests passed

Do not switch to enforcement based only on a green syntax check. DMARC reports must show that legitimate Spark CMS traffic passes through SPF or DKIM with a matching domain.

At p=none, receivers can still filter or reject mail for other reasons. The policy provides visibility, not an inbox-placement guarantee.

Verify and troubleshoot

Test the real path by submitting a public Spark CMS form or triggering the actual notification workflow. A message sent by another mail system does not prove the CMS configuration works.

Send to two receivers: Submit the same form to mailboxes at different providers when the workflow allows it. This exposes receiver-specific parsing or delivery problems.
Inspect headers: Record the From domain, Return-Path, DKIM d= value, selector, source IP, and Authentication-Results.
Verify DMARC logic: At least one domain-matched path must pass. SPF can fail while DKIM passes with a matching domain, or DKIM can fail while SPF passes with a matching return path.
Retest after propagation: Wait for the old DNS TTL to expire, then generate a new message. Previously received messages preserve the old result.

Passing result

DMARC: The result is pass.
DKIM: The signature passes and d= matches the From domain.
SPF: The result passes and the return path matches.

Failure pattern

SPF permerror: Merge duplicate records or reduce lookups.
DKIM neutral: Correct the selector record and reactivate signing.
DMARC fail: Fix domain matching, not just raw SPF or DKIM.

The email tester is the quickest end-to-end check. Send a Spark CMS-generated message to the address it provides, then review authentication, domain matching, headers, and content findings together.

Use a fresh test for every configuration change so cached DNS and old message headers do not obscure the result.

Email tester

Send a real email to this address. Suped shows a results button when the test is ready.

?/43tests passed

If DKIM passes with the wrong signing domain, send Market Creations the full Authentication-Results header and ask them to sign with your verified domain. If SPF passes with the wrong return-path domain, ask them to apply the custom return path already requested.

If both domain-matched paths pass but mail still lands in spam, authentication is no longer the primary fault. Review complaint rates, recipient consent, content, sending consistency, and source reputation.

Get alerted when it breaks

A one-time test cannot catch a later selector change, expired DNS value, new source IP, or edited SPF record. Continuous DMARC reporting turns those changes into evidence tied to real mail volume.

Monitor authentication: Track DMARC, SPF, and DKIM results for the Spark CMS source instead of checking only aggregate domain pass rates.
Verify the source: Label known Spark CMS traffic only after its sending IP, return path, and DKIM identity match a message generated by your site.
Alert on change: Notify the team when domain-matched pass rates fall, an unverified sender appears, or the DMARC policy changes.
Retain context: Keep the Spark CMS support ticket, issued DNS values, and a known-good header sample with the domain record.

For most teams, Suped is the best overall fit for this workflow. Suped's DMARC monitoring groups authentication data by sending source, detects issues automatically, and provides steps to fix them. Real-time alerts reduce the gap between a broken Spark CMS change and the team's response.

The same Suped workspace can monitor DMARC, SPF, DKIM, blocklist or blacklist status, and delivery signals. Agencies and managed service providers can keep multiple client domains in one multi-tenant view.

Alert on the condition that matters

A Spark CMS SPF failure is not automatically an incident when DKIM still passes with a matching domain. Prioritize DMARC failures, sustained drops in domain-matched authentication, unexpected source changes, and policy changes.

Route alerts to whoever can change DNS and to whoever owns the Spark CMS support relationship. That avoids a warning reaching a mailbox whose owner cannot correct either side of the configuration.

Secure your domain with p=reject

Move to p=reject only after every legitimate source has a domain-matched pass path. For Spark CMS, require DKIM with a matching signing domain and keep the matching return path working so one method can cover a temporary failure in the other.

Inventory all sources: Identify every system using the From domain, including low-volume form handlers and alerting systems.
Verify Spark CMS: Confirm sustained DMARC passes for website forms and automated notifications. Test each distinct template or module that sends mail.
Fix unknown traffic: Authorize a legitimate source, move it to a subdomain, or stop it. Do not weaken domain matching to accommodate unidentified mail.
Stage enforcement: Move to p=quarantine with a limited percentage, observe normal business cycles, then increase coverage before switching to p=reject.
Keep monitoring: Enforcement blocks unauthenticated impersonation, but it can also expose forgotten legitimate senders. Keep alerts active after reaching reject.

Final DMARC enforcement recordDNS

v=DMARC1; p=reject; rua=mailto:dmarc@example.com

A percentage rollout reduces operational risk, but pct is not a repair. Resolve known failures first, and remember that receiver handling of percentage sampling can vary.

Suped makes this progression practical by showing verified and unverified sources, surfacing the exact failing mechanism, and providing tailored repair steps. Hosted DMARC can manage policy staging, while real-time alerts catch regressions after enforcement.

Ready for reject

Promote the policy when Spark CMS passes DKIM with a matching signing domain, its custom return path matches for SPF, other legitimate sources are verified, and no unexplained failure volume remains.

After publishing p=reject, submit another Spark CMS form immediately. Confirm DMARC pass at the receiver and watch aggregate data for at least one full reporting cycle.