If someone is sending fraudulent emails that look like they are coming from your domain, or if your legitimate emails are landing in spam, SPF, DKIM, and DMARC are the DNS records that fix it. Here is what each one does and how to set them up correctly for a BC business using Microsoft 365.
SPF: The Sender Allowlist
Sender Policy Framework (SPF) is a DNS TXT record that lists which mail servers are authorised to send email on behalf of your domain. When a receiving mail server gets a message claiming to be from yourcompany.ca, it checks your DNS to see if the sending server is on the list. If not, the message is more likely to be marked as spam or rejected.
For a Microsoft 365 domain, your SPF record should include include:spf.protection.outlook.com plus any other legitimate sending services (your CRM, your marketing platform). Every service that sends email on your behalf needs to be in the SPF record.
DKIM: The Cryptographic Signature
DomainKeys Identified Mail (DKIM) adds a cryptographic signature to outgoing email. The receiving server uses your public key (published in DNS) to verify the signature. If the signature checks out, the email has not been tampered with in transit and it genuinely came from a server you authorised.
In Microsoft 365, DKIM is configured in the Defender admin portal. You generate the DKIM keys, publish two CNAME records in your DNS, then enable signing. Once enabled, every outgoing M365 email gets a DKIM signature automatically.
DMARC: The Policy Layer
Domain-based Message Authentication, Reporting, and Conformance (DMARC) sits on top of SPF and DKIM. It tells receiving servers what to do with messages that fail authentication: none (monitor only), quarantine (send to spam), or reject (block delivery). It also specifies where to send aggregate reports about who is sending email using your domain.
Start with p=none to collect data about your mail streams. Run this for 30 days and review the DMARC reports (use a free tool like DMARC Analyser or MXToolbox to parse them). Once you understand all your legitimate senders, move to p=quarantine, then p=reject.
Why This Matters for Your Business
Without DMARC at enforcement, anyone can send email that appears to come from yourcompany.ca. Attackers use this to impersonate your business in supplier fraud schemes, invoice fraud, and phishing campaigns targeting your clients. A p=reject DMARC policy makes this category of attack significantly harder.
Google and Yahoo both began enforcing DMARC requirements for bulk senders in 2024. Microsoft followed with similar requirements for Outlook. If your domain does not have DMARC published, your legitimate emails will increasingly face deliverability challenges.
Common Mistakes to Avoid
The most common mistake is moving to p=reject before all legitimate sending services are in SPF and DKIM. If your CRM sends from your domain but is not in your SPF record, p=reject will cause those emails to bounce. Review every sending service before enforcing rejection.
Multiple SPF records are also a common error. Your domain should have exactly one SPF TXT record. Multiple records cause SPF to fail entirely. Use an SPF flattening tool if you have many sending services to merge them into a single record.