🛡️ Cybersecurity

SPF, DKIM and DMARC: Protecting Your Company's Email Domain

How SPF, DKIM and DMARC stop others from sending fake emails in your domain's name, and how to roll them out gradually without blocking genuine mail.

The protocol that carries email was born in an era when everyone trusted everyone. That's why, originally, anyone could send an email using any address as the sender, including your company's. If you have your own domain, say companyname.com, there are three tools that let mail servers around the world tell genuine emails from forged ones: SPF, DKIM and DMARC.

They don't protect your mailbox from incoming mail: they protect your name from people using it to defraud customers and suppliers. And they have a welcome side effect: your genuine emails end up in spam less often.

Where they are configured

All three are set up as DNS records for the domain, entries in the control panel of your registrar or DNS provider. Nothing is installed on computers. You do need some information from your email provider (for example Microsoft 365, Google Workspace or your hosting provider) and from every service that sends email on your behalf.

SPF: who is allowed to send

SPF (Sender Policy Framework) is a public list of the servers authorised to send email for your domain. When a server receives a message claiming to come from companyname.com, it checks whether the sending server is on the list.

An SPF record looks something like this:

v=spf1 include:mail-service.example -all

The final part says what to do with anyone not on the list: -all means "reject", ~all means "treat as suspicious". Two practical points:

  • there must be only one SPF record per domain: if you add a second, both stop working properly;
  • there's a limit on the number of DNS lookups an SPF record can trigger, so it's best not to pile up unnecessary includes.

DKIM: the message signature

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every email. The sending server signs the message with a private key; the receiving server fetches the public key from your domain's DNS and checks that the signature is valid and that the message hasn't been altered on the way.

Usually your email provider generates the key pair and tells you which record to publish. It needs to be enabled for every service that sends on your behalf: the main mailbox, the newsletter platform, the business software that sends invoices.

DMARC: the rule and the reports

SPF and DKIM on their own don't tell the recipient what to do when a check fails. That's the job of DMARC (Domain-based Message Authentication, Reporting and Conformance), which does three things:

  1. it checks that the domain visible in the "From" field matches the one verified by SPF or DKIM;
  2. it sets a policy for messages that fail the checks;
  3. it asks receiving servers to send you periodic reports on who is sending in your domain's name.

There are three possible policies:

Policy Effect
p=none No action, monitoring and reports only
p=quarantine Non-compliant messages go to spam
p=reject Non-compliant messages are refused

A typical initial record is:

v=DMARC1; p=none; rua=mailto:dmarc-reports@companyname.com

Rolling them out gradually

The most common mistake is jumping straight to a strict policy and discovering that invoices sent by your business software or your newsletters no longer arrive. A prudent path:

  1. List every service that sends email with your domain: mailboxes, website, online shop, CRM, newsletters, business software, multifunction printers that email scans.
  2. Configure SPF to include all those services.
  3. Enable DKIM on each one, where possible.
  4. Publish DMARC with p=none and an address for reports.
  5. Read the reports for a few weeks: they're technical files, but there are services and tools that make them readable. You'll discover any forgotten services and any forgery attempts.
  6. Move to p=quarantine, then, once you're sure all genuine mail is compliant, to p=reject.

What about domains that don't send email?

Many businesses own secondary domains they don't use for email: variants of the name, different extensions, old brands. These can be used to forge messages too. To protect them you can publish an SPF record that authorises nobody (v=spf1 -all) and a DMARC record with p=reject.

What they don't do

SPF, DKIM and DMARC protect your exact domain. They don't stop a fraudster from registering a similar domain, with one letter changed, and configuring it correctly in turn. For that risk you need vigilance, verification procedures and, if the problem recurs, pre-emptive registration of the most obvious variants of your name.

In short

  • SPF lists authorised servers, DKIM signs messages, DMARC decides what to do and sends reports.
  • They're configured in the domain's DNS, following your email providers' instructions.
  • First take stock of every service that sends email on your behalf.
  • Start DMARC in monitoring mode and move to reject step by step.
  • Protect the domains you don't use for email as well.
MM
Marco Marzaduri

Marco Marzaduri works in cybersecurity, digital forensics and web development. With degrees in computer science and psychology, he combines technical analysis with an understanding of the human factor.

Read also