Why email authentication matters

Email was invented in an era when the internet was a small, trusted network of researchers and academics. The protocol that carries email — SMTP — has no built-in mechanism for verifying that the sender is who they claim to be. Anyone with the right tools can send an email that appears to come from your domain. They can make it look like it came from invoices@yourcompany.ca, your CEO, your bank, or the Canada Revenue Agency.

This is the foundation of phishing attacks. A supplier receives an email that appears to come from your accounting department asking them to update banking information. A customer receives what looks like a receipt from your store with a link to a fake login page. Neither attack requires compromising your actual email server — they just need your domain name and a mail server willing to send.

SPF, DKIM, and DMARC are DNS-based standards that let you publish a verifiable statement about who is authorised to send email on your domain's behalf. Mail servers receiving your email can check those records and decide whether to trust the message. When all three are properly configured, spoofing your domain becomes significantly harder, and your legitimate mail is more likely to land in the inbox rather than the spam folder.

The Canadian angle. Under CASL — Canada's anti-spam legislation — you have legal obligations around commercial electronic messages. Having proper email authentication in place is part of demonstrating that your sending infrastructure is legitimate. It also protects your customers from fraud conducted in your name, which is both an ethical responsibility and a reputational one.

SPF: telling the internet who can send on your behalf

SPF stands for Sender Policy Framework. An SPF record is a DNS TXT record that lists the mail servers authorised to send email for your domain. When a receiving mail server gets a message claiming to be from you@yourdomain.ca, it looks up your domain's SPF record and checks whether the sending server's IP address is on the list. If it is not, the message may be marked as suspicious or rejected.

A basic SPF record looks like this:

v=spf1 include:_spf.google.com ~all

Breaking that down: v=spf1 identifies the record as SPF version 1. include:_spf.google.com authorises Google's mail servers (used when your email is handled by Google Workspace). The final ~all is the policy: a soft fail, meaning messages from unlisted servers should be accepted but marked as suspicious. A stricter policy uses -all (hard fail), which tells receivers to reject messages from unlisted servers outright.

If you send email through multiple services — your hosting provider's mail server, a marketing platform like Mailchimp, a CRM that sends automated messages, and Google Workspace — your SPF record needs to authorise all of them. This is where SPF gets complicated: the record has a lookup limit of ten DNS queries, and some includes chain to others, so complex setups can hit this limit and cause legitimate mail to fail authentication.

SPF only checks the envelope sender — the technical address used in the SMTP conversation, not the friendly "From" address you see in your email client. This distinction matters when you get to DMARC.

DKIM: a cryptographic signature on your mail

DKIM stands for DomainKeys Identified Mail. It works differently from SPF: instead of checking where a message was sent from, it verifies that the message content was not tampered with in transit, and that it was sent by someone with access to a cryptographic key associated with your domain.

When you configure DKIM, your mail server (or sending service) generates a private key that it uses to sign every outgoing message. The corresponding public key is published as a DNS TXT record on your domain. Receiving mail servers retrieve that public key, verify the signature in the message header, and confirm that the message body has not been altered since it was signed.

DKIM adds a header to your outgoing messages that looks something like this:

DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.ca; s=google; ...

The d= value is the signing domain. When DKIM passes, the receiving server knows the message was sent by an entity controlling that domain — and that the content was not modified. DKIM checks the header From address (the one you see in your email client), which makes it more directly relevant to user-facing spoofing protection.

Most major email providers (Google Workspace, Microsoft 365, and common Canadian hosting providers) make enabling DKIM reasonably straightforward — you generate the key in your email provider's admin panel and then add the provided TXT record to your DNS.

DMARC: what to do when checks fail

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It builds on SPF and DKIM by letting you tell receiving mail servers what to do when a message fails those checks — and by giving you reports so you can see what is being sent in your name.

A DMARC record also addresses the gap between SPF and DKIM: SPF checks the envelope sender; DKIM checks the signing domain. DMARC requires that at least one of those aligns with the visible "From" address — this alignment is the mechanism that actually protects against spoofing of the address your recipient sees.

A minimal DMARC record looks like this:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.ca

