Audit your domain's email security and deliverability

A complete audit of email security and deliverability

A domain's email setup plays out on two fronts. On the sending side, authentication (SPF, DKIM, DMARC) decides whether your messages reach the inbox or end up in spam. On the receiving side, transport security (MTA-STS, DANE, TLS-RPT) and DNS integrity (DNSSEC) protect your exchanges against interception and impersonation. A weakness on a single side undermines the whole.

This email deliverability and security audit (also called a "DMARC checker", "SPF lookup", "DKIM validator", "domain health check", or "email security audit") runs nine protocols, split across three pillars, through a single scan.

Sending (outbound):

Receiving (inbound):

There are three moments when this audit earns its keep. Before a campaign, to confirm the domain is ready to send. To secure receiving, by checking transport encryption and DNS integrity. And after a platform change, when you need to make sure the new DKIM selectors and their records are actually published.

How to use the email audit in 3 steps

Step 1: Enter your domain

Type the domain to audit (captaindns.com). If you send through several platforms (Mailchimp, Brevo, Google Workspace), add the matching DKIM selectors for a complete check of the sending side.

Where to find your DKIM selectors:

• Mailchimp: k1 (settings → domain → authentication)
• Brevo: mail (settings → senders → DKIM)
• Google Workspace: google (Admin Console → Apps → Gmail → Authentication)
• Microsoft 365: selector1, selector2 (Admin → Domains → DNS records)

Step 2: Run the analysis

The tool queries your DNS records with no action needed from you.

On the sending side, it checks SPF syntax, its lookup count, and its -all mechanism, validates each DKIM selector along with the key size (2048 bits or more), inspects the DMARC policy and its reports, then confirms the BIMI record points to an accessible logo.

On the receiving side, it lists your MX records and tests their resolution and redundancy, checks the MTA-STS record, its HTTPS policy, and its mode (enforce or testing), matches DANE's TLSA records against DNSSEC validation, and makes sure TLS-RPT actually declares a report destination.

Step 3: Review the results

You get:

• Overall score out of 100 with a configuration badge (Excellent, Good, Fair, Poor)
• Protocol-by-protocol diagnostics with pass/fail status
• Corrective actions ranked by priority
• JSON export to share with your technical team

How the score out of 100 is calculated

The overall score aggregates three weighted pillars: sending (50%), receiving (35%), and DNS security (15%). Here is how they break down.

Each pillar is scored out of 100, then weighted accordingly. The total leads to a grade. Above 90, everything is in place: that's Excellent. Between 75 and 89, the foundation holds and a few tweaks remain (Good). From 55 to 74, errors or warnings nibble at your deliverability or your security (Fair). Below 55%, the outlook is grim: a major blocker compromises sending or receiving (Poor).

Points breakdown by pillar

Sending (100 points):

Receiving (100 points):

DNS security (100 points):

A CAA record (Certification Authority Authorization) declares which certificate authorities are allowed to issue a certificate for your domain. Without one, any authority can sign a certificate for captaindns.com. The value 0 issue ";" shuts the door on all issuance, and the iodef tag opens a channel to report attempts to you.

Common errors detected by the audit

Four problems turn up in the vast majority of failed audits. Here is how to spot them and fix them.

SPF: too many DNS lookups (permerror)

SPF tolerates at most 10 DNS lookups. One include: too many and the whole thing breaks: the resolver returns permerror and simply ignores your policy. The telltale symptom is a sinking SPF score even though the record clearly exists. The audit recounts your lookups, spots nested include: directives (often 12 or more), and points to the overage. The way out: swap include: directives for IP ranges, or do the job in one click with our SPF Flattener.

DKIM: selector not found

Each sending platform has its own DKIM selector. Until it's published in your zone, the signature fails on every message, no exceptions. You think DKIM is set up, the audit shows an NXDOMAIN on k1._domainkey.captaindns.com: the key doesn't exist on the DNS side. Get the right selector from your sending provider and publish the matching TXT record.

DMARC: policy too permissive

A p=none policy protects against nothing. It observes, it doesn't block: mailbox providers let unauthenticated emails sent in your name through. The audit flags it as soon as it reads p=none, especially when the rua reports are missing too. The steps to follow: tighten in stages, p=quarantine then p=reject, while keeping an eye on the DMARC reports so you don't block any legitimate send.

MX: missing or invalid record

No MX, no inbound mail. A domain without an MX record receives no email, and some filters even judge it illegitimate for sending. When the audit returns an MX score of zero, it means no record was found. Publish at least one valid MX. If the domain isn't meant to receive mail, declare a null MX (0 .): that's an explicit stance, not an error.

