How to set up DMARC/DKIM/SPF for Trustpilot
Updated on 21 Oct 2026: We clarified Trustpilot's SPF instructions, custom-sender limits, and authentication checks for AFS trigger emails.
Trustpilot invitations sent with noreply.invitations@trustpilotmail.com use Trustpilot's domain, so your business domain needs no Trustpilot-specific SPF or DKIM record for that sending path. The documented custom-sender setup does not provide a custom Return-Path. SPF can pass for a Trustpilot-controlled domain while DMARC still fails its domain-match test.
Keep Trustpilot's default sender and verify a real invitation. Publish DMARC separately for your business domain. When a branded From address is mandatory, send Trustpilot-generated invitation links through mail infrastructure that already authenticates your domain.
Check your Trustpilot business domain
Check the business domain in the Trustpilot Business profile before changing invitation settings. This connects the correct public profile and invitation configuration, but it does not authenticate email on its own.
- Claim the profile. Create or claim the business in Trustpilot Business with an email address on the same domain when possible. Open the activation message and complete the account setup.
- Open profile settings. Go to Settings, Public profile settings, then Profile page. Enter the business name and canonical website domain.
- Publish the domain. Select Save and publish. Check that the public profile points to the exact domain customers recognize, including the correct country-domain form where applicable.
- Complete verification. Follow Trustpilot's verification prompt if the account email does not match the website domain. For the registered-domain checkmark, complete Confirm company details and keep the business registration data current. Trustpilot rechecks that ownership data periodically.
Trustpilot Business profile page with the website domain field
Profile verification is separate
A claimed profile or domain-ownership checkmark does not create SPF, DKIM, or DMARC records. Complete Trustpilot profile verification separately from DNS email authentication.
Set up SPF
With Trustpilot's default sender, no Trustpilot mechanism is needed in your business domain's SPF record. The Return-Path uses a Trustpilot-controlled domain, so receiving systems evaluate that domain's SPF policy.
- Open email settings. In Trustpilot Business, go to Settings, Invitation settings, then Email settings.
- Choose the default. Select noreply.invitations@trustpilotmail.com as Sender Email. Set the Sender Name to the business name and set a monitored Reply-to address.
- Preserve one record. Keep exactly one SPF TXT record at each sending domain. Do not publish a second record for Trustpilot.
- Check the lookup count. Keep SPF evaluation within the limit of ten DNS-lookup-causing terms, counting nested includes and redirect across the evaluation. Remove obsolete mechanisms only after confirming that their senders are retired.
A custom Sender Email is available on specified paid Trustpilot plans; check the options in your account. If the Return-Path stays on a Trustpilot-controlled domain while From uses your business domain, SPF does not satisfy the DMARC domain-match requirement, even when SPF authentication passes. Changing the Sender Name or Reply-to address does not change that requirement.
Trustpilot invitation email settings with the default sender selected
Trustpilot SPF verification is separate from DMARC
Trustpilot's SPF instructions name include:trustpilotservice.com for custom-domain sending. If your account requires it, merge that mechanism into the existing SPF TXT record before the final all mechanism. Preserve other authorized senders and the existing ~all or -all ending.
Trustpilot says its SPF check looks for that literal include and does not support SPF flattening. Passing that check does not change the Return-Path or make a different business From domain pass DMARC.
This example applies only when Trustpilot requires the include for your custom sender. Replace the mail-provider placeholder with your existing authorized sender. The example is not needed for the default Trustpilot sender, and adding the include does not repair a Return-Path mismatch.
Conditional custom-sender SPF exampleDNS
Host: @ Type: TXT Value: v=spf1 include:your-mail-provider.example include:trustpilotservice.com -all
Run the Suped SPF checker against the domain you edited. Confirm that it finds one valid SPF policy within the DNS lookup limit and reports no SPF permanent error.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
A clean SPF result confirms the published record is valid. It does not prove that a Trustpilot invitation passes DMARC, because DMARC also compares the authenticated SPF domain with the visible From domain.
Check Trustpilot DKIM support
Trustpilot signs its default invitation mail with infrastructure it controls. This is separate from custom DKIM signing for your business domain. Do not publish a Trustpilot DKIM key under your domain because the documented sender setup has no customer selector and public key workflow.
- Send a test. Open Get reviews, Email templates, select More, then Test last saved version. Deliver it to a mailbox where full headers are available.
- Inspect the signature. Use the receiving mailbox's Authentication-Results and record dkim, header.d, and header.from. A dkim=pass result confirms signature verification, while DMARC also requires the signing domain to match the visible From domain under the applicable comparison mode.
- Keep the default From. When a passing DKIM signature has a header.d domain that matches header.from under the applicable comparison mode, it can satisfy DMARC without any DNS change on your business domain.
- Reject invented selectors. Do not create selector1, selector2, or a copied public key unless Trustpilot provides those exact records inside the account. A guessed DKIM record cannot authenticate Trustpilot mail.
Default Trustpilot sender
- DNS work. No customer DKIM record.
- Expected result. DKIM passes and the domains match.
Custom business sender
The visible From uses your domain while Trustpilot controls the signing domain and Return-Path. Authentication can pass without the domains matching for DMARC.
- DNS work. No documented customer DKIM key.
- Expected result. DMARC fails unless another authenticated domain matches.
If a branded From address must use your domain, generate a unique invitation link through Trustpilot's Invitation API and send it through your existing authenticated mail stream. Confirm API access and invitation allowance in your plan. Use the link-generation operation; the Create invitation(s) operation still sends through Trustpilot. Your mail stream must pass DKIM or SPF with a domain that matches the visible From domain.
Authenticate Automatic Feedback Service trigger emails
Trustpilot's Automatic Feedback Service (AFS) can use a BCC copy of an order confirmation or another transactional email to queue a later review invitation. These are separate messages with separate authentication requirements.
- Authenticate the original transactional email through the system that sends it. If From uses your business domain, that message needs a passing SPF or DKIM domain match, even when the later invitation uses Trustpilot's default sender.
- Use the unique AFS recipient address assigned in Trustpilot Business. Adding that address as BCC does not make Trustpilot the sender of your order confirmations or require a Trustpilot SPF include for those messages.
- If your system sends a separate AFS trigger email, authenticate that sending path too. Test the trigger and the resulting customer invitation separately.
- If no invitation appears, check delivery of the trigger to the AFS address and the invitation status in Trustpilot before changing the invitation sender or your DMARC policy.
Set up DMARC
DMARC belongs on the business domain even when Trustpilot uses its own sender domain. It protects direct use of your domain in visible From addresses and requests aggregate data for finding legitimate and unauthorized sources.
- Check the current policy. Query _dmarc.example.com for example.com, or _dmarc.reviews.example.com if From uses reviews.example.com. Check for an applicable parent-domain policy when no record exists at the From domain. Keep an existing valid p=quarantine or p=reject policy and edit it only when necessary.
- Create the mailbox. Make dmarc@example.com able to receive aggregate XML reports, or replace it with the reporting address assigned by the monitoring workflow.
- Publish one TXT record. For a domain with no applicable DMARC policy, publish the monitoring example below at _dmarc, replacing example.com and the report address with your own values. Do not create multiple DMARC records.
- Retest after DNS. Confirm the authoritative DNS response has updated, then allow older cached responses to expire according to their TTL. Check the version, policy, and aggregate-report address.
Use the Suped DMARC record generator to add tags without introducing syntax errors. For a first deployment, p=none requests reports without asking receiving systems to quarantine or reject failing mail. Other spam and security checks still apply.
Initial DMARC recordDNS
Host: _dmarc Type: TXT Value: v=DMARC1; p=none; rua=mailto:dmarc@example.com
The rua address requests machine-readable aggregate reports, often as compressed XML attachments; reporting is not guaranteed for every recipient. Use a reporting platform to process these at scale. If rua points outside your organizational domain, confirm that the reporting provider has published the required external-reporting authorization. The checker confirms publication, while reports show source and domain-match results.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
The checker should find one applicable DMARC record and parse its tags without errors. The adkim and aspf tags are optional and default to relaxed comparison when omitted. A successful lookup confirms DNS syntax only. It does not confirm that Trustpilot messages pass DMARC.
Verify the sending path with an actual invitation because message headers contain the decisive domains. The Suped DMARC checker and the test message answer different questions, and both results are required before enforcement.
Verify Trustpilot email authentication
A real invitation is the final check. Test the exact template, sender option, and invitation method used in production because a preview cannot prove SPF, DKIM, or DMARC behavior.
Trustpilot email template menu with Test last saved version selected
- Send the production path. Trigger one invitation through the same integration or Trustpilot workflow used for customers, then send a template test as a second sample.
- Open raw headers. Record header.from, smtp.mailfrom, header.d, SPF result, DKIM result, and DMARC result. Do not rely on the visible sender name.
- Compare the domains. DMARC passes when either the passing DKIM domain or the passing SPF Return-Path domain matches the visible From domain under the published comparison mode.
- Classify the failure. SPF and DKIM can both pass while DMARC fails if neither authenticated domain matches From. Read the method attached to each error: spf=permerror includes invalid records or excessive lookups, while dmarc=permerror concerns DMARC evaluation. A temperror indicates a temporary evaluation problem, often a DNS failure.
- Repeat after changes. Send another invitation after changing the sender choice or DNS. Old headers never prove that the updated setup works.
Under DMARC domain comparison rules, relaxed comparison accepts authenticated domains with the same organizational domain, such as mail.example.com and example.com. Strict comparison, selected by aspf=s or adkim=s, requires exact equality for that method. Relaxed comparison does not make trustpilotmail.com match example.com.
|
|
|
|---|---|---|
SPF | Pass | Check Return-Path |
DKIM | Pass | Check signing domain |
DMARC | Pass | Confirm From domain |
rDNS | Present | Supporting evidence only; not a DMARC pass condition |
Header results for a Trustpilot invitation
The Suped email tester supplies a test address and exposes authentication details for the received message. Send a fresh Trustpilot invitation to that address, since forwarding an existing message can change the SPF result. A DMARC pass validates the From domain; it does not guarantee inbox placement.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
If the default Trustpilot sender passes DMARC, no SPF or DKIM record is needed on your business domain for that stream. Keep the headers as a baseline. Invitations with a trustpilotmail.com From domain generally appear in reports for Trustpilot's domain, not your business domain's reports.
If a custom From address produces SPF and DKIM passes for Trustpilot-controlled domains but DMARC fails, the problem is domain matching. Adding more SPF mechanisms to the business domain will not change which Return-Path the receiver evaluated. Switch to Trustpilot's default sender or send Trustpilot invitation links through your authenticated mail system.
Do not weaken DMARC for one sender
Changing the whole domain to p=none removes the request for quarantine or rejection but does not repair Trustpilot's custom-sender failure or guarantee delivery. Fix the sender path instead of lowering an existing enforcement policy.
For a wider DNS review, the Suped domain health checker checks the business domain beyond the one invitation. Trustpilot's own deliverability guidance also treats domain authentication as a core sender-reputation control.
Monitor authentication changes
A one-time test cannot catch a later sender change, deleted TXT record, expired configuration, or new unauthorized source. Suped is our DMARC and email authentication platform. Use it to process reports for your business From domains, identify failing sources, and track the repairs.
- Route aggregate reports. Use the reporting address provided during Suped setup in the rua tag, then verify that reports arrive for every protected domain.
- Identify business-domain traffic. For custom business From addresses, compare reported IP and authentication domains with a known test invitation and its sending window. Aggregate reports do not provide individual message timestamps. Do not classify a source by rDNS alone.
- Enable failure alerts. Set failure thresholds and investigate newly observed sources. Aggregate reports usually cover daily activity, so alerts based on those reports depend on when receivers send them.
- Review weekly summaries. Check reported business-domain volume and pass rates. For Trustpilot's default sender, check invitation delivery results in Trustpilot and repeat direct invitation tests after sender changes.
Suped's DMARC monitoring shows reported sources and SPF and DKIM domain-match results. Compare those results with message headers to decide whether the repair belongs in DNS or the sending route. Aggregate reports are delayed observations, not a live feed of every invitation.
Alert on changes that need action
- New source. Confirm ownership before authorizing it.
- Failure spike. Compare it with the last Trustpilot test.
- Record change. Check who changed DNS and restore the approved value.
- Unknown volume. Investigate before changing policy.
Secure your domain with p=reject
Move to p=reject only after legitimate mail using your business From domain has a passing DKIM or SPF domain match. Your business policy does not govern invitations sent from Trustpilot's own domain. Move a failing custom business sender to the default address or an authenticated sending route before enforcement.
- Observe normal volume. For a new deployment, keep p=none long enough to capture routine business-domain mail and less frequent operational senders. Inventory order confirmations and billing mail as well as custom-domain review invitations. Keep an existing enforcement policy while repairing sources.
- Resolve every source. Mark each sender authorized or unauthorized. Repair authorized senders, retire unused sources, and do not whitelist an unexplained IP range.
- Apply quarantine. Publish p=quarantine only when legitimate pass rates are stable. Watch for rejects, spam placement, and new failures during a full operating cycle.
- Enforce rejection. Publish p=reject after quarantine shows no unexplained legitimate failures. Continue monitoring because vendor and DNS changes can break a working source later.
Quarantine policyDNS
Host: _dmarc Type: TXT Value: v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com
At quarantine, run another production-path Trustpilot invitation and verify the received headers. A custom business-domain From that still lacks a matching authenticated domain is not ready for reject.
Reject policyDNS
Host: _dmarc Type: TXT Value: v=DMARC1; p=reject; rua=mailto:dmarc@example.com
Suped's hosted DMARC supports policy staging after its initial DNS setup. Review reported sources and remaining failures before changing policy, then keep failure alerts active after p=reject. Those alerts depend on incoming reports.
Trustpilot decision before reject
- Default sender. Keep it when the test shows a DMARC pass.
- Custom sender. Do not enforce until a test shows a matching authenticated domain.
- Branded alternative. Send Trustpilot invitation links through your authenticated mail stream.
- Ongoing control. Keep alerts active after the policy change.
Frequently asked questions
No, not when invitations use noreply.invitations@trustpilotmail.com. Receivers check SPF against Trustpilot's Return-Path domain. Adding a Trustpilot-related include to your business domain does not create a domain match when the Return-Path remains under Trustpilot's control.
The documented custom-sender setup has no custom Return-Path or customer-domain DKIM workflow. If SPF and DKIM authenticate only unrelated Trustpilot domains, a business-domain From address fails DMARC. Confirm the received headers for your account before enforcement. Use the default sender or send invitation links through your authenticated mail stream when the custom address fails.
No. Reverse DNS (rDNS) identifies a sending host and is only a clue when infrastructure is shared. Confirm a suspected Trustpilot source by comparing a known test invitation with its sending IP, Return-Path, DKIM signing domain, and visible From domain.
It is the SPF include named in Trustpilot's custom-sender instructions. If required for your account, add it to the existing SPF record rather than creating a second record. It authorizes the included sending infrastructure when that SPF policy is evaluated; it does not create a custom Return-Path or a business-domain DKIM signature.
A default Trustpilot invitation that passes DMARC under Trustpilot's own From domain is evaluated against Trustpilot's policy, not your business domain's policy. An invitation using your business domain in From can be rejected under your p=reject policy when neither SPF nor DKIM has a passing domain match. Test that exact path before enforcement.
