Why Your Email Goes to Spam (SPF, DKIM, and DMARC Explained)

You send an email from your domain. It lands in spam. Or worse — it never arrives at all, and the recipient never knows to look.

The problem usually isn't your content. It's that your domain is missing the DNS records that tell the world's mail servers you're allowed to send from it. Here's what those records are and why they matter.

Email was never built to verify senders

When email was designed, there was no verification that a sender was who they claimed to be. Anyone could send a message claiming to be from [email protected], and receiving servers had no way to know it wasn't legitimate.

SPF, DKIM, and DMARC are the three standards that fix this — and all three are configured through DNS records on your domain.

SPF: who is allowed to send on your behalf

An SPF record is a TXT record that lists the mail servers authorized to send email for your domain. When a receiving server gets a message from [email protected], it checks the SPF record on example.com and verifies the sending server's IP is on the list.

A basic SPF record looks like this:

v=spf1 ip4:203.0.113.1 include:_spf.example.net ~all

• ip4:203.0.113.1 directly authorizes a specific IP address
• include:_spf.example.net delegates to your mail provider's own list of authorized servers
• ~all means any other source is a "soft fail" — suspicious but not automatically rejected
• -all is stricter: any other source is a hard fail and should be rejected

If you use multiple email providers (say, your main email host and a transactional email service like Postmark or SendGrid), all of them need to be included in your single SPF record. You can only have one SPF record per domain, and receiving servers will ignore extras or treat them as invalid.

DKIM: a cryptographic signature on every message

SPF tells receivers which servers can send for you. DKIM goes further: it lets your mail server cryptographically sign every outgoing message, and the receiving server verifies that signature using a public key stored in your DNS.

Your DKIM record is also a TXT record, but it lives on a special subdomain — something like:

selector._domainkey.example.com

The "selector" is a label chosen by your mail provider — common values are default, selector1, or something provider-specific. Your provider gives you the exact subdomain to add.

The key thing DKIM proves is the message wasn't modified in transit. Even if a message passes SPF (came from an authorized server), a tampered message will fail DKIM.

DMARC: the policy that ties it together

SPF and DKIM are checks. DMARC is the policy that says what to do when those checks fail — and it's what receiving servers actually act on.

A DMARC record tells receivers three things:

1. What to do with messages that fail SPF and DKIM (none, quarantine, or reject)
2. Where to send reports about messages that claim to be from your domain
3. How strictly to apply the policy (p=reject vs. p=quarantine vs. p=none)

A minimal DMARC record:

v=DMARC1; p=none; rua=mailto:[email protected]

Starting with p=none is standard — it means "report but don't block anything yet." This lets you see what traffic is claiming to come from your domain before you start rejecting it. Moving to p=quarantine or p=reject too quickly can break legitimate email flows you didn't know about.

Why "alignment" matters

DMARC introduces a concept called alignment: the domain in the From: header that users see must match the domain that passed SPF or DKIM.

This is what prevents a common attack: a bad actor uses a legitimate mail server (passing SPF) but forges the From: address to look like your domain. Without alignment checks, that message could pass SPF. With DMARC, it fails — because the authenticated domain doesn't match the displayed sender.

Common mistakes

Multiple SPF records. You can only have one. If you add a second v=spf1 record, receivers may ignore both or throw an error. If you use multiple services, combine them into one record: v=spf1 include:_spf.example.net include:spf.example.org ~all.

Missing DKIM for a sending service. Every service you use to send email has its own DKIM key that needs to be added to your DNS. If you add a new transactional email provider and forget to add their DKIM record, messages from that provider will fail.

Jumping straight to p=reject. Without reviewing DMARC reports first, you can accidentally block legitimate mail — forwarded email, mailing lists, or internal tools sending on your behalf.

Forgetting subdomains. A DMARC policy on example.com doesn't automatically cover mail.example.com unless you add sp=reject to the policy or set up a separate record for the subdomain.

How to verify your setup

You can inspect your records directly:

dig TXT example.com          # SPF
dig TXT selector1._domainkey.example.com  # DKIM (replace selector1 with yours)
dig TXT _dmarc.example.com   # DMARC

For a quicker check, MyDMARC's free tools include a DMARC, SPF, and DKIM checker to validate each record and flag common misconfigurations.

Reading your DMARC reports

Once you have a DMARC record with a rua (reporting URI), you'll start receiving aggregate reports — XML files showing which servers sent mail claiming to be from your domain and whether those messages passed or failed.

In practice, these reports are unreadable without a tool to parse them. MyDMARC processes your DMARC reports and turns them into a clear view of your email traffic: which services are sending on your behalf, what's failing, and when it's safe to tighten your policy.

How DNS monitoring fits in

SPF, DKIM, and DMARC records are just DNS records — which means they can be accidentally deleted, overwritten, or changed. A misconfigured SPF record can quietly start failing without anyone noticing until email deliverability drops. OneDollarDNS monitors your records and alerts you immediately if anything changes, so you catch a broken email authentication record before your users end up in spam folders.