SPF, DKIM and DMARC Explained

If your website sends email — order confirmations, contact form notifications, password resets — three DNS records determine whether that email is trusted by the mail servers receiving it: SPF, DKIM, and DMARC. Get them wrong, and legitimate email from your domain can land in spam. Leave them unconfigured, and it becomes easier for someone else to send email that appears to come from your domain.

SPF: who is allowed to send

SPF (Sender Policy Framework) is a DNS record that lists which mail servers are authorized to send email on behalf of your domain. When a receiving server gets a message claiming to be from your domain, it checks whether the sending server appears on your SPF list.

v=spf1 include:_spf.example-mail-provider.com ~all

If a message arrives from a server not on that list, the receiving server treats it with more suspicion — or rejects it outright, depending on how strict your policy is.

DKIM: proof the message wasn’t altered

DKIM (DomainKeys Identified Mail) works differently: it attaches a cryptographic signature to outgoing email, generated using a private key that only your mail provider holds. The receiving server checks that signature against a public key published in your DNS. If the message was altered in transit, or wasn’t actually signed by your legitimate sender, the signature won’t validate.

Where SPF answers “did this come from an authorized server,” DKIM answers “was this message tampered with after it was sent.”

DMARC: what to do when checks fail

DMARC (Domain-based Message Authentication, Reporting and Conformance) ties SPF and DKIM together and tells receiving servers what to do when a message fails those checks — quarantine it, reject it outright, or simply monitor and report on failures without taking action yet.

v=DMARC1; p=quarantine; rua=mailto:reports@example.com

DMARC also enables reporting, so you can see when messages claiming to be from your domain fail authentication — which is often the first sign that someone is attempting to spoof your domain.

Why all three matter together

Each record covers a different gap:

Record	Question it answers
SPF	Is this server allowed to send for my domain?
DKIM	Was this message altered after sending?
DMARC	What should happen when SPF or DKIM checks fail?

Configuring only one leaves gaps. SPF alone doesn’t protect against message tampering. DKIM alone doesn’t restrict which servers can claim to send from your domain. DMARC without SPF or DKIM configured underneath it has nothing to enforce.

A sensible rollout

If none of these are configured yet, a cautious approach works well:

1. Add SPF and DKIM first, matching them to whatever service actually sends your email.
2. Add a DMARC record in monitoring mode (p=none) so you can see how your legitimate mail is being evaluated without risking anything being blocked.
3. Review the reports, confirm your legitimate mail is passing, then move DMARC to a stricter policy over time.

The takeaway

SPF, DKIM, and DMARC together form the backbone of email trust for your domain. They’re DNS configuration, not application code, which means they’re straightforward to set up once — and worth checking periodically as part of the broader DNS review described in DNS Security Explained.