SPF, DKIM, DMARC, and DNSSEC: A Practical Checklist
Four acronyms, four DNS records, and most companies still get at least one wrong. SPF, DKIM, DMARC, and DNSSEC each protect a different piece of the trust chain between your domain and the inbox or resolver on the other end. Here is what each one actually does, and a checklist to confirm they are configured correctly, including on subdomains people forget about.
SPF: who is allowed to send mail
Sender Policy Framework is a DNS TXT record that lists the mail servers and services authorized to send email on behalf of a domain. When a receiving mail server gets a message, it checks the sending server's IP against the domain's SPF record. If the IP is not listed, the message fails the check, which helps stop attackers from sending spoofed mail that appears to come from your domain.
The most common SPF mistake is an incomplete record: a company adds a new email marketing tool or CRM but forgets to add its sending servers to the SPF record, so legitimate mail starts failing checks and landing in spam.
DKIM: proving a message was not altered
DomainKeys Identified Mail adds a cryptographic signature to outgoing email headers, generated with a private key held by the sending service and verified using a public key published in DNS. If any part of the signed content is modified in transit, the signature no longer validates, which tells the receiving server the message may have been tampered with.
Unlike SPF, which only checks the sending IP, DKIM survives forwarding, since the signature travels with the message itself rather than depending on which server relayed it last.
DMARC: telling receivers what to do
Domain-based Message Authentication, Reporting, and Conformance sits on top of SPF and DKIM. It does two things: it requires that at least one of SPF or DKIM pass and align with the visible "From" domain, and it tells receiving servers what to do when a message fails, whether to deliver it anyway, quarantine it, or reject it outright. DMARC also enables aggregate reports, giving domain owners visibility into who is sending mail using their domain, including unauthorized senders.
A DMARC policy of "none" does not protect you
Many domains publish a DMARC record with p=none, which only requests reports and takes no enforcement action. Spoofed mail using that domain still gets delivered. Moving to p=quarantine or p=reject is what actually stops impersonation, but it should only happen after confirming every legitimate sender is properly authenticated.
DNSSEC: protecting DNS answers themselves
DNSSEC is a different layer entirely. It cryptographically signs DNS records so that resolvers can verify a DNS answer actually came from the authoritative source and was not altered in transit. Without it, an attacker positioned between a user and a DNS resolver, or one who successfully poisons a resolver's cache, can return forged answers, redirecting traffic for a domain, including its mail servers, to infrastructure they control.
DNSSEC does not stop email spoofing directly, but it protects the DNS lookups that SPF, DKIM, and DMARC all depend on. If the DNS answers themselves cannot be trusted, none of the mail authentication protocols built on top of them mean much either.
The practical checklist
| Protocol | Verify | Common gap |
|---|---|---|
| SPF | TXT record lists every service that sends mail, one record only | Multiple SPF records, or a forgotten sending service |
| DKIM | Selector and public key published, signing enabled at the sending service | Signing enabled but DNS record never published |
| DMARC | Policy set to quarantine or reject, rua reporting address configured | Stuck at p=none indefinitely |
| DNSSEC | Zone signed, DS record published at the registrar | Signed at the DNS host but DS record never added at the registrar |
Why forgotten subdomains break all of this
These protocols are usually configured carefully for the main domain and then forgotten for subdomains. Marketing platforms, old product launches, and internal tools often send mail from subdomains like mail.example.com or news.example.com, each of which needs its own SPF alignment and, ideally, DMARC coverage. A subdomain nobody remembers exists is also a subdomain nobody remembered to protect, and it can become an easy spoofing vector even when the root domain looks fully locked down.
Finding every subdomain that could plausibly send or receive mail is the first step before auditing any of these records, since you cannot secure what you do not know exists.
Find every mail-capable subdomain first
Subdomain Finder surfaces forgotten and historical subdomains, including old marketing and mail infrastructure, so you can check each one for SPF coverage before an attacker finds the gap first.
Try a scan free →Frequently asked questions
What is the difference between SPF, DKIM, and DMARC?
SPF lists which servers are allowed to send mail for a domain, DKIM cryptographically signs outgoing messages so tampering can be detected, and DMARC tells receiving servers what to do when SPF or DKIM checks fail, plus where to send reports.
Do I need DNSSEC if I already have SPF and DMARC set up?
Yes, they protect different layers. SPF, DKIM, and DMARC secure email specifically, while DNSSEC protects the integrity of DNS answers themselves, preventing cache poisoning and spoofed DNS responses that could undermine every other protocol relying on DNS.
Why do forgotten subdomains matter for email security?
Any subdomain that can send mail, including old marketing or transactional platforms, needs its own SPF coverage and DMARC alignment. A forgotten subdomain without these controls can be spoofed by attackers even if your main domain is fully protected.