Server Defenders logo
Emergency Support
Sign In
My Account
Get Support

SPF, DKIM And DMARC Explained Simply

Three DNS records decide whether other mail servers trust email from your domain. Here is what SPF, DKIM and DMARC each do, in plain language, with examples.

By The Server Defenders Team6 November 20264 min read
SPF, DKIM And DMARC Explained Simply

When your server sends an email, the receiving mail provider has a problem. Anyone can write any address in the “From” line, so how does it know the message really came from you? For years the answer was “it doesn’t”, which is why spoofed and phishing emails were so easy to send.

SPF, DKIM and DMARC are three DNS records that handle email authentication and fix that. Each answers a different question, and together they let providers like Gmail and Outlook decide whether to trust your mail. Large mailbox providers now expect them to be in place, especially for anyone sending in volume, so they are no longer optional extras.

SPF: Who Is Allowed To Send

SPF (Sender Policy Framework) is a list of servers allowed to send mail for your domain. It lives in a TXT record on the domain itself. A simple example:

example.com.  TXT  "v=spf1 ip4:203.0.113.10 include:_spf.google.com ~all"

This says: mail from example.com may come from the server at 203.0.113.10, or from Google’s mail servers. The ending tells receivers what to do with anything else:

  • ~all is a soft fail: treat other senders as suspicious.
  • -all is a hard fail: other senders are not authorised.
  • ?all is neutral and offers little protection.

Common SPF Mistakes

  • Two SPF records. A domain must have only one. If you add a new sender, edit the existing record rather than adding a second one.
  • Too many lookups. SPF allows a maximum of ten DNS lookups when it is checked. Each include counts, and so do includes nested inside them. Too many and the record fails entirely.
  • Forgotten senders. Newsletter tools, CRM systems, invoicing software and website contact forms that send through outside services all need to be included.

SPF has one important limitation. It checks the hidden “envelope” sender used by mail servers, not the From address people see. That is one reason DMARC exists.

DKIM: Proof The Message Was Not Changed

DKIM (DomainKeys Identified Mail) adds a digital signature to each outgoing email. Your mail server signs the message with a private key, and publishes the matching public key in DNS. Receivers look up the key and check the signature. If it matches, they know the message was sent by a server holding your key, and that it was not altered on the way.

The public key is published under a selector name, which lets you have several keys at once:

default._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

Control panels such as cPanel, Plesk and DirectAdmin can generate DKIM keys for you and, if they host your DNS, publish the record too. If your DNS is hosted elsewhere, such as at your registrar or a CDN, you need to copy the record across by hand. Use 2048-bit keys where your DNS provider supports the longer record.

Each service that sends mail for you, such as a newsletter platform, usually has its own DKIM key with its own selector. Add each one.

DMARC: The Policy That Ties It Together

DMARC (Domain-based Message Authentication, Reporting and Conformance) does two jobs. First, it checks that SPF or DKIM passed for a domain that matches the From address people actually see. This matching is called alignment, and it is what stops someone passing SPF with their own domain while showing yours in the From line.

Second, it tells receivers what to do with mail that fails, and where to send reports. The record lives at _dmarc on your domain:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

The policy, p=, has three settings:

  • p=none asks receivers to report failures but take no action. This is the starting point.
  • p=quarantine asks them to treat failing mail as spam.
  • p=reject asks them to refuse failing mail outright.

The rua address receives aggregate reports, XML files listing which servers sent mail claiming to be from your domain and whether they passed. These are hard to read by eye, so many people use a DMARC report service to turn them into something readable.

How The Three Work Together

Think of it like this:

  • SPF says which servers may send for you.
  • DKIM proves a message came from someone with your key and was not changed.
  • DMARC checks that at least one of those passed for the domain in the From address, and tells receivers what to do if not.

DKIM is the more robust of the two checks, because it survives forwarding, which often breaks SPF. Aim for every legitimate sender to pass DKIM with your domain.

Rolling Them Out Safely

  1. List every service that sends email as your domain: your server, your office mail provider, newsletters, CRM, helpdesk, invoicing and any website forms.
  2. Publish a single SPF record covering them all.
  3. Set up DKIM for each sender.
  4. Publish DMARC with p=none and a reporting address.
  5. Read the reports for a few weeks and fix any legitimate senders that fail.
  6. Move to p=quarantine, then later to p=reject once you are confident nothing legitimate is failing.

Jumping straight to p=reject is the classic mistake. It can quietly block your own invoices or newsletters if a sender was missed.

To check what is published, use dig:

dig +short TXT example.com
dig +short TXT default._domainkey.example.com
dig +short TXT _dmarc.example.com

You can also send a message to a Gmail account and use “Show original” to see whether SPF, DKIM and DMARC passed. If the results do not make sense, ask us and we can take a look at your records.

How Server Defenders Can Help

We set up and fix SPF, DKIM and DMARC for domains sending from cPanel, Plesk, DirectAdmin and Linux mail servers, alongside the rest of your server management. If your mail is failing checks or you are not sure where to start, contact us.

Keep Reading

See All Guides