The p= value is the policy: none (monitor only, take no action), quarantine (send failing messages to spam), or reject (refuse failing messages outright). Most organisations start with p=none to collect reports and understand what is sending email on their behalf before enforcing a stricter policy. The rua= value is the address where aggregate reports get sent — daily XML summaries from major mail providers showing authentication results.

DMARC reports are not human-readable out of the box. Tools like Google Postmaster Tools, dmarcian, or Postmark's DMARC Digests can parse and visualise them. Reviewing a few weeks of reports before moving to quarantine or reject is strongly recommended — you may discover legitimate sending sources you forgot to authenticate.

How the three records work together

SPF, DKIM, and DMARC are not alternatives — they are layers. Each addresses a different part of the email authentication problem, and having all three is what provides meaningful protection.

SPF proves that the message came from an authorised server but does not protect the visible From address and is not tamper-resistant. DKIM signs the message content and aligns with the From address but does not define a policy for what happens when the signature fails. DMARC ties SPF and DKIM alignment to a policy and provides reporting visibility.

Without DMARC, a bad actor can pass SPF by sending from an authorised-looking server and still spoof your From address in a way that SPF never checks. Without DKIM, messages that pass SPF can be altered in transit. Without SPF, a wide range of servers can pass basic infrastructure checks. Together, the three make spoofing your domain significantly harder and give you visibility into attempts to abuse it.

Setting up SPF, DKIM, and DMARC

All three records are published as DNS TXT records on your domain. If your domain is registered through a Canadian registrar — CIRA-accredited registrars like Rebel.ca, Namespro, or major hosting companies with domain services — you manage DNS through your registrar's control panel or your hosting account's DNS zone editor.

The general process is:

Step 1: Inventory your sending sources. List every service that sends email on your domain's behalf — your primary email provider, your marketing platform, any automated transactional systems (invoicing software, CRM, booking systems). Each one needs to be authorised in your SPF record and ideally has its own DKIM key.

Step 2: Configure SPF. Create a TXT record at your root domain (e.g., yourdomain.ca) with the appropriate v=spf1 ... all value. Your email provider's documentation will give you the specific include: value to use for their infrastructure.

Step 3: Enable DKIM. In your email provider's admin panel, generate a DKIM key pair. Add the provided public key as a TXT record in your DNS at the selector subdomain they specify (e.g., google._domainkey.yourdomain.ca). Then enable DKIM signing in the provider settings.

Step 4: Add a DMARC record. Start with a monitoring-only policy: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.ca as a TXT record at _dmarc.yourdomain.ca. Wait two to four weeks, review the reports, and then move to p=quarantine or p=reject once you are confident all legitimate sending sources are authenticated.

Common mistakes Canadian businesses make

Not authenticating third-party senders. Many businesses have SPF and DKIM configured for their primary mail provider but forget about the email marketing platform they use for newsletters or the invoicing software that sends payment reminders. If those services send email from your domain without being included in SPF or DKIM, authentication fails for that mail.

Moving straight to a strict DMARC policy without reviewing reports. Jumping from no DMARC to p=reject without a monitoring period is the fastest way to start rejecting legitimate mail you forgot to authenticate. A two-to-four-week monitoring phase with p=none and a working report address is not optional — it is the correct procedure.

Having multiple SPF records. Your domain should have exactly one SPF TXT record. Multiple SPF records cause authentication failures. If you have authorised multiple sending services, they all belong in a single record using multiple include: statements: v=spf1 include:_spf.google.com include:servers.mcsv.net -all.

Not authenticating subdomains separately. If you send email from subdomains (e.g., noreply@mail.yourdomain.ca), those subdomains need their own SPF and DKIM records. A DMARC record at the root domain applies to the root domain; subdomains need their own or inherit a sp= subdomain policy if you specify one.

Verify with free tools. MXToolbox (mxtoolbox.com), Google Admin Toolbox, and DMARC Analyser all offer free record checking tools. Look up your domain's SPF, DKIM, and DMARC records and run a test message through Gmail's message headers to confirm authentication is passing before calling the setup complete.

For most Canadian small businesses, the practical goal is: one clean SPF record, DKIM enabled through your primary email provider, and a DMARC record starting at p=none with reports going somewhere you actually check. That configuration provides meaningful protection against spoofing, improves deliverability, and satisfies the requirements now being enforced by the major inbox providers. From there, moving to p=reject after a monitoring period closes the loop.