Yotpo SPF, DKIM and DMARC setup, step by step

To authenticate Yotpo Reviews or native Loyalty & Referrals email, ask the relevant Yotpo support team for the CNAME records for the exact domain configured in that product’s email settings. Publish the complete domain-specific set, then return to support so Yotpo can validate it and complete the setup. If another application already uses SendGrid on that domain, disclose it before records are generated. Finally, inspect a delivered message from each product you actually use. Yotpo’s domain-authentication procedure

This guide describes the documented workflow and tests your administrator should perform. No Yotpo account, customer DNS, support activation or live delivery was tested while preparing it.

Confirm whether Yotpo actually sends this email

This guide covers the Reviews and Loyalty custom-domain route identified in Yotpo’s CNAME authentication documentation. That route uses SendGrid behind Yotpo. It is not a universal setup for every Yotpo product, a standalone SMS & Email workflow, or an independent email service receiving events from Yotpo.

Loyalty & Referrals can send notifications natively or pass events to an integrated email service provider. When an external ESP sends the message, authenticate that ESP separately. Adding Yotpo’s native records cannot authorize a different service’s envelope sender or signing key. Yotpo native versus integrated email

List the storefront, product, account, message type and intended From address before asking for DNS changes. A review request passing DMARC does not establish that a Loyalty notification or an ESP integration passes too.

Set the intended sender in the correct product

Yotpo Reviews

Open Settings > Email Settings in Reviews and inspect the General Settings sender fields. Set a recognizable From name, the intended From email, and a monitored Reply email, then use Save Changes. The authentication request must name the domain in From email, not your storefront’s hostname or an unrelated reply domain. Yotpo notes that advanced email settings depend on the plan. Reviews email settings

Yotpo’s current deliverability guide says a blank From email defaults to reviews@yotpo.com. A message using that default may authenticate as Yotpo without proving anything about your branded domain. Verify the visible From on the delivered sample before troubleshooting your own DNS. Reviews default and branded senders

Native Loyalty & Referrals

In the Loyalty admin, open Communication > Settings and identify Sender’s name and Sender’s email address. Yotpo explicitly warns that this sender email is not a reply-to address and that replies to these automated messages are not delivered to it. Do not promise customers a monitored reply channel merely because the sender looks like your support mailbox. Loyalty sender and reply behavior

The native email cards are under Communications, including Loyalty emails and Referrals emails. Establish which enabled notification you are authenticating. Do not change reward rules or reminder timing just to produce a convenient authentication sample: those controls can also affect events sent to an integrated ESP.

For both products, confirm that your organization controls the sender domain and can modify its authoritative DNS. If the desired sender controls are absent from the account, resolve access or plan applicability with the product owner and support before publishing records for an identity the account cannot use.

Request the domain-specific CNAME set from Yotpo

Contact Yotpo Reviews Support or Yotpo Loyalty Support, as appropriate, with:

• The exact domain shown in that product’s email settings.
• The product and storefront/account it belongs to.
• The intended From address and whether both Reviews and Loyalty need authentication.
• Any other application already using SendGrid on the domain.
• Any existing CNAME owner that could conflict with a new record.

Yotpo’s official instructions require the requested domain to match the product’s configured email domain. They specifically ask customers with another SendGrid-using application to tell support so it can supply a different record structure. Record request and collision handling

Its example shows three CNAMEs: an envelope-related alias and two DKIM-selector aliases. The hostnames and targets are generated per domain. Do not copy the example’s numbers, SendGrid account identifiers or selector names into your zone.

You do not need to create a separate SendGrid account to follow this Yotpo process. Yotpo is the provider coordinating the records and validation. Do not configure a different SendGrid account and assume its authentication applies to mail sent by Yotpo.

Publish the records without overwriting another application

Export or record the current zone before changing it. Locate the authoritative DNS host, which may not be the domain registrar. Keep the generated list and support case with the approved change.

For each supplied CNAME:

1. Check whether the DNS editor expects a relative label or the full owner name. Automatic suffixing can turn host.example.com into host.example.com.example.com.
2. Enter the owner and target exactly as issued. Retain underscores and the correct record type.
3. Check existing records at that owner. A CNAME cannot coexist with ordinary A, TXT or other data at the same name. Do not delete an active selector to force the new one into place. DNS alias rules
4. If the owner conflicts, stop that change and ask Yotpo for the supported alternative. Never invent an alternate selector locally; Yotpo’s signing configuration must use the same selector.
5. With Cloudflare, keep authentication CNAMEs DNS only. Check both the record-level Flatten control and the zone-wide CNAME flattening for all CNAME records setting: either can hide a required alias. Coordinate any shared zone-setting change with the DNS owner and assess other services first. If the subdomain is delegated to another DNS host, preserve that delegation and publish at its authoritative host rather than deleting the NS record. Cloudflare CNAME verification guidance

