Pages and copy
Why are my emails going to spam?
This free email deliverability checker reads your domain's SPF, DKIM and DMARC records, the authentication Gmail and Yahoo check first, and shows which ones to fix.
SPF, DKIM, DMARC
Reads the records Gmail and Yahoo check first, plus MX and BIMI.
Lookups counted
Follows every SPF include and counts the DNS lookups against the limit of 10.
Sourced checks
Each finding links to the RFC or the provider's own documentation.
Past clients or mentioned on
Email deliverability checker: what do your records say?
Free, no sign-up. Type the domain you send from, or your email address, and Convertica's server reads that domain's public DNS records. Below is the result for a made-up store.
Result for store.example
1 to review
Nothing to fix; 1 to review.
These are DNS records only. Content, reputation, complaints and list quality also decide where mail lands.
Example result, for the made-up store in the worked example
SPF: which servers may send as you
- Pass One SPF record at store.example. RFC 7208: Sender Policy Framework (SPF)
- Pass 9 of 10 DNS lookups. RFC 7208: Sender Policy Framework (SPF)
- Pass Ends in ~all: mail from servers the record does not list gets softfail, a weaker signal than -all. RFC 7208: Sender Policy Framework (SPF)
DKIM: the signature on your mail
- Pass DKIM key found at selector google (Google Workspace (default selector)). Google Workspace: set up DKIM
- Pass DKIM key found at selector km1 (Klaviyo (marketing)). Klaviyo Help: set up a branded sending domain
DMARC: what to do with mail that fails
- Pass One DMARC record at _dmarc.store.example. RFC 9989: DMARC
- Pass Policy p=none is the least Google and Yahoo ask of bulk senders. It asks receivers to take no action on mail that fails, so it does not stop others sending as your domain. Google: email sender guidelines
- Review No rua address, so receivers send no aggregate reports. Those reports show which servers send mail as your domain and whether it passes. RFC 9989: DMARC
MX and BIMI
- Note Mail to store.example goes to mx1.mailhost.example, mx2.mailhost.example.
- Note No BIMI record. BIMI is optional: it lets some inboxes show your logo, and Gmail needs DMARC at quarantine or reject and a certificate for it. Google Workspace: set up BIMI
Gmail and Yahoo sender requirements
- SPF or DKIM for the sending domain (All senders)
- In place
- Both SPF and DKIM (Bulk senders)
- In place
- A DMARC record, at least p=none (Bulk senders)
- In place
- The From: domain aligned with the SPF or the DKIM domain (Bulk senders)
- Not visible in DNS
- Forward and reverse DNS (PTR) for the sending IP addresses (All senders)
- Not visible in DNS
- A TLS connection for sending (Google) (All senders)
- Not visible in DNS
- Spam rate below 0.3% (All senders)
- Not visible in DNS
- One-click unsubscribe on marketing mail, and a visible unsubscribe link (Bulk senders)
- Not visible in DNS
SPF record
- TXT at store.example
- v=spf1 include:_spf.mailhost.example include:send.newsletter.example include:helpdesk.example ~all
- Lookups counted
- 9 of 10
- Where they come from
- store.example: include:_spf.mailhost.example, include:send.newsletter.example, include:helpdesk.example _spf.mailhost.example: include:_net1.mailhost.example, include:_net2.mailhost.example _net1.mailhost.example: no lookups _net2.mailhost.example: no lookups send.newsletter.example: include:_ips.newsletter.example _ips.newsletter.example: no lookups helpdesk.example: a, mx, include:_relay.helpdesk.example _relay.helpdesk.example: no lookups
- Mail from unlisted servers
- ~all (softfail)
DMARC record
- TXT at _dmarc.store.example
- v=DMARC1; p=none
- Policy for this domain
- none
DKIM selectors checked
- google._domainkey
- Key found, rsa
- selector1._domainkey
- No key
- selector2._domainkey
- No key
- km1._domainkey
- Key found, rsa
- km2._domainkey
- No key
- kt1._domainkey
- No key
- kt2._domainkey
- No key
- ks1._domainkey
- No key
- ks2._domainkey
- No key
- kl1._domainkey
- No key
- kl2._domainkey
- No key
- s1._domainkey
- No key
- s2._domainkey
- No key
- k2._domainkey
- No key
- resend._domainkey
- No key
MX and BIMI
- MX
- 1 mx1.mailhost.example 5 mx2.mailhost.example
- BIMI at default._bimi
- None
Why are my emails going to spam? The usual causes
Your emails go to spam when the receiving mailbox cannot confirm the mail came from you, or when its filters and your recipients treat the mail as unwanted. Gmail, Outlook and Yahoo weigh authentication, your sending history, complaints and content together. Authentication is the one cause you can check from outside in a minute, so start there.
| Cause | What goes wrong | How to check it | This checker |
|---|---|---|---|
| Missing or broken authentication | No SPF, DKIM or DMARC record, two SPF records, or an SPF record over 10 lookups, so the receiver cannot confirm the mail is yours | Read the DNS records, or the Authentication-Results header of a message you sent | Yes |
| Spam complaints | Recipients press "Report spam". Google asks senders to stay below 0.3% | Google Postmaster Tools for Gmail; your sending tool's complaint report | No |
| List quality | Old, bought or scraped addresses bounce, never open, or belong to people who did not ask for the mail | Bounce and engagement reports in your sending tool | No |
| Sending pattern | A new domain or a sudden jump in volume, with no history behind it | Compare this month's sends with your usual volume | No |
| Content and links | Misleading subject lines, a link to a domain with a poor record, or a message that is one large image | Send to inboxes you control and look where it lands | No |
| Blocklists | Your sending IP address or domain is listed by a blocklist that receivers consult | The blocklist operators' own lookup pages | No |
| The recipient's own settings | A filter, a block or an earlier "Report spam" on that one account | Ask the recipient to check the spam folder and mark the message as not spam | No |
One cause hides another. A domain with perfect records still lands in spam if half its list never asked for the mail, and a clean list still struggles when SPF fails. Fix the records first because they are quick and certain, then look at complaints and the list.
How to check your email deliverability
To check email deliverability, read your domain's authentication records, then confirm what receivers concluded about a real message, then look at complaints. The email deliverability checker does the first step. The other two use a message you sent and the reports your mailbox providers give you.
-
Check the records
Type the domain you send from into the checker above. It reads SPF, DKIM, DMARC, MX and BIMI and marks each finding Fix, Review, Pass or Note, with the rule it comes from.
-
Read the headers of a message you sent
Send a message from each tool you use (your mailbox, your newsletter tool, your store's order emails) to a Gmail address. In Gmail on a computer, open it, choose More, then Show original. The Authentication-Results header records whether SPF, DKIM and DMARC passed, and the DKIM-Signature header names the selector in s=.
-
Look where the message landed
Send the same message to inboxes you control at Gmail, Outlook and Yahoo, and note whether it reached the inbox, a tab or spam. That is the only way to see placement for yourself.
-
Watch the spam rate
If you send to Gmail in volume, verify your domain in Google Postmaster Tools. Google's sender guidelines say to keep the spam rate it reports below 0.3%, and recommend staying under 0.1%.
What does the email deliverability checker read?
The email deliverability checker reads five kinds of public DNS record for your domain: SPF, DKIM, DMARC, MX and BIMI. It asks Cloudflare's DNS resolver for them, the same records any receiving mail server can read, and checks each against the standard or the mailbox provider's rule linked in the last column.
| Record | Where it lives | What it does | Rule from |
|---|---|---|---|
| SPF | A TXT record at your domain starting v=spf1 | Lists the servers allowed to send mail for the domain | RFC 7208 |
| DKIM | A TXT record at selector._domainkey.yourdomain | Holds the public key that checks the signature your sending service adds to each message | Each provider's own setup page |
| DMARC | A TXT record at _dmarc.yourdomain starting v=DMARC1 | Says what receivers should do with mail that fails, and where to send reports | RFC 9989 |
| MX | MX records at your domain | Names the servers that receive mail for the domain, so replies and bounces arrive | RFC 7505 for a null MX |
| BIMI | A TXT record at default._bimi.yourdomain | Points to a logo some inboxes show beside your mail | BIMI draft, Google |
What is an SPF record, and what is the 10 lookup limit?
An SPF record is a TXT record that lists which servers may send mail for your domain. A receiver compares the server that delivered a message with that list. RFC 7208 allows one SPF record per domain and at most 10 DNS lookups while checking it. Past either limit, SPF returns permerror and fails for every message.
The lookups are the terms include, a, mx, ptr, exists and redirect, counted through every record an include brings in. The terms ip4, ip6 and all cost nothing. Each sending tool you add usually asks for one more include, and some of those includes contain includes of their own, which is how a record drifts past the limit without anyone noticing.
Worked example: counting SPF lookups
The example result at the top of this page is for a made-up store at store.example. Every name, address and key in it is invented. Its SPF record is:
v=spf1 include:_spf.mailhost.example include:send.newsletter.example include:helpdesk.example ~all| Include | Its own record | Lookups |
|---|---|---|
include:_spf.mailhost.example | v=spf1 include:_net1.mailhost.example include:_net2.mailhost.example ~all | 3 |
include:send.newsletter.example | v=spf1 include:_ips.newsletter.example -all | 2 |
include:helpdesk.example | v=spf1 a mx include:_relay.helpdesk.example ~all | 4 |
| Total | 9 of 10 |
Each include costs one lookup for itself plus whatever its own record triggers. The help desk's record adds three because a, mx and its include each count. The store passes with 9.
Now the store connects a CRM and adds include:crm.example, whose record holds two includes of its own. The count goes to 12, and the checker says: "12 DNS lookups, over the limit of 10. A receiver must return permerror once the limit is passed, so SPF can fail for your mail. Remove includes for services you no longer use, or replace some with ip4 and ip6 ranges." Nothing looks broken in the store's own record, and every tool in it is real. That is why the count has to be followed through each include.
To bring a record back under the limit, remove includes for tools you no longer send with, keep one record for one domain, and ask a provider whether a narrower include exists. Some senders move one tool's mail to a subdomain with its own SPF record, which keeps each record short.
What does ~all or -all mean at the end of an SPF record?
The last term tells receivers what to do with mail from a server the record does not list. -all asks them to fail it, ~all to softfail it, a weaker signal. ?all says nothing either way, and +all lets any server on the internet pass, which defeats the record. The checker marks +all as a fix and ?all as one to review.
What is DKIM, and why can't a checker always find it?
DKIM is a signature your sending service adds to each message, checked against a public key in your DNS. The key lives at a name that starts with a selector, such as google._domainkey.yourdomain.com. A checker can only find a DKIM key if it knows the selector, and there is no way to list every selector a domain uses.
So this checker tries the selectors that providers publish in their own documentation, below. If yours is not found, that does not prove DKIM is off. Open a message you sent, show the original, and read s= in the DKIM-Signature header: that is your selector.
SendGrid lets each account pick its own selector, and many other services do too, so a default selector is a likely place to look, not a certain one. Amazon SES, Postmark and others generate names per account and are not in the list for that reason.
What DMARC policy should I use?
A DMARC policy tells receivers what to do with mail that claims to be from your domain but fails both SPF and DKIM alignment. p=none asks them to do nothing special, p=quarantine to treat it as suspicious, and p=reject to refuse it. Google and Yahoo accept p=none from bulk senders.
| Policy | What receivers are asked to do with failing mail | Meets Google's and Yahoo's bulk requirement |
|---|---|---|
p=none | Nothing special; send reports if rua is set | Yes |
p=quarantine | Treat it as suspicious, for example by putting it in spam | Yes |
p=reject | Refuse it | Yes |
A safe order for most senders: publish p=none with a rua address, read the reports until every service that sends as you passes, then move to quarantine and later reject. Moving early can send your own invoices or newsletters to spam if one tool is not yet signing with your domain.
Two details changed in May 2026, when RFC 9989 replaced RFC 7489. A record with no p= is now treated as p=none, and the old pct= tag is historic, partly replaced by t=y for testing a policy one level below what it states. A domain with no record of its own is covered by its parent's record, found by walking up the domain name, which the checker does too.
What do Gmail and Yahoo require from email senders?
Since February 1, 2024, Google requires every sender to Gmail to have SPF or DKIM, valid forward and reverse DNS, a TLS connection and a spam rate below 0.3%. Senders of 5,000 or more messages a day must also have SPF, DKIM, a DMARC record, alignment and one-click unsubscribe. Yahoo publishes a similar list.
| Requirement | All senders | Bulk senders | Visible in DNS |
|---|---|---|---|
| SPF or DKIM for the sending domain | Yes | Yes | Yes |
| Both SPF and DKIM | No | Yes | Yes |
| A DMARC record, at least p=none | No | Yes | Yes |
| The From: domain aligned with the SPF or the DKIM domain | No | Yes | No |
| Forward and reverse DNS (PTR) for the sending IP addresses | Yes | Yes | No |
| A TLS connection for sending (Google) | Yes | Yes | No |
| Spam rate below 0.3% | Yes | Yes | No |
| One-click unsubscribe on marketing mail, and a visible unsubscribe link | No | Yes | No |
Sources: Google's email sender guidelines and Yahoo's sender best practices. Google counts a bulk sender by messages a day to Gmail accounts; Yahoo's page does not define one. Alignment means the domain in the From line matches the domain SPF or DKIM checked, which only a sent message can show. Your sending tool's domain setup is what makes it match.
Why are my Klaviyo emails going to spam?
Klaviyo emails often go to spam for the same reasons as any other: no branded sending domain, no DMARC record, or a list and complaint problem. Without a branded sending domain, Klaviyo sends from a shared Klaviyo domain, and inboxes may show "via klaviyomail.com" beside your name. Setting one up puts Klaviyo's DKIM keys on your own domain.
- Selectors. Klaviyo's help page lists km1 and km2 for marketing mail, kt1 and kt2 for transactional, ks1 and ks2 for service mail, and kl1 and kl2 on older domains. The checker tries all of them.
- DMARC. Klaviyo can add
v=DMARC1; p=none;for you during setup, and says you still need to meet the other sender requirements. - One record. If your domain already has a DMARC record, do not add a second one: two records at the same name are both discarded.
Shopify Email and other store platforms
Shopify's help page says to authenticate your sender domain with the CNAME records it shows, which cover DKIM and SPF, and that automatic setup on a domain bought elsewhere does not add a DMARC record: you add v=DMARC1; p=none yourself. Until the domain is authenticated, Shopify rewrites your sender address to one at shopifyemail.com. Check the domain here once the records are in.
Why are my emails suddenly going to spam?
When emails that used to arrive suddenly go to spam, something changed: in your DNS, in your sending tools, in your volume or in how recipients responded. Start with the records, because a DNS change is the quickest cause to confirm and to reverse.
- A new tool in the SPF record. One more include can take the count past 10, as in the worked example above.
- A second record. A new tool's setup guide says "add this SPF record" and someone adds it beside the old one instead of merging. Two SPF records fail; two DMARC records are discarded.
- A provider switch. Moving mailboxes or newsletter tools leaves the old include in place and the new DKIM key missing.
- A policy change. Moving DMARC to quarantine or reject before every service passes sends that service's mail to spam.
- A campaign to an old list. Bounces and "Report spam" clicks rise together, and the next campaigns pay for it.
How to stop emails going to spam
To stop emails going to spam, fix authentication first, then send only mail people asked for and make leaving easy. These steps follow Google's and Yahoo's own requirements; none of them guarantees the inbox, because each mailbox provider decides for itself.
- Publish one SPF record under 10 lookups, listing every tool that sends as your domain, ending in
~allor-all. - Turn on DKIM in every sending tool, with your own domain, not the tool's shared one.
- Add a DMARC record of at least
p=none, with aruaaddress so you receive reports. - Send from your own domain. A free mailbox address in the From line cannot pass DMARC for a domain you do not control.
- Add one-click unsubscribe to marketing mail and a visible unsubscribe link in the body.
- Send to people who asked. Remove addresses that bounce, and stop mailing people who have not opened in a long while.
- Watch complaints. Keep the spam rate Google Postmaster Tools reports below 0.3%.
- Change volume gradually. A new domain or a much bigger send has no history behind it.
What this email deliverability checker cannot tell you
This email deliverability checker reads public DNS records. It cannot predict whether a message will reach the inbox, because receivers also weigh things no DNS lookup shows.
- Inbox placement. It sends no mail, so it cannot see where a message lands.
- Reputation and complaints. Only the mailbox providers know these; Google shows Gmail's in Postmaster Tools.
- Alignment. Whether your From domain matches the domain SPF and DKIM checked shows only in a sent message's headers.
- DKIM at other selectors. It tries 15 published selectors; a key elsewhere is not found.
- Your IP addresses. It does not check reverse DNS (PTR) or blocklists for your sending servers.
- Its own limits. It makes a capped number of lookups per check, so a very long SPF chain is reported as "at least" its count. Each IP address can run 10 checks per 10 minutes.
What lost emails cost a store
For a store, the emails that matter most are the ones customers wait for or act on: the order confirmation, the shipping update, the abandoned cart reminder, the reply to a question. When those land in spam, the sale they were meant to finish often does not happen, and nothing in your analytics says why. Fixing the records is the first step. The second is making sure the page each email links to does its job once the visitor arrives.
- Fix the records with the checker above, then confirm with a sent message's headers.
- Check the landing page. The landing page analyzer scores the page an email campaign sends people to.
- Tag the links. The UTM builder tags each email's links so you can see in analytics which ones bring sales.
- Audit the page. The free CRO audit checks the page behind the click.
See all free tools and how they fit together.
Short answer
Emails go to spam when receivers cannot confirm they came from you, or when recipients and filters treat them as unwanted. Gmail and Yahoo check SPF, DKIM and DMARC first, so a missing or broken record is the cause you can find in minutes. Complaints, list quality and content are the rest.
- Google asks every sender for SPF or DKIM, and senders of 5,000 or more messages a day for SPF, DKIM and a DMARC record.
- An SPF record may trigger at most 10 DNS lookups, counted through every include. Past that, SPF returns permerror.
- DKIM can only be found with its selector, so a checker that does not find it has not proved it is missing.
- p=none meets the DMARC requirement but asks receivers to do nothing about mail that fails.
- Records are one cause. Spam complaints, old lists and content decide the rest, and no DNS check can predict the inbox.
Emails going to spam: FAQ
Why are my emails going to spam?
Emails usually go to spam for one of a few reasons: the domain's SPF, DKIM or DMARC records are missing or broken, too many recipients mark the mail as spam, the list holds old or bought addresses, or the content and links look like spam. Gmail and Yahoo now require authentication from senders, so check the records first.
Why are my emails suddenly going to spam?
Something changed. Common changes are a new sending tool added to the SPF record that pushes it past 10 DNS lookups, a second SPF or DMARC record added by mistake, a DKIM key removed when a provider was switched, a jump in volume, or a campaign to an old list that drew complaints. Check the records first, then the spam rate in Google Postmaster Tools.
How do I stop my emails from going to spam?
Publish one SPF record under 10 lookups, turn on DKIM signing with your sending provider, and add a DMARC record of at least p=none with a rua address. Then send only to people who asked for your mail, make unsubscribing one click, and keep the spam rate Google reports below 0.3%.
Why are my Klaviyo emails going to spam?
Check the domain setup first. Without a branded sending domain, Klaviyo sends from a shared Klaviyo domain and inboxes may show "via klaviyomail.com". A branded sending domain adds Klaviyo's DKIM keys (selectors such as km1 and km2) to your domain. Then check DMARC, list quality and complaints, which Klaviyo cannot fix for you.
Can this checker tell me if my email will land in the inbox?
No. It reads your domain's public DNS records, which is one part of the picture. Where a message lands also depends on your sending reputation, complaints, the list, the content and each recipient's own settings. To see where a message lands, send it to inboxes you control at Gmail, Outlook and Yahoo and look.
What is the SPF 10 lookup limit?
RFC 7208 lets an SPF check make at most 10 DNS lookups, counting include, a, mx, ptr, exists and redirect, including those inside each include. Past 10 the check must return permerror, so SPF can fail for your mail. ip4, ip6 and all do not count. The checker counts them for you.
Do I need a DMARC record?
If you send 5,000 or more messages a day to Gmail accounts, yes: Google and Yahoo require a DMARC record from bulk senders, and p=none is enough to meet that. For any sender, DMARC with a rua address sends you reports of who sends mail as your domain, which is how you find a tool that is not set up.
Why can't the checker find my DKIM record?
A DKIM key lives at a name that includes a selector the sender chooses, such as google._domainkey for Google Workspace. The checker tries the selectors that Google, Microsoft, Klaviyo, SendGrid, Mailchimp and Resend publish. If yours uses another one, find the s= value in the DKIM-Signature header of a message you sent.
Is this email deliverability checker free, and what happens to my data?
It is free with no sign-up. Only the domain is sent to Convertica's server, which looks up its public DNS records through Cloudflare's DNS resolver and returns them. If you type an email address, the part before the @ stays in your browser. Nothing is stored, and each IP address can run 10 checks per 10 minutes.
