Free email deliverability audit

Almost always one of three things, in order of likelihood: authentication gaps (no aligned SPF, DKIM, and DMARC — the #1 cause and easiest to fix), sender reputation (a history of complaints, spam traps, or sending to dead addresses), and content/list hygiene (spammy copy, no unsubscribe, or unengaged recipients). A posture audit catches the authentication problems immediately.

They are three layers of proving an email is really from you. SPF lists which servers may send for your domain. DKIM cryptographically signs each message against a public key in your DNS. DMARC ties SPF and DKIM together with alignment (the authenticated domain must match the visible From: address) and tells receivers what to do when checks fail. You need all three — SPF and DKIM without an enforcing DMARC policy still leaves you spoofable.

DMARC's p= policy tells receivers how to handle mail that fails authentication. p=none is monitor-only — failing mail still gets delivered and anyone can still spoof you. p=quarantine sends failing mail to spam. p=reject rejects it outright, which is the goal and what large mailbox providers increasingly expect from bulk senders. The path is none to quarantine to reject, ramping as you confirm your legitimate mail passes. Staying on p=none forever is the most common deliverability mistake.

Valid SPF/DKIM/DMARC records are necessary but not sufficient. Watch three traps: receive-only domains (auth records do not make a forwarding-only domain send-ready), alignment (your ESP's mail must align to your domain, not the ESP's), and never sending cold or scaled outbound from your root domain — use a dedicated sending subdomain so a reputation hit on cold outreach does not poison your primary mail.

These are transport-security records that ensure mail to your domain travels over encrypted, authenticated connections. MTA-STS declares 'always use TLS to reach me'; TLS-RPT reports when someone fails to connect securely; DANE pins your TLS certificate in DNS (and is only trusted when your DNSSEC chain validates). They are not a deliverability lever the way DMARC is, but they are increasingly required in regulated, government, and security-conscious contexts. Treat them as hardening — do them when the requirement or buyer calls for it.

BIMI shows your verified logo next to your emails in supporting inboxes (Gmail, Apple Mail, Yahoo). It requires a strong DMARC policy (quarantine or reject) as a prerequisite, and a VMC (Verified Mark Certificate) for the blue verified checkmark. It is worth it for brands sending real volume: it lifts recognition and open rates, and the DMARC prerequisite forces a strong authentication posture. High value — not just hardening.

Since 2024, Gmail and Yahoo require bulk senders (roughly 5,000+ messages/day to their users) to authenticate with SPF and DKIM, publish a DMARC policy with alignment (Google explicitly allows that policy to be p=none — authentication is the requirement, enforcement is your choice), and keep spam-complaint rates under about 0.3%. One-click unsubscribe is required for marketing and subscribed messages specifically, not for transactional mail like receipts and alerts. Microsoft has announced similar expectations. Mail that does not comply gets throttled or junked.

DMARCbis is the modernized DMARC standard, published as RFC 9989 (May 2026), which obsoletes the original DMARC (RFC 7489). The changes that matter to operators: a DNS Tree Walk replaces the Public Suffix List for determining organizational domains; np= is a new policy that applies specifically to NON-EXISTENT subdomains of your domain (set np=reject so nobody can send as a subdomain you never created). Note what it does not do: a lookalike "cousin" domain is a separate registration, and no DMARC policy on your domain can reach it; and pct, rf, and ri are removed. If you run DMARC across subdomains, this is worth acting on now.

Eventually yes, and the clock is public. NIST's draft guidance on the transition (IR 8547, still an initial public draft rather than final) proposes treating today's classical crypto (RSA-2048, ECC P-256) as deprecated around 2030 and disallowed after 2035 — a direction of travel, not a settled mandate. For email this shows up in transport (TLS 1.3 is the floor for hybrid post-quantum key exchange), DKIM signing (where there is as yet NO standardized post-quantum path — the PQC signature schemes are large and the IETF work is early — so the actionable move today is classical hygiene: a domain still on RSA-1024 DKIM is behind on the standard that already exists), and DNSSEC. The cheap moves now — get to TLS 1.3, rotate off RSA-1024 DKIM — are also your PQC head start.

DNSSEC cryptographically signs your DNS so the answers — including your mail records — can't be forged in transit, and it's the prerequisite for DANE. It's more a security/trust measure than a direct deliverability lever: enable it when a security review or compliance requirement calls for it, or as part of a strong overall posture. The audit flags whether your zone is signed (and its answers cryptographically validate).

Yes. A brand-new domain has no sending reputation, so mailbox providers throttle it by default — send cold or at volume from a freshly registered domain and much of it lands in spam. Warm up gradually: start with low volume to engaged recipients and ramp over a few weeks before scaling. The audit flags a domain that's only days old.

Increasingly people ask AI answer engines about vendors instead of searching, and those engines use their own crawlers (GPTBot, ClaudeBot, PerplexityBot, OAI-SearchBot, Google-Extended and others). If your robots.txt blocks them, your site is invisible to those answers. The audit checks whether your robots.txt is shutting AI crawlers out, so you can decide which to allow.

Yes. The same engine that powers this page is also a free GitHub Action. Add it to a workflow and it checks your sending domain's SPF, DKIM, DMARC, MTA-STS and more on every push or pull request, writes a scorecard with the exact fix for each finding, and can fail the build when your posture regresses below a threshold you choose. Like this page it is fully read-only and needs no secrets — it only queries public DNS. Start in advisory mode (report-only), then turn on enforcement once you are clean. It is on the GitHub Marketplace as the Amino Email Deliverability Audit.

Yes, fully read-only — though "read" covers a little more than DNS, so here is the whole list. It queries your public DNS records; it fetches your published MTA-STS policy over HTTPS (that file is served over HTTPS by design, not DNS); it reads your robots.txt to check AI-crawler visibility; and it looks up your domain's registration date via public RDAP. All four are public information that any mail server or crawler can read. It drafts the exact changes for you to review, but it never touches your DNS, sends mail, or needs credentials. Nothing changes until you choose to apply a fix yourself.