SPF, DKIM and DMARC checker

Why SPF, DKIM and DMARC matter

These three DNS records tell other mail servers who may send e-mail on behalf of your domain and how to recognise a forgery. Without them anyone can pretend to be your company – and attackers use exactly that for phishing your customers and employees. Gmail, Yahoo and Microsoft also require SPF, DKIM and DMARC from bulk senders, and messages without them are more likely to land in spam or be rejected.

What the test checks

MX – where mail is delivered

MX records name the servers that accept mail for the domain. Without them nobody can send you e-mail. Domains protected by Čistý mail point their MX records to our filtering servers.

SPF – who may send for the domain

SPF lists the servers (IP addresses and services) allowed to send mail for your domain. It is a single TXT record on the domain, for example:

company.com.  TXT  "v=spf1 mx ip4:192.0.2.10 include:_spf.example.net -all"

• mx – the servers from the MX records may send,
• ip4: / ip6: – specific addresses (e.g. your mail server or the website with forms),
• include: – addresses of another service (newsletter, CRM, invoicing),
• -all – reject all other servers; ~all is softer (only mark them).

A domain may have only one SPF record, with at most 10 mechanisms that need a DNS lookup (include, a, mx, exists, redirect). Above that SPF is invalid.

DKIM – a digital signature for messages

The sending server signs each message with a private key and publishes the public key in DNS under a so-called selector, e.g. mail._domainkey.company.com. The receiver uses it to verify that the message really comes from your domain and was not altered. The key is generated by your mail server or the service you send through; the selector is in the DKIM-Signature header (the s= tag) of a sent message.

DMARC – what to do with forgeries

DMARC builds on SPF and DKIM: it tells receivers what to do with a message that fails the checks and where to send aggregate reports. The record lives at _dmarc.company.com:

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

• p=none – monitor only (good for a start),
• p=quarantine – put suspicious messages into spam,
• p=reject – reject forged messages,
• rua= – address for daily reports on who sends mail for the domain.

MTA-STS and TLS-RPT – encrypted delivery

MTA-STS makes other servers deliver mail to you only encrypted and with a valid certificate. TLS-RPT enables reports about encryption problems. Both are recommended extras once everything else works.

CAA – who may issue certificates

A CAA record restricts which certificate authorities may issue certificates for the domain (e.g. only Let's Encrypt). It is not about mail directly, but it lowers the risk of forged certificates.

Recommended steps

1. List everyone who sends for the domain – mail server, website forms, newsletter, CRM, invoicing, scan-to-e-mail printers.
2. Set up SPF with all these sources and end it with ~all.
3. Enable DKIM on the mail server and in every service that supports it.
4. Add DMARC with p=none and a report address.
5. After 2–4 weeks review the reports and add forgotten senders.
6. Tighten SPF to -all and DMARC to quarantine, later reject.

Most common mistakes

• Two SPF records – adding a new service creates a second record instead of editing the first. Both then stop working.
• Exceeding the 10-lookup limit – too many include: in a row.
• DMARC stuck at p=none – the domain is only monitored, forgeries are still delivered.
• A forgotten sender – a website form or invoicing system whose mail starts going to spam after tightening.
• DKIM on only part of the mail – the mail server signs, but the newsletter or CRM does not.

Step-by-step details: SPF record, setting up DMARC and why e-mails go to spam. We are happy to help you secure your domain – write to us.