Email Deliverability Checker: SPF, DKIM, DMARC and MX

What this checker does, and what it cannot do

This free email deliverability tool looks up the public DNS records that tell mailbox providers who is allowed to send as your domain. It queries Cloudflare's public DNS-over-HTTPS resolver from your browser and checks four things:

• SPF: the TXT record on your domain that lists which servers may send for it.
• DMARC: the TXT record at _dmarc.yourdomain.com that tells receivers what to do when authentication fails.
• DKIM: the public key at selector._domainkey.yourdomain.com for the selector you type in.
• MX: the records that say where mail to your domain, including replies, is delivered.

It does not send an email, so it cannot tell you where your mail actually lands. Be clear about the limits before you trust a green result:

Most of the email deliverability tools that rank for this search fall into those categories: seed-list placement testers that send your message to accounts at several providers, spam scorers that give you an address to send a test email to, reputation dashboards run by the mailbox providers, and list verification services. They answer different questions, so pick the one that matches the problem you have. If you have not set up authentication yet, start here, because none of the others help much until DNS is right.

SPF: one record, ten lookups

SPF (Sender Policy Framework, RFC 7208) is a TXT record on your domain that starts with v=spf1 and lists the servers allowed to send mail for it. A typical record for a domain that sends through Google Workspace and Amazon SES looks like v=spf1 include:_spf.google.com include:amazonses.com ~all.

• Publish exactly one SPF record. RFC 7208 treats more than one v=spf1 record on the same name as a permanent error, which means SPF fails for everything. When you add a new sending service, merge its include: into the existing record instead of adding a second one.
• Stay under ten DNS lookups. Every include, a, mx, ptr, exists and redirect costs a lookup, including the ones nested inside the records you include. RFC 7208 caps evaluation at ten; past that, the result is a permanent error. Remove services you no longer use before you add new ones.
• Choose ~all or -all deliberately. -all says mail from any other server should fail; ~all (softfail) says it is suspicious but not definitely forged. Both are reasonable once DMARC is in place, because DMARC decides the outcome. Never publish +all, which authorizes every server on the internet.
• Know what SPF actually checks. SPF validates the envelope sender (the Return-Path address used for bounces), not the From address your readers see. Many sending platforms use their own bounce domain unless you set up a custom one, which is why SPF can pass while DMARC alignment fails.

DKIM: selectors and key length

DKIM (DomainKeys Identified Mail, RFC 6376) adds a cryptographic signature to each message. The receiving server fetches your public key from DNS and checks that the message was signed by your domain and not changed on the way.

• Selectors. The key lives at selector._domainkey.yourdomain.com. The selector is a label your sending platform chooses, and a domain can have several, one per sending service. That is why this checker asks you to type one: there is no way to list every selector a domain has from DNS alone.
• Finding your selector. The easiest place is the DNS setup screen of your email platform: the records it asked you to add have names that start with the selector. Google Workspace uses google by default, Microsoft 365 uses selector1 and selector2, and Amazon SES Easy DKIM uses three CNAME records with long generated selectors. If you are unsure, open a message you sent and look for s= in the DKIM-Signature header; the d= value next to it is the signing domain.
• Use 2048-bit keys. Google's DKIM setup guide recommends 2048-bit keys whenever your DNS provider supports them, because longer keys are more secure. Older 1024-bit keys still validate, but rotate to 2048 when you can.
• Sign with your own domain. A DKIM signature from your platform's shared domain does not help DMARC. The d= domain needs to match the domain in your From address.

For a step-by-step walkthrough on Amazon SES, including the CNAME records and how to confirm signing, see this guide on how to set up DKIM for your sending domain.

DMARC: from p=none to enforcement

DMARC (RFC 7489) ties SPF and DKIM to the From address your readers see and tells receivers what to do when mail fails. The record is a TXT record at _dmarc.yourdomain.com, for example v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com.

• Alignment is the point. A message passes DMARC if SPF passes for a domain that aligns with the From domain, or DKIM passes with a d= domain that aligns with it. Relaxed alignment (the default) accepts subdomains of the same organizational domain; strict alignment requires an exact match.
• Start with p=none and reports. p=none changes nothing about delivery but, with a rua address, gets you aggregate reports from receivers. RFC 7489 sets the default reporting interval at one day. The reports are XML, so use a free DMARC report reader rather than opening them by hand.
• Fix every legitimate source. The reports list every server sending as your domain. Some will be yours and failing (a billing tool, a help desk, an old newsletter platform). Authenticate them or stop them.
• Then enforce. Move to p=quarantine, which sends failing mail to spam, and later p=reject, which blocks it. There is no fixed schedule: move when the reports show your legitimate mail passing consistently. The pct tag lets you apply the policy to a share of failing mail first.

MX: can your readers reply?

MX records say where mail sent to your domain is delivered. For a newsletter, they matter because replies go to your From or Reply-To address. If that domain has no working MX, replies bounce, and replies are one of the clearest signs that a reader wants your mail. Send from an address you can actually read.

Gmail and Yahoo sender requirements since February 2024

Since February 2024, Gmail and Yahoo have enforced published requirements for anyone sending to their users. Google defines a bulk sender as one that sends close to 5,000 or more messages to personal Gmail accounts within 24 hours, and says that status is permanent once reached. Google also says that from November 2025 it is ramping up enforcement, with temporary and permanent rejections for mail that does not comply.

