SPF, DKIM and DMARC: Email Security in Plain Language

Your business email might be landing in spam folders. Or worse, someone might be sending emails that look like they come from your domain. SPF, DKIM and DMARC are three email security protocols that prevent both problems.

They sound technical. They are technical. But the concepts behind them are simple, and setting them up takes about 30 minutes.

What each protocol does

Think of sending an email like sending a physical letter. These three protocols each solve a different trust problem.

SPF: who is allowed to send mail from your domain

SPF stands for Sender Policy Framework. It's a DNS record that lists which mail servers are allowed to send email on behalf of your domain.

Without SPF, anyone can send an email that claims to come from yourcompany.nl. With SPF, the receiving mail server checks whether the sending server is on your approved list. If it's not, the email gets flagged.

Real-world analogy: SPF is like telling the post office "only these three people are authorized to send letters with our company letterhead."

DKIM: proof the message wasn't tampered with

DKIM stands for DomainKeys Identified Mail. It adds a digital signature to every email you send. The receiving server can verify that the email hasn't been changed since it left your server.

Your mail server signs each outgoing email with a private key. The receiving server looks up your public key in DNS and checks whether the signature matches. If someone changed the email in transit, the signature breaks.

Real-world analogy: DKIM is like a wax seal on a letter. If the seal is broken, you know someone opened it.

DMARC: what to do when checks fail

DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It ties SPF and DKIM together and tells receiving servers what to do when an email fails those checks.

DMARC also sends you reports about who is sending email from your domain. This is how you discover if someone is spoofing your address.

Real-world analogy: DMARC is your policy for what the post office should do with suspicious letters. Deliver them anyway? Put them aside for review? Reject them completely?

Why this matters for your business

Two reasons: deliverability and security.

Deliverability. Gmail, Outlook and other major email providers check SPF, DKIM and DMARC when deciding where to put your email. Without them, your perfectly legitimate business emails are more likely to land in spam. Since February 2024, Google requires SPF or DKIM for anyone sending to Gmail addresses. Bulk senders need all three.

Security. Without these protocols, attackers can send phishing emails that appear to come from your domain. They can email your customers, your suppliers, or your own employees pretending to be you. This is called domain spoofing and it's disturbingly easy without DMARC.

How to check your current setup

Using dig commands

If you're comfortable with the command line, you can check your records directly:

# Check SPF record
dig TXT yourcompany.nl | grep spf

# Check DKIM record (replace 'default' with your DKIM selector)
dig TXT default._domainkey.yourcompany.nl

# Check DMARC record
dig TXT _dmarc.yourcompany.nl

Using online tools

If command line isn't your thing, these free tools work well:

• MXToolbox.com has SPF, DKIM and DMARC lookup tools
• mail-tester.com lets you send a test email and grades your setup
• dmarcian.com/dmarc-inspector checks your DMARC record specifically

Our free website scanner also checks your domain's email authentication records as part of a broader security review.

Setting up SPF

SPF is a single TXT record in your DNS. Here is what it looks like:

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

Breaking that down:

• v=spf1 declares this is an SPF record
• include:_spf.google.com authorizes Google Workspace to send mail for your domain
• include:sendgrid.net authorizes SendGrid for transactional emails
• -all means reject everything else

Step by step:

1. List every service that sends email from your domain. Think about: your email provider, your website contact form, your newsletter tool, your CRM, your invoicing software.
2. Find the SPF include statement for each service. They all publish these in their documentation.
3. Combine them into one TXT record. You can only have one SPF record per domain.
4. Add the record to your DNS settings at your domain registrar or DNS provider.
5. Test it using MXToolbox or dig.

Common mistakes:

• Having two SPF records. You can only have one. Merge them.
• Forgetting a sending service. If your invoicing tool sends emails from your domain and isn't in the SPF record, those emails will fail.
• Using ~all instead of -all. The tilde means "soft fail," which is less strict. Use -all once you're confident your list is complete.
• Exceeding 10 DNS lookups. SPF has a limit of 10 include/redirect lookups. If you use many services, you might need to consolidate.