If your DNS provider cannot publish the required record structure, involve Yotpo and the DNS provider. Do not switch to an unrelated SendGrid configuration or replace the requested CNAMEs with guessed TXT records.

Keep the required literal CNAME answer: turn relevant per-record Flatten off where available and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, apex CNAMEs are flattened by default and same-zone targets are flattened regardless of that setting; flatten-all cannot be overridden per record. If mandatory behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration without breaking other services or removing NS delegation. These are DNS-host behaviors, not controls assumed in the sending provider. Cloudflare flattening controls and limits.

How SPF works in this CNAME-based route

Yotpo identifies SendGrid as its email provider. SendGrid documents CNAME-based management of SPF and DKIM when automated security is used, including a generated return-path subdomain. This explains the delegation model; Yotpo’s support-issued records remain the values to publish for Yotpo, not records generated in another SendGrid account. Yotpo’s provider and record instructions, SendGrid domain-authentication architecture

There is no universal Yotpo SPF include in this documented workflow. Do not add include:sendgrid.net to the root merely because you recognize SendGrid in a target. The SPF domain is the actual SMTP MAIL FROM domain, normally shown by Return-Path and the receiver’s smtp.mailfrom result. It may differ from the visible From domain. For a null reverse-path, SPF uses HELO. SPF identities

If support identifies a different supported route that requires a direct SPF TXT edit, keep one SPF policy at the evaluated owner, retain other legitimate authorizations and validate the complete chain. The limit is ten evaluated DNS-dependent terms, including nested evaluation, not ten visible includes. include, a, mx, ptr, exists and redirect consume that term budget. A second SPF policy at the same owner causes PermError. SPF selection and evaluation limits

If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.

How to recognize the DKIM records

A DKIM signature identifies its signing domain in d= and selector in s=. The receiver queries selector._domainkey.signing-domain for its public key, following the CNAME where applicable. Both supplied selector records should remain published even when a particular message uses only one. DKIM verification

For an illustrative issued owner SELECTOR._domainkey.reviews.example.com, use relative SELECTOR._domainkey.reviews in example.com, SELECTOR._domainkey in delegated reviews.example.com, or SELECTOR at an existing delegated _domainkey.reviews.example.com authority. Use the actual Yotpo-issued selector, not this placeholder, and preserve NS delegation and other selectors. Relative names.

A working branded link or recognizable From name does not prove DKIM signing. Later, check that the intended branded signature actually passes. Keep private signing keys out of DNS, support tickets and shared evidence; the CNAMEs expose only the provider’s public verification route.

Ask Yotpo to validate and complete activation

After publishing, return to the relevant Yotpo support team and ask it to validate the records. The official procedure explicitly requires this follow-up. DNS publication alone is not the final step. Keep the validation confirmation tied to the exact product/account and domain. Yotpo activation step

The Yotpo authentication article does not promise a fixed activation deadline. DNS caches and support validation are separate dependencies. Inspect authoritative answers first, then recursive visibility, and ask support about its account-side status. Do not report the domain ready simply because enough hours have elapsed.

If both Reviews and Loyalty use the domain, have support confirm what the records cover and validate each product’s real message. If you later change the From domain, return to this process rather than assuming an old domain’s authentication transfers.

Keep DMARC policy and alignment separate from activation

DMARC passes when SPF or DKIM both passes and aligns with the visible From domain. Relaxed alignment allows a common organizational domain; strict aspf=s or adkim=s requires exact equality for the corresponding mechanism. A branded bounce subdomain can align under relaxed SPF without satisfying strict SPF. An unrelated SendGrid-domain signature can pass cryptographically without supplying aligned DKIM for your brand. Current DMARC alignment rules

Preserve an established DMARC policy and its reporting destinations. Do not remove DMARC or lower enforcement to make unauthenticated Yotpo mail appear acceptable. Repair the configured sender and signing route or pause that affected send. An SPF include at the wrong domain cannot repair an identity mismatch.

If your domain has no DMARC policy, the domain owner can authorize a monitored starting policy. This is an illustration, not a Yotpo-issued record:

Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Replace the domain and address with your approved, functioning destination. Keep one policy at the relevant owner, and verify any required authorization at an external reporting service. Aggregate reports contain operational information; choose recipients and retention deliberately. Do not turn on failure reporting without a privacy review. DMARC aggregate-report authorization

Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4. For an owner-approved first monitoring policy only, with no direct or applicable inherited policy to preserve, publish one TXT policy at the actual From domain’s DMARC owner. From example.com uses full owner _dmarc.example.com, or _dmarc relative to the example.com zone. From news.example.com uses full owner _dmarc.news.example.com: enter _dmarc.news in the parent zone, but _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve NS delegation; never create a child monitoring override of existing protection. DMARC policy publication, relative DNS names. This first TXT policy is conditional on no direct or applicable inherited policy and the domain owner’s approval of the monitoring/review plan; never create a child override of existing protection.

