Why your emails go to SPAM (and how to configure SPF, DKIM and DMARC)

You send an email from contact@yourcompany.com and it lands straight in the recipient's spam folder. The content is fine, the subject has no suspicious words — but Gmail, Outlook or the recipient's server decided that email isn't trustworthy. In most cases the reason is technical: the domain has no SPF, DKIM or DMARC configured, so any server can pretend to send on behalf of yourcompany.com, and email providers know it.

What the receiving server checks

When an email arrives, the recipient's server asks three questions before delivering it to the inbox:

1. SPF — is the server that sent this email authorized to send on behalf of this domain?
2. DKIM — was the message signed with a private key that matches the public key published in the domain's DNS?
3. DMARC — does the domain have a policy defining what to do when SPF or DKIM fail?

Without positive answers to these, the email is suspicious by definition.

SPF: who can send on behalf of your domain

SPF is a DNS TXT record listing the servers authorized to send email for your domain. DNS TXT for yourcompany.com (root domain, no subdomain)

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

• include:_spf.google.com — authorizes Google Workspace
• include:sendgrid.net — authorizes SendGrid (swap for your actual sending provider)
• ~all — emails from other servers are marked as suspicious (softfail); use -all to hard-reject them

Critical mistake: multiple SPF records. A domain must have exactly one SPF TXT record. Adding a second one makes the behavior undefined and providers ignore both. Combine everything into a single line using include:.

10 DNS lookup limit: SPF has a limit of 10 DNS lookups during validation. Every include: spends one lookup. Go over that and SPF fails automatically — permerror.

DKIM: cryptographic signature of the message

DKIM adds a signature to the message using a private key that lives on the sending server. DNS publishes the matching public key. The recipient's server checks whether the signature matches.

The DNS record lives at selector._domainkey.yourcompany.com: Example with Google Workspace (selector "google")

google._domainkey.yourcompany.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4..."

The public key (p=...) is generated by your email provider. You grab it from the admin console (Google Workspace, SendGrid, Amazon SES, etc.) and publish it in DNS.

Common mistake: modifying the body or headers of the email after it's signed. Forwarding systems break DKIM because they modify the message. That's expected — DMARC can still pass if SPF aligns.

DMARC: the policy that ties it all together

DMARC tells the recipient's server what to do when SPF and DKIM both fail, and asks for usage reports on the domain. DNS TXT for _dmarc.yourcompany.com

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourcompany.com; pct=100

• p=none — monitor only, take no action (good starting point)
• p=quarantine — send to spam on failure
• p=reject — reject entirely on failure (safest)
• rua= — address that receives daily aggregate reports

Recommended rollout: start with p=none for 2-4 weeks, review the reports to confirm legitimate email is passing, then move to quarantine and finally reject.

For a deeper explanation of each mechanism — including how they work together — see the complete SPF, DKIM and DMARC guide.

Quick verification checklist

1. Check the SPF record exists: nslookup -type=TXT yourcompany.com
2. Check DKIM: nslookup -type=TXT google._domainkey.yourcompany.com
3. Check DMARC: nslookup -type=TXT _dmarc.yourcompany.com
4. Send a test email to mail-tester.com — it scores 1 to 10 and shows exactly what's wrong

Common mistakes that kill deliverability

Two SPF records in DNS — providers ignore both. Always keep a single SPF TXT record per domain.

SPF without DMARC — without DMARC, SPF alignment isn't enforced and Gmail ignores the result. All three records work together.

DKIM with a 1024-bit key — 1024-bit keys have already been broken. Use 2048 bits when generating the key pair with your provider.

Subdomains with no DMARC policy — a p=reject on the root domain doesn't automatically cover subdomains. Add sp=reject to the DMARC policy, or publish a separate _dmarc.subdomain.yourcompany.com record.

Sending IP on a blocklist — correct SPF, DKIM and DMARC won't help if your sending server's IP is on a blocklist like Spamhaus. Check at mxtoolbox.com/blacklists.

---

Configured SPF, DKIM and DMARC but want to confirm your infrastructure has no other security gaps? VulnexusAI's scanner analyzes HTTP headers, TLS, CORS and exposed sensitive files in seconds.