Setting up DKIM

DKIM requires two things: your mail server signs outgoing messages, and you publish the public key in DNS.

Most email providers handle the signing automatically. You just need to add the DNS record they give you.

For Google Workspace:

1. Go to Admin console > Apps > Google Workspace > Gmail > Authenticate email
2. Click "Generate new record"
3. Copy the TXT record value
4. Add it to your DNS as a TXT record for google._domainkey.yourcompany.nl

For Microsoft 365:

1. Go to Microsoft 365 Defender > Email & collaboration > Policies > Threat policies > Email authentication settings
2. Select your domain and follow the DKIM setup wizard
3. Add the two CNAME records they provide to your DNS

The DNS record looks something like this:

google._domainkey.yourcompany.nl  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

The long string after p= is your public key. Receiving servers use it to verify the signature on your emails.

Setting up DMARC

DMARC is another TXT record in DNS. Start with a monitoring-only policy:

_dmarc.yourcompany.nl  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.nl"

Breaking that down:

• v=DMARC1 declares this is a DMARC record
• p=none means "don't block anything yet, just report"
• rua=mailto:dmarc@yourcompany.nl is where aggregate reports get sent

The three DMARC policies:

| Policy | What it does | When to use | |---|---|---| | p=none | Monitor only. Emails still get delivered. | Start here. Collect data for 2-4 weeks. | | p=quarantine | Failed emails go to spam. | After you've fixed all legitimate senders. | | p=reject | Failed emails get blocked completely. | When you're confident everything is set up correctly. |

Important: p=none is not protection. Many businesses set up DMARC with p=none and think they're done. They're not. p=none only collects reports. It doesn't stop anyone from spoofing your domain. It's a diagnostic tool, not a security control.

Step by step to full protection:

1. Set p=none and wait 2-4 weeks
2. Review the reports. Services like dmarcian.com or Postmark's free DMARC monitoring can parse the XML reports into readable dashboards
3. Fix any legitimate senders that are failing SPF or DKIM
4. Move to p=quarantine for another 2-4 weeks
5. If everything looks clean, move to p=reject

The whole process takes about 4 to 8 weeks. Don't rush to p=reject without the monitoring phase, or you'll block your own legitimate emails.

A complete example

Here is what a properly configured setup looks like for a small business using Google Workspace and Mailchimp:

# SPF record
yourcompany.nl  TXT  "v=spf1 include:_spf.google.com include:servers.mcsv.net -all"

# DKIM record (Google)
google._domainkey.yourcompany.nl  TXT  "v=DKIM1; k=rsa; p=MIIBIjANB..."

# DKIM record (Mailchimp)
k1._domainkey.yourcompany.nl  CNAME  dkim.mcsv.net

# DMARC record
_dmarc.yourcompany.nl  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@yourcompany.nl"

Four DNS records. That's all it takes to protect your email. If you're not sure about your current email security setup, scan your domain for free and we'll check these records for you.

Common Questions

Do I need all three protocols?

For proper protection, yes. SPF alone is easy to bypass. DKIM alone doesn't specify a policy. DMARC ties them together and gives you control. Think of it as a chain: each link matters.

Will setting up DMARC break my email?

Not if you start with p=none. This monitoring-only mode doesn't affect email delivery at all. You only move to blocking policies after you've confirmed everything works.

My newsletter tool sends from our domain. Will SPF block it?

Only if you forget to include it in your SPF record. Check your newsletter provider's documentation for their SPF include statement and add it to your record.

How do I read DMARC reports?

The raw reports are XML files and not easy to read directly. Use a free tool like Postmark's DMARC monitoring, dmarcian.com, or DMARC Analyzer to convert them into readable dashboards.

Does this apply to me if I only use Gmail or Outlook personally?

If you send email from your own domain, yes. If you only use a @gmail.com or @outlook.com address, Google and Microsoft already handle this for you.

---

Check your website now. Scan your domain for email security issues, missing records and other compliance problems. Free, no signup. Scan your website