Email Deliverability
Email Deliverability helps you comprehensive email deliverability and authentication test, for secure mail validation, policy checks, and troubleshooting.
Advertisement · Anuncio
Advertisement · Anuncio
Technical Analysis & Guide
What It Does
Email Deliverability runs four authentication and routing checks on a domain and combines them: it validates the SPF record, evaluates the DMARC policy, probes DKIM keys at the common selectors default, google, k1 and s1 (stopping at the first one found), and confirms that MX records exist. Each finding is listed under passed, warnings or issues, and the headline status reflects the most serious one. It inspects published DNS only, not your sending IPs or message content.
Why It Matters
- →Bulk sender rules: Since February 2024 Gmail and Yahoo reject or spam-folder mail from high-volume senders that lack SPF, DKIM and a DMARC record.
- →Pre-campaign gate: A newsletter platform or CRM added without updating SPF or DKIM can push an entire launch email into junk.
- →Spoofing exposure: A domain with missing DMARC or a permissive SPF lets fraudsters send invoices in your name, and the complaints damage your own reputation.
- →Reply-path sanity: Missing MX records mean customer replies and bounce notices vanish, and some receivers treat a domain that cannot receive mail as suspicious.
- →Quick health baseline: One combined result shows marketing, IT and support teams where to start before opening tickets with an email provider.
How to Read Results
- Status: FAIL when at least one critical issue exists, WARN when there are only warnings, PASS when SPF, DMARC, DKIM and MX all succeeded.
- SPF: 'SPF configured correctly' is a pass; 'SPF has warnings' means the record has no all mechanism, ends in a neutral ?all, or is close to the 10-lookup limit; 'SPF missing or misconfigured' is a critical issue.
- DMARC: 'DMARC configured correctly' is a pass. A missing record or weak policy appears under warnings as 'DMARC missing or has warnings'; a malformed record is a critical issue.
- DKIM: 'DKIM configured (selector: x)' names the selector found. 'No DKIM records found with common selectors' is only a warning, because your provider may use another selector such as selector1 or a random token.
- MX: 'MX records configured' or the critical issue 'No MX records found' / 'MX records missing'.
- Not measured here: PTR records, TLS, one-click unsubscribe headers, spam complaint rate and blocklist status. Use the reverse lookup, SMTP, header analyzer and blacklist tools for those.
Technical Background
Inbox placement rests on proving that a message really comes from the domain in its From header. SPF (RFC 7208) lists the IP addresses allowed to send for the envelope domain, for example v=spf1 include:_spf.google.com include:sendgrid.net -all, and is limited to ten DNS-querying mechanisms. DKIM (RFC 6376) attaches a signature verified against a public key at <selector>._domainkey.<domain>. DMARC (RFC 7489) ties them together: it passes when SPF or DKIM passes for a domain aligned with the visible From, and the policy p=none, quarantine or reject tells receivers what to do with failures.
In February 2024 Google and Yahoo turned these practices into enforced requirements. Every sender must authenticate with SPF or DKIM, send from IPs with valid forward-confirmed reverse DNS (a PTR whose hostname resolves back to the same IP), use TLS for transmission, follow RFC 5322 message formatting and keep the spam complaint rate reported in Google Postmaster Tools below 0.3 percent, with 0.1 percent as the practical target. Bulk senders, defined by Google as those sending roughly 5,000 or more messages a day to personal Gmail accounts, must additionally pass both SPF and DKIM, publish DMARC with at least p=none, align the From domain with SPF or DKIM, and include one-click unsubscribe on marketing mail. Microsoft announced comparable requirements for Outlook.com in 2025.
One-click unsubscribe is specified by RFC 8058. A compliant marketing message carries two headers: List-Unsubscribe with an HTTPS URL (optionally also a mailto:), and List-Unsubscribe-Post: List-Unsubscribe=One-Click. The message must be DKIM-signed with those headers covered by the signature, and the provider must process the unsubscribe within two days. A link buried in the footer alone no longer satisfies the rule for bulk senders.
This tool covers the DNS foundation of that list. Its DKIM probe tries only four widespread selectors, so a domain signed with selector1 and selector2 (common on Microsoft 365) or with per-tenant tokens from an ESP may show a DKIM warning even though signing works. To confirm, open the Authentication-Results header of a delivered message, or run the DKIM checker with your real selector.
Authentication is necessary but not sufficient. Reputation is built over weeks by sending wanted mail at a steady volume, removing bounced addresses, honoring unsubscribes and avoiding purchased lists. Combine this check with a PTR lookup of your sending IPs, a blocklist check and the header analyzer on a test message to see the full picture.
Common Errors and How to Fix Them
- ProblemA new ESP was added with a second SPF TXT record, so receivers see two v=spf1 records and return permerror.
- FixMerge all senders into one record, e.g. v=spf1 include:_spf.google.com include:spf.esp.example -all, and delete the extra TXT.
- ProblemMarketing mail passes SPF on the ESP's bounce domain but fails DMARC because nothing is aligned with the From domain.
- FixEnable custom DKIM signing with your own domain at the ESP (publish their CNAME or TXT keys) or configure a custom return-path subdomain so SPF aligns.
- ProblemDMARC sits at p=none for years and spoofed invoices still reach customers.
- FixReview aggregate reports, authorize every legitimate source, then move to p=quarantine and finally p=reject, optionally ramping pct during the transition.
- ProblemBulk mail is rejected by Gmail with a message about unsubscribe requirements.
- FixAdd List-Unsubscribe with an HTTPS URL and List-Unsubscribe-Post: List-Unsubscribe=One-Click, include both headers in the DKIM signature, and process requests within two days.
- ProblemMail from a self-hosted server lands in spam because its IP has no PTR or the PTR points to a generic ISP name.
- FixAsk the IP owner (hosting provider) to set a PTR such as mail.example.com, create the matching A record, and use the same name in the SMTP banner and HELO.
Frequently Asked Questions
What are the Gmail and Yahoo bulk sender requirements?
Senders of about 5,000 or more messages a day to Gmail must authenticate with both SPF and DKIM, publish a DMARC record with at least p=none and alignment on the From domain, offer RFC 8058 one-click unsubscribe on marketing mail, honor unsubscribes within two days, and keep spam complaints under 0.3 percent. All senders also need valid PTR records and TLS. Yahoo applies closely matching rules.
Why does the tool say no DKIM was found when my email is signed?
The checker tries only the selectors default, google, k1 and s1. Many providers use others: Microsoft 365 uses selector1 and selector2, and email service providers often generate unique tokens. Look at the DKIM-Signature header of a sent message, read the s= value, and test that selector with the DKIM checker to confirm the key is published.
What spam complaint rate is acceptable?
Google asks bulk senders to stay below 0.3 percent as measured in Postmaster Tools and recommends keeping it under 0.1 percent. The rate is complaints divided by messages delivered to the inbox, so it can climb quickly for small lists. Clear opt-in, easy unsubscribe and removing inactive recipients are the most effective ways to keep it low.
Is p=none enough for DMARC compliance?
For the 2024 Gmail and Yahoo bulk sender rules, a DMARC record with p=none satisfies the minimum, provided messages are aligned. It does not stop spoofing, though, and features such as BIMI require quarantine or reject. Use the reporting from p=none to find all legitimate senders, then move toward enforcement.
Does passing this check guarantee my emails reach the inbox?
No. A pass confirms that SPF, DMARC, DKIM on common selectors and MX are published correctly, which is the baseline receivers expect. Placement also depends on IP and domain reputation, complaint rates, engagement, content, list hygiene and blocklist status. Treat a pass as removing technical excuses, then watch Postmaster data and bounce logs.
Academic Documentation
Protocol context and primary references
DMARC.org
Domain-based Message Authentication standard
Open source →
SPF Project
Sender Policy Framework documentation
Open source →
IETF
Internet Engineering Task Force
Open source →
RFC Editor
Official RFC documentation
Open source →
IANA
Internet Assigned Numbers Authority
Open source →
M3AAWG
Operational guidance for email authentication and abuse handling.
Open source →
REST API Documentation
v1.0GET /api/tools/email-deliverability
curl -X POST https://epcybertools.com/api/tools/email-deliverability \
-H "Content-Type: application/json" \
-d '{"domain":"google.com"}'
{
"success": true,
"results": [
{ "test": "Sample Check", "status": "pass", "message": "All clear" }
]
}
Usage Examples
# SPF and DMARC records
dig +short TXT example.com | grep spf1; dig +short TXT _dmarc.example.com
# DKIM key for a specific selector
dig +short TXT selector1._domainkey.example.com
# Forward-confirmed reverse DNS of a sending IP
dig +short -x 203.0.113.25