Anyone on the internet can send an email that says it is from your domain. Email was designed that way decades ago, and it has never been fixed at the root. SPF, DKIM and DMARC are the three DNS records that patch over it, so a receiving mail server can tell whether a message claiming to be from you really is.
If you have never looked at them, there is a fair chance your domain is only partly set up. That has two costs. Criminals can send fake invoices that appear to come from your exact address, and more of your own genuine email ends up in junk folders or bounces, because the big mailbox providers now check.
What each one does
SPF (Sender Policy Framework) is a list, published in DNS, of the servers allowed to send email for your domain. For a Microsoft 365 business it usually includes spf.protection.outlook.com plus any other service that sends as you: your accounting package, your CRM, your newsletter tool. The catch is that SPF checks the hidden "envelope" sender rather than the From address people see, and an SPF record can only trigger 10 DNS lookups before it fails.
DKIM (DomainKeys Identified Mail) puts a cryptographic signature on each message. The receiving server looks up your public key in DNS and checks that the message was signed by your domain and not altered on the way. In Microsoft 365, DKIM for your own domain is switched on in the Defender portal and needs two CNAME records at your DNS host.
DMARC ties the two together. It checks that the domain in the visible From address matches (aligns with) the domain that passed SPF or DKIM, then tells receivers what to do when it does not: nothing (p=none), send it to junk (p=quarantine) or refuse it (p=reject). It also asks receivers to send you daily aggregate reports, which is how you find out who is sending as you.
Only DMARC at quarantine or reject actually stops someone spoofing your domain. p=none is monitoring and nothing more. Enforcement has a cost too: it can disrupt mail that passes through mailing lists and some forwarding services, and the updated DMARC standard (RFC 9989, below) cautions against p=reject on domains used for everyday staff email for that reason. Check how your mail actually flows before you enforce.
Why this became urgent
The large mailbox providers moved from recommending these records to requiring them.
- Google and Yahoo, February 2024. Google's rules for sending to personal Gmail accounts took effect on 1 February 2024. Every sender needs SPF or DKIM. Anyone sending more than 5,000 messages a day to Gmail needs SPF, DKIM and a DMARC record (which can be
p=none), must keep reported spam rates under 0.3%, and must support one-click unsubscribe for marketing. Yahoo started enforcing similar requirements in the same month. - Microsoft, May 2025. Microsoft announced in April 2025 that domains sending more than 5,000 messages a day to Outlook.com, Hotmail and Live addresses must pass SPF and DKIM and publish DMARC of at least
p=none, aligned with SPF or DKIM. Enforcement began on 5 May 2025, and Microsoft said non-compliant mail would be rejected with the error550 5.7.515.
Most small businesses do not send 5,000 messages a day. Your newsletter platform might, on your behalf. And Google's baseline of SPF or DKIM applies to every sender, whatever the volume. Getting authentication right now affects whether your mail arrives, as well as who can fake it.
How to get from p=none to reject in Microsoft 365
Microsoft's own guidance is a gradual rollout, and it is the right approach. Rushing to reject is how businesses end up blocking their own invoices.
- List every service that sends as your domain. Microsoft 365, plus accounting, payroll, CRM, website forms, marketing, the photocopier that scans to email. People forget at least one.
- Fix SPF. One SPF record per domain, including every legitimate sender, under the 10-lookup limit, ending in
-allor~all. - Turn on DKIM for each custom domain in Microsoft 365, and for each third-party sender that supports signing with your domain.
- Publish DMARC at
p=nonewith reporting. For example, a TXT record at_dmarc.yourdomain.com.auwithv=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com.au. Use a reporting service to read the reports: the raw XML is not meant for people. - Watch for a few weeks. Every legitimate source should pass SPF or DKIM with alignment. Fix each one that does not, usually by setting up DKIM in that service.
- Move to
p=quarantine, thenp=reject. Microsoft recommends starting with lower-volume domains or subdomains and leaving the main domain for last. Keep reading the reports at each step. - Protect domains that never send email. Parked domains and your
onmicrosoft.comdomain should have an SPF record ofv=spf1 -alland DMARC atp=reject, so nobody can use them either.
One 2026 change to know about. In May 2026 the IETF published RFC 9989, the updated DMARC standard, which replaces RFC 7489. It removes the pct= tag that let you apply a policy to a percentage of mail, and adds a t= test flag in its place. Existing records keep working, and records still start with v=DMARC1, but receivers will move to the new rules over time. If your rollout plan relies on stepping pct from 10 to 100, test each step with a whole domain or subdomain instead.
DMARC does not stop lookalike domains, like your name with an extra letter. That is why the payment process in our article on business email compromise and fake invoice fraud still matters.
Where Geidi fits
Our cloud and business systems service implements and manages the platforms your people work in every day, alongside our 24/7 security operations centre. If you are not sure what your records say, talk to us.
Sources
- Google Workspace Admin Help: Email sender guidelines
- Yahoo Sender Hub: Sender best practices and requirements
- Microsoft Defender for Office 365 blog: Outlook's new requirements for high-volume senders
- Microsoft Learn: Set up DMARC to validate the From address domain
- Microsoft Learn: How to use DKIM for email in your custom domain
- Microsoft Learn: Set up SPF to identify valid email sources
- RFC Editor: RFC 9989, Domain-Based Message Authentication, Reporting, and Conformance (DMARC), May 2026
