Skip to content
article 4 min read

SPF, DKIM and DMARC, explained without the jargon.

Three DNS records decide whether your email is trusted or sent to spam. What each one does, and the order to set them up in.

Anyone can type your address into the From line of an email. Nothing in the way email was first designed stops them. SPF, DKIM and DMARC are three records in your domain’s DNS that let a receiving mail server check whether a message that claims to come from you really does.

They matter for two reasons. They make it much harder for someone to impersonate your business, and they help decide whether your own mail reaches the inbox. Gmail has required authentication from every sender since February 2024, and asks for all three records from anyone who sends more than 5,000 messages a day to Gmail accounts.

SPF: who is allowed to send

SPF (Sender Policy Framework) is a single TXT record that lists the servers allowed to send mail for your domain. When a message arrives, the receiving server looks up that list and checks whether the server that delivered the message is on it.

A typical record names your mail provider and anything else that sends as you, such as an invoicing system or a newsletter platform. Two limits catch people out. A domain can have only one SPF record, so adding a second one breaks both. And the record may trigger no more than ten DNS lookups, which is easy to exceed once several services have been added.

DKIM: proof the message was not changed

DKIM (DomainKeys Identified Mail) adds a digital signature to every message you send. Your mail provider signs with a private key, and the matching public key sits in your DNS. The receiving server uses the public key to confirm two things: the message was signed by your domain, and nobody altered it on the way.

Unlike SPF, a DKIM signature usually survives forwarding, because it travels with the message and does not depend on which server passed it along.

DMARC: the policy that ties them together

SPF and DKIM each check a technical detail that most people never see. DMARC (Domain-based Message Authentication, Reporting and Conformance) connects them to the address a person does see. A message passes DMARC when SPF or DKIM passes and the domain that was checked matches the domain in the From line.

DMARC also tells receivers what to do when a message fails. There are three policies:

  • none: deliver as normal and send reports. This is monitoring mode.
  • quarantine: treat failing mail as suspicious, which usually means the spam folder.
  • reject: refuse failing mail outright.

The reports are the valuable part at first. Receivers send regular summaries of every server that sent mail claiming to be you, and whether it passed. Most businesses find a service they had forgotten about.

The order to set them up in

  1. List everything that sends email as your domain: the mail service, the website, accounting and booking tools, newsletters, printers and scanners.
  2. Publish one SPF record that covers all of them.
  3. Turn on DKIM signing in each service that supports it, and publish the keys it gives you.
  4. Publish a DMARC record with the policy set to none, and an address to receive the reports.
  5. Read the reports for a few weeks. Fix any legitimate sender that is failing.
  6. Move the policy to quarantine, then to reject, once the only mail failing is mail you do not recognise.

What these records do not do

They protect your exact domain. They do not stop someone registering a lookalike domain, and they do not stop a real account that has been broken into from sending mail. That is why they sit alongside multi-factor authentication and staff who know how to spot a phishing email, not in place of them.

If you would rather not do this by hand, it is part of IT Support: we set up the records, watch the reports and move the policy when it is safe to.

Sources

  1. How to combat fake emails (Australian Signals Directorate) cyber.gov.au
  2. Email sender guidelines (Google) support.google.com
  3. How email authentication works in Microsoft 365 (Microsoft Learn) learn.microsoft.com
  4. DMARC overview (dmarc.org) dmarc.org
  5. RFC 7208: Sender Policy Framework (SPF) rfc-editor.org
  6. RFC 6376: DomainKeys Identified Mail (DKIM) Signatures rfc-editor.org
  7. RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) rfc-editor.org

Published by Only Tech Solutions.

This is general information, not advice for your situation. See the terms and conditions.

We can sort this for you

More articles

All articles

Tell us what needs sorting.

Book a call or send an email. We reply within one business day.