The problem they solve
Email was designed decades ago without any way to prove who sent a message. Anyone can configure an email program to say it's from [email protected], just as anyone can write any return address on an envelope. Scammers use this to send fake invoices, payment requests and phishing emails that appear to come from you.
SPF, DKIM and DMARC are the fixes that were added on top. They're published as records in your domain's DNS settings, the same place that tells the internet where your website and email live. Receiving mail servers, like Microsoft's and Google's, look them up and use them to decide whether a message claiming to be from you is genuine.
SPF: the guest list
SPF, short for Sender Policy Framework, is a list of the servers allowed to send email for your domain. If you use Microsoft 365, your SPF record includes Microsoft's servers. If your accounting software, website contact form or email marketing tool also sends email from your domain, they need to be on the list too.
When a message arrives claiming to be from you, the receiving server checks whether it came from a server on your list. SPF has limits: it checks a technical sender address that recipients don't normally see, and it breaks when messages are forwarded. That's why it isn't enough on its own.
DKIM: the tamper-proof seal
DKIM, short for DomainKeys Identified Mail, adds a digital signature to each email you send. Your email service signs the message with a private key, and you publish the matching public key in your DNS. The receiving server uses the public key to confirm the message really came through your system and wasn't changed along the way.
Think of it as a wax seal on a letter. Anyone can write your name on an envelope, but only you have the seal. DKIM survives forwarding better than SPF, which makes it the more reliable of the two in practice. Microsoft 365 and Google Workspace both support DKIM, but you may need to switch it on and add the records yourself.
DMARC: the instructions and the report
DMARC, short for Domain-based Message Authentication, Reporting and Conformance, ties SPF and DKIM to the From address people actually see, and tells receiving servers what to do with messages that fail. The policy can be none, which means just report, quarantine, which sends failures to spam, or reject, which blocks them entirely. DMARC also sends you reports showing who is sending email using your domain, both legitimate services and impersonators. Those reports are machine-readable files that are hard to read directly, so most businesses use a reporting service or their IT provider to turn them into something useful.
Why it matters more than it used to
Large email providers including Google and Yahoo now expect bulk senders to have SPF, DKIM and DMARC in place, and Microsoft has introduced similar expectations for high-volume senders. Even if your business doesn't send bulk email, messages from domains without these records are increasingly treated with suspicion and are more likely to land in spam.
There's a reputational side too. If scammers can send convincing emails using your exact domain, your customers and suppliers are the ones who get hurt, and your name is attached to the fraud. Strong DMARC gives them, and their email filters, a reliable way to tell the real you from a fake.
Setting them up without breaking your email
Start by listing every service that sends email from your domain: Microsoft 365 or Google Workspace, accounting and invoicing software, your website, CRM, booking systems and marketing tools. Add each to your SPF record and turn on DKIM for each where supported. Then publish a DMARC record with a policy of none and a reporting address. Watch the reports for a few weeks to find any legitimate senders you missed. Once everything genuine passes, move the policy to quarantine and then to reject. Rushing straight to reject can block your own invoices or website enquiries, which is why the gradual approach matters.
What these records won't do
SPF, DKIM and DMARC stop people using your exact domain. They don't stop a scammer registering a lookalike domain, such as one with a letter changed or a different ending, and they don't help if one of your real mailboxes is hacked, because messages from it are genuine. MFA, staff awareness and payment verification rules are still needed for those. They also only protect you from impersonation of your domain. To protect your own staff from spoofed incoming email, your email filtering should check other domains' DMARC results, which Microsoft 365 and Google Workspace do by default.
In short
- SPF lists the servers allowed to send your email.
- DKIM signs each message so it can be verified.
- DMARC tells receivers what to do with failures and reports who sends as you.
- Move gradually from a policy of none to reject to avoid blocking real email.
- These records stop exact-domain spoofing, not lookalike domains or hacked mailboxes.