SPF, DKIM & DMARC for Purelymail.
Purelymail is a low-cost, privacy-focused mailbox provider, and it authenticates your domain with a genuine SPF include, CNAME-delegated DKIM, and — unusually — a Purelymail-managed DMARC record. In the Account Admin portal (purelymail.com/manage) you add your domain and it hands you a short, fixed list of records: an ownership-proof TXT, one MX, an SPF TXT built around include:_spf.purelymail.com, three DKIM CNAMEs, and a DMARC CNAME. Publish them at your DNS host, click "Check DNS records", and Purelymail sends and receives as your own domain with SPF and DKIM both aligned. The one decision to make deliberately is DMARC: accept Purelymail's managed p=reject CNAME, or publish your own record so the reports come to you.
Why authenticate Purelymail?
Authenticating a Purelymail domain isn't housekeeping — it decides whether your mail reaches the inbox and whether anyone can spoof you. Since February 2024, Gmail and Yahoo have required every sender to pass SPF or DKIM, and every bulk sender (roughly 5,000+ messages a day) to also publish DMARC with alignment; Yahoo matched the rules the same month and Microsoft began enforcing on Outlook.com/Hotmail/Live in 2025. Until the records are live, mail you send through Purelymail is only weakly attributable to your domain, DMARC can't pass, and a registered-but-unprotected domain is trivially spoofable. Purelymail is in an unusually strong position once configured: because it sends with your own domain as the envelope (Return-Path) sender, SPF aligns to your organizational domain and DKIM signs as d=yourdomain.com, so both mechanisms pass aligned — not just DKIM, as with most ESPs. And Purelymail's managed DMARC ships at p=reject, which actively blocks spoofed mail the moment it resolves. The catch is that a p=reject policy also rejects any legitimate sender you forget to authenticate, so the setup rewards doing all three records deliberately.
The SPF reality for Purelymail
Purelymail is a true "include" provider — not a CNAME-delegating ESP (Mailchimp, Klaviyo) and not a Return-Path-owning relay. You add one shared mechanism, include:_spf.purelymail.com, to the single SPF TXT record on your root domain; the full record is v=spf1 include:_spf.purelymail.com ~all. Two things make this SPF pull real weight. First, the include resolves to a flat record that contains only three ip4 addresses and its own ~all (verified live: v=spf1 ip4:34.202.193.197 ip4:54.89.13.140 ip4:3.231.132.23 ~all) — there are no nested includes — so it costs exactly ONE of your 10 SPF DNS lookups, not the two or three some checkers guess. Second, and unlike most sending platforms, Purelymail uses your own domain as the SMTP envelope sender when you send as you@yourdomain.com, so SPF actually ALIGNS to your organizational domain and contributes a DMARC pass on its own, alongside DKIM. Purelymail publishes ~all (softfail), not -all, which is the sensible default while you confirm every sender is listed. The usual rules apply: keep exactly one SPF TXT record on the root — if you also send via Google Workspace, Microsoft 365, or a transactional relay, merge every include into that single v=spf1 line rather than publishing a second SPF record (two SPF records is a PermError) — and delete any leftover SPF from a previous email host.
Two ways to set it up
Your own DMARC record (TXT) — control + reports
- You publish v=DMARC1; p=none; rua=mailto:you@yourdomain.com and receive the aggregate reports yourself
- Lets you ramp p=none → quarantine → reject after confirming every sender aligns
- Safe when you also send from a newsletter tool, CRM, or website form — you see them in reports before enforcing
- Required if you use any sender besides Purelymail, or want visibility into who's mailing as your domain
Purelymail-managed DMARC (CNAME) — zero-maintenance
- A single CNAME (_dmarc → dmarcroot.purelymail.com) gives an instant, enforced p=reject with no upkeep
- Purelymail keeps the policy current for you; you never edit the record
- Failure reports go to dmarc@purelymail.com, not you — no aggregate (rua) visibility into your own domain
- p=reject is enforced immediately, so ANY sender you haven't authenticated is rejected outright, not just Purelymail
Step by step
- 1
Open the Add Domain page
Sign in to the Account Admin portal at purelymail.com/manage, click Domains in the top navigation, then Add New Domain and enter your domain (e.g. yourdomain.com).
- 2
Copy the record list Purelymail shows
The setup page lists everything you need for this account: the purelymail_ownership_proof TXT value, one MX (mailserver.purelymail.com), the SPF TXT, three DKIM CNAMEs (purelymail1/2/3._domainkey), and the DMARC CNAME. Copy the ownership value exactly — it's unique to your domain.
- 3
Add the ownership TXT and clear old records
At your registrar/DNS host, add a TXT record on the root (Host @ or blank) with the purelymail_ownership_proof=… value. While you're there, delete any MX and SPF records left over from a previous email provider so they don't conflict.
- 4
Add the MX record
Create one MX record: Host @ (or blank), value mailserver.purelymail.com, priority 50. This is the only MX Purelymail needs — remove any others so inbound mail isn't split between providers.
- 5
Add or merge the SPF TXT
Add a TXT record on the root: v=spf1 include:_spf.purelymail.com ~all. If a v=spf1 record already exists for another sender, merge the include into that single record instead of creating a second SPF TXT.
- 6
Add the three DKIM CNAMEs
Create three CNAME records: purelymail1._domainkey → key1.dkimroot.purelymail.com, purelymail2._domainkey → key2.dkimroot.purelymail.com, and purelymail3._domainkey → key3.dkimroot.purelymail.com. Keep them as CNAME (don't switch to TXT), and on Cloudflare set each to DNS only (grey cloud).
- 7
Add DMARC — pick managed or your own
For the hands-off option, add a CNAME _dmarc → dmarcroot.purelymail.com (Purelymail's managed p=reject policy). If you send from anywhere besides Purelymail or want your own reports, skip the CNAME and instead add a TXT at _dmarc such as v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. You can have one or the other, never both.
- 8
Click Check DNS records, then finish setup
Back on the Purelymail setup page, click Check DNS records. Allow ~15 minutes (up to 24–48 hours) for propagation. Once everything validates, set Deliver Mail To = Purelymail, optionally leave Allow Account Reset enabled for recovery, click Save, then create your user mailboxes for the domain.
- 9
Send a test and read the headers
Send a message from your new Purelymail address to a Gmail account, open it, and choose ⋮ → Show original. You want SPF: PASS, DKIM: PASS with d=yourdomain.com, and DMARC: PASS — all aligned to your domain.
Records to add
Purelymail generates the exact values in its setup wizard — these show the shape of what you'll add at your DNS host.
| Type | Host | Value |
|---|---|---|
| TXT | @ | purelymail_ownership_proof=xxxxxxxxxxxxxxxxxxxxIllustrative — copy the exact per-domain value from the Add Domain page. Required before Purelymail will add the domain. |
| MX | @ | mailserver.purelymail.comPriority 50 — the only MX Purelymail uses. Delete any previous provider's MX records first. |
| TXT | @ | v=spf1 include:_spf.purelymail.com ~allRoot SPF — keep exactly one SPF record; merge other senders in. The include resolves to a flat 3-IP record = 1 DNS lookup, and aligns because your domain is the envelope sender. |
| CNAME | purelymail1._domainkey | key1.dkimroot.purelymail.comDKIM rotating key 1 (Purelymail-managed). CNAME delegation — keep as CNAME, DNS only on Cloudflare. |
| CNAME | purelymail2._domainkey | key2.dkimroot.purelymail.comDKIM rotating key 2 — all three are required because Purelymail signs with one of three keys it rotates. |
| CNAME | purelymail3._domainkey | key3.dkimroot.purelymail.comDKIM rotating key 3. |
| CNAME | _dmarc | dmarcroot.purelymail.comPurelymail-managed DMARC (currently resolves to v=DMARC1; p=reject; ruf=mailto:dmarc@purelymail.com). Use this OR your own _dmarc TXT — a name can't be both a CNAME and a TXT. |
Keep exactly one SPF (v=spf1) TXT record on your root domain — merge every sender into it. Two SPF records is itself an error.
The 10-lookup budget
SPF is capped at a hard 10 DNS lookups — go over and it returns a permerror and stops validating everywhere. Here's what Purelymail's setup costs against that budget.
Purelymail adds 1 of your 10 lookups; ip4: and ip6: mechanisms are free.
DKIM
Purelymail's DKIM is CNAME-delegated across three rotating keys, which is why you publish three records rather than one. Create purelymail1._domainkey, purelymail2._domainkey, and purelymail3._domainkey as CNAMEs pointing to key1.dkimroot.purelymail.com, key2.dkimroot.purelymail.com, and key3.dkimroot.purelymail.com respectively. Because these are CNAMEs — not TXT records you paste — Purelymail holds the private keys and publishes the public keys behind those dkimroot hostnames (each resolves to a v=DKIM1; k=rsa; p=… TXT on Purelymail's side), and it can rotate among the three keys on its own schedule without you ever editing DNS again. That's the whole point of the CNAME approach and the reason all three are mandatory: any given message is signed with one of the three keys, so if you publish only one CNAME, roughly two-thirds of your mail will fail DKIM. Signatures are made as d=yourdomain.com, so DKIM aligns to your organizational domain and satisfies DMARC. Two practical notes: don't convert these to TXT records (that breaks Purelymail's rotation), and if your DNS is behind Cloudflare set each of the three CNAMEs to "DNS only" (grey cloud) or the proxy will mask the target and DKIM won't validate.
DMARC
DMARC is where Purelymail does something most providers don't: it offers a fully managed policy delivered by CNAME. If you add _dmarc → dmarcroot.purelymail.com, that CNAME currently resolves to v=DMARC1; p=reject; ruf=mailto:dmarc@purelymail.com — an enforced reject policy that Purelymail maintains for you. For a domain that sends only through Purelymail, that's a genuinely nice zero-maintenance win: you get strong anti-spoofing protection instantly and never touch the record. But understand the trade-offs before you choose it. First, the failure/forensic reports (ruf) go to Purelymail's own mailbox, and there is no rua aggregate report sent to you at all — so you get zero visibility into who is sending as your domain or whether a legitimate source is failing. Second, p=reject is enforced the moment it resolves, so any other sender you use — a newsletter tool, a CRM, a website contact-form relay, a marketing platform — will have its mail outright rejected unless it's already authenticated and aligned to your domain. If you send from anywhere besides Purelymail, or you want your own reports and a safe ramp, publish your own record instead: a TXT at _dmarc such as v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com, watch the aggregate reports for a week or two until every legitimate sender passes aligned, then tighten to p=quarantine and finally p=reject. You cannot use both — a hostname can be a CNAME or hold TXT records, never both (RFC 1034) — so it's one path or the other. Keep exactly one _dmarc record for the whole organizational domain either way.
Check it actually worked
Don't rely on Purelymail's "Check DNS records" green check alone — confirm on a real message. Send a test from your Purelymail address to a Gmail account, open it, and choose ⋮ → Show original: you want SPF: PASS (aligned to yourdomain.com, since Purelymail uses your domain as the envelope sender), DKIM: PASS with d=yourdomain.com, and DMARC: PASS. You can spot-check the raw records from a terminal too: dig TXT _spf.purelymail.com should show the three ip4 addresses, dig CNAME purelymail1._domainkey.yourdomain.com should point at key1.dkimroot.purelymail.com, and dig TXT _dmarc.yourdomain.com should return your DMARC policy (following the CNAME if you used the managed one). Then run your domain through Qualisend's domain health check to confirm the SPF stays at one lookup, all three DKIM CNAMEs resolve, and DMARC is present. If you opted for the managed CNAME, remember its reports go to Purelymail — the moment you want your own visibility, switch to your own DMARC record with a rua pointing at you and feed the aggregate reports into the DMARC report analyzer.
Common gotchas
- DNS setup
DMARC is a CNAME here, not a TXT — and you can't have both. If you want your own rua reports or a p=none-to-reject ramp, do NOT add Purelymail's _dmarc CNAME; publish a _dmarc TXT instead. A hostname can be a CNAME or hold TXT records, never both (RFC 1034), so mixing them is a config error your DNS host will reject.
- Coverage
The managed DMARC is p=reject and enforced immediately. It will reject legitimate mail from any sender you haven't authenticated — a newsletter tool, CRM, form plugin, or transactional relay — not just Purelymail. Authenticate every sender first, or run your own p=none record while you ramp.
- DNS setup
Managed DMARC's reports go to dmarc@purelymail.com, and there is no aggregate (rua) report sent to you. You get no visibility into who's mailing as your domain. Publish your own DMARC with rua= if you want the reports.
- DNS setup
All three DKIM CNAMEs are required. Purelymail signs each message with one of three rotating keys, so publishing only purelymail1._domainkey means messages signed with keys 2 and 3 fail DKIM. Add all of purelymail1/2/3._domainkey.
- Breaks auth
Delete old MX and SPF from any previous provider. A leftover MX splits your inbound mail between hosts, and a second SPF TXT record is a PermError. Keep exactly one MX (mailserver.purelymail.com, priority 50) and one SPF TXT.
- DNS setup
Cloudflare proxy breaks the CNAMEs. Set the three DKIM CNAMEs and (if used) the DMARC CNAME to 'DNS only' (grey cloud). An orange-cloud proxied CNAME won't resolve to Purelymail's dkimroot/dmarcroot hosts and validation fails.
- DNS setup
Copy the ownership proof exactly. Purelymail won't add the domain until the purelymail_ownership_proof TXT resolves; a truncated or edited value silently fails the 'Check DNS records' step.
- DNS setup
Host-field doubling: many registrars auto-append your domain, so entering purelymail1._domainkey.yourdomain.com becomes purelymail1._domainkey.yourdomain.com.yourdomain.com. Enter just the label (purelymail1._domainkey, _dmarc, @) when the panel adds the domain for you.
Build your SPF record
Purelymail is pre-selected below. Add any other platforms you send through, then publish the single merged record.
This domain's own servers
Authorize the domain itself, if it sends mail directly (not through a platform above).
Other senders & IPs
Anything not in the list — another provider's SPF host, or specific IP addresses.
We add the include: prefix — enter the hostname your provider documents.
Policy for everyone else
What receivers should do with mail from any server not listed above (the all mechanism).
- Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
- Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
- Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.
Authentication published? The next step is sending to a clean, verified list.
Verify a listPurelymail SPF — FAQ
Related reading
Once it's published, confirm everything resolves with the domain health check, then read who's sending as you with the DMARC report analyzer. Browse all sending sources in the generator. Authentication is only half of deliverability, though — a listed sending IP or domain still lands you in spam no matter how clean your SPF is, so it's worth watching the blacklists with blacklist monitoring.
Authenticated — now keep the list clean
Passing SPF, DKIM, and DMARC gets you to the inbox; a clean list keeps you there. Verify yours — start free with 100 credits, no card required.