If someone can send an email that appears to come from your domain, they can impersonate your business to your customers, suppliers, and staff. SPF, DKIM, and DMARC are three DNS-based standards that prevent this. They also improve the deliverability of your legitimate email, reducing the chance that your messages end up in spam folders.
All three are configured as DNS records. None of them require software installation. And all three should be in place for any business domain used to send email.
The Problem They Solve
Email was designed without authentication. The original protocols have no mechanism to verify that an email claiming to come from invoices@yourcompany.com was actually sent by your mail server. Anyone can send an email with any sender address they choose.
This is exploited constantly: attackers send phishing emails impersonating banks, couriers, and businesses; fraudsters send fake invoices using a company’s actual domain; spammers use legitimate-looking addresses to bypass filters.
SPF, DKIM, and DMARC add authentication layers that let receiving mail servers verify the legitimacy of incoming email and decide what to do with messages that fail those checks.
SPF: Sender Policy Framework
What it does: Specifies which mail servers are authorised to send email on behalf of your domain.
SPF is a DNS TXT record that lists the IP addresses and services permitted to send email from your domain. When a receiving mail server gets an email claiming to be from your domain, it checks your SPF record to confirm the sending server is on the approved list.
Example SPF record:
v=spf1 include:spf.protection.outlook.com -allThis example authorises Microsoft 365’s mail servers to send email for your domain and instructs receiving servers to reject mail from any other source (-all).
What to include in your SPF record: Your primary email platform (Microsoft 365, Google Workspace), any third-party services that send email on your behalf (marketing platforms, CRM systems, invoicing tools), and any other legitimate sending sources.
Common mistake: Having multiple SPF records. A domain can only have one SPF record. If you have multiple sending services, combine them into a single record using include: statements.
DKIM: DomainKeys Identified Mail
What it does: Adds a cryptographic signature to outgoing emails that receivers can verify.
DKIM uses a public/private key pair. Your mail server signs each outgoing email with a private key. The corresponding public key is published in your DNS. Receiving mail servers retrieve your public key and use it to verify the signature on incoming messages.
If the signature is valid, the email hasn’t been tampered with in transit and genuinely originated from a server with access to your private key.
How to set it up: Your email platform (Microsoft 365, Google Workspace) generates the key pair and provides you with a DNS record to publish. In Microsoft 365, DKIM is configured under the Defender portal. In Google Workspace, it’s under Admin Console > Apps > Google Workspace > Gmail > Authenticate email.
DKIM signing is specific to each sending domain. If you use third-party services to send email on your behalf, they should provide their own DKIM records to publish for their sending domain or subdomain.
DMARC: Domain-based Message Authentication, Reporting and Conformance
What it does: Tells receiving mail servers what to do with email that fails SPF or DKIM checks, and provides reporting on email sent using your domain.
DMARC ties SPF and DKIM together. It specifies a policy: what should happen to email that claims to be from your domain but fails authentication? The options are:
none— take no action; just report (monitoring mode)quarantine— send failing messages to the spam folderreject— reject failing messages entirely
DMARC also introduces alignment: it checks that the domain in the visible From address matches the domain authenticated by SPF or DKIM. This closes a loophole where an attacker could pass SPF by sending from a different domain while displaying your domain in the From field.
A starting DMARC record:
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourcompany.comStart with p=none to collect reports without affecting mail flow. Review the reports to understand what’s sending email on behalf of your domain, ensure legitimate sources are covered by SPF and DKIM, then progress to p=quarantine and eventually p=reject.
DMARC reports come in two forms. Aggregate reports (RUA) provide a daily summary of all email sent using your domain. Forensic reports (RUF) provide detail on individual failures. Use a DMARC report analyser tool (several free options exist, including MXToolbox and Postmark’s DMARC analyser) to parse these into a readable format.
How They Work Together
SPF confirms the sending server is authorised. DKIM confirms the message hasn’t been tampered with and originated from an authorised source. DMARC enforces policy on messages that fail either check and provides visibility into email sent using your domain.
All three working together provide meaningful protection against domain spoofing. SPF or DKIM alone are insufficient; without DMARC, there’s no policy enforcement even if authentication fails.
Setting Up: Practical Steps
- Configure SPF. Add a TXT record to your domain’s DNS listing all authorised sending sources. Use an SPF generator tool (MXToolbox has a good one) if you’re unsure of the syntax.
- Enable DKIM. In your email platform’s admin settings, generate DKIM keys and publish the provided DNS record. Allow up to 48 hours for DNS propagation before enabling signing.
- Add a DMARC record. Start with
p=noneand an RUA address to receive aggregate reports. Review reports over 2 to 4 weeks to identify all legitimate sending sources. - Tighten the policy. Once you’re confident all legitimate sending is covered, move to
p=quarantine, thenp=reject.
What These Records Don’t Do
SPF, DKIM, and DMARC protect your domain from being spoofed in the From address. They don’t:
- Prevent someone from registering a lookalike domain (e.g.
yourcompany-invoices.com) and sending from that - Protect against phishing emails that pass authentication from legitimate but compromised accounts
- Replace spam filtering or endpoint security
They are one important layer in a broader email security posture.