If your email keeps landing in spam, or you've been told to "set up SPF, DKIM and DMARC" and have no idea where to start, this guide is the map. These three records are the backbone of email authentication — the system mailbox providers use to decide whether a message really came from your domain or from someone impersonating you. Get them right and your mail is trusted; leave them out and you're at the mercy of spam filters.

Why email needs authentication at all

The protocol that carries email, SMTP, was designed in an era of mutual trust and has no built-in way to verify the sender. Anyone can connect to a mail server and claim to be billing@yourbank.com. That open design is exactly what spammers and phishers exploit. Email authentication adds the missing proof: a set of DNS records that let receiving servers cryptographically and administratively confirm that a message was authorised by the domain it claims to come from.

Since February 2024, Google and Yahoo require every sender to authenticate, and bulk senders must publish a DMARC policy. Authentication is no longer optional or "advanced" — it's the price of admission to the inbox.

The three records, in plain English

SPF — who is allowed to send

SPF (Sender Policy Framework) is a published list of the servers and services allowed to send mail using your domain. You add a TXT record naming your provider — for example include:_spf.google.com for Google Workspace. When a receiving server gets a message, it checks whether the sending server appears on your list. If it doesn't, that's a strike against the message.

DKIM — proof the message wasn't forged or altered

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to every message you send. Your mail provider signs each message with a private key; the matching public key lives in your DNS. The receiver fetches the public key, verifies the signature, and confirms two things: the message genuinely came from your domain, and nothing in it was tampered with in transit.

DMARC — what to do when checks fail, and who to tell

DMARC (Domain-based Message Authentication, Reporting & Conformance) ties the other two together. It tells receiving servers what to do with mail that fails SPF and DKIM — do nothing, send it to spam, or reject it outright — and it asks them to send you reports showing who is sending mail as your domain. Without DMARC, SPF and DKIM still run, but you have no policy and no visibility.

How they work together: alignment

The piece that makes DMARC powerful is alignment. It's not enough for SPF or DKIM to merely pass — the domain they authenticate must match the domain in the visible From: address. A spammer can easily make SPF pass for their own domain, but they can't make it align with yours. DMARC passes only when at least one of SPF or DKIM both passes and aligns with the From: domain. That alignment requirement is what actually stops impersonation.

In one sentence: SPF lists your senders, DKIM signs your mail, and DMARC enforces a policy and reports abuse — and alignment ensures all of it is tied to the domain your recipients actually see.

The order to set them up in

  1. SPF first. It's the simplest — one TXT record listing your sending services. Most providers give you the exact value to publish.
  2. DKIM next. Turn on signing in your mail provider's admin console; it gives you a record (or two) to add to DNS. Once published, your mail is signed.
  3. DMARC last. Only enable a DMARC policy once SPF and DKIM are passing, and start in monitoring mode (p=none) so you can read reports before tightening. Jumping straight to p=reject can block your own legitimate mail.

Common misconceptions

"I have SPF, so I'm covered." SPF alone doesn't stop spoofing of your visible From: address, and it breaks when mail is forwarded. You need DKIM and DMARC too.

"DMARC will block my email." Only if you set an enforcing policy before your real mail authenticates. Started correctly, at p=none, DMARC changes nothing about delivery — it just reports.

"This is a one-time setup." Every time you add a new sending service (a newsletter platform, a CRM, a helpdesk), you need to authorise it in SPF and ideally have it sign with DKIM, or its mail will fail your DMARC policy.

Check where you stand

The fastest way to see your current state is to look all three up at once. MXHelper's full domain check reports SPF, DKIM, and DMARC together, flags what's missing or misconfigured, and gives provider-specific steps to fix each one. From there you can read the deeper guides on SPF, DKIM, and setting up DMARC.