DMARC and Email Authentication Evidence: The Cyber Insurance Control Most Canadian SMBs Are Missing
Most Canadian SMBs are focused on the wrong cyber threat. They are hardening against ransomware while the claim that is most likely to hit their business — and the one their cyber insurer is most worried about — arrives as an email.
Business email compromise (BEC) overtook ransomware as the top cyber claim driver for small and mid-sized businesses in North America between 2022 and 2024. It does not encrypt your files. It does not trigger an alert from your EDR tool. It impersonates someone your staff trusts, and it works because email authentication is misconfigured — or missing entirely.
DMARC, DKIM, and SPF are the technical controls that stop domain impersonation. And they are now on Canadian cyber insurance checklists alongside MFA and EDR — quietly, without fanfare, as a standard underwriting requirement.
If your DMARC policy is set to p=none — the default “monitor only” setting that most domains land on when someone sets it up years ago and never returns to it — you are not protected. And depending on how your insurance application was answered, you may be in a coverage dispute position if a BEC claim occurs.
Why Insurers Started Caring About Email Authentication
The claims data made the case for them.
A BEC attack does not require malware. It requires a convincing impersonation of a CEO, a vendor, or a finance team member — and a recipient who acts on it before verifying. Funds get transferred. Invoices get paid to fraudulent accounts. Payroll gets redirected. The average BEC loss in Canada runs into the tens of thousands of dollars per incident, and the majority of victims are businesses with fewer than 250 employees.
Domain impersonation — where an attacker sends email that appears to come from your domain, or a convincing lookalike — is the technical mechanism behind a large proportion of these attacks. DMARC, DKIM, and SPF are the controls that exist specifically to stop it. They work at the email infrastructure level, before any human sees the message.
Insurers responded to rising BEC claim frequency by adding email authentication controls to underwriting questionnaires. Some carriers ask about it directly. Others fold it into broader questions about email security posture. Either way, the expectation is now there.
What SPF, DKIM, and DMARC Actually Do
These three controls work as a layered system. They are all configured as DNS records on your domain — not software you install, but settings your IT provider or domain registrar manages.
SPF (Sender Policy Framework) specifies which mail servers are authorized to send email from your domain. When a receiving mail server gets a message claiming to be from your domain, it checks SPF to see if the sending server is on your approved list. If it is not, the receiving server can flag or reject the message.
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outgoing emails. The signature is validated by the receiving server against a public key in your DNS records. If the message was tampered with in transit, the signature fails. DKIM proves that the email genuinely originated from your infrastructure and was not modified.
DMARC (Domain-based Message Authentication, Reporting and Conformance) is the policy layer that sits on top of SPF and DKIM. It tells receiving servers what to do when an email fails authentication — none (do nothing, just report), quarantine (send to spam), or reject (block the message entirely). It also generates reports on authentication failures so you can see who is trying to impersonate your domain.
A DMARC policy of p=reject means that any email failing both SPF and DKIM alignment will be blocked before it reaches a recipient’s inbox. This is the protection level. p=none means you receive reports but nothing is blocked. It offers no protection against domain impersonation.
How to Check Your Current DMARC Status Right Now
You can check your domain’s current email authentication configuration in under 60 seconds using a free lookup tool. Go to mxtoolbox.com/dmarc and enter your domain name.
The result will show you:
- Whether a DMARC record exists for your domain
- What policy is set (
p=none,p=quarantine, orp=reject) - Whether SPF and DKIM records are present
- Basic configuration errors
Common findings for Canadian SMBs:
- No DMARC record at all — no policy, no reporting, full domain impersonation risk
- DMARC at
p=none— monitoring only, no blocking, effectively no protection - SPF present but DKIM missing — partial coverage, DMARC cannot reach full enforcement
- DMARC at
p=quarantine— partial protection, suspicious mail goes to spam but is not blocked - DMARC at
p=rejectwith SPF and DKIM aligned — full protection, insurer-ready posture
If you are at p=none or have no DMARC record, you are in the majority of Canadian SMBs — and you are not where your insurer expects you to be.
What Insurers Ask — and What Your Answer Signals
Cyber insurance applications and renewal questionnaires phrase the email authentication question in several ways. Understanding what they mean — and what your answer implies — matters.
“Do you have email authentication controls including SPF, DKIM, and DMARC in place?” — A “yes” here implies all three are configured and functional. If you have SPF but no DMARC, or DMARC at p=none, a technically accurate answer may be “partially.”
“Is DMARC enforced on your primary email domain?” — “Enforced” specifically means p=quarantine or p=reject. p=none is not enforced. This distinction matters in a post-claim review.
“Do you have controls in place to prevent domain spoofing?” — DMARC at p=reject is the primary technical control for domain spoofing. Answering “yes” to this without it creates exposure.
The risk is not that you will fail the application. It is that an inconsistency between what you stated and what exists becomes a basis for a coverage dispute when a BEC claim occurs. Post-claim underwriting reviews look at what the business said it had, and what it actually had, at the time of application.
The Path to Insurer-Ready Email Authentication
Moving from no DMARC or p=none to full enforcement is a three-step process. It requires access to your DNS records, which your IT provider or domain registrar manages.
Step 1 — Confirm SPF and DKIM are correctly configured. Before enabling DMARC enforcement, verify that your legitimate outgoing mail streams (your primary email platform, any third-party senders like your CRM, marketing tools, or invoicing software) are covered by SPF and authenticated by DKIM. Enabling p=reject before this step can cause legitimate mail to be blocked.
Step 2 — Start at p=quarantine and monitor reports. Set your DMARC policy to quarantine and enable reporting (set an rua address to receive aggregate reports). Review reports over 2–4 weeks to identify any legitimate mail sources failing authentication. Address any failures before moving to full rejection.
Step 3 — Move to p=reject. Once your reports show clean authentication for all legitimate mail sources, update your DMARC policy to p=reject. This is the enforcement level. Domain impersonation attempts will be blocked before reaching any recipient.
The entire process, for a business with a single domain and a straightforward mail stack, typically takes 2 to 4 weeks from start to full enforcement. Businesses with multiple third-party senders may take longer to identify and authenticate all legitimate mail sources.
Documenting Your Email Authentication Posture for a Renewal
Once your email authentication is configured correctly, documenting it for an insurance renewal requires capturing:
- A screenshot of your current DMARC record from your DNS management console, showing the policy value (
p=reject) - A screenshot of your SPF record showing authorized sending sources
- DKIM selector confirmation — showing that DKIM is published and active for your domain
- A DMARC lookup result from a tool like mxtoolbox as a dated screenshot, showing all three controls passing
- A brief note on DMARC reporting — who receives reports and how often they are reviewed
This is a straightforward documentation task. Most IT providers can produce it in under 30 minutes. The issue for most SMBs is not that it is difficult — it is that no one has ever asked for it, organized it, or kept it current.
How Readiness AI Helps
Readiness AI helps Canadian SMBs organize email authentication evidence — alongside MFA, backup, EDR, and other control documentation — into a structured, broker-ready evidence package.
Rather than asking your IT provider to pull documentation under renewal deadline pressure, your email authentication posture is maintained as part of your ongoing readiness record. When your renewal arrives, the evidence already exists.
Start your Readiness Review to see where your email authentication posture sits and what a complete evidence package looks like for your renewal. Or view a sample evidence pack to see how email authentication documentation fits into a full submission.
Readiness AI helps Canadian SMBs organize cyber readiness evidence for insurance renewal, client security reviews, and compliance workflows. It does not provide insurance advice, legal advice, or a guarantee of coverage. Businesses should work with a qualified cyber insurance broker for advice specific to their situation.
Frequently Asked Questions
Is DMARC required for cyber insurance in Canada?
DMARC is increasingly included in Canadian cyber insurance underwriting questionnaires, particularly for policies covering business email compromise. While no carrier universally mandates it as a binary pass/fail requirement, being unable to demonstrate DMARC enforcement — or having answered “yes” to email security questions without it — creates exposure in a post-claim review. The practical standard is DMARC at p=reject with SPF and DKIM aligned.
What is the difference between DMARC p=none and p=reject?
p=none means receiving mail servers take no action on failing messages — they are delivered normally. p=reject means receiving servers block messages that fail DMARC alignment. Only p=reject (or p=quarantine as an interim step) provides protection against domain impersonation. p=none is a monitoring configuration, not a security control.
How do I know if my business email is vulnerable to spoofing?
Check your domain at mxtoolbox.com/dmarc. If your DMARC policy is p=none, is missing entirely, or your SPF and DKIM records are absent or misconfigured, your domain can be impersonated by attackers. This means an attacker can send emails that appear to come from your domain to your clients, staff, or partners — with no technical barrier to delivery.
Does setting up DMARC break existing email?
DMARC enforcement can block legitimate mail if your SPF and DKIM records are incomplete — for example, if a third-party service (CRM, invoicing platform, marketing tool) sends mail from your domain but is not included in your SPF record. The correct approach is to start at p=none, review DMARC reports to identify all legitimate mail sources, ensure all sources pass SPF or DKIM, then move to p=quarantine and finally p=reject. Done in sequence, this process does not disrupt legitimate mail flow.