Action plan to improve your security and deliverability

Tackle the work in order of impact. The two tables below rank the fixes for sending, then receiving, from the most critical to the optional.

Sending:

Receiving:

Tip: re-run the audit at the moments that matter, before a campaign, after a provider change, on every DNS edit. That's how you catch problems before they penalize your sends or expose your domain.

Real-world use cases

Issue 1: Marketing campaign with 80% in spam

Symptom: You send a newsletter via Mailchimp, but most of it lands in spam.

Audit diagnosis:

• MX = ✅ Pass
• SPF = ❌ Fail → 14 lookups (limit exceeded)
• DKIM = ❌ Fail → Selector k1 not found
• DMARC = ⚠️ p=none

Priority actions:

1. Flatten SPF to get under 10 lookups
2. Publish Mailchimp's DKIM CNAME
3. Move DMARC to p=quarantine

Issue 2: B2B emails rejected by Microsoft 365

Symptom: Your business emails are rejected by clients using Outlook/Microsoft 365.

Audit diagnosis:

• SPF = ✅ Pass
• DKIM = ✅ Pass
• DMARC = ❌ Fail → p=reject policy but alignment failed

Priority actions:

1. Verify that the From domain matches the DKIM domain (strict alignment)
2. Configure aspf=r and adkim=r for relaxed alignment

Issue 3: migration to Google Workspace

Symptom: After migrating to Google Workspace, emails land in spam.

Audit diagnosis:

• SPF = ⚠️ Warning → include:_spf.google.com missing
• DKIM = ❌ Fail → Selector google not published

Priority actions:

1. Add include:_spf.google.com to your SPF
2. Generate and publish the DKIM key from the Admin Console

FAQ - Frequently asked questions

Q: What exactly does this email audit check?

A: Nine protocols spread across three pillars. On the sending side, the audit inspects SPF (authorized servers), DKIM (cryptographic signature), DMARC (authentication policy), and BIMI (brand logo). On the receiving side, it covers MX (inbound servers), MTA-STS (forced TLS encryption), DANE (certificate authentication via DNSSEC), and TLS-RPT (TLS failure reports). The DNS security pillar handles DNSSEC (zone signing) and CAA (authorized certificate authorities).

Q: How does the score out of 100 work?

A: Three weighted pillars combine: sending (50%) gathers DMARC (40 pts), SPF (30 pts), DKIM (25 pts), and BIMI (5 pts); receiving (35%) adds MX (40 pts), MTA-STS (30 pts), DANE (15 pts), and TLS-RPT (15 pts); DNS security (15%) splits DNSSEC (80 pts) and CAA (20 pts). Each pillar is scored out of 100, then folded into the total by its weight. Past 90, the configuration is dialed in.

Q: Why does my SPF show "too many lookups"?

A: RFC 7208 caps SPF at 10 DNS lookups. Every include:, a:, mx:, or redirect= eats one. Stack Mailchimp, Brevo, and Google, and the count climbs fast. To get back under the line, our SPF Flattener converts your includes into direct IP addresses.

Q: How do I add a DKIM selector?

A: The selector changes from one provider to the next: k1 for Mailchimp, mail for Brevo, google for Google Workspace, selector1 and selector2 for Microsoft 365. Enter it in the audit form, and the tool confirms it's actually published in your zone.

Q: What DMARC policy should I use?

A: Move up in stages. You start at p=none to observe without blocking anything, switch to p=quarantine to send suspicious messages to spam, then lock it down with p=reject to reject everything that isn't authenticated. At each step, keep the rua reports running: they're what stops you from blocking a legitimate send.

Q: Is the audit free?

A: Yes, free and no registration. You enter your domain, the results appear.

Q: Is my data stored?

A: No. The audit only queries public DNS records, the kind anyone can pull with a standard DNS query. Nothing is kept on our end.

Complementary tools

Useful resources

• RFC 7208 - SPF (official SPF specification)
• RFC 6376 - DKIM (official DKIM specification)
• RFC 7489 - DMARC (official DMARC specification)
• RFC 8461 - MTA-STS (SMTP MTA Strict Transport Security)
• RFC 8460 - TLS-RPT (SMTP TLS Reporting)
• RFC 6698 - DANE (DNS-Based Authentication of Named Entities)
• Google - Email Authentication (Gmail guide)
• Microsoft - Email Authentication (Microsoft 365 guide)