Skip to main content

Domain Deliverability Diagnostic

What it does

The Domain Deliverability Diagnostic checks the three things that decide whether inbox providers trust your domain to send email: SPF (which servers can send for you), DKIM (the cryptographic signature on your emails), and DMARC (the policy that says what to do when SPF or DKIM fails). The output translates each technical finding into plain language — “your domain is set up to prevent spoofing” or “ask your email service to add this DNS record” — instead of protocol verification jargon.

Common situations

Your emails are going to spam and you suspect the cause is domain authentication. The diagnostic shows whether SPF, DKIM, and DMARC are in place and whether they’re configured correctly. Usually one of the three is missing or weak; the report tells you which to fix and how.

A new email service is asking you to add DNS records to verify your domain, and you want to confirm they’re set up correctly afterwards. Run the diagnostic on your domain; the tool reports whether SPF, DKIM, and DMARC records are present and properly formatted.

You’ve moved to a new email provider and want to verify the migration didn’t break authentication. The diagnostic checks both old and new records; if your new provider’s records are missing while the old ones still exist, that’s the gap.

You’re auditing a client’s deliverability before taking over their email program. The diagnostic surfaces whether their domain is properly authenticated as a baseline — common to find clients with weak DMARC policies or missing DKIM that the previous agency never set up.

You suspect your domain is being spoofed (spoofed emails appearing to come from your domain reach customers). The diagnostic shows your DMARC policy — p=reject blocks spoofed mail; p=quarantine sends spoofed mail to spam; p=none only monitors. Most domains start with none for safety and never tighten further.

What you need to know

Three protocols together prove your email is legitimate. Missing any of them progressively damages deliverability:

SPF (Sender Policy Framework) — a DNS TXT record listing which mail servers are authorised to send email for your domain. When mail arrives, the receiving server checks whether the sending IP is on your SPF list. If not, the email fails SPF check. Without SPF, anyone can claim to send from your domain.

Common SPF issues:

  • Multiple SPF records — you can only have one. Multiple records is a configuration error.
  • Too many DNS lookups — SPF allows max 10 lookups via include: mechanisms. Adding too many email services pushes past the limit, breaking SPF entirely.
  • No -all or ~all — without an explicit fail mechanism, SPF is permissive (anyone can send). ~all is soft-fail (mark suspicious), -all is hard-fail (reject).

DKIM (DomainKeys Identified Mail) — a cryptographic signature added to every email by your sending server using a private key. The receiver verifies the signature against a public key published in your DNS. If signatures don’t match, the email has been tampered with or isn’t from you.

Common DKIM issues:

  • No DKIM record published — your email service generated keys but you never added the DNS record.
  • Selector mismatch — DKIM uses selectors (default._domainkey.example.com, selector1._domainkey.example.com) to identify which key signed which email. The selector your email service uses must match the DNS record name.

DMARC (Domain-based Message Authentication, Reporting & Conformance) — a policy declaring what to do when SPF or DKIM fail. Three policy levels:

  • p=none — monitor only, no enforcement. Useful as a starting point for collecting reports.
  • p=quarantine — failed mail goes to spam. Strong protection.
  • p=reject — failed mail is bounced. Strongest protection.

DMARC also requires alignment: the From-domain header must match the SPF/DKIM-authenticated domain. Mail that authenticates correctly but with a different From domain (common in misconfigurations) still fails DMARC.

Gmail and Yahoo’s February 2024 sender requirements made DMARC effectively required for senders of more than 5,000 emails per day. Domains without DMARC face progressive filtering at major providers.

Frequently asked questions

What does it mean if SPF / DKIM / DMARC is missing?

Without SPF, your domain is more easily spoofed. Without DKIM, your emails can be tampered with in transit. Without DMARC, there’s no policy telling receivers what to do with mail that fails. Major inbox providers (Gmail, Yahoo, Microsoft) progressively filter or reject mail without these.

How long do DNS changes take to propagate?

Usually under an hour for new records, up to 24-48 hours in worst cases. Changes are propagated through DNS resolvers worldwide; the speed depends on TTL settings and the resolvers your test traffic hits. The diagnostic checks current records; if you’ve just added them and they don’t appear, retry in 30 minutes.

Can I have multiple SPF records?

No. SPF requires exactly one record per domain. Multiple records is a configuration error and most receivers will fail SPF entirely (returning permerror). If you have multiple email services, combine them into one SPF record using include: mechanisms.

What’s the 10-lookup limit for SPF?

