DMARC at p=none is not email authentication
The claim A published DMARC record with a policy of none protects nobody. It asks receiving mail servers to report on forged mail and then deliver it anyway. Most Canadian business...
The claim
A published DMARC record with a policy of none protects nobody. It asks receiving mail servers to report on forged mail and then deliver it anyway. Most Canadian businesses we audit have exactly this configuration, published two or three years ago during a compliance exercise, still sitting at p=none, with the reporting address pointed at a mailbox nobody reads. That is not a security control. It is a note to yourself that you were once meaning to do something.
What the three records actually do
They are not interchangeable and each fails differently.
SPF lists the servers permitted to send for your domain. It breaks on forwarding, because the forwarding server is not on your list, and it has a hard limit of ten DNS lookups — exceed it and the result is permerror, which most receivers treat as a failure.
example.ca. TXT "v=spf1 include:_spf.google.com include:mailgun.org ~all"
Count your lookups before you add a fourth vendor:
dig +short TXT example.ca | grep spf1
DKIM signs the message with a private key and publishes the public half in DNS. It survives forwarding, which is why it does the real work. Use a 2048-bit key; 1024 is still common and no longer defensible.
DMARC ties the other two to the domain a human actually sees in the From header, and tells receivers what to do when neither aligns. Without DMARC, an attacker can pass SPF using their own domain while forging yours in the visible From field.
The record you should be working towards
_dmarc.example.ca. TXT "v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:dmarc@example.ca; pct=100"
p=reject is the only value that stops forged mail. adkim=s and aspf=s require strict alignment, so a subdomain cannot be used as a loophole. Anything short of this is telling the world your domain is available for use.
A six-week path from none to reject
The reason organisations stall at p=none is a real fear of blocking their own invoices. Resolve that with a schedule rather than indefinite delay.
| Week | Action | What you are looking for |
|---|---|---|
| 1 | Publish p=none with a working rua address | Aggregate reports arriving daily |
| 2–3 | Inventory every sender in the reports | Payroll, CRM, invoicing, marketing, the plugin on the website |
| 3–4 | Add SPF entries and DKIM keys for each legitimate sender | Alignment rate above 98% |
| 5 | p=quarantine; pct=25 | No increase in support tickets about missing mail |
| 6 | p=quarantine; pct=100, then p=reject | Report volume of failing mail drops to noise |
The inventory step is where the surprises live. Every organisation finds at least one sender nobody remembered: a ten-year-old shipping notification script, a franchise location using a personal Gmail address with the company domain in the From field, a marketing tool set up by someone who has since left.
Reading the reports without buying a tool
Aggregate reports arrive as gzipped XML attachments, one per receiving provider per day, and they are genuinely unpleasant to read by hand. You do not need a subscription to get started. A dozen lines of scripting will extract the counts you care about — source IP, message volume, SPF result, DKIM result, disposition — and load them into a spreadsheet. What you are looking for in week two is a small number of high-volume sources that fail alignment, because those are your legitimate senders. High-volume sources from residential address ranges in other countries are the forgeries, and they are why you are doing this.
Commercial platforms are worth the $30 to $150 CAD per month once you are managing more than three or four domains, mostly because they handle the parsing and keep the history. For a single domain, the manual approach for six weeks is sufficient, and then you can stop.
Also publish a null record for your unused domains
Parked and defensive domain registrations are attractive to forgers precisely because nobody monitors them. Two records shut that down:
parked.ca. TXT "v=spf1 -all"
_dmarc.parked.ca. TXT "v=DMARC1; p=reject;"
The Canadian angle
CASL governs the commercial messages you send, not the ones criminals send in your name, so DMARC is not a compliance requirement in that sense. The practical connection is different: when a supplier receives a convincing invoice-redirection email that appears to come from your accounts department, the resulting dispute is your problem regardless of where the message originated. A rejecting DMARC policy makes that specific attack technically impossible from your exact domain, which is a narrow win but a real one, and it costs three DNS records and six weeks of attention.
Verify, then diarise
dig +short TXT _dmarc.example.ca
dig +short TXT selector1._domainkey.example.ca
Put a calendar reminder at six months to re-read a week of aggregate reports. New senders appear whenever someone in the business signs up for a tool, and the failure mode is quiet: their mail simply stops arriving, and they blame the recipient.