Why Your Emails Go to Spam: SPF, DKIM, and DMARC Explained

If mail from your domain keeps landing in spam, or a client tells you their filter "flagged" your message, the cause is almost always one of three DNS records — SPF, DKIM, or DMARC — being missing, misconfigured, or simply never set up. None of them are visible in your inbox or your email client; they live entirely in DNS, which is exactly why they're so easy to get wrong without noticing until deliverability quietly degrades.

SPF: who's allowed to send as you

SPF (Sender Policy Framework) is a DNS TXT record that lists which mail servers are authorized to send email claiming to be from your domain. A receiving server checks the sending server's IP against your domain's SPF record; if it's not on the list, that's a strong spam signal.

A typical SPF record looks like:

v=spf1 include:_spf.google.com ~all

The include: mechanism delegates authorization to another provider's list (here, Google Workspace's own SPF record), and the trailing ~all means "anything not explicitly authorized should be treated with suspicion, but not hard-rejected" (a softfail). The alternative, -all (fail), is stricter and generally the better choice once you're confident your SPF record is complete — a common rollout pattern is to start with ~all, confirm nothing legitimate is getting flagged, then tighten to -all.

One easy-to-miss failure mode: SPF has a hard limit of 10 DNS lookups per check (RFC 7208). Each include:, a, mx, ptr, and exists: mechanism counts toward that limit — stack enough third-party services (a CRM, a marketing tool, a helpdesk, a transactional-email provider) and it's easy to blow past 10 without realizing, at which point SPF evaluation fails entirely, for everyone, including your legitimate mail.

Try it: SPF Lookup

Look up and analyze a domain's SPF record for common misconfigurations.

DKIM: proving the message wasn't tampered with

Where SPF authorizes by IP address, DKIM (DomainKeys Identified Mail) works differently: outgoing mail is cryptographically signed with a private key, and the receiving server verifies that signature against a public key published in your DNS. If even a single byte of the signed content changes in transit, the signature fails to verify.

The public key lives at a DNS name shaped like <selector>._domainkey.<yourdomain>, where the selector is a short identifier your email provider chooses — commonly something like google, selector1, or s1, though it varies. Because there's no DNS record type that lists all active selectors for a domain, you generally need to already know it (check an email's raw headers for a DKIM-Signature field's s= value, or your provider's setup documentation) — or try a handful of common names, which is exactly what the "Try common selectors" option in the tool below does.

An empty p= tag in a DKIM record (v=DKIM1; k=rsa; p=) isn't a mistake — it's how a key is deliberately revoked, per RFC 6376. If you rotate DKIM keys, the old selector's record often gets zeroed out this way rather than deleted outright.

Try it: DKIM Lookup

Look up and analyze a domain's DKIM key record by selector.

DMARC: the policy that ties them together

SPF and DKIM each answer a narrow question — "was this server authorized?" and "was this message tampered with?" — but neither says what a receiving server should do when a check fails, and neither one alone stops someone from spoofing your domain in the visible "From" address while still passing the other check. DMARC (Domain-based Message Authentication, Reporting & Conformance) closes that gap: it's a policy record, published at _dmarc.<yourdomain>, that tells receiving servers what to do with mail that fails SPF or DKIM alignment.

v=DMARC1; p=reject; rua=mailto:reports@yourdomain.com

The p= tag is the policy: none (monitor only — mail is delivered either way, but you receive reports), quarantine (send failing mail to spam), or reject (block it outright). Most domains should start at p=none to see what the aggregate reports (rua=) show before tightening — jumping straight to p=reject on a domain with an incomplete SPF/DKIM setup risks blocking your own legitimate mail.

Try it: DMARC Lookup

Look up and analyze a domain's DMARC policy and reporting configuration.

Putting it together

The three work as a layered system, not three independent checks: SPF authorizes servers, DKIM verifies message integrity, and DMARC decides what happens when either one fails — while also requiring that the domain in the visible "From" header actually aligns with the domain SPF or DKIM authenticated, closing the spoofing gap neither one closes alone. If you're only setting up one thing today, SPF is the fastest win; if you want to stop spoofing outright, DMARC at p=quarantine or p=reject is where the real protection is, but only after SPF and DKIM are both confirmed working — check all three with the tools above before changing anything in production DNS.