SPF, DKIM and DMARC explained: stop criminals sending email as you

Anyone can send an email that claims to come from your domain. Without the right records in place, a criminal can email your clients from “accounts@yourbusiness.ca” asking them to update your bank details, and it may land in their inbox looking entirely genuine.

Three DNS records stop that: SPF, DKIM and DMARC. They also help your legitimate mail reach inboxes rather than spam folders. Google, Yahoo and Microsoft now expect them, and require them for senders of large volumes.

SPF: who is allowed to send

Sender Policy Framework is a DNS record listing the services allowed to send email for your domain, such as Microsoft 365, your invoicing system or your newsletter platform. A receiving server checks whether the sending server is on the list.

Things to know:

• One SPF record per domain. Two records break it. Every sender goes in the same record.
• A limit of 10 DNS lookups. Each “include” counts, and exceeding the limit makes SPF fail. Businesses with many sending services run into this.
• The ending matters. ~all means “treat others with suspicion”; -all means “reject others”. Start with ~all while you confirm every sender, then tighten it.

DKIM: a signature on every message

DomainKeys Identified Mail adds a cryptographic signature to each outgoing message. The receiving server checks it against a public key published in your DNS. If the message was altered, or did not come from a system holding your private key, the check fails.

In Microsoft 365, DKIM is enabled by publishing two DNS records and switching it on in the admin portal. Other services that send as your domain, such as CRMs and marketing platforms, provide their own DKIM records to publish.

DMARC: the policy that ties it together

Domain-based Message Authentication, Reporting and Conformance tells receiving servers what to do when a message fails the checks, and sends you reports about who is sending mail using your domain.

DMARC has three policy levels:

1. p=none: monitor only. Nothing is blocked, but you receive reports.
2. p=quarantine: failing messages go to spam.
3. p=reject: failing messages are refused outright.

DMARC also checks alignment, meaning the domain the recipient sees in the “From” line must match the domain verified by SPF or DKIM. This is what actually stops look-alike spoofing.

The rollout that does not break anything

The risk with email authentication is blocking your own legitimate mail: invoices from accounting software, notifications from your website, a scanner that emails PDFs. Roll it out in stages:

1. List every service that sends as your domain. Microsoft 365, accounting and invoicing, CRM, newsletters, your website’s contact form, booking systems, scanners and printers.
2. Publish SPF covering them all, ending in ~all.
3. Enable DKIM for Microsoft 365 and for each other sender that supports it.
4. Publish DMARC at p=none with a reporting address, and read the reports for a few weeks.
5. Fix any legitimate senders that fail.
6. Move to p=quarantine, then p=reject, once the reports show only unauthorised mail failing.

Common mistakes

• Two SPF records, often left behind by a previous provider
• Forgetting a sender, so invoices start going to spam after DMARC is tightened
• Sitting at p=none forever, which reports spoofing but never stops it
• Nobody reading the reports, so problems go unnoticed
• Leaving parked or unused domains unprotected. A domain that sends no mail should publish records saying so, because criminals use them too.

Check your own domain

Several free online tools will look up your SPF, DKIM and DMARC records and flag problems. If DMARC is missing, or sitting at p=none with nobody reading the reports, it is worth fixing.

Email authentication is part of our managed security service, and we set it up as standard in every Microsoft 365 tenant we manage.