ReferralCandy SPF, DKIM and DMARC setup, step by step

ReferralCandy activates a custom sender when you save an owned-domain sender address and verify the three DKIM CNAME records generated by Create keys. Verification runs automatically. Once both required steps are verified, the page shows Custom sending active and native ReferralCandy emails switch to your address.

DMARC and the optional custom-envelope SPF setup are separate steps. Neither blocks sending inside ReferralCandy, but that does not make authentication policy optional at receiving systems or guarantee delivery. Until the custom-sender requirements are complete, native email continues from ReferralCandy’s default address. Official custom email domain guide.

This guide covers email ReferralCandy sends directly, including referral invitations, reminders, rewards and applicable native account messages. It does not configure referral-portal links or email sent by external Klaviyo flows. Those flows use Klaviyo’s sender settings; native messages such as advocate password resets can still use ReferralCandy.

Before you begin: approve the sender and the automatic switch

Use a domain you own. Personal addresses at services such as Gmail or Outlook are not accepted for custom-domain sending. Confirm that the sender mailbox and any separate Reply-To mailbox exist, are monitored and are authorized to receive customer correspondence.

You need an operator who can access the account’s Custom email domain settings and a DNS administrator for the authoritative zone. The current instructions do not establish a universal plan restriction or named role for this feature. If settings are unavailable, confirm access with the owner and ReferralCandy rather than purchasing a plan or changing permissions speculatively.

Before publication, record the existing settings and approve the domain and scope of the change. DKIM verification automatically switches the native sender once the sender address is saved. There is no documented extra Activate button to hold that transition for you. Coordinate the timing before adding records to a live account.

Inventory existing SPF, DKIM, DMARC and relevant MX or NS records, including separately delegated child zones. Identify which emails actually come from ReferralCandy and which come from another integration. A change in ReferralCandy’s account settings must not be assumed to authenticate every email in your referral program.

Understand the identities and the default route

The documented default is postman@candymail.com; some accounts use the related candymail.co, candymail.cc or candymail.ch domains. A message from that provider route may authenticate correctly without meeting your branded-From requirement. Do not call fallback delivery successful custom-domain deployment. See raw DKIM results versus aligned DKIM results.

1. Open Custom email domain and save the sender

Use the route that matches your account:

• Shopify: Shopify admin → Apps → Referral Candy → Account → Custom email domain.
• Other platforms or direct login: ReferralCandy → Account → Custom email domain.

The page has a Setup progress header and four numbered steps. Sender email and DKIM are required for the From-address switch. The other two steps become available after the sender is saved, but do not determine whether the application sends from that address.

In step 1:

1. Enter the approved address in Sender (from) email address.
2. Keep Use this as your reply-to email selected if replies should reach the same mailbox. Otherwise, clear it and enter the approved alternate address.
3. Click Save.

There is no verification email to click for this address. The address is saved immediately; domain ownership is established through DNS in the DKIM step. Saving alone does not activate the custom From. Carefully check spelling and authorization because mailbox control is not being established through an email challenge. Sender setup and activation rules.

A Reply-To change affects where potentially sensitive customer correspondence goes. Do not silently direct replies to a personal account, third-party system or former employee.

2. Generate and publish all three DKIM CNAMEs

In step 2, click Create keys. ReferralCandy generates CNAME 1–3, each with a Name and Value. Use its copy buttons and retain every complete account-specific owner and target.

The guide illustrates an account-specific selector beneath _domainkey pointing to an Amazon SES DKIM hostname. That is a structural example, not a universal selector or a reason to create a standalone SES account. Do not reuse another merchant’s records, shorten a target or substitute a TXT public key for an issued CNAME.

Publish all three CNAME records at the authoritative DNS host. That host may differ from the domain registrar or storefront provider. Copy each Name to the appropriate Name/Host field and each Value to the Target/Value field.

Get the owner names right

This table demonstrates DNS-editor mapping, not actual ReferralCandy-issued records. Replace SELECTOR and the example domain with each full Name from your account.

Some DNS hosts expect a full name instead. Check the editor’s convention and the expanded saved owner so the domain is not appended twice. Keep the target complete regardless of how the owner field works. Existing NS delegations determine where records belong; do not remove them to force publication in the parent zone.

