On this page
Three DNS records tell mail servers whether email from a domain is genuine: SPF, DKIM and DMARC. For an agency they matter twice: a prospect’s weak setup is a real problem you can verify and help fix, and Google and Yahoo expect the same records on your own outreach.
What SPF, DKIM and DMARC do
SPF: who may send
SPF (Sender Policy Framework, RFC 7208) is one TXT record on the domain that lists the servers allowed to send its email. Receivers look up the domain in the envelope sender, the return path most people never see, and check that the sending server is on its list.
v=spf1 include:_spf.google.com ~all is the record Google documents for a domain that sends only through Google Workspace. Google’s servers may send; mail from any other server is probably not allowed.
At the end, -all fails every other server, ~all marks them as probably not allowed (Google recommends it), ?all stays neutral, and +all lets anyone send as the domain.
-all has a catch: RFC 9989 warns that it can get mail refused before DMARC sees its DKIM signature. Whatever the ending, keep to one record: only one TXT record on a domain may start with v=spf1.
DKIM: a signature on each message
With DKIM (DomainKeys Identified Mail, RFC 6376), the sending service signs each message. The receiver fetches the public key from DNS and checks the signature, which also shows the signed parts weren’t changed on the way.
The key lives at selector._domainkey.yourdomain.ca, and Google Workspace’s default selector is google. DNS can’t list selectors: to find one, view a message’s source and read s= in its DKIM-Signature header, alongside d=, the signing domain.
DMARC: the rule that ties them together
DMARC (RFC 9989, which replaced RFC 7489 in May 2026) is a TXT record at _dmarc.yourdomain.ca. It tells receivers what to do with mail that shows the domain in its From address but fails DMARC, and where to send reports.
v=DMARC1; p=none; rua=mailto:reports@yourdomain.ca makes a good first record. Its policy, p=, takes one of three values:
none: no preference, only reports. RFC 9989 calls this monitoring modequarantine: treat failing mail as suspicious, which can mean the spam folderreject: refuse failing mail
How they work together: alignment
SPF and DKIM each vouch for a domain, but not always the one people see. A scammer can pass SPF for a domain they own while showing yours in the From line. DMARC closes that gap with alignment.
A message passes DMARC when SPF or DKIM passes and the domain it passed for matches the From domain. With relaxed alignment, the default, a subdomain counts: news.yourdomain.ca aligns with yourdomain.ca. Strict alignment (adkim=s or aspf=s) needs the exact domain.
One aligned pass is enough, and RFC 9989 asks for two where possible. Lean on DKIM: forwarded mail will most likely fail SPF unless the forwarder rewrites the return path, while DKIM signatures generally survive.
How to check any domain
It’s all public, so checking a domain sends nothing to its owner. The quickest way is our email check: type a domain and it reads MX, SPF, DKIM and DMARC from your browser in a few seconds, with what to fix.
By hand
Look up the SPF record
In a terminal, run
nslookup -type=TXTdomain.ca on Windows ordig +short TXTdomain.ca on a Mac, and find the record that starts withv=spf1.Look up the DMARC record
Do the same for
_dmarc.domain.ca. No record starting withv=DMARC1means no DMARC.Look up a DKIM key
With the selector from a message’s
s=value, look up selector._domainkey.domain.ca. No answer under a guessed name proves nothing.
With Email health in RadiusPilot
In RadiusPilot, open Tools › Email health, enter a domain, an email address or a website, or pick a business you scanned, and choose Check email. It reads public DNS in a few seconds, in the Windows app or the web app.
| Record | What Email health reads and flags |
|---|---|
| MX | Receives email: the mail servers and who runs them. Flags a domain with none, since mail to it bounces. |
| SPF | Allowed senders: the record, the services it allows and its own lookups. Flags no record or several, +all, a neutral or missing ending, and over 10 lookups. |
| DKIM | Signed email: keys under 22 common selectors, with a rough size. Flags a key switched off (empty p=); none found reads Unknown, not Missing. |
| DMARC | Protection from fakes: the policy and the report address. Flags no record or several, no valid policy, p=none, test mode (t=y) and the retired pct below 100. |
You get a verdict (Healthy, Needs work or At risk), a What to fix list, starter records when SPF or DMARC is missing, and a pitch line built only from the check.
If the domain is a business’s website in your workspace, the result is saved on that business and feeds its website audit and opportunity score. The audit runs Email health too, even across a whole scan with Audit several.
What a weak result looks like
Act on these, on any domain, yours included.
| What you see | What it means, and the fix |
|---|---|
| No SPF record | Receivers can’t tell who may send for the domain. Fix: publish one record listing every sender. |
| Two SPF records | Only one is allowed, so SPF returns an error. Fix: merge them into one. |
+all at the end | Any server in the world may send as the domain. Fix: end with ~all or -all. |
| Over 10 DNS lookups | SPF returns an error and can’t pass. Fix: remove what the domain no longer uses. |
| No DMARC record | Nothing asks receivers to act on fakes. Fix: add p=none with reports, then move up. |
p=none for months | Receivers are asked to do nothing about fakes. Fix: act on the reports, then move to quarantine. |
| No DKIM key found | Unsigned mail, or a custom selector. Fix: turn on signing in the email service. |
Too many DNS lookups
Each include, a, mx, ptr, exists and redirect in an SPF record costs a DNS lookup, and so does each one inside the records it includes. RFC 7208 caps the total at 10. ip4, ip6 and all don’t count.
To get back under, drop services the domain no longer uses, and any ptr, which RFC 7208 says not to publish. Email health counts the record’s own lookups; includes add theirs, so check them when the count nears 10.
A DMARC policy stuck at none
Starting at p=none is right: it’s the time to read reports and fix the domain’s own mail. Left there, it asks receivers to do nothing about mail that fakes the domain.
RFC 9989 warns that p=reject can break mail sent through mailing lists and forwarders, and requires DKIM signing from domains that use it. Before p=reject, it suggests a month or more at p=none, then as long at p=quarantine, comparing reports.
To try a stricter policy, RFC 9989 replaces the old pct= tag with test mode, t=y: receivers then apply one level less, so reject acts as quarantine and quarantine as none. Email health shows both as warnings. Remove pct=, and remove t=y once the reports are clean.
What Google and Yahoo require
Since February 2024, Google and Yahoo have set requirements for mail to their users, with a longer list for bulk senders.
| Requirement | Every sender | Bulk senders |
|---|---|---|
| Authentication | SPF or DKIM | SPF and DKIM |
| DMARC | Recommended by both | Required; p=none is accepted |
| Alignment | Not required | From aligned with SPF or DKIM |
| Unsubscribe | Not required | One-click, plus a visible link |
| Spam rate | Below 0.3% | Below 0.3% |
| Sending servers | Forward and reverse DNS | The same |
| Encryption | TLS, for Gmail | TLS, for Gmail |
Google counts as bulk anyone who sends more than 5,000 messages a day to Gmail accounts; Yahoo’s requirements page gives no number. The unsubscribe rules cover marketing and subscribed messages, and Yahoo wants them honoured within 2 days.
Google requires DKIM keys of 1024 bits or longer for personal Gmail accounts and recommends 2048 bits, and Yahoo recommends at least 1024. Email health shows each key’s rough size.
RadiusPilot’s daily limit starts at 50 people and never passes 200, far below Google’s bulk threshold. Google still recommends all three records for every domain: unauthenticated mail might be marked as spam or rejected.
Get your own domain right first
Check yours before you point out anyone else’s.
List every service that sends as you
Your mailbox, plus any newsletter, invoicing, booking or form tool using your domain.
Publish one SPF record
Include each service, end with
~all, and stay within 10 lookups.Turn on DKIM everywhere
Have each service sign with your own domain, so DKIM aligns.
Add DMARC in monitoring mode
v=DMARC1; p=none; rua=mailto:reports@yourdomain.ca goes in a TXT record named_dmarc. Reports are built for software, so a report-reading service helps.Move up when the reports are clean
Once every service passes, switch to
p=quarantine, then run Email health again.
Turn a weak result into a first email
A weak record is a fact anyone can verify: a fair reason to write, if you stay useful rather than alarming.
- Lead with one finding, in plain words, and how you found it: public DNS records, nothing sent to their servers.
- Say what it allows, no more. “Nothing tells mail servers to refuse email that fakes your address” is accurate; “you’ve been hacked” isn’t.
- Name the fix: a DNS change, by whoever manages the domain or the email.
- Leave out what you couldn’t confirm, like a DKIM key under a guessed selector.
- Check again the day you send. Records change.
The rules in Canada
CASL, Canada’s anti-spam law, covers commercial email sent from or opened on a computer in Canada, wherever you’re based. Implied consent can come from an address a business publishes conspicuously, with no statement refusing unsolicited messages, when your email relates to its business.
Each message must identify you, give contact details valid for at least 60 days, and offer an unsubscribe you honour within 10 business days. RadiusPilot adds your business name, postal address and unsubscribe line to every email, blocks your opt-out list and stops at your daily limit.
Published contacts keeps the page where a business published its address, as your record. The email rules guide covers the rest.
Email health is one of the eight tools in RadiusPilot. Try it in the web app, on your own domain first.
Sources
- Google: Email sender guidelines
- Google Workspace: Set up SPF
- Google Workspace: Set up DKIM
- Yahoo Sender Hub: Sender requirements and recommendations
- RFC 7208: Sender Policy Framework (SPF)
- RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
- RFC 9989: DMARC (May 2026)
- RFC 7489: DMARC (2015, replaced by RFC 9989)
- Justice Laws Website: Canada’s anti-spam law (S.C. 2010, c. 23)
Checked against these pages on November 1, 2026.