Google measures the spam rate in Postmaster Tools, as the share of your mail that Gmail users report as spam. If you use a newsletter platform, it handles the unsubscribe headers and most of the infrastructure; your job is DNS on your own domain and a clean list. Read the full rules in Google's email sender guidelines and Yahoo's sender best practices.

List hygiene

• Use confirmed opt-in where you can. A confirmation email filters out typos, fake addresses and spam traps before they reach your list.
• Remove hard bounces immediately. An address that does not exist will never exist. Most platforms suppress these automatically; check that yours does.
• Sunset inactive subscribers. Pick a window that suits your cadence, send a short re-engagement email, and remove people who do not respond. Judge activity by clicks and replies, not opens: Apple's Mail Privacy Protection loads images on the reader's behalf, so opens overstate who is really reading.
• Never import contacts who did not sign up. Bought or scraped lists are the fastest way to raise complaints and hit spam traps.

Warm-up on a new domain or IP

A new sending domain or dedicated IP has no history, so mailbox providers are cautious with it. Warming up means building that history gradually: start by sending to your most engaged subscribers, increase volume step by step over the following weeks, and watch bounces and complaints after each send. If either climbs, hold volume where it is until they settle. Treat any warm-up schedule you find online as a starting point, not a rule: your list quality matters more than the day count.

Moving platforms counts as a new start too. When I moved The Efficient Entrepreneur from beehiiv to Substack, the mail began coming from different infrastructure, which is exactly the moment to send carefully and keep your most engaged readers at the front of the queue.

Where your reputation lives matters here. On shared sending infrastructure, part of your reputation is pooled with other senders on the same IPs. On your own infrastructure, it is yours alone, for better and worse. That is the reason Meisa sends through your own AWS SES account: SaaS founders keep the sending reputation they build instead of renting it.

Complaint rate: the number to watch

Set up Google Postmaster Tools for your domain (it takes one DNS TXT record to verify) and check the user-reported spam rate after each send. Postmaster Tools may show no data until you send enough daily volume to Gmail, so a small list can look empty at first. Yahoo and Microsoft run feedback loops that report individual complaints back to the sender, and many platforms process them for you and suppress the people who complained.

People rarely mark mail as spam out of spite. They do it when they do not recognize the sender, do not remember signing up, or cannot find the unsubscribe link. So: use a From name they will recognize, send a welcome email right after sign-up that says what is coming and how often, and put the unsubscribe link where it is easy to find.

Content: what helps, and what matters less than you think

• Keep the From name and address consistent from issue to issue, so readers and filters see the same sender every time.
• Include a plain-text part alongside the HTML. Most platforms generate one; check that it reads properly.
• Balance images and text. An email that is one big image gives filters and readers with images turned off nothing to read.
• Avoid public URL shorteners. Shortened links hide the destination and share a domain with everyone else who uses the service. Link to your own domain or the real destination.
• Write honest subject lines. Fake "Re:" prefixes and all-caps urgency tend to cost you trust with readers. Check yours with our free subject line tester, and read our guide to newsletter subject lines for the craft.

Keep this in proportion. Look at what Gmail and Yahoo actually publish as requirements: authentication, unsubscribe handling and complaint rates. Neither publishes a list of banned words. Most inbox placement comes down to your reputation and how recipients react to your mail, so the list hygiene and complaint sections above will do more for you than rewording a sentence.

One cheap habit: keep a separate inbox, subscribe it to your own newsletter, and look at where each issue lands. I keep a burner inbox just for subscribing to other newsletters, and it doubles as a rough check on my own. One inbox is not a placement test, but it catches obvious breakage fast. If you are starting from zero, our guide on how to start a newsletter puts this setup in order.

Email deliverability checklist

• One SPF record on your sending domain, under ten DNS lookups, ending in ~all or -all.
• DKIM signing with your own domain as d=, using a 2048-bit key where your DNS host supports it.
• A DMARC record at _dmarc with a rua address, starting at p=none.
• DMARC reports read, and every legitimate sending service authenticated.
• A plan to move DMARC to p=quarantine, then p=reject.
• MX records on the From or Reply-To domain, so replies arrive.
• A test message sent to yourself shows SPF, DKIM and DMARC as pass in the headers.
• One-click unsubscribe headers and a visible unsubscribe link in every issue.
• Unsubscribes honored within 48 hours.
• Google Postmaster Tools verified, with the spam rate below 0.1% and never near 0.3%.
• Confirmed opt-in on sign-up forms, and no imported contacts.
• Hard bounces suppressed automatically.
• A sunset policy for inactive subscribers based on clicks and replies.
• Volume ramped gradually on any new domain, IP or platform.
• A consistent From name, a plain-text part, and no public URL shorteners.
• A welcome email that says what is coming and how often.

FAQ

Sources

1. Google: Email sender guidelines
2. Google: Email sender guidelines FAQ
3. Google Workspace: Set up DKIM
4. Gmail Help: Set up Postmaster Tools
5. Yahoo Sender Hub: Sender best practices
6. RFC 7208: Sender Policy Framework (SPF)
7. RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
8. RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
9. RFC 8058: Signaling One-Click Functionality for List Email Headers
10. Apple Support: Use Mail Privacy Protection on iPhone