SPF, DKIM, DMARC: Email Authentication for People Who Don't Want To Read RFCs

Three DNS records — SPF, DKIM, and DMARC — together decide two huge things about your business email:

• Whether your outgoing emails land in inboxes or in spam folders.
• Whether attackers can spoof your domain to scam your customers and partners.

Most companies have them set up incorrectly or not at all. This is the plain-English version of what they do, in the order you should configure them.

The 30-second mental model

Email was designed in 1982. Authentication was not a requirement. Anyone can send an email claiming to be from any address. SPF, DKIM, and DMARC are three decades of patches layered on top to fix that.

• SPF answers: which servers are allowed to send email for my domain?
• DKIM answers: was this specific email actually signed by my domain's private key?
• DMARC answers: what should the receiver do when SPF or DKIM fails, and please tell me about it.

Each one alone is incomplete. Together they're a working defense.

SPF: which servers can send for you

SPF is a single TXT record at your domain root that lists the IP addresses and hostnames allowed to send email from your domain. For a typical business it looks something like this:

example.com.  TXT  "v=spf1 include:_spf.google.com include:resend.com -all"

Two things to get right:

• List every sender. If you use Google Workspace, Resend, Mailchimp, and your CRM — they all need to be in the record (via include: directives that the provider gives you). Forget one and that service's emails fail SPF.
• End with -all, not ~all. The hyphen means "hard fail — drop unauthorised senders." The tilde means "soft fail — accept but mark suspicious." Use hard fail in production once you're sure the record is complete.

Watch out for the 10-lookup limit. SPF only allows 10 DNS lookups total per record. Big providers (Microsoft 365, Salesforce) burn through these fast. If you hit the limit, every email fails SPF — silently. Use a free SPF flattener or limit your includes.

DKIM: cryptographically signing every message

DKIM puts a digital signature in the header of every outgoing email. Your sending platform signs the message with a private key; the matching public key is published in your DNS so receivers can verify.

Receivers do this for you automatically. Your job is:

• Enable DKIM signing in every sending platform you use (Gmail/Google Workspace, Microsoft 365, Resend, Mailchimp, etc.). Each is a one-click setting plus a DNS record they give you.
• Use at least 2048-bit RSA keys. 1024-bit is still accepted but considered weak — and the major mailbox providers have started flagging 1024-bit signers in their reputation systems.
• Rotate keys every 6–12 months. Most platforms do this automatically if you let them manage the records.

DMARC: the rule that ties it together

DMARC is the policy. It tells receiving mail servers:

• If SPF and DKIM both fail, do what?
• Send me a report so I can see what's being sent in my name.

A simple, safe starting record:

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

Three policy modes, in order of strictness:

• p=none — receivers do nothing, but send you reports. Start here. Run for at least 4 weeks to see exactly which legitimate senders are failing.
• p=quarantine — failed messages go to the recipient's spam folder. Move here once your reports show no legitimate failures.
• p=reject — failed messages are dropped entirely. This is the goal. At p=reject, attackers cannot spoof your domain to any modern mailbox provider.

Move gradually. Jumping straight to p=rejectwithout monitoring reports first is how companies accidentally drop their own newsletter, payment notifications, or recruiter outreach.

DMARC reports: actually read them

The rua address in your DMARC record receives daily XML reports from every mailbox provider that receives email claiming to be from your domain. They're unreadable in raw form but services like Postmark's free DMARC monitoring or dmarcian parse them into dashboards.

Reports tell you two valuable things:

• Your own legitimate sources you forgot about. Almost every company runs DMARC for the first time and discovers their payroll provider, recruiting tool, or a long-forgotten marketing automation account is sending in their name.
• Spoofing attempts in real time. Volume spikes from random IPs trying to send as your domain. That's an attack in progress.

BIMI: the bonus round

Once you reach p=quarantine or p=reject, you unlock BIMI — Brand Indicators for Message Identification. Add one more DNS record pointing to a verified SVG version of your logo, and major providers (Gmail, Apple Mail, Yahoo) will display your logo next to your emails in the inbox.

BIMI does two things at once: marketing (recognisable brand presence in every inbox) and security (visual cue that this email is genuinely authenticated). It requires a paid certificate (VMC) from a CA, typically €1000–1500/year. Worth it if email is a major channel for your business.

Quick checklist

1. SPF record published with every legitimate sender, ending in -all.
2. DKIM signing enabled and DNS records published for every sending platform, 2048-bit minimum.
3. DMARC starts at p=none with reporting on.
4. Use a DMARC monitoring service (free tiers exist).
5. After 4+ weeks of clean reports, move to p=quarantine.
6. After another month of clean reports, move to p=reject.
7. Optional: add BIMI for visual branded inboxes.

The bottom line

Most companies treat email authentication as someone else's job — and attackers thank them for it. The records take an hour to set up, cost nothing, and stop entire categories of attacks against your customers. If you do nothing else from this article, get DMARC reports running tomorrow. You'll be surprised by what they show.