Email authentication explained: how SPF, DKIM, DMARC and DNSSEC fit together

SPF, DKIM, DMARC and DNSSEC get mentioned together often enough that it is easy to assume they all do roughly the same job. They do not. Each one protects a different part of the journey a domain name or an email message takes, and understanding how they fit together makes it much easier to know what you actually need to configure, and why. This post is a short orientation to how the pieces relate; each one has its own dedicated guide linked below for the full detail. If you’re using a service like Premium Email, these are exactly the DNS records worth getting right when you set it up.

SPF: which servers are allowed to send

SPF (Sender Policy Framework) is a DNS record that lists which mail servers are authorised to send email on behalf of your domain. When a receiving server gets a message claiming to be from your domain, it checks the sending server’s IP address against your SPF record; if the IP is not listed, the message fails the check. It answers a single question: is this server allowed to send as us?

Full detail: SPF records explained.

DKIM: proof the message was not altered

DKIM (DomainKeys Identified Mail) adds a digital signature to outgoing messages, generated using a private key held by the sending server, which the receiving server can verify against a public key published in your DNS. If the signature checks out, the receiving server knows the message genuinely came from a server holding your private key and that its content was not modified in transit. It answers a different question from SPF: has this specific message been tampered with since it was sent?

Full detail: DKIM records explained and how to use DKIM to prevent domain spoofing.

DMARC: what to do when SPF or DKIM fail, and reporting back

DMARC (Domain-based Message Authentication, Reporting and Conformance) sits on top of SPF and DKIM rather than replacing either of them. It does two things: it tells receiving servers what to do with a message that fails SPF and/or DKIM checks (quarantine it, reject it outright, or take no special action), and it asks receiving servers to send you regular reports on mail claiming to be from your domain, which is invaluable for spotting spoofing attempts and misconfigured legitimate senders alike.

Full detail: what is DMARC: understanding DMARC records.

DNSSEC: proving the DNS answers themselves are genuine

DNSSEC (Domain Name System Security Extensions) is a different layer entirely, and it is not specific to email at all. It cryptographically signs your DNS records so that resolvers can verify the answers they receive (for any DNS record, including but not limited to your SPF, DKIM and DMARC records themselves) have not been tampered with or forged somewhere along the way, a technique known as DNS spoofing or cache poisoning, one of several attack types covered in our wider website security guides. Without DNSSEC, all of SPF, DKIM and DMARC are still relying on the assumption that the DNS answers used to check them are trustworthy in the first place; DNSSEC is what protects that underlying assumption.

Full detail: what is DNSSEC and why it matters for your online security. For DNS fundamentals more broadly, see what is a DNS and how does it work.

How they work together

Think of it as layered protection rather than four versions of the same thing:

• DNSSEC protects the integrity of your DNS zone as a whole, including every record type, so that lookups against it cannot be forged.
• SPF authorises which servers can send mail as your domain.
• DKIM proves a specific message genuinely came from an authorised server and was not altered.
• DMARC ties SPF and DKIM together, tells receiving servers what to do when either check fails, and gives you visibility through reporting.

A domain with all four properly configured is in a strong position: its DNS answers cannot be forged, only authorised servers can send mail as it, every message can be verified as unaltered, and there is a clear policy plus reporting for anything that slips through. It also keeps outgoing mail on the right side of most providers’ anti-spam requirements, including our own Acceptable Use Policy. If you are starting from nothing, a sensible order is SPF first, then DKIM, then DMARC once both are stable and you have reviewed some reports, with DNSSEC handled separately at the DNS zone level whenever your registrar and DNS provider support it.

If everything here is configured correctly and you are still seeing mail land in spam, the next place to look is deliverability factors outside authentication entirely, covered in diagnosing email deliverability problems beyond SPF, DKIM and DMARC.