SPF, DKIM and DMARC Explained: Why Every Business Domain Needs All Three

This guide explains what each one does, how they work together, and how to get them set up correctly.

Why Email Authentication Exists

The email protocol SMTP was built in the 1980s and has a fundamental flaw: anyone can send an email claiming to be from any domain. There is no built-in verification. That’s why phishing, spoofing and business email compromise (BEC) remain so widespread: the infrastructure that carries email was never designed to stop them.

SPF, DKIM and DMARC were developed to fill that gap. They don’t change how email works at a basic level; they layer authentication checks on top of the existing system using DNS records that receiving mail servers can look up and act on.

SPF: Sender Policy Framework

What it does

SPF tells receiving mail servers which IP addresses are authorised to send email on behalf of your domain. It’s a DNS TXT record that acts as an approved sender list.

When someone receives an email from your domain, their mail server checks your SPF record and compares the sending IP address against your approved list. If the IP matches, the check passes. If it doesn’t, the message is either flagged or rejected, depending on how the receiving server handles SPF failures.

What an SPF record looks like

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Breaking this down:

• v=spf1: identifies this as an SPF record
• include: adds approved sending sources (your email provider, CRM, newsletter platform and so on)
• ~all: a soft fail, meaning unauthorised senders are flagged but not outright rejected
• -all: a hard fail, meaning unauthorised senders are rejected

SPF’s limitations

SPF has two important weaknesses worth understanding.

First, it only checks the “envelope from” address, the technical sending address used between mail servers, not the “From” address your recipients actually see in their inbox. This means someone can spoof the visible From address while still passing SPF.

Second, SPF breaks when email is forwarded. When a message is forwarded, the forwarding server’s IP address isn’t on your SPF list, so the check fails even though the message is legitimate. DKIM was developed partly to solve this.

DKIM: DomainKeys Identified Mail

What it does

DKIM adds a cryptographic digital signature to your outgoing emails. The signature is generated using a private key held by your sending server, and verified using a public key that you publish in your DNS records.

The signature travels with the message. When the receiving server gets the email, it looks up your public key in DNS, uses it to verify the signature and confirms two things:

1. The email genuinely came from a server authorised by your domain
2. The content of the email has not been altered in transit

What a DKIM record looks like

selector._domainkey.yourdomain.com  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB..."

The selector is a label that links the DNS record to a specific signing key, useful if you use multiple email platforms, as each can have its own selector.

Why DKIM survives forwarding

Because the DKIM signature is embedded in the email headers and travels with the message, it doesn’t depend on the sending IP address. When an email is forwarded, the signature remains intact and the DKIM check still passes, unlike SPF.

DKIM’s limitation

DKIM confirms that a message was signed by a legitimate key and hasn’t been modified. But it doesn’t, on its own, check that the signing domain matches the From address your recipient sees. That’s where DMARC comes in.

DMARC: Domain-based Message Authentication, Reporting and Conformance

What it does

DMARC builds on SPF and DKIM by answering a question neither of them fully addresses: what should happen to a message that fails authentication?

Without DMARC, a receiving server makes its own decision about what to do with a message that fails SPF or DKIM. With DMARC, you tell receiving servers exactly what to do, and you get reports back showing what’s happening with email sent from your domain.

DMARC also introduces “alignment”, a check that the domain in your SPF or DKIM result actually matches the From address the recipient sees. This closes the gap that allows spoofing even when SPF or DKIM individually pass.

The three DMARC policies

v=DMARC1; p=none; rua=mailto:[email protected]

• p=none: monitoring only, no action taken on failures (good starting point)
• p=quarantine: failing messages go to spam
• p=reject: failing messages are blocked entirely

What alignment means

For DMARC to pass, at least one of the following must be true:

• SPF alignment: the domain in the MAIL FROM address matches the From address in the email header
• DKIM alignment: the d= domain in the DKIM signature matches the From address

This is the key point that makes DMARC genuinely protective rather than just advisory. An attacker can set up their own domain with valid SPF and DKIM: but they can’t make those records align with your domain in the From header.

DMARC reports

DMARC includes a reporting mechanism that sends aggregate data (and optionally, forensic reports on individual failures) to an email address you specify. These reports tell you:

• Which servers are sending email claiming to be from your domain
• Whether SPF and DKIM are passing or failing
• Whether any unauthorised sources are attempting to send on your behalf

This visibility is genuinely valuable: not just for security, but for diagnosing deliverability issues before they become serious.

How the Three Work Together

Think of them as three layers of a security check:

