Troubleshooting

DNS propagation can take up to 48 hours, but it's usually much faster. Start by checking whether your records are actually visible publicly:

1. Go to dnschecker.org and paste in the full Name of one of your DKIM CNAME records (e.g. em1234._domainkey.yourdomain.com).
2. Select CNAME from the record type dropdown and click Search.
3. If you see green checkmarks with the expected value from multiple locations, the record is live — try clicking Verify records in PristineSend again.
4. If most locations show red X marks, DNS hasn't propagated yet. Wait another few hours and check again.

If dnschecker.org shows the records are live globally but PristineSend still won't verify, there may be a typo. See Records added but still failing.

This is almost always a typo or formatting issue. Check each of the following:

• Wrong record type. DKIM records must be CNAME, not TXT. DMARC and SPF records must be TXT, not CNAME. Using the wrong type is a common mistake.
• Trailing dot in the value. Some registrars (and DNS export tools) append a trailing dot to CNAME values — for example, em1234.dkim.pristinesend.com. with a dot at the end. Delete the trailing dot.
• Root domain included in the Name. If your registrar asks for the full record name, use em1234._domainkey.yourdomain.com. If it asks for just the subdomain, use em1234._domainkey. Adding your domain twice creates a record on the wrong host.
• Copied the wrong record. Double-check that the value in your registrar matches exactly what's shown in PristineSend settings — character for character.
• Only added one or two of three DKIM CNAMEs. DKIM requires all three records. Check that you have all three in your DNS panel.

Cloudflare proxies DNS records by default (the orange cloud icon). When a CNAME is proxied, Cloudflare intercepts and rewrites the lookup — which breaks DKIM verification.

1. Log in to the Cloudflare dashboard and open DNS → Records.
2. Find each of your three DKIM CNAME records (names containing _domainkey).
3. Click the orange cloud icon next to each one to switch it to DNS only (the icon turns grey).
4. Wait a few minutes for the change to take effect, then click Verify records in PristineSend.

Your DMARC and MAIL FROM records don't need to be proxied either — grey cloud is correct for all email authentication records.

PristineSend's records don't conflict with Google Workspace or Microsoft 365. Here's why:

• DKIM records are on unique subdomains. Google's DKIM record lives at something like google._domainkey.yourdomain.com. PristineSend's DKIM records use different subdomain names (e.g. em1234._domainkey). They coexist without any conflict.
• MX records are for receiving, not sending. Your existing MX records (pointing to Google or Microsoft mail servers) handle incoming email for your team. PristineSend only sends — it doesn't affect those records.
• SPF records need merging if you use custom MAIL FROM. Your root domain's SPF record (at yourdomain.com) authorises which services can send from your main domain. PristineSend's custom MAIL FROM uses a subdomain (like bounce.yourdomain.com), so it's a separate TXT record and doesn't touch your existing SPF.

If you're unsure, add the PristineSend records and check your Google Workspace or Microsoft 365 mail flow after — it should be completely unaffected.