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

Think of it like a passport, a seal, and a customs officer

These three records work together to answer one question for every receiving mail server on earth: is this email actually from who it claims to be from? SPF is like showing a passport at the border, proving you're allowed to travel from where you say you're coming from. DKIM is like a wax seal on the envelope, proving nobody tampered with the contents along the way. DMARC is the customs officer's standing instructions on exactly what to do with anyone who shows up without valid documents.

Without any of these, a receiving mail server has almost nothing to go on except reputation and pattern matching, both of which increasingly flag legitimate business mail as suspicious by default, purely because so much spam and phishing goes unauthenticated too.

SPF: the passport

SPF, Sender Policy Framework, is a DNS TXT record published under your domain that lists exactly which mail servers are allowed to send email claiming to be from you. When another mail server receives a message from your domain, it checks whether the sending server appears on that list. If your website is hosted with one provider and your email is handled by a different one, like Google Workspace or Microsoft 365, your SPF record needs to include both, or mail from the one not listed gets treated with suspicion.

DKIM: the wax seal

DKIM, DomainKeys Identified Mail, attaches a cryptographic signature to every outgoing message, generated using a private key your mail provider holds. The receiving server checks that signature against a public key published in your DNS as a TXT record. If the signature matches, the message is confirmed as genuinely from your domain and unaltered in transit. If someone tampered with the message along the way, or forged the sender address without the matching private key, the signature simply won't validate.

DMARC: the customs officer

DMARC, Domain-based Message Authentication, Reporting and Conformance, ties SPF and DKIM together into an actual policy. It's also a DNS TXT record, and it tells receiving mail servers what to do specifically when a message fails SPF or DKIM: deliver it anyway, mark it as spam, or reject it outright. It can also send you regular reports showing who's sending mail claiming to be from your domain, which is often the first sign of someone spoofing your address for phishing.

Most domains should start a DMARC policy in monitoring mode, watching what fails without rejecting anything, before moving to a stricter enforcement policy once you're confident every legitimate sending source is properly covered by SPF and DKIM.

How to check your current setup

Several free online DNS lookup tools will show you, in seconds, whether your domain currently has valid SPF, DKIM, and DMARC records, and flag common errors in each. It's worth checking even if you've never had an obvious deliverability problem, since a broken or missing record often just means slightly lower inbox placement rather than an obvious total failure, which is easy to miss without deliberately checking.

Common mistakes

• Multiple SPF records. Only one SPF record is valid per domain. If your website builder, email provider, and a marketing tool each ask you to add a separate SPF record, they need to be merged into a single record, not stacked as several.
• DKIM never actually enabled. Many mail providers support DKIM but don't turn it on automatically, leaving it as a setting you need to explicitly enable and then publish the matching DNS record for.
• Jumping straight to a strict DMARC policy. Setting DMARC to reject before confirming every legitimate sending source passes SPF and DKIM can cause real business email to bounce entirely, not just land in spam.

Frequently asked questions