Using just SPF or just DKIM leaves gaps. An attacker can pass SPF from a different domain while spoofing the From address. They can pass DKIM similarly. Only DMARC checks whether the authenticated domain matches what the recipient actually sees and enforces a policy when it doesn’t.

Why This Matters More in 2025

This has shifted from best practice to a hard requirement. Google and Yahoo introduced mandatory email authentication rules for bulk senders in early 2024. Microsoft followed with similar requirements for Outlook and Hotmail in 2025. If you’re sending more than 5,000 emails per day to these platforms without properly configured SPF, DKIM and DMARC, you face bulk delivery failures.

Even below that volume threshold, misconfigured authentication is now one of the most common reasons for emails being deferred or filtered to spam. Major mailbox providers treat it as a basic signal of sender legitimacy.

Beyond deliverability, there’s the brand and security angle. Business email compromise costs businesses billions every year. If your domain isn’t protected by DMARC at enforcement level (quarantine or reject), anyone can send emails that appear to come from you. That includes fake invoices, credential phishing, and impersonation attacks targeting your clients.

How to Set Up SPF, DKIM and DMARC

Step 1: Set up SPF

Add a TXT record to your DNS with the approved sending sources for your domain. If you use Google Workspace, that looks like:

v=spf1 include:_spf.google.com ~all

If you also send through a CRM, newsletter platform or other tool, add those too:

v=spf1 include:_spf.google.com include:_spf.mailchimp.com ~all

Keep in mind that SPF records have a 10 DNS lookup limit. If you’re using many sending platforms, this can become an issue. Tools like dmarcian or EasyDMARC can flatten your SPF record to stay within the limit.

Step 2: Set up DKIM

DKIM is usually enabled through your email platform rather than manually. In Google Workspace, go to Admin Console > Apps > Google Workspace > Gmail > Authenticate email. Generate the key, then add the TXT record provided to your DNS.

For other platforms (Mailchimp, SendGrid, HubSpot and so on), the process is similar. You’ll be given a CNAME or TXT record to add to your DNS.

Add a DMARC TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1

Start with p=none. This generates reports without blocking or filtering anything. After a few weeks of reviewing reports, you’ll see all the sources sending email from your domain, move to p=quarantine, then eventually to p=reject once you’re confident legitimate email is authenticating correctly.

Rushing straight to p=reject without reviewing reports first is a common mistake that can block legitimate email.

Verification

Once records are published, you can verify them using tools like:

• MXToolbox (mxtoolbox.com) – check SPF, DKIM and DMARC records
• Google Admin Toolbox (toolbox.googleapps.com) – useful for checking DNS propagation
• Mail-tester.com – sends a test email and scores your authentication setup

Common Mistakes to Avoid

Multiple SPF records: You can only have one SPF record per domain. If you add a second, both are ignored. Merge all your sending sources into a single record.

Skipping DKIM for third-party senders: If you send through a marketing platform, CRM or any other tool, DKIM should be configured for that platform too, not just your main email. Many platforms handle this via CNAME records you add to your DNS.

Going straight to p=reject: Without reviewing DMARC reports first, you risk rejecting legitimate email from platforms you’d forgotten about. Always monitor first.

Forgetting subdomains: SPF and DKIM records apply per domain. DMARC, by contrast, automatically covers subdomains that don’t have their own DMARC record, but if you have subdomains used for sending, it’s worth checking they’re configured correctly.

Ignoring the reports: DMARC reports are genuinely useful. Even if you’re already at p=reject, monitoring reports tells you if anyone is attempting to spoof your domain or if a new sending platform has been set up without proper authentication.

A Note on BIMI

Once DMARC is at enforcement level (quarantine or reject), you become eligible for BIMI, Brand Indicators for Message Identification. This is an emerging standard that lets you display a verified brand logo next to your emails in supporting inboxes (currently Gmail, Yahoo and Apple Mail). It’s a relatively new addition to the email authentication stack, but it’s worth knowing about as a next step once the core three are properly configured.

Summary

SPF, DKIM and DMARC solve different parts of the same problem. SPF controls which servers can send on your behalf. DKIM confirms message integrity through cryptographic signing. DMARC ties them together, adds alignment checking and gives you a policy for what happens when things fail.

All three are now required by major mailbox providers for bulk senders, and all three contribute meaningfully to deliverability and domain security even at lower sending volumes. If your domain doesn’t have all three configured and verified, it’s worth addressing sooner rather than later.

Websites on our Website Plans get this set up and monitored as standard, but if you need help auditing your current email authentication setup or getting these records configured correctly, get in touch with TEA Websites.