SPF, DKIM, and DMARC Explained: Securing Your Domain's Email

Email was never designed with sender verification in mind — anyone can put any "From" address on a message. SPF, DKIM, and DMARC are three DNS-based standards that, together, close that gap: they let receiving mail servers verify that a message claiming to be from your domain actually came from a source you authorized.

SPF: Sender Policy Framework

SPF lists which mail servers are allowed to send email on behalf of your domain, published as a TXT record. When a receiving server gets a message, it checks the sending server's IP against your domain's SPF record.

example.com. TXT "v=spf1 include:_spf.google.com include:sendgrid.net -all"

Here, include: authorizes Google Workspace and SendGrid as legitimate senders, and -all ("hard fail") tells receivers to reject mail from any other source claiming to be example.com. A softer ~all ("soft fail") asks receivers to flag rather than reject — useful while testing a new SPF record before committing to strict enforcement.

SPF's biggest limitation: it only validates the envelope sender (the technical return-path address), not the "From" header a user actually sees — and it breaks when mail is forwarded, since the forwarding server's IP won't match your SPF record.

DKIM: DomainKeys Identified Mail

DKIM takes a different approach: it cryptographically signs each outgoing message with a private key, and publishes the corresponding public key in DNS. The receiving server verifies the signature against the public key, confirming the message wasn't altered in transit and genuinely originated from a system holding your private key.

selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."

Unlike SPF, DKIM survives most forwarding, because the signature travels with the message content rather than depending on the sending IP. Most email service providers (Google Workspace, Microsoft 365, SendGrid, Mailgun) generate and rotate DKIM keys for you — you just add the TXT record they give you.

DMARC: Domain-based Message Authentication, Reporting & Conformance

DMARC ties SPF and DKIM together and adds two things neither has on its own: an explicit policy for what receivers should do when a message fails authentication, and a reporting mechanism so you can see who's sending mail as your domain.

_dmarc.example.com. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; pct=100"

• p=none — monitor only, take no action (the recommended starting point)
• p=quarantine — send failing messages to spam/junk
• p=reject — refuse failing messages outright (the strongest setting)
• rua — where to send daily aggregate reports showing every source sending mail as your domain, pass or fail

Critically, DMARC alignment requires that the domain in the visible "From" header match the domain validated by SPF or DKIM (at least one of the two, depending on the alignment mode) — this is what closes the gap SPF alone leaves open, since spoofers can pass SPF for their own return-path while forging your "From" address.

A Safe Rollout Plan

1. Start at p=none and collect aggregate reports for 1–2 weeks. This shows you every legitimate sending source (including ones you may have forgotten, like a marketing tool or a helpdesk system) before you risk blocking real mail.
2. Fix SPF and DKIM for every legitimate source the reports reveal.
3. Move to p=quarantine; pct=25, gradually increasing the percentage as reports confirm no legitimate mail is affected.
4. Finish at p=reject; pct=100 once you're confident every legitimate sending source passes.

Skipping straight to p=reject without this rollout is the most common cause of "our real emails suddenly went to spam" incidents.

How SiteGraph Checks This

SiteGraph inspects a domain's DNS TXT records for SPF, DKIM selectors, and a DMARC policy as part of every scan, reporting whether each is present and, where possible, how strict the DMARC policy is set — a quick signal for whether a domain is protected against email spoofing.