SPF, DKIM and DMARC Explained: How to Check Your Email Security

Anyone can put your domain in the "From" line of an email — unless you stop them. Email was not built with authentication, so three standards were layered on top to fix it: SPF, DKIM and DMARC. Together they prevent attackers from spoofing your domain in phishing and scam emails, and they materially improve whether your legitimate mail reaches the inbox. This guide explains each one in plain English, how they work together, and how to check yours.

These records sit at the infrastructure layer, much like the signals in how to find out where a website is hosted — and like those, they are public and easy to read once you know how.

Why email authentication matters

Two problems make email authentication essential. The first is spoofing: without protection, a scammer can send email that appears to come from your domain, using your brand to phish your customers or staff. The damage — to victims and to your reputation — can be severe. The second is deliverability: mailbox providers increasingly use authentication as a trust signal, and major providers now effectively require it for bulk senders. Mail from a domain without proper SPF, DKIM and DMARC is more likely to land in spam or be rejected. So these records both defend your brand and protect your reach; neglecting them risks impersonation and lost legitimate mail.

SPF: who is allowed to send

Sender Policy Framework (SPF) is a DNS TXT record that lists the mail servers authorised to send email for your domain. When a receiving server gets a message claiming to be from you, it looks up your SPF record and checks whether the sending server is on the approved list. An SPF record starts with v=spf1 and contains mechanisms naming permitted IPs, hostnames and third-party senders (your email provider, marketing platform, help desk and so on), ending with a policy like ~all (soft fail) or -all (hard fail). The most common SPF mistake is forgetting to include a service you actually send from, or exceeding SPF's limit of 10 DNS lookups, which causes it to fail — both of which can quietly send your legitimate mail to spam.

DKIM: proving the message is genuine

DomainKeys Identified Mail (DKIM) adds a cryptographic signature to every message. Your sending server signs outgoing mail with a private key, and you publish the matching public key in DNS at a selector subdomain (selector._domainkey.yourdomain.com). The receiving server uses that public key to verify the signature, which proves two things: the message genuinely came from your domain, and it was not altered in transit. Unlike SPF, DKIM survives forwarding, because the signature travels with the message rather than depending on the sending server's IP. Each email platform you use has its own selector and key, so a domain sending through several services will have several DKIM records.

DMARC: tying it together and telling receivers what to do

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the policy layer that makes SPF and DKIM useful. Published as a TXT record at _dmarc.yourdomain.com starting with v=DMARC1, it does three things. First, it requires alignment — the domain the user sees in the From address must match the domain authenticated by SPF or DKIM — which closes a loophole spoofers exploited. Second, it sets a policy for mail that fails: p=none (monitor only), p=quarantine (treat as suspicious) or p=reject (refuse outright). Third, it requests reports, sent to an address you specify, telling you who is sending mail using your domain — invaluable for spotting both abuse and your own misconfigured services.

How they work together

The three are complementary, not redundant. SPF authorises servers; DKIM authenticates messages; DMARC sets the policy and demands alignment, then reports back. A message passes DMARC if it passes either SPF or DKIM with alignment — which is why having both improves robustness (SPF can break on forwarding, DKIM usually does not). Set up well, the combination means a receiving server can confidently tell genuine mail from your domain apart from a spoof, and act on the difference exactly as your DMARC policy instructs. A helpful way to remember the division of labour: SPF checks the envelope (which server is delivering this?), DKIM checks the seal (has the letter been opened or altered?), and DMARC sets the house rules (what to do when the envelope or seal does not match, and please send me a logbook of every attempt). Miss any one of the three and you leave a gap a determined spoofer can work through, which is why they are designed to be deployed together rather than picked from à la carte.

How to check yours

Everything here is public DNS, so checking is straightforward. From a terminal, dig TXT yourdomain.com shows your SPF record (the line starting v=spf1), dig TXT _dmarc.yourdomain.com shows your DMARC record, and dig TXT selector._domainkey.yourdomain.com shows a DKIM key (you need the selector your provider uses). Online checkers and broader audits do the same lookups and interpret the results for you, flagging missing records, SPF lookup-limit problems, and weak DMARC policies. StackOptic reports email-security configuration as one module of its wider site analysis, so you can see SPF/DKIM/DMARC health next to your security headers and the rest of the stack.

The journey to enforcement

The single most common email-security failure is not the absence of DMARC but leaving it at p=none forever. Monitoring mode is meant to be a starting point, not a destination. The intended path is: publish DMARC at p=none and read the reports to discover every legitimate service sending as your domain; authorise each properly in SPF and enable DKIM for it; then, once reports show your real mail consistently passing, tighten the policy to p=quarantine and finally p=reject. Only an enforced policy actually stops spoofed mail — p=none merely watches it happen. Moving to enforcement is the difference between knowing you are being impersonated and preventing it.

A worked example: securing a new domain's email

Imagine you have just set up email for a new domain through a provider, and you also send marketing through a separate platform and support tickets through a help desk. Here is the path. First, publish an SPF record that includes all three senders — your mailbox provider, the marketing platform and the help desk — while staying within the 10-lookup limit (consolidating where you can). Next, enable DKIM on each of the three platforms, publishing the selector record each one gives you, so every source signs its mail. Then publish a DMARC record at p=none with a reporting address, and watch the reports for a couple of weeks: they will show every source sending as your domain, including any you forgot. Once the reports confirm all your legitimate mail passes SPF or DKIM with alignment, move DMARC to p=quarantine, watch again, and finally to p=reject. The whole process is mostly waiting and reading reports — but it ends with a domain that is genuinely hard to spoof and mail that reliably reaches the inbox.

Email security and your brand

It is worth seeing this as brand protection, not just plumbing. Your domain is part of your identity, and an unprotected domain is an open invitation for criminals to impersonate you to your own customers — the kind of incident that erodes trust quickly and is hard to recover from. Conversely, a properly authenticated domain signals competence to the mailbox providers that decide whether your mail is trusted, and (with BIMI) can even display your logo in the inbox. For any organisation that emails customers, getting SPF, DKIM and DMARC right is as much a reputation investment as a security one, which is why it deserves attention even from teams that do not think of themselves as security-focused.

A note on BIMI

Once you reach an enforced DMARC policy, you unlock BIMI (Brand Indicators for Message Identification), which lets your verified logo appear next to your messages in supporting mailbox providers. It is a nice payoff — better brand visibility in the inbox — but it is strictly downstream of getting SPF, DKIM and an enforced DMARC right first. Treat it as the reward for finishing the job, not a starting point.

Common mistakes

• Leaving DMARC at p=none indefinitely, so spoofing is observed but never blocked.
• Incomplete SPF that omits a sending service, or too many DNS lookups causing SPF to fail.
• DKIM enabled on some platforms but not others, leaving gaps.
• Ignoring DMARC reports, which are how you find and fix the above.
• Forgetting a new sending service — every time you add a tool that emails as your domain, update SPF and enable DKIM for it, or its mail will start failing.

Go deeper

• Harden the site too: HTTP security headers explained.
• Judge a site's safety: is this website safe?
• The infrastructure layer: how to find out where a website is hosted.

Want your SPF, DKIM and DMARC checked automatically? StackOptic reports email-security configuration alongside security headers, performance and SEO — free.