To authenticate Privy email, add your root domain under Settings → Email Settings → Sending Domain, publish the exact CNAME and TXT records Privy generates, then choose Verify and Set Default. Set the intended From address and update emails created before the change. Finish by checking public DNS and a delivered message for a passing, aligned Privy DKIM signature and a DMARC pass. Current Privy setup instructions.
There is no universal Privy SPF value to copy from this guide. The current workflow uses account-generated records, while older third-party instructions describe different infrastructure. Do not add a historical Mandrill include to a shared SPF policy without current instructions for your actual Privy sending route.
This guide covers Privy's own email campaigns and flows using a custom sending domain. It does not authenticate another email platform merely because Privy collects or synchronizes contacts to it. It also does not configure SMS or provide mailbox hosting.
Check the prerequisites and existing senders
Privy requires a domain you own, DNS editing access and a website hosted at the root domain. Its documented registration accepts example.com, not a subdomain such as mail.example.com; a Gmail or Yahoo address does not qualify. These example names illustrate the distinction and are not DNS records to publish. Custom-domain prerequisites.
Confirm that the account has email-sending capability. Privy's pricing distinguishes its Email service from Pop-ups & Displays-only plans. The current custom-domain article does not specify a separate authentication tier, so do not assume a display-only account can send email or that a paid upgrade is necessarily required just to fix DNS. Check the account's entitlement if Email Settings are unavailable. Privy's current plans.
Before changing records, record the domain's authoritative DNS host and save its current SPF, DMARC, DKIM selectors, MX and web records. Include all senders sharing the domain, particularly the ecommerce platform, employee mail and any previous marketing service. An unused-looking s1._domainkey or s2._domainkey name may already belong to another active sender.
Keep the intended From address, business account and generated record set together. If an agency manages several stores, copying the right-looking record from the wrong store is still an authentication error.
Generate the records in the current Privy dashboard
Open Settings from the lower-left dashboard navigation, choose Sending Domain within Email Settings, and use + Add Sending Domain. Enter the owned root domain and save. Privy displays the generated records; use DNS Records on the domain row to reopen them later. Privy's current workflow.
Create a worksheet with the record type, complete owner name, exact value and purpose for every row. Privy describes a mixture of CNAME and TXT records. Treat the actual output as authoritative for this account, rather than forcing all rows into a single type.
The public troubleshooting examples include these owner families:
scphXXXX._domainkey
s1._domainkey
s2._domainkey
privy-sg
privy._verification
These are recognition aids, not a complete reusable DNS template. XXXX is a placeholder, and the sample numeric selector in a help article is not your assigned key. The account's targets and public-key data must be copied exactly. A verification token proves the relevant domain-control check; it is not automatically an SPF policy or a DKIM key.
Do not create your own private/public key pair and expect Privy to sign with it. The sending service must hold the corresponding private key and use the matching signing configuration. Publishing an unrelated public key cannot enable that behavior. How DKIM keys and signatures relate.
Publish CNAME and TXT records safely
Translate each full owner into the DNS editor's expected form. If the zone is example.com and the editor appends it automatically, the relative owner s1._domainkey becomes s1._domainkey.example.com. If the editor requires a fully qualified name, enter that full name instead. Do not create s1._domainkey.example.com.example.com by appending the suffix twice.
Registering a root domain in Privy does not mean every DNS record is located at @. Most generated owners are beneath that root. If an authentication subtree is already delegated to another DNS service, use its actual authoritative zone and calculate the owner relative to that zone. Do not move DNS authority or add a competing parent-zone copy to work around a delegation.
For an actual issued full owner s1._domainkey.example.com in an existing separately delegated _domainkey.example.com namespace, enter relative s1 at that authority. This is a placement example only: use the actual issued selector and type, preserve existing NS and other selectors, and do not interpret it as support for registering a child sending domain in Privy. Relative DNS names.
Check for conflicts before adding CNAMEs. A normal CNAME cannot share its owner with ordinary TXT, MX or address records. At a zone apex it would also conflict with the zone's SOA and NS. Preserve another sender's existing selector and request a supported alternative from Privy if the generated name collides. Do not delete the other sender's record to make Privy's check pass. CNAME coexistence rules.
Where the DNS host offers CDN proxying, keep provider-required literal CNAMEs DNS-only. Also check both per-record flattening and a zone-wide “flatten all CNAMEs” setting. Verification may need the alias itself, not the IP addresses produced by flattening. Any change to shared zone settings needs a dependency review; prefer a record-specific exception rather than disabling website protection or changing nameservers. Cloudflare's documented verification caveat.
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.
Publish TXT content as supplied. A long DKIM key may be displayed as several quoted character-strings within one TXT record; those strings are concatenated by the verifier. Confirm the DNS provider's method before splitting the value. Do not create separate competing DKIM TXT records or lose characters from the key. DKIM TXT retrieval.
Handle SPF using the actual sending identity
SPF authorizes the connecting server for the SMTP envelope sender domain, normally reflected in Return-Path. It does not automatically check the visible From domain. A root SPF addition cannot change the envelope address selected by Privy. SPF identity rules.
The current Privy custom-domain page does not publish a single universal root SPF include or promise an exact envelope identity for every account. Use the generated record set and inspect the delivered route. Privy's broader authentication article contains illustrative Google-related SPF values, but those examples are not instructions to authorize Google for Privy mail. Privy's authentication overview.
If Privy supplies a CNAME for an envelope/bounce owner, keep that owner and target exactly as generated and examine its resolved SPF data. Do not place SPF TXT alongside the CNAME. If current account instructions explicitly require an SPF TXT update at an owner that already has SPF, merge the authorized mechanism into the existing policy under change control. Keep one v=spf1 record there and preserve other legitimate senders and the intended terminal policy.
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.
Evaluate the whole SPF path against the ten DNS-querying-term limit, including nested include and redirect processing. It is not a limit of ten textual includes or ten DNS records. Duplicate SPF policies, malformed syntax and excessive evaluated lookups can cause permerror; temporary DNS failures can cause temperror. SPF publication and lookup limits.
A provider-owned envelope domain can pass SPF without aligning with your From domain. In that case an aligned branded DKIM signature can provide the DMARC path. This is a conditional interpretation, not a claim that every Privy account uses the same Return-Path. An actual SPF failure remains a fault to investigate even when DKIM supplies DMARC.
Verify, set the default, and update older emails
After publishing all required rows, return to the domain's records in Privy and select Verify and Set Default. The documented button both checks DNS and selects the domain for future emails. Privy allows up to 48 hours for DNS changes to become visible, but a wrong owner, conflict or truncated value should be corrected rather than left to “propagate.” Verification and default selection.
Next, open Email Settings → Sender Options. Set the username in Default From Email, confirm the desired domain on the right side of @, and save. If you leave the default username unchanged, Privy documents offers as the default for the custom domain.
Existing emails need a separate review. Open each relevant email's editor, select From under Sender Info, enter the intended address, select the verified domain and save. Check both existing campaigns and flow emails. A new account default does not establish that already-created messages have changed.
Privy's authentication overview distinguishes its DNS-record check from its DMARC-policy check. It says an account can show Can send emails when DNS passes even if DMARC does not. That is not a completion criterion for this guide: validate DMARC coverage and the actual delivered-message identities as well. Do not treat an unexplained status combination as authorization to bypass the checks. Privy sending-status documentation.
The custom-domain guide also notes that an scphXXXX._domainkey TXT row may remain unverified in some hosting configurations that use a different DKIM arrangement. Treat this as a narrow provider-documented exception. Confirm the active signing route with Privy and require its intended signature to pass and align. It is not permission to ignore all DKIM failures or a missing branded signature.
Keep the applicable DMARC policy intact
DMARC compares the visible From domain with authenticated SPF and DKIM identities. Either an aligned SPF pass or an aligned DKIM pass can satisfy DMARC. Relaxed mode uses the applicable organizational-domain relationship; strict mode requires identical domain names. For a branded Privy deployment, additionally require the intended Privy signature to pass and align, so a DMARC pass achieved only through another mechanism does not conceal broken DKIM. DMARC, RFC 9989.
Read the exact From-domain policy and any applicable inherited policy before publishing a replacement. Preserve p, sp, np, adkim, aspf and approved reporting settings. An explicit valid From-domain policy takes precedence; otherwise current discovery can find the organizational-domain or applicable public-suffix policy. Root registration in Privy does not justify changing policy for other senders or weakening inherited enforcement.
If no policy exists, agree a monitored rollout and an authorized report destination with the domain owner. Do not blindly apply a generic p=quarantine example before legitimate sources have been assessed. A monitoring policy without rua does not request aggregate reports. See EmailAuth's guide to strict and relaxed alignment before changing the domain relationships your policy accepts.
Only after establishing that no direct or inherited DMARC policy applies, an owner-approved monitoring record can begin as:
Type: TXT
Full owner for From example.com: _dmarc.example.com
Value: v=DMARC1; p=none
In a suffix-appending example.com zone, enter _dmarc; use the full owner when the DNS interface requires it. For general policy assessment of a child From domain, the direct owner would be _dmarc.CHILD.example.com, entered as _dmarc.CHILD in the parent zone or _dmarc in a delegated child zone. Those child examples explain DNS placement, not supported subdomain registration in Privy. Keep one DMARC policy at an owner: edit an existing record instead of adding a duplicate. If aggregate reporting is approved, append ; rua=mailto: and your actual authorized reporting address to the same value. Do not use an example mailbox.
For rua destinations in another organizational domain, arrange the external reporting authorization required by RFC 9990. Use the reporting service's exact instructions, preserve approved destinations and obtain privacy approval before sharing domain-level sending data. Do not copy an arbitrary report address. More detailed failure reports can expose different information and need separate consideration. Aggregate reports and external 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.
Check public DNS and the final receiver's results
Use the actual generated owner names in these read-only examples. They are placeholders, not a customer test log:
dig +short NS YOUR_ZONE
dig @YOUR_AUTHORITATIVE_NS GENERATED_TXT_OWNER TXT +noall +answer
dig @YOUR_AUTHORITATIVE_NS GENERATED_CNAME_OWNER CNAME +noall +answer
dig @1.1.1.1 GENERATED_TXT_OWNER TXT +noall +answer
dig @1.1.1.1 GENERATED_CNAME_OWNER CNAME +noall +answer
dig @1.1.1.1 SELECTOR._domainkey.SIGNING_DOMAIN TXT +noall +answer
dig +short TXT _dmarc.YOUR_FROM_DOMAIN
Check every required row against the account output on authoritative DNS and at least one public resolver. Follow a DKIM CNAME to its public-key TXT target. If a selector has changed, query the one the delivered signature actually uses. Distinguish an absent record from a DNS timeout and from a cached older answer.
Then have the authorized owner send representative new-campaign and existing-flow messages through their intended Privy routes to a controlled external mailbox. Include an older email after changing its From address. These samples test the sender selection, not just DNS publication.
Trust only authentication results from receiving infrastructure you control or trust. An attacker can prepend Authentication-Results; a familiar authserv-id string alone proves nothing. If the receiver cannot distinguish or remove untrusted fields, use an independent trusted mailbox or message trace. RFC 8601's trust boundary.
For each sample, retain the visible From domain, smtp.mailfrom, intended DKIM d= and s=, receiver results and applicable alignment modes. Acceptance requires the intended branded DKIM pass and alignment, dmarc=pass, the right From address and no unexplained SPF fault. A provider-only passing signature or a green dashboard status does not meet that test. Redact recipient details and content before sharing diagnostic evidence.
Troubleshooting and frequently asked questions
Why does Privy reject my subdomain?
The documented custom-domain registration requires the root domain and a website at that root. Register the supported domain rather than trying to work around the form with DNS aliases. Keep the generated child record owners exactly as issued.
My domain verified, but old emails still use the shared address. Why?
Default changes apply to newly created emails. Review each existing email's Sender Info → From setting and select the verified domain. Inspect a newly delivered sample after saving rather than relying on the editor's preview.
Should I use the Mandrill SPF record from an older Privy guide?
Not without current account-specific confirmation. The present setup generates its own records. A historical service assumption can add irrelevant authorization and lookup cost while leaving the actual envelope route unchanged.
Can I ignore an unverified scph DKIM row?
Only after Privy confirms the documented alternate signing arrangement applies and delivered evidence proves the intended signature passes and aligns. If no aligned branded DKIM signature is present, the setup is not complete, even if another mechanism makes DMARC pass.
What if s1 or s2 is already in use?
Identify the current owner and sender. Do not overwrite a live DKIM selector or combine unrelated CNAME targets. Ask Privy for a supported configuration that avoids the collision, and keep the existing sender operational while resolving it.
Why does SPF pass while DMARC fails?
Compare domains, not just pass labels. The authenticated envelope identity may be unrelated to From, while DKIM is absent, broken or unaligned. Fix the relevant sending identity or key configuration instead of weakening DMARC or adding a random root SPF include.
Does a successful check guarantee delivery?
No. Authentication is one prerequisite. Consent, complaints, recipient filtering and sending history still matter. Plan a controlled transition and monitor delivery feedback; do not respond to every placement problem by changing correct DNS. Privy's domain warm-up guidance.
This is a documentary guide, not a report of hands-on account configuration. No customer DNS changes, account changes, sending tests or delivery validation were performed.