Trustpilot SPF, DKIM and DMARC setup, step by step

For Trustpilot-hosted review invitations, the simplest documented choice is the default sender, noreply.invitations@trustpilotmail.com. Trustpilot recommends that option. Its Premium and Enterprise plans also offer a custom Sender Email and document the SPF mechanism include:trustpilotservice.com, but the same official SPF guide explicitly says it does not support DKIM and DMARC schemes. Do not interpret the custom sender field or SPF include as a complete branded-domain authentication setup. Invitation email settings, Trustpilot SPF instructions.

This guide explains the supported choices, safe SPF handling and the validation needed before using a business-domain From address. No Trustpilot account, DNS change or invitation send was tested.

Identify who sends the review invitation

A Trustpilot link in an email does not necessarily mean Trustpilot sent that email.

Trustpilot's invitation-methods guide distinguishes automatic invitations from invitation links and other collection methods. Follow its fair, unbiased invitation requirements. Changing delivery method can also change the review's collection label; do not promise the same review status merely because the URL points to Trustpilot.

Before editing DNS, record the business unit/domain, plan, invitation method, visible From address, Reply-To and sending system. For multiple stores or business units, keep separate records rather than assuming one sender setting applies everywhere.

Default sender, sender name and Reply-To are different

The documented settings path is Trustpilot Business > Settings > Invitation settings > Email settings. You can choose templates, the company identifier, Sender Name and Reply-to address. Trustpilot's default reply address is the login email, and the settings page provides Manage your Reply-to emails to change it. The custom Sender Email feature is identified as Premium and Enterprise. Current settings documentation.

For a default-sender configuration, retain noreply.invitations@trustpilotmail.com and use an appropriate business name and monitored reply address. No instruction in that route requires you to publish Trustpilot DKIM records in your business-domain DNS. A business name or Reply-To address can make the message recognizable, but it does not change the domain DMARC evaluates in the From address.

The official settings page recommends Trustpilot's default sender. Its own-domain option asks you to enter the sender manually and consider SPF setup. That is not evidence of account-generated branded DKIM keys, custom return-path controls or guaranteed DMARC alignment.

Add the documented Trustpilot SPF mechanism safely

For the eligible custom-sender workflow, Trustpilot documents this mechanism:

include:trustpilotservice.com

It is an SPF mechanism, not a complete policy. The official SPF page says its checker looks specifically for that literal include and does not support SPF flattening. Replacing the include with a manually copied IP list may therefore fail Trustpilot's check and introduces maintenance risk.

Ask the DNS administrator to locate the existing SPF TXT policy for the intended domain. If it exists, insert the mechanism before its terminal all, preserving the other approved senders and existing qualifier. The following illustrates a merge; spf.current-provider.example is a placeholder, not a usable authorization:

Before: v=spf1 include:spf.current-provider.example -all
After: v=spf1 include:spf.current-provider.example include:trustpilotservice.com -all

Do not copy a duplicate v=spf1 prefix or create a second competing SPF record. If there is no policy, inventory the domain's legitimate senders before building one. Trustpilot's official instructions direct users without an existing SPF record to their domain provider; they do not justify erasing another service's settings.

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.

These are owner examples, not a recommendation to create an unnecessary subdomain. Some editors require full names. Inspect the resulting owner to avoid reviews.example.com.example.com. Preserve unrelated TXT records, MX delivery and other DKIM selectors. If the intended SPF owner is a CNAME, do not add TXT data beside it; reconcile the design first.

SPF allows one policy per owner, and its evaluation is limited to ten DNS-dependent terms, including nested includes and redirects. Adding one visible include can add several nested lookups. A root policy does not automatically cover a subdomain. SPF publication and limits.

Why an SPF include does not prove DMARC alignment

SPF checks the connecting sender against the SMTP MAIL FROM domain. The visible From address is a different identity. Read smtp.mailfrom from a trusted receiver's Authentication-Results and compare it with From; do not assume the business domain was evaluated simply because you edited its SPF record. SPF MAIL FROM identity.

If the actual envelope domain is controlled by Trustpilot, SPF can pass there without aligning with From: reviews@example.com. Adding the include at example.com cannot change the envelope domain emitted by the sender. The reviewed official setup pages do not establish a custom return-path procedure, so this guide supplies none.

DMARC requires a passing aligned SPF result or a passing aligned DKIM signature. Under relaxed alignment, the domains share an organizational domain; strict alignment requires the exact same domain. For example, a passing envelope identity at bounce.reviews.example.com can align with reviews.example.com in relaxed mode but not strict mode. An unrelated provider domain does not align in either mode. DMARC alignment rules.

What can you configure for Trustpilot DKIM?

The current Trustpilot SPF page expressly says DKIM and DMARC schemes are not supported. In the context of this own-domain sender workflow, it does not provide customer selectors, CNAME targets, public keys or a signing-activation step. There is no verified customer-DKIM recipe to publish here.