A CNAME owner cannot also contain TXT, A, AAAA, MX or a different CNAME. If an issued owner conflicts with existing data, stop and coordinate with the DNS administrator and ReferralCandy. The provider’s general statement that services use distinct DKIM records is not permission to overwrite an actual collision.

Keep required CNAME answers visible

These authentication records should be DNS-only, not HTTP-proxied. ReferralCandy’s documented lookup check expects each Name to return its matching Value. Flattening can hide that literal CNAME answer.

For Cloudflare, turn the applicable per-record Flatten control off where available and ensure relevant zone-wide settings do not flatten these aliases. Coordinate shared-setting changes instead of disabling a feature globally without reviewing other records. Cloudflare automatically flattens apex CNAMEs and also documents same-zone target behavior that ignores the ordinary setting. If those conditions prevent the required response, stop and arrange a supported configuration; do not invent a switch or move nameservers. Proxy status and CNAME flattening setup document those controls.

Do not publish private keys or transmit API credentials for this process. The native task is to publish the three public aliases issued in ReferralCandy.

3. Confirm automatic verification and Custom sending active

ReferralCandy checks the records automatically every few minutes. The DKIM step shows Checking… while waiting, then Verified when it passes; the provider also sends a confirmation email. Its instructions allow up to 72 hours for propagation and recommend contacting Support if correct records still have not verified after that period. This is documented guidance, not a guaranteed completion time.

Independently compare each authoritative CNAME answer with the account’s complete expected Value, then check a public recursive resolver. A missing answer, wrong target or duplicated domain suffix requires correction. Do not merely wait out the stated period when the records are demonstrably wrong.

When steps 1 and 2 are verified, Setup progress → Custom sending active confirms the application’s switch to the custom address. DNS answers and account status are two checks; neither proves that the intended DKIM signature passed on a delivered message. Perform the message-level acceptance below before calling the branded configuration verified.

The page also uses Not started, Action needed, Failed and Needs attention. The last means a previously verified step stopped passing. Investigate the specific step and actual message behavior rather than assuming every status has the same fallback or blocks all mail.

4. Check DMARC without weakening existing protection

Step 3 is labeled Required for Gmail & Yahoo delivery, but ReferralCandy explicitly says it does not block application sending. That UI behavior is not permission to ignore your domain’s policy or a guarantee of recipient acceptance.

Review the direct and applicable inherited DMARC policy for the intended From domain. Keep existing enforcement, alignment settings and authorized reporting destinations. The provider accepts an existing stricter policy; do not replace it with the example p=none, duplicate the TXT record or add a weaker child override.

If there is no direct or applicable inherited policy, the owner approves the change and an appropriate monitoring plan exists, an initial TXT value can be:

v=DMARC1; p=none

This conditional first-policy example does not request reports by itself and does not guarantee delivery.

After the appropriate policy is available, click Verify DMARC in step 3. If a direct-record check disagrees with an effective inherited policy, coordinate a supported resolution that retains effective protection, including any different inherited sp policy. Do not bypass the discrepancy with a weaker record. Avoid obsolete percentage-rollout instructions. Current DMARC specification.

ReferralCandy continues checking this step. A previously verified record can show Needs attention and generate an email if it stops passing; the source says this does not itself stop sending from the custom address. Correct the issue rather than treating continued sending as policy success.

If you add rua, choose a real, authorized reporting recipient. For a destination in a different Organizational Domain from the domain where the policy was found, the report-generating receiver must check DNS authorization. A destination within that same Organizational Domain is excepted. Different hostnames alone do not establish an external destination, and protocol authorization does not replace the owner’s data-sharing approval. RFC 9990, section 4.

5. Optional: configure the custom envelope subdomain for SPF

Step 4 is an advanced, optional configuration. Do not add an Amazon SES include to your root domain simply because ReferralCandy uses SES infrastructure. This workflow issues records for a chosen sending subdomain.

1. Choose an unused subdomain in step 4. The suggested label is mail, but that name may already serve your mailbox provider. Pick a different approved unused label if necessary.
2. Click Set up SPF.
3. Review the two records generated for that subdomain: an MX record with priority 10 and a TXT record containing the following published policy.
4. Approve the exact issued MX destination and affected owner, then add both records at the authoritative DNS host.
5. Wait for the step’s check to confirm the records. It displays Checking… while they have not yet been found.

