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 (requires DNSSEC). 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, keep spam-complaint rates under about 0.3%, and support one-click unsubscribe. 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 for non-existent subdomains (set np=reject to shut down cousin-domain spoofing); 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 guidance (IR 8547) sets today's classical crypto (RSA-2048, ECC P-256) as deprecated by 2030 and disallowed by 2035. For email this shows up in transport (TLS 1.3 is the floor for hybrid post-quantum key exchange), DKIM signing (the migration path is to larger PQC signatures — a domain on RSA-1024 DKIM is doubly behind), and DNSSEC. The cheap moves now — get to TLS 1.3, rotate off RSA-1024 DKIM — are also your PQC head start.

Yes, fully read-only. It inspects public DNS and 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.