Email Security

SPF, DKIM and DMARC: the complete setup guide

8 min read · Email Security · Check your domain →

If you run a domain that sends email, setting up SPF, DKIM, and DMARC is the single most impactful thing you can do for your email deliverability and domain reputation. This guide walks through all three, in the order you should implement them.

Part 1: SPF (Sender Policy Framework)

SPF tells the world which mail servers are authorised to send email from your domain. It's a TXT record published at the root of your domain.

How SPF works

When a mail server receives an email claiming to be from you@yourdomain.com, it looks up the SPF record for yourdomain.com and checks whether the sending server's IP is listed. If it isn't, the email fails SPF.

A basic SPF record

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

Common includes for popular providers

⚠️ The 10 DNS lookup limit — SPF records can cause a maximum of 10 DNS lookups. Each include:, a, and mx mechanism counts. Exceed this and SPF will fail entirely. If you use many email providers, consider an SPF flattening service.

Part 2: DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to every email you send. The receiving server can verify this signature using your public key, published in DNS. This proves the email really came from you and wasn't modified in transit.

How DKIM works

Your mail server signs each outbound email with a private key. The public key is published as a TXT record at selector._domainkey.yourdomain.com. The "selector" is just a name you choose — most providers use something like default, google, s1, or k1.

Setting up DKIM

DKIM setup depends on your mail provider. Generally:

  1. Your mail provider generates a public/private key pair
  2. They give you a TXT record to add to your DNS
  3. You publish it at the selector they specify (e.g. google._domainkey.yourdomain.com)
  4. Your provider begins signing outbound mail

For Plesk with Postfix/Dovecot, enable DKIM signing in Tools & Settings → Mail Server Settings. Plesk generates the keys and adds the DNS records automatically if you're managing DNS there.

DKIM record example

default._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBA..."

Part 3: DMARC

DMARC is the policy layer that sits on top of SPF and DKIM. It tells receivers what to do when mail fails authentication, and sends you reports showing who's sending as your domain.

Recommended rollout

Week 1–2: Publish a monitoring-only record and set up a reporting mailbox:

_dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; pct=100;"

Week 3–4: Review your reports. Confirm all legitimate senders (your mail server, marketing tools, helpdesk, etc.) are passing SPF or DKIM. Then move to quarantine at a low percentage:

v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@yourdomain.com;

Week 5–8: Gradually increase pct to 100:

v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@yourdomain.com;

Final state: Move to reject for full protection:

v=DMARC1; p=reject; pct=100; rua=mailto:dmarc@yourdomain.com; sp=reject;

🤖 Verify your setup at any stage with Fred's mail auth checker →

Domains that don't send email

For parked domains or domains that only receive email (never send), you still need protection. Publish these records:

@ TXT "v=spf1 -all"
*._domainkey TXT "v=DKIM1; p="
_dmarc TXT "v=DMARC1; p=reject;"

This tells the world: "nobody is authorised to send email from this domain — reject everything." The empty p= in DKIM records indicates the key has been revoked.

Also consider adding a null MX record so senders know not to attempt delivery:

@ MX 0 .

Troubleshooting common failures