How to handle DMARC failures when using TrustPilot email invitations with a custom domain?
Michael Ko
Co-founder & CEO, Suped
Published 17 Apr 2025
Updated 17 Aug 2025
7 min read
Dealing with DMARC failures when using a third-party sender like TrustPilot for email invitations with your custom domain can be a real headache. It is a common scenario where a service sends emails on your behalf, but their technical setup doesn't quite align with modern email authentication standards, specifically DMARC.
The core of the issue often stems from how these platforms handle SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) authentication. While they might pass SPF, they often fail to provide DKIM alignment or DMARC enforcement for emails sent using your domain. This misalignment means that even if the emails are technically authenticated, DMARC will view them as unauthenticated for your domain, potentially leading to delivery issues like landing in spam folders or being rejected outright.
I've seen this challenge countless times, and it is a frustrating barrier to maintaining a strong sender reputation and ensuring your important invitation emails reach their intended recipients. Let us dive into understanding why this happens and what practical steps you can take to mitigate these DMARC failures.
DMARC (Domain-based Message Authentication, Reporting, and Conformance) relies on the alignment of either SPF or DKIM with the domain in the From header. When a third-party service like TrustPilot sends emails on your behalf, they often use their own infrastructure and return-path domain for SPF. If they do not also sign the email with your domain's DKIM key, or if the domain in the From header does not align with their SPF-authenticated domain, DMARC will fail. This is a common challenge with many email service providers, not just TrustPilot.
Specifically, TrustPilot, for its invitation emails sent via a custom domain, generally only supports SPF. This means that while the Return-Path (or MailFrom) domain might pass SPF, the From header, which contains your custom domain, won't achieve DMARC alignment through SPF. Without DKIM signing from your domain, DMARC validation will fail, leading to significant deliverability issues.
This situation is not unique to TrustPilot. Many third-party senders, for various reasons, do not provide the necessary DKIM or DMARC configurations that allow full alignment with your custom domain. This oversight can seriously impact your email deliverability, especially when your DMARC policy is set to p=quarantine or p=reject. If you are encountering these issues, it is crucial to understand how to troubleshoot DMARC failures.
Immediate workarounds for DMARC failures
The most straightforward solution to avoid DMARC failures when a third-party sender doesn't offer full DMARC alignment is to revert to sending emails from their domain instead of your custom domain. For TrustPilot, this means using their default noreply.invitations@trustpilotmail.com address. While this might feel like a step backward for branding, it ensures your emails pass DMARC checks, as TrustPilot (or any reputable ESP) will properly authenticate emails from their own domain.
If maintaining your custom domain in the From header is critical for branding, another approach is to use a dedicated subdomain for these invitations, rather than your main sending domain. This allows you to set a more lenient DMARC policy (like p=none) on the subdomain without compromising the security and deliverability of your primary domain. For more information on why emails might be failing due to DMARC, SPF, and DKIM, read about why emails go to spam.
While it is a suboptimal solution, setting a p=none DMARC policy on a dedicated subdomain can prevent rejections while you work with the vendor. This policy tells receiving mail servers not to take any action if DMARC fails, only to report. This is a temporary measure, not a long-term solution for optimal security and deliverability.
Using a dedicated subdomain for invitations
Isolate risk: By using a subdomain, DMARC failures only affect that specific subdomain, protecting your main domain's reputation.
Flexible policy: You can set a p=none policy for the subdomain to allow invitations through while still monitoring for issues.
Sample DMARC record for a subdomain
DNS TXT Record for _dmarc.invitations.yourdomain.com
If a third-party vendor like TrustPilot is crucial to your operations, it is worth engaging with their support team to advocate for full DMARC support, including DKIM signing for custom domains. Many services use robust email infrastructure like Twilio or SendGrid, which inherently support DKIM and DMARC, meaning the limitation is often a business choice rather than a technical one on their end. Highlight the importance of DMARC compliance for modern email security and deliverability.
Review TrustPilot's invitation email settings on their help pages to ensure you are following all their guidelines for custom domain usage. Sometimes, there are specific DNS records or settings that need to be configured on your end to enable better authentication, even if it is not full DMARC. Always double-check their most up-to-date documentation.
If discussions with the vendor do not yield results, and the custom domain for TrustPilot invitations remains problematic, consider alternative solutions for collecting customer feedback. This could involve using a different review platform that offers robust DMARC support, or integrating review requests directly into your post-purchase email flows using a fully DMARC-compliant ESP you control. This ensures your email deliverability is not compromised.
Monitoring and maintaining deliverability
Proactive DMARC monitoring is essential. Even with workarounds, keeping an eye on your DMARC reports will give you insights into how your emails are being treated by recipient servers. These reports detail which emails are passing or failing DMARC, and why. Tools that help understand DMARC reports can pinpoint specific issues and help you track improvements over time.
While dealing with third-party DMARC issues, ensure your primary email sending domains are fully DMARC compliant. Regularly check your SPF, DKIM, and DMARC records for accuracy and proper configuration. A well-configured DMARC record, especially with a p=reject policy, protects your brand from phishing and spoofing. You can use a free DMARC record generator to ensure correctness.
It is also crucial to be aware that email forwarding can break DMARC alignment. When a recipient forwards an email, the original authentication headers might be stripped or altered, leading to DMARC failures for the forwarded message. This is a separate but related issue to consider when evaluating DMARC reports. Monitoring for blocklist (or blacklist) listings is also important, as persistent DMARC failures can negatively impact your sender reputation, potentially leading to listings on a blocklist (or blacklist). You can check whether your domain is on a blocklist.
Sending from your custom domain (TrustPilot)
Pros: Stronger brand identity and recognition for recipients.
Cons: DMARC failures due to lack of DKIM alignment from TrustPilot.
Deliverability impact: High risk of emails landing in spam or being rejected, especially with strict DMARC policies.
Sending from TrustPilot's domain
Pros: Emails are fully DMARC compliant and authenticated by TrustPilot's domain.
Cons: Less direct brand association in the sender address.
Deliverability impact: High deliverability as emails pass all authentication checks.
Conclusion
Handling DMARC failures, especially with third-party senders like TrustPilot, requires a strategic approach. While the ideal solution involves the third-party provider offering full SPF and DKIM alignment for your custom domain, immediate workarounds such as reverting to their sending domain or using a dedicated subdomain with a lenient DMARC policy can help maintain deliverability. Long-term, advocating for better authentication support from vendors and continuous monitoring of your DMARC reports are key to protecting your sender reputation and ensuring your emails reach the inbox.
Views from the trenches
Best practices
Ensure your email service provider fully supports DMARC alignment for all emails.
Utilize a dedicated subdomain for third-party transactional emails if direct DMARC alignment is not feasible.
Regularly monitor your DMARC reports for insights into email authentication results and potential issues.
Engage with third-party vendors to advocate for improved DMARC support, including DKIM signing.
Maintain proper SPF, DKIM, and DMARC records for your primary sending domains to protect your brand.
Common pitfalls
Relying solely on SPF for third-party sending without verifying DKIM alignment will lead to DMARC failures.
Ignoring DMARC reports, which can hide critical deliverability issues and potential spoofing attacks.
Applying a strict DMARC policy (p=reject) without ensuring all legitimate senders are aligned.
Using your main sending domain for services that do not fully support DMARC alignment, risking your primary reputation.
Failing to adapt to evolving email authentication standards and requirements from mailbox providers.
Expert tips
If a vendor only supports SPF, ensure the SPF domain matches the sending domain for compliance.
Implement DMARC gradually, starting with a `p=none` policy to gather data before enforcing stricter policies.
Consider a phased rollout of DMARC enforcement by subdomain to manage risk.
Regularly audit all third-party senders to ensure they meet your DMARC compliance requirements.
Automate DMARC report analysis to quickly identify and resolve authentication issues.
Marketer view
Marketer from Email Geeks says that TrustPilot email invitations, when using a custom domain, only support SPF, which is insufficient for DMARC alignment, leading to deliverability problems. They were looking for a way to own the email sending process but found it problematic.
Feb 2, 2024 - Email Geeks
Expert view
Expert from Email Geeks suggests that if the vendor does not support DMARC/DKIM, using a dedicated subdomain for these emails could be a viable workaround.