Do not invent a selector such as trustpilot._domainkey, use an online key generator or borrow SendGrid records because a message happens to pass through related infrastructure. A public key is useful only when the actual sender signs with its matching private key. DKIM signature and key lookup.

This limitation is not a claim that Trustpilot never authenticates mail using its own domains. It means the documented custom-sender setup cannot be treated as a supported branded-DKIM implementation. If your requirement is your own From domain plus a passing aligned branded DKIM signature, keep that requirement open. Use the default hosted sender, or consider sending an allowed review link through an email system that already supports your domain's SPF, DKIM and DMARC. Do not weaken the domain's policy to accommodate an unsupported route.

If Trustpilot Support offers a different, account-specific supported capability, obtain written documentation identifying the product, plan, domain, generated records and activation process before changing DNS. A sales claim or a successful SPF-string check is insufficient acceptance evidence.

Keep your business-domain DMARC protection

Trustpilot's custom-sender limitation does not prevent you from protecting your own business domain with DMARC. Preserve the established policy and report destinations. Do not remove p=reject, disable alignment or replace an existing record with p=none merely to allow custom-address invitations.

For a domain with no established policy, an approved monitoring record can help inventory all legitimate senders before enforcement. An example, only after provisioning the report mailbox, is:

Use a first policy only if no direct or applicable inherited policy exists and the domain owner approves the monitoring and review plan. For full owner _dmarc.example.com, use relative _dmarc in example.com. For full child owner _dmarc.reviews.example.com, use _dmarc.reviews in that parent zone or _dmarc at a separately delegated reviews.example.com authority. Preserve delegation, existing policy and authorized reporting destinations. This is not a native Trustpilot DKIM issuance workflow. DMARC publication.

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

This is not a Trustpilot setup value. Publish one DMARC record at the owner, use a reporting destination your organization controls or has approved, and arrange external-destination authorization where needed. Inspect any sender-subdomain policy as well as the parent. Monitoring reports expose authentication outcomes; they do not grant Trustpilot DKIM support.

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.

When using Trustpilot's default From domain, your business-domain DMARC dashboard need not contain those invitations, because their visible From is not your business domain. That absence is not proof of failed delivery or proof that the business domain has no other unauthorized senders.

Validate the chosen route without false positives

DNS checks

Use the real sender/envelope domains in place of these examples. These are read-only diagnostic commands, not checks performed for this article.

dig +short TXT example.com
dig +short TXT reviews.example.com
dig +short TXT _dmarc.example.com
dig +short TXT _dmarc.reviews.example.com

For the documented custom-sender SPF check, confirm one syntactically valid SPF policy containing the literal Trustpilot include at the intended owner. Then separately query the actual SPF domain found in a delivered message. An empty response at the wrong owner is not evidence about the correct one. Investigate duplicate policies, malformed syntax, NXDOMAIN and SERVFAIL; compare authoritative and recursive results if propagation is suspected.

There is no customer-generated Trustpilot DKIM selector to guess. If inspecting an actual signature, take its s= and d= values from the received header and query s._domainkey.d using those exact values. A DNS key's presence does not prove that the message signature passes or that its domain aligns.

For a message with multiple signatures, EmailAuth’s DKIM selector guide explains how to keep each actual d= and s= pair together for its public-key lookup. It does not supply a missing provider signing feature.

Delivered-message checks

Arrange a separately authorized, harmless invitation to a controlled mailbox using the intended business unit and method. Do not upload a customer list or send invitations merely to follow this written guide. Open the original message at its recipient, not a forwarded copy.

Use Authentication-Results generated within the recipient's verified mail-system trust boundary. Confirm the authoritative authentication service and inbound forged-header filtering with its administrator. Neither a copied line nor a familiar authserv-id establishes that the receiver produced the result. RFC 8601, section 7.1. For branded-DKIM acceptance, require the intended branded signature to pass and align even if SPF alone produces dmarc=pass. The documented Trustpilot custom-sender path does not provide the DKIM configuration needed to promise that outcome.

For a separately chosen own-provider route, or a future documented custom capability, require the intended route-specific signature matched by its active d= and s= to pass and align under the effective adkim mode with the unchanged approved branded From, plus trusted receiver dmarc=pass. A rewritten provider From or a different aligned signer does not complete that branded requirement. The default Trustpilot From remains a valid separately selected route, not customer-domain DKIM. Signature identifiers, alignment.

Distinguish spf=pass on an unaligned provider domain from an actual error. If SPF returns fail or softfail, inspect authorization and the route used. For permerror, check duplicate records, syntax and lookup limits. For temperror, investigate DNS resolution and retest. A passing aligned DKIM result can satisfy DMARC, but it is not a reason to ignore a genuine SPF defect.

Troubleshooting Trustpilot invitations

Give Support the invitation method, plan, business unit, UTC test time, sender domain and redacted receiver results. Do not send customer lists, message bodies or authentication credentials unnecessarily.