Your emails are landing in spam and you're not sure why. You've checked the content, removed spammy words, and it's still happening. The problem is almost certainly your domain's email authentication — specifically SPF, DKIM, and DMARC.

These three DNS records tell receiving mail servers that your emails are legitimate. Without them, Gmail, Outlook, and other providers have no way to verify that an email claiming to be from your domain actually came from you. So they err on the side of caution and dump it in spam — or reject it entirely.

Here's the complete checklist for getting your email authentication right.

The three pillars of email authentication

SPF (Sender Policy Framework)

SPF tells receiving servers which IP addresses and mail servers are allowed to send email on behalf of your domain. It's a TXT record in your DNS.

A basic SPF record looks like this:

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

This says: "Google's mail servers can send for my domain. Soft-fail everything else."

DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to every email you send. The receiving server checks this signature against a public key published in your DNS. If the signature matches, the email hasn't been tampered with in transit.

DKIM records are published as TXT records under a selector subdomain:

selector1._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCS..."

DMARC (Domain-based Message Authentication, Reporting & Conformance)

DMARC ties SPF and DKIM together and tells receiving servers what to do when authentication fails. It also lets you receive reports about who's sending email using your domain.

_dmarc.yourdomain.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com"

The checklist

1. Audit your current setup

Before changing anything, check what you have. Scan your domain with ScanMyDomain to get a complete picture of your SPF, DKIM, DMARC, and MX configuration in one report.

Common findings at this stage:

No SPF record at all
SPF record exists but doesn't include all your sending services
No DKIM records found
No DMARC record, or DMARC set to p=none (monitoring only, no enforcement)

2. List all your email sending services

Before configuring SPF, you need to know every service that sends email using your domain. This is usually more than you think:

Primary email — Google Workspace, Microsoft 365, etc.
Transactional email — SendGrid, Postmark, Resend, Amazon SES
Marketing email — Mailchimp, HubSpot, ConvertKit
Help desk — Zendesk, Intercom, Freshdesk
CRM — Salesforce, HubSpot (sends emails on your behalf)
Invoicing — Xero, QuickBooks, Stripe
Your own app — if your application sends emails directly

Missing even one service from your SPF record means those emails may fail authentication.

3. Configure SPF correctly

Create or update your SPF TXT record to include all sending services:

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

Critical rules for SPF:

One record only — you can only have one SPF TXT record per domain. Multiple records cause both to fail.
Stay under 10 lookups — SPF has a hard limit of 10 DNS lookups. Each include: counts as at least one lookup, and nested includes count too. Exceeding this limit causes SPF to fail entirely. Read more about the SPF 10-lookup limit.
Use ~all or -all — ~all (soft fail) is recommended during setup. Move to -all (hard fail) once you've confirmed everything works.
Don't use +all — this allows anyone to send as your domain. Never use it.

4. Set up DKIM for each sending service

Each email service provides its own DKIM setup instructions. The process is usually:

Go to the service's email authentication settings
They give you a CNAME or TXT record to add to your DNS
Add the record
Verify in the service's dashboard

Do this for every service that sends email as your domain. DKIM is per-service — you need separate DKIM records for Google Workspace, SendGrid, Mailchimp, etc.

Common DKIM selectors by provider:

Google Workspace — google._domainkey
Microsoft 365 — selector1._domainkey, selector2._domainkey
SendGrid — s1._domainkey, s2._domainkey
Mailchimp — k1._domainkey
Postmark — varies by account

5. Implement DMARC

Start with a monitoring-only policy to see what's happening:

_dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com"

This tells receiving servers to send you reports about emails using your domain, without blocking anything. Review the reports for 2-4 weeks to identify:

Legitimate services you forgot to add to SPF/DKIM
Unauthorised senders using your domain
Configuration issues causing false failures

6. Tighten DMARC policy

Once you've confirmed all legitimate email is passing SPF and DKIM, escalate your DMARC policy:

Step 1: Quarantine a percentage

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

This quarantines (sends to spam) 10% of emails that fail DMARC. Monitor for issues.

Step 2: Increase percentage

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

Step 3: Move to reject

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

This is the strongest policy — emails that fail DMARC are rejected outright. This is the goal, but don't jump straight here or you risk blocking legitimate email.

Read the full DMARC policy guide for a detailed walkthrough of each enforcement level.

7. Verify MX records

Your MX records tell the world where to deliver email for your domain. Check that they're correct and point to your actual mail provider:

yourdomain.com MX 1 aspmx.l.google.com
yourdomain.com MX 5 alt1.aspmx.l.google.com

Common issues:

MX records pointing to old mail servers after a migration
Missing backup MX records
Priority values misconfigured (lower number = higher priority)

8. Check your sending reputation

Even with perfect authentication, your emails can land in spam if your sending IP has a bad reputation. Check:

Google Postmaster Tools — shows your domain's reputation with Gmail
Microsoft SNDS — shows reputation with Outlook/Hotmail
MXToolbox Blacklist Check — checks if your IP is on any blacklists

If your IP is blacklisted, you'll need to identify the cause (compromised account, purchased email list, etc.) and request delisting.

9. Set up ongoing monitoring

Email authentication isn't a one-time setup. Things change:

You add a new SaaS tool that sends email
A team member sets up a marketing campaign through a new service
Your email provider rotates DKIM keys
SPF lookup count creeps above 10 as you add more includes

Set up weekly monitoring with ScanMyDomain to catch these issues automatically. You'll get alerts when your SPF, DKIM, or DMARC configuration changes or breaks.

Common mistakes to avoid

Using multiple SPF records

You can only have one SPF TXT record per domain. If you have two, both fail. This is the single most common SPF misconfiguration.

Wrong:

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

Right:

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

Exceeding the SPF lookup limit

Every include:, a:, mx:, and redirect: in your SPF record counts toward the 10-lookup limit. Nested includes count too. Once you hit the limit, SPF fails for all emails.

Solutions: use IP addresses (ip4:) instead of includes where possible, or use an SPF flattening service.

Setting DMARC to reject immediately

Jumping to p=reject without monitoring first will block legitimate email from services you forgot to configure. Always start with p=none, review reports, then escalate gradually.

Forgetting about subdomains

If you send email from mail.yourdomain.com or news.yourdomain.com, those subdomains need their own SPF and DKIM records. Your root domain's records don't automatically apply to subdomains.

DMARC does cascade to subdomains by default, but you can override this with the sp= tag.

Not testing after changes

After any DNS change, verify it's working. DNS changes can take up to 48 hours to propagate, though most complete within minutes with modern providers. Use ScanMyDomain to verify your changes are live and passing.

Quick reference

| Record | Purpose | Where to add | Format | |--------|---------|-------------|--------| | SPF | Authorise sending servers | Root domain TXT | v=spf1 include:... ~all | | DKIM | Sign emails cryptographically | selector._domainkey TXT/CNAME | Provider-specific | | DMARC | Policy for failed auth | _dmarc TXT | v=DMARC1; p=...; rua=... | | MX | Where to receive email | Root domain MX | priority mailserver |

Summary

Getting email deliverability right comes down to three records: SPF, DKIM, and DMARC. Configure all three, verify they're working, and monitor for drift. Scan your domain now to see exactly where your email authentication stands and what needs fixing.

Email Deliverability Checklist: SPF, DKIM, and DMARC Setup Guide