v=spf1 include:amazonses.com ~all

Use that policy only in the supported optional configuration at the account’s chosen owner, with the actual generated MX target. No universal MX destination is supplied here. The target, priority and full owner must match the account packet and authorized routing plan.

For a chosen rcmail.example.com owner in a parent example.com zone, a suffix-appending editor commonly takes rcmail. If that child is separately delegated, its records belong in the child’s authoritative zone, commonly at @ or its apex input. Confirm the host’s convention rather than publishing unreachable parent-zone data.

This is not a root-mail migration. Do not replace the business’s existing apex MX, occupy another service’s mail hostname, remove an NS delegation or overwrite a CNAME to make the optional step pass. Stop on any conflict and choose a supported unused owner with the responsible administrator.

SPF evaluates the actual SMTP MAIL FROM identity, not Reply-To or display name. Preserve legitimate authorizations and qualifiers at each evaluated owner; publish only one SPF policy there. Parent SPF does not automatically cover a child. The ten-term limit counts evaluated DNS-dependent terms including nested mechanisms, not ten includes, and redirect is ignored when an all mechanism is present. SPF specification.

The source describes optional SPF as a backup to DKIM, but it is not an unconditional DMARC guarantee. A custom child envelope can align with a parent From under relaxed aspf yet fail strict alignment, which requires exact equality. Inspect the actual MAIL FROM and policy before claiming an aligned SPF fallback. A ~all result also does not dictate the receiver’s final delivery decision.

6. Verify a native message without generating real referrals

Use an authorized controlled recipient and harmless content. Do not create purchases, recruit real advocates, issue rewards, reset another person’s password or bypass self-referral protections to generate headers.

ReferralCandy documents Send test email in its Visual Editor context. Open the relevant campaign and Theme:

• On Shopify: ReferralCandy → Referral campaigns → campaign → Themes → Customize.
• On other platforms: Campaigns → campaign → Themes → Customize.

Select the relevant email and use the available test-email control with the approved recipient. The Shopify editor guide and other-platform editor guide say test emails use placeholder data, not real customer data; their buttons are not tied to a real referral. Do not change live Theme or reward settings merely to test authentication.

A template test does not establish every final notification route. Record which path was tested. Where final-route verification is still needed, use an existing legitimately received native message or a separately approved, non-transactional controlled workflow. Leave that check pending if there is no safe way to obtain it.

Use the receiving service’s own Authentication-Results from its known processing boundary. Check its documented handling of external result fields or obtain an administrator’s trace. Header position and a familiar authserv-id are not sufficient; ignore attacker-supplied results. Receiver trust boundary.

Accept the branded route only when:

• The actual visible From is the intended custom address, not a candymail fallback.
• The intended provider signature is present, and its actual d= and s= accompany a trusted dkim=pass.
• That signature aligns with From under the applicable adkim mode, and the receiver reports dmarc=pass.
• The actual envelope identity and SPF result are understood, including whether the optional subdomain is being used.
• Reply-To, recipients and expected content are correct.

Relaxed alignment compares Organizational Domains; strict alignment requires exact equality. A DMARC pass through SPF alone does not prove DKIM works, and an unrelated passing signature is not a replacement for the intended one. DNS presence, Verified badges and authentication success do not guarantee inbox placement or message safety.

Troubleshooting and sender changes

To change the sender, expand step 1, edit the address and click Save. Changing only the local part before @ retains setup progress. Changing to another domain resets DKIM, DMARC and SPF progress, so coordinate the new domain’s records and verification. Do not assume old-domain records carry over.

Remove email returns native sending to the default ReferralCandy address. Use that only as an owner-approved route change, not an invisible troubleshooting action. Removing the custom address or abandoning optional SPF does not authorize deleting DNS records still used by other mail or by a pending transition.

Preserve the previous configuration and coordinate any pause or rollback. Remove obsolete selectors or envelope records only after the replacement route is accepted and all dependencies are checked. Support evidence should contain redacted status/error information and non-secret record identities, not customer exports, private message contents or credentials.