SPF allows up to 10 DNS lookups when evaluating the record. Each include:, a, mx, ptr, exists, and redirect mechanism counts as one lookup. Adding many email services (Mailchimp, HubSpot, Google Workspace, etc.) can push past the limit, breaking SPF for everyone. Use SPF flattening services (Mailhardener, MX Toolbox) if needed.

What DMARC policy should I use?

Start with p=none and reporting (rua=mailto:dmarc-reports@yourdomain.com) to collect data on who’s sending mail claiming to be you. After a few weeks, you can see in the reports whether legitimate senders are properly authenticated. Once everything legitimate is authenticated, tighten to p=quarantine and eventually p=reject.

Why are common DKIM selectors checked?

Different email services use different DKIM selector names. Most use one of: default, selector1, selector2, google (Google Workspace), mail, s1, k1 (Mailchimp), dkim. The diagnostic checks all common selectors to find your active DKIM record(s). Custom selectors won’t be detected automatically; check your email service’s documentation for what selector they use.

Do I need separate DKIM for every email service?

Yes — each email service that signs your mail needs its own DKIM record. Mailchimp uses one selector, HubSpot another, Google Workspace another. They can coexist; multiple DKIM records at different selector names work fine.

What does it mean if DMARC policy is “none”?

Monitoring only. DMARC is collecting authentication data but not enforcing any action on failures. Mail that fails authentication still gets through to recipients. p=none is useful as a starting point to gather data; it should be tightened to quarantine or reject once you’re confident legitimate senders are properly authenticated.

Common problems

Problem: SPF record looks correct but Gmail still flags my mail as suspicious.

Most common cause: SPF passes but DMARC alignment fails. Gmail in particular checks DMARC alignment — the From-domain header must match the SPF-authenticated domain. If you’re sending from mail.yourdomain.com but the From header shows yourdomain.com, alignment fails. Configure your email service to align the From-domain.

Problem: DKIM was set up months ago but is still showing as missing.

Either the DNS record wasn’t added correctly, the DNS hasn’t propagated (unlikely after months), or your email service is using a different selector than the one being checked. Look in your email service’s settings for the active DKIM selector and DNS record value, then verify the DNS record at your domain registrar matches exactly.

Problem: DMARC reports show authentication failures from servers I don’t recognise.

Spoofers using your domain. The reports (rua= reporting address) show every IP claiming to send as your domain. IPs you don’t recognise are spoofing attempts. With p=reject, this mail is blocked at the receiver — the spoofers can claim to be you, but receivers won’t accept their mail.

Problem: Adding a new email service broke SPF — it now exceeds 10 lookups.

You’ve hit the SPF lookup limit. Three options: use SPF flattening (services like Mailhardener resolve all your includes once and produce a flat record); consolidate email services to fewer providers; or accept the limit and prioritise critical senders. Flattening is the cleanest fix for active multi-service senders.

Problem: Diagnostic reports SPF and DKIM working but DMARC missing.

Common situation. SPF and DKIM are usually set up by the email service when you onboard; DMARC is a separate domain-owner responsibility. Add a basic DMARC record at _dmarc.yourdomain.com with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com to start monitoring. Tighten policy after data accumulates.

Tips

  • All three protocols (SPF, DKIM, DMARC) need to be in place. Two out of three is partial coverage; one out of three is barely better than nothing.
  • Start DMARC with p=none for monitoring, then tighten to p=quarantine and eventually p=reject over weeks.
  • Set up DMARC reporting (rua=) from day one. Without reports, you can’t see who’s spoofing your domain or which legitimate senders are misconfigured.
  • Don’t ignore the 10-lookup SPF limit. Hitting it breaks SPF entirely; SPF flattening is the long-term fix.
  • Test DMARC alignment specifically when changing email services. Many issues come from From-domain not matching the authenticated domain.

Related tools in this suite

The Inbox Reachability Checker checks individual email content alongside sender authentication; this tool focuses on the domain-level authentication setup. Run both for full pre-send confidence.

What this looks like at scale

For a single domain, the diagnostic is sufficient. For organisations with many domains and subdomains, authentication monitoring should be continuous — DMARC reports collected and analysed regularly, SPF records audited as new email services are added. Paid tools (Valimail, dmarcian) automate this for enterprise scale.

Take it further

If your authentication setup has accumulated cruft over years (multiple SPF includes, unused DKIM selectors, DMARC stuck on p=none because you haven’t had time to tighten it), structured cleanup pays for itself in deliverability. Talk through the situation and we can scope what auditing and remediating looks like.