A p=none policy does not guarantee acceptance or inbox placement. Before stronger enforcement, inventory other legitimate senders and examine reporting over time. RFC 9989 requires domains publishing p=reject to apply valid DKIM signatures rather than rely solely on SPF and discusses forwarding and mailing-list risks. One successful review request is not domain-wide enforcement evidence. DMARC interoperability

Verify DNS and capture separate product-level message evidence

Replace the uppercase placeholders below with your actual zone, authoritative nameserver, and support-issued owners/targets. Repeat for every CNAME. These are proposed commands, not executed checks.

dig NS YOUR_DNS_ZONE +short
dig @AUTH_NS YOTPO_CNAME_OWNER CNAME +noall +answer
dig @1.1.1.1 YOTPO_CNAME_OWNER CNAME +noall +answer
dig @1.1.1.1 YOTPO_CNAME_TARGET TXT +noall +answer
dig @1.1.1.1 _dmarc.YOUR_FROM_DOMAIN TXT +noall +answer

Each owner should return the corresponding target from the current support case. Follow aliases to confirm the available SPF policy or DKIM public key. For a subdomain, absence of an explicit _dmarc record does not prove that no DMARC policy applies; inspect the applicable policy-discovery path and parent policy. DMARC policy discovery

If output is empty, rerun without the output filters. Distinguish NXDOMAIN, a successful response with no requested answer, a timeout and SERVFAIL. A typo or wrong delegated zone is not repaired by waiting for propagation.

After support confirms activation, have the authorized product owner arrange controlled messages:

• Reviews: use the same review-request workflow intended for customers, with an approved test recipient and non-sensitive content. Verify the branded From and configured Reply email.
• Native Loyalty/Referrals: check the relevant native triggered email separately. Do not award real customer benefits or alter production reminders just to create a test; arrange a controlled event with the product owner.
• Preview: Yotpo’s Loyalty Send Preview Email goes to the Contact email in General Settings. It is useful for appearance, but compare it with the real triggered route before using its authentication result as production evidence. Loyalty preview behavior
• External ESP: validate an actual message from that ESP. A native Yotpo preview cannot prove its setup.

Collect full message source at a controlled external recipient. Use the Authentication-Results written by the receiving system you trust, not an arbitrary upstream copy. Authentication-Results trust model

Record which mechanism supplies DMARC pass. If SPF passes but is unaligned, aligned DKIM may still satisfy DMARC. If SPF alone supplies the pass while branded DKIM fails, keep repairing DKIM rather than treating the CNAME deployment as finished. Compare direct and forwarded samples separately: forwarding can change SPF evaluation and message modification can invalidate DKIM.

Decide whether this route is ready

For this branded DKIM-enabled setup, accept the route only when the intended branded DKIM signature passes and aligns, the trusted receiver reports DMARC pass, and the observed From identity is correct. This operational acceptance bar is stricter than DMARC’s minimum rule, which can be satisfied by either aligned mechanism.

Match the intended active Yotpo-issued signature’s d= and s= with the supported account/product configuration and require its passing alignment under effective adkim with the unchanged intended visible From, plus trusted dmarc=pass. Another aligned signer or an unexpected provider-default From does not complete this branded setup.

Inspect SPF independently even if aligned DKIM supplies DMARC pass. An SPF pass that is unaligned is an identity-design observation, not an SPF failure; record it and confirm the intended envelope configuration. Actual fail, softfail, permerror or temperror needs investigation of the real envelope domain, authorization and DNS evaluation. A passing DKIM result does not repair an SPF error. Resolve the problem or record an explicitly accepted, understood route-specific exception before rollout. Do not broaden SPF authorization indiscriminately.

Diagnose the actual smtp.mailfrom result independently: fail or softfail calls for checking the connecting sender against the approved authorization; temperror is a transient evaluation failure, often DNS; permerror requires checking malformed or duplicate policies and the evaluated lookup budget. An aligned DKIM pass does not repair these SPF faults. Do not change an unrelated apex policy to fix a provider-controlled envelope domain. SPF result definitions.

To establish which authentication result is trustworthy, confirm with the receiving mail administrator or provider documentation where authentication is evaluated and how externally supplied Authentication-Results fields are stripped or distinguished. A familiar authserv-id, a convincing hostname or its position near the top of the message alone is not sufficient proof of origin. If that trust boundary is unknown, keep the result unverified and request receiver-side evidence. RFC 8601 forged-header precautions

Troubleshoot the specific failure, then retest

For support, provide the product/account, domain, public DNS observations, validation state, timestamp and redacted authentication headers. Never include private keys, passwords or unnecessary customer message content.

If a rollout fails, pause only the affected message workflow and compare the approved DNS diff. Restore a known-good configuration only with its owner’s approval. Keep selectors needed by queued messages and other integrations. Do not remove all SendGrid-related DNS or weaken the whole domain’s DMARC policy. Repeat the same product-specific acceptance test after any repair, domain migration or key change.