If fraudulent emails are being sent that appear to come from your domain, or if your legitimate emails are regularly landing in recipients' spam folders, the problem is almost certainly in your email authentication records, SPF, DKIM, and DMARC. These are three DNS records that together tell the world's mail servers which servers are authorised to send email on your behalf, and what to do when an unauthorised server tries. Here is what each one does and how to set them up correctly for a BC business on Microsoft 365.
SPF: The Authorised Sender List
Sender Policy Framework (SPF) is a DNS TXT record that lists the mail servers authorised to send email from your domain. When a receiving mail server gets a message from yourcompany.ca, it checks your domain's DNS to see if the sending server is on the SPF list. If it's not, the message is more likely to be rejected or marked as spam.
For a Microsoft 365 domain, your SPF record should include:
`` v=spf1 include:spf.protection.outlook.com -all ``
The -all at the end instructs receiving servers to reject mail from servers not listed. (Some guides recommend ~all, a soft fail. In 2026, -all is preferable for most business domains.)
The common SPF mistake: Every service that sends email on your behalf needs to be in the SPF record, your CRM, your marketing platform, your helpdesk system, your ERP if it sends invoices. Missing one means that service's mail is likely to be flagged as spam.
SPF also has a 10-lookup limit. If you have many sending services, you may need a flattening tool to keep the record within the limit.
DKIM: The Cryptographic Signature
DomainKeys Identified Mail (DKIM) adds a cryptographic signature to every outgoing email. The receiving server uses your domain's published public key to verify that the signature is valid, confirming that the email genuinely came from a server you control and has not been altered in transit.
For Microsoft 365, DKIM configuration involves:
- In the Microsoft Defender admin portal, navigate to Email & Collaboration > Policies & Rules > Threat policies > Email authentication settings.
- Select your domain and click Enable.
- M365 generates two CNAME records that you publish in your domain's DNS.
- Once the DNS records propagate (typically 15 - 60 minutes), enable DKIM signing in the portal.
After enabling, every email sent from M365 under your domain is signed. Receiving servers can verify the signature. This is a one-time setup that runs automatically afterward.
DMARC: The Policy Layer
Domain-based Message Authentication, Reporting, and Conformance (DMARC) sits on top of SPF and DKIM. It tells receiving mail servers what to do when a message fails SPF or DKIM alignment, and sends you reports showing who is sending email that claims to be from your domain.
DMARC is configured as a DNS TXT record on the _dmarc subdomain:
`` _dmarc.yourcompany.ca TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourcompany.ca; pct=100" ``
Policy options (p=):
none, Monitor only. Failing messages are delivered, but you receive reports. Start here if you're not sure all your legitimate senders are in SPF and DKIM.quarantine, Failing messages go to spam. Appropriate once you've confirmed all legitimate senders are covered.reject, Failing messages are rejected entirely. The strongest protection against spoofing. Move to this once you've validated the configuration.
The right progression: Start at p=none for 2 - 4 weeks while reviewing DMARC reports. Identify any legitimate senders that aren't in your SPF/DKIM configuration. Fix those. Then move to quarantine, then to reject.
The rua= tag specifies where aggregate DMARC reports are sent. Use a real mailbox you monitor, or a DMARC reporting service (Postmark, MXToolbox, Dmarcian) that presents reports in a readable format.
Why This Matters for BC Businesses
Email spoofing, sending email that appears to come from your domain, is used in business email compromise (BEC) attacks. A supplier with a p=reject DMARC policy is substantially harder to impersonate. Without DMARC at reject, anyone can send email that looks like it came from your domain.
Email deliverability also depends on these records. Google and Microsoft's mail infrastructure now penalise domains without properly configured SPF, DKIM, and DMARC, your legitimate emails are more likely to land in spam without them.
Common Mistakes to Avoid
- Multiple SPF records, You can only have one SPF TXT record per domain. Multiple records cause SPF to fail. Combine all your senders into one record.
- SPF without DMARC, SPF alone is not enough. DMARC is what enforces the policy and gives you reporting.
- Moving straight to
p=reject, Without reviewing reports first, you risk rejecting legitimate email from services you forgot to include in SPF/DKIM. - Setting DMARC on the wrong record, The record must be at
_dmarc.yourdomain.ca, notyourdomain.ca.
Talk to a Prince George-based IT team about setting up email authentication for your domain, call 672-983-1174 or book a free assessment at northstarit.ca.
Need email authentication set up correctly?
North Star configures SPF, DKIM, and DMARC for BC businesses as part of our M365 security baseline. Get a free email security assessment.
Book a Free Assessment Read more InsightsServices mentioned in this post.
Frequently asked questions
What is the difference between DKIM and DMARC?
DKIM provides a digital signature to verify that email content has not been tampered with, while DMARC uses both SPF and DKIM to tell receiving servers what to do if an email fails authentication. Together, they create a robust defence against domain spoofing. For businesses in BC or Alberta, implementing these protocols ensures that your clients and partners can trust that emails appearing to come from your domain are genuine and secure.
Does my small business really need SPF records?
Yes, SPF records are the first line of defence in email authentication. They list the specific IP addresses and services authorised to send email on behalf of your domain. Without an SPF record, major providers like Google and Microsoft may flag your mail as suspicious. Northstar IT helps organisations across Western Canada correctly configure these records to prevent delivery issues and stop hackers from impersonating your staff in phishing campaigns.
How do I know if my DMARC policy is working?
Effective DMARC implementation requires monitoring reports generated by receiving mail servers. These reports show who is sending mail using your domain and whether they passed or failed authentication. By moving from a none policy to a quarantine or reject policy, you actively block unauthorised mail. Our managed IT services include regular audits of these logs to ensure your email infrastructure remains secure and compliant with modern industry standards.