How to set up SPF, DKIM and DMARC using Cyber Centre and Government of Canada guidance

Email that spoofs a real organization's domain is a staple of invoice fraud and phishing. Three DNS-based standards let receiving mail servers check whether a message claiming to come from your domain is genuine: Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM) and Domain-based Message Authentication, Reporting and Conformance (DMARC). The Canadian Centre for Cyber Security (Cyber Centre) recommends implementing all three together and configuring them so receivers reject messages that fail.

The Cyber Centre's Implementation guidance: email domain protection (ITSP.40.065 v1.1) sets out a four-phase rollout. The Government of Canada applies the same approach to its own departments in its email configuration requirements. Large mailbox providers now expect it too: since Feb. 1, 2024, Google has required anyone sending 5,000 or more messages a day to Gmail accounts to have SPF, DKIM and DMARC in place.

Phase 1: Assess

Step 1: Inventory your domains and senders

1. List every domain and subdomain you own, including those that never send email.
2. List every system that sends mail as your domain: Microsoft 365 or Google Workspace, marketing platforms, CRM, ticketing and payroll systems, website forms, printers and scanners.
3. Check what is already published. Look up the TXT records for your domain and for _dmarc.yourdomain.ca.

Step 2: Publish a monitoring DMARC record

Start with a policy that changes nothing but sends you reports:

_dmarc.example.ca TXT "v=DMARC1; p=none; rua=mailto:[email protected]"

The rua tag requests daily aggregate reports from receivers. The Cyber Centre advises against the ruf tag for forensic reports, because those can contain personal information. Federal departments must also add the Cyber Centre as an aggregate report recipient ([email protected]); other organizations can check the guidance for whether that applies to them. A DMARC reporting tool or service makes the XML reports readable.

Phase 2: Deploy

Step 3: Publish SPF

1. Create one SPF TXT record per sending domain listing authorized senders, directly or by include: references supplied by your providers. Microsoft 365 tenants, for example, use include:spf.protection.outlook.com.
2. End the record with -all, which tells receivers no other source is authorized. The Cyber Centre recommends this hard fail.
3. Stay within SPF's limit of 10 DNS lookups. Each include counts, and nested includes add up fast. Remove services you no longer use.
4. Publish only one SPF record per domain; two records cause failures.

Step 4: Turn on DKIM for every sender

DKIM signs each outgoing message with a private key; receivers verify it against a public key in your DNS. The Cyber Centre recommends RSA-SHA256 with 2048-bit keys (1024-bit only where a system cannot support 2048), separate keys per domain and annual key rotation.

In Microsoft 365:

1. In the Microsoft Defender portal, go to Email & collaboration > Policies & rules > Threat policies > Email authentication settings, then select the DKIM tab.
2. Select your custom domain. The details flyout shows two CNAME records to publish, with host names selector1._domainkey and selector2._domainkey.
3. Publish both CNAMEs in your DNS, wait for them to resolve, then switch DKIM signing on for the domain.
4. In Exchange Online PowerShell, New-DkimSigningConfig accepts a -KeySize of 1024 or 2048. Use Rotate DKIM keys in the same flyout for annual rotation; Microsoft says a new key takes four days to start signing.

Every third-party sender (newsletter platform, CRM) needs its own DKIM setup using your domain, usually through CNAME records the provider supplies.

Step 5: Read the reports and fix failures

For two to four weeks, review aggregate reports. Every legitimate source must pass DMARC, which means either SPF or DKIM passes and aligns with the domain in the visible From address. Common culprits: a marketing tool signing with its own domain, or a forwarding service breaking SPF. Fix each one before moving on. The Cyber Centre suggests a short time to live (TTL) of 30 minutes on records you are still changing, and 24 hours once they are stable.

Phase 3: Enforce

Step 6: Move to quarantine, then reject

1. Change the policy to p=quarantine. Optionally use the pct tag to apply it to a share of failing mail first.
2. Watch reports and help desk tickets for a few weeks.
3. Move to p=reject with pct=100, the Cyber Centre's end state. Federal departments must reach quarantine or reject in phases based on their risk profile.

Step 7: Lock down domains that never send mail

Attackers also spoof parked and unused domains. For each one, the Cyber Centre recommends:

• a null MX record (preference 0, host "."), showing the domain accepts no mail;
• an SPF record of v=spf1 -all, published as a wildcard to cover subdomains;
• a DMARC record with p=reject, sp=reject and pct=100, plus a reporting address.

Phase 4: Maintain

• Keep reviewing DMARC reports; new unauthorized senders show up there first.
• Add authentication to every new email service before it goes live.
• Rotate DKIM keys at least once a year.
• Check inbound mail too: make sure your gateway validates SPF, DKIM and DMARC on messages you receive.

Troubleshooting common failures

• SPF permerror: usually too many DNS lookups or two SPF records on one domain. Flatten or remove unused includes.
• DKIM passes but DMARC fails: the message is signed with the provider's domain, not yours. Set up custom-domain DKIM with that provider.
• Mailing lists and forwarders: forwarding often breaks SPF, and list software that edits messages can break DKIM. Watch reports for these sources before moving to reject.

What this does not do

DMARC stops exact-domain spoofing. It does not stop look-alike domains (example-ca.com) or mail sent from a genuinely compromised account. Pair it with user awareness, MFA and a clear rule that payment changes are confirmed by phone using a known number.

Sources

• Canadian Centre for Cyber Security: Implementation guidance, email domain protection (ITSP.40.065 v1.1)
• Government of Canada: Email management services configuration requirements
• Microsoft Learn: How to use DKIM for email in your custom domain
• Google Workspace Admin Help: Email sender guidelines