Email Deliverability
The Complete Email Domain Health Checklist for Agencies (25 Checks Explained)
Every check your agency should be running on every client domain from SPF and DKIM to BIMI and DANE. Plus how to automate the whole thing.
If you manage email for clients, you already know the moment: a client forwards you a screenshot of a bounce notification or a complaint that their campaign landed in spam. They've probably been live for weeks. The problem has been sitting there the whole time.
The difference between agencies that catch these issues first and agencies that find out from clients is monitoring. Specifically, knowing which checks to run, how often to run them, and what to do when one fails.
This guide covers every check that matters all 25 why each one exists, what breaks when it's wrong, and what a fix looks like. At the end, we'll cover how to run these automatically across every client domain without it becoming a full-time job.
Why domain health monitoring is different from deliverability monitoring
Most agency tools focus on deliverability metrics: open rates, bounce rates, spam complaints. Those are outcome metrics. By the time they move, something upstream already broke.
Domain health is infrastructure monitoring. It's checking the DNS records, certificates, authentication stack, and security settings that determine whether email from a domain can even reach the inbox. A misconfigured SPF record doesn't show up in your open rate until you've sent 10,000 emails to a damaged list.
Catch it at the infrastructure layer and you stop problems before they become campaigns.
The 25 checks every agency should run
Authentication stack
1. SPF (Sender Policy Framework)
SPF is a DNS TXT record that lists every server authorized to send email on behalf of a domain. Receiving mail servers check it on every inbound email.
What breaks without it: email lands in spam or gets rejected outright. Most major mailbox providers treat a missing SPF record as a strong spam signal.
What a fix looks like: v=spf1 include:_spf.google.com include:sendgrid.net ~all
2. DKIM (DomainKeys Identified Mail)
DKIM adds a cryptographic signature to outbound email that receiving servers verify against a public key published in DNS. It proves the email wasn't modified in transit and that it genuinely came from an authorized sender.
What breaks without it: emails fail authentication checks. Combined with a missing SPF record, this almost guarantees spam folder placement.
What a fix looks like: publish the public key your ESP provides as a TXT record at selector._domainkey.yourdomain.com
3. DMARC (Domain-based Message Authentication, Reporting and Conformance)
DMARC tells receiving servers what to do when SPF or DKIM fails: nothing (p=none), send to spam (p=quarantine), or reject outright (p=reject). It also routes aggregate reports back to you so you can see who's sending email from your domain.
What breaks without it: you're blind to spoofing attempts and have no enforcement. Google and Yahoo now require a DMARC record for bulk senders.
What a fix looks like: v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=100
4. DMARC Alignment
DMARC alignment checks whether the domain in the From header matches the domain used for SPF or DKIM authentication. A passing SPF check on a different domain doesn't satisfy DMARC alignment.
What breaks without it: DMARC passes technically but misaligned authentication means you're not actually protected against spoofing.
5. Subdomain DMARC
A DMARC policy on the root domain doesn't automatically protect subdomains. sp=reject in your root DMARC record extends protection to subdomains, but many organizations skip this.
What breaks without it: attackers can send spoofed email from mail.yourdomain.com or noreply.yourdomain.com even if your root domain is protected.
6. SPF Enforcement
SPF has three enforcement levels: ~all (softfail treat as suspicious), -all (hardfail reject), and ?all (neutral do nothing). Many domains are stuck on ~all for years.
What breaks without it: softfail means receiving servers can still deliver forged email. For most domains, -all is the right answer once your sending sources are correctly listed.
7. DMARC Coverage
This checks whether your DMARC pct tag is set to 100, meaning the policy applies to all email, not just a sample. Many organizations set pct=10 during rollout and forget to raise it.
8. SPF Record Length
SPF records have a limit: no more than 10 DNS lookups. Every include: statement counts toward this limit. Exceed it and your SPF record is technically invalid receiving servers may treat it as a fail.
What breaks without it: complex sending setups with multiple ESPs, transactional email providers, and marketing platforms often exceed this limit without anyone noticing.
Infrastructure
9. MX Records
MX records tell other mail servers where to deliver incoming email. Missing or misconfigured MX records mean your domain can't receive email.
What breaks without it: bounced inbound email. Also a signal to spam filters that the domain isn't properly configured for email.
10. PTR / Reverse DNS
A PTR record maps an IP address back to a hostname. When your sending server has an IP of 203.0.113.1, the PTR record should resolve to a hostname that matches the domain it's sending from.
What breaks without it: many enterprise mail servers reject email from IPs without a valid PTR record. This is especially common when clients use shared hosting or custom SMTP configurations.
11. Null MX
If a domain doesn't send or receive email, it should have a Null MX record (MX 0 .) to explicitly signal this. Without it, mail servers attempting delivery waste time on connection attempts.
What breaks without it: unnecessary delivery attempts, potential for mail loops, and missing spoofing protection on non-email domains.
Security
12. DNSSEC
DNSSEC adds cryptographic signatures to DNS records, preventing attackers from intercepting DNS queries and redirecting traffic. Without it, DNS responses can be forged.
What breaks without it: DNS spoofing attacks can redirect your domain's email to an attacker's server without anyone knowing.
13. CAA Records
CAA (Certification Authority Authorization) records specify which certificate authorities are allowed to issue SSL certificates for your domain. Without them, any CA can issue a certificate for your domain.
What breaks without it: an attacker who can complete a domain validation check (sometimes easier than it sounds) can obtain a legitimate SSL certificate for your domain.
14. DANE/TLSA
DANE (DNS-based Authentication of Named Entities) uses DNSSEC to pin a specific certificate or CA to a domain's mail server. It's the strongest available protection against man-in-the-middle attacks on email in transit.
What breaks without it: email in transit is vulnerable to interception even when TLS is used, because TLS certificates aren't verified against DNS without DANE.
15. Registrar Lock
Domain registrar lock prevents unauthorized domain transfers. An unlocked domain can be transferred to a different registrar by anyone who can access the registrar account or by social engineering the registrar's support team.
What breaks without it: domain hijacking. This is rare but catastrophic when it happens. Locked domains require explicit unlock steps before any transfer can proceed.
16. Nameserver Change Detection
If your domain's nameservers change without your knowledge, all DNS records including your email authentication records could be pointing somewhere else entirely.
What breaks without it: complete loss of email deliverability, potential traffic interception. Nameserver changes are one of the first signs of domain hijacking.
17. Subdomain Lockdown
Open subdomains that don't send email are targets for spoofing. If newsletter.yourdomain.com has no SPF or DMARC policy, attackers can use it to send email that appears to come from your client.
Certificate and domain health
18. SSL Certificate
An expired SSL certificate breaks HTTPS and, for mail servers, breaks encrypted email delivery. It also affects DKIM verification for some configurations.
What breaks without it: browsers show security warnings, HTTPS traffic fails, and email delivery may be impacted for servers that require valid TLS.
19. WHOIS / Domain Age
Domain age is a deliverability signal. Newly registered domains (under 30 days) have no sending reputation and are treated with suspicion by spam filters. This check flags domains approaching expiry and very new domains.
What breaks without it: sending campaigns from a brand-new domain or from a domain about to expire.
Advanced authentication
20. MTA-STS
MTA-STS (Mail Transfer Agent Strict Transport Security) tells sending mail servers to only deliver email to your domain over encrypted connections, and to reject delivery if a valid certificate isn't present.
What breaks without it: email delivered to your domain can be downgraded to unencrypted connections, making it readable in transit.
21. TLS-RPT
TLS-RPT (TLS Reporting) is the reporting companion to MTA-STS. It instructs sending servers to send reports when they encounter TLS issues delivering to your domain, so you can detect and fix problems.
22. BIMI (Brand Indicators for Message Identification)
BIMI displays your client's logo next to their email in supporting inboxes currently Gmail, Yahoo Mail, and Apple Mail. It requires a verified DMARC policy at p=quarantine or p=reject and a Verified Mark Certificate (VMC) from an approved authority.
What breaks without it: no logo in inbox. This check flags missing or misconfigured BIMI records and checks whether the linked SVG logo is accessible.
23. DKIM Key Strength
DKIM keys should be at least 2048 bits. Older 1024-bit keys are considered weak and can be factored by sophisticated attackers. Some legacy ESPs still generate 1024-bit keys by default.
What breaks without it: weak DKIM keys are a security risk. Google and other providers have deprecated 1024-bit keys.
24. Google Bulk Sender Compliance
Google introduced bulk sender requirements in 2024: domains sending more than 5,000 emails per day to Gmail addresses must have SPF, DKIM, and DMARC configured correctly, must have easy unsubscribe, and must keep spam complaint rates below 0.3%. This check verifies your domain meets those requirements.
25. Subdomain DMARC (sp= tag)
Covered above under authentication, but worth repeating: this is one of the most commonly missed configurations. The sp= tag in your root DMARC record controls policy for all subdomains. Without it, subdomains inherit the root policy only on some mail servers behavior varies by provider.
What to do when a check fails
Not every failure is equal. A missing BIMI record won't tank deliverability. A missing SPF record on an active sending domain will.
Here's a rough triage priority:
Immediate action required
- Missing or broken SPF on an active sending domain
- DMARC at
p=noneon a domain sending bulk email - SSL certificate expired or expiring within 7 days
- Domain on a major blacklist
- Nameserver change detected
Fix within the week
- SPF enforcement at
~allinstead of-all - DKIM key strength below 2048 bits
- Missing PTR record on a sending IP
- SPF record exceeding 10 DNS lookups
- DMARC
pctbelow 100
Fix when you can
- Missing MTA-STS or TLS-RPT
- Missing CAA records
- BIMI not configured
- Missing Null MX on non-sending domains
The problem with running these manually
If you're managing five client domains, a manual checklist is manageable. At 20 domains it starts to slip. At 50 it's impossible to maintain consistently.
The checks that matter most blacklist status, SSL expiry, nameserver changes need to be running continuously. A domain can get blacklisted between your Monday morning audit and Tuesday's campaign send.
This is the problem Infraova was built to solve. It runs all 25 checks on every domain in your portfolio, every hour, and sends alerts the moment something changes. When a client's DMARC policy gets misconfigured, you know before they do. When a domain hits a blacklist, you know before the campaign goes out.
Every week, it generates a PDF report with everything above domain scores, issue breakdown, fix recommendations, 30-day trends, and a client-facing summary your clients can actually read. The kind of report a deliverability consultant would charge $500 to produce. Infraova generates it automatically.
If you're managing client domains and running these checks manually today, it's worth seeing what continuous monitoring looks like in practice.
Summary checklist
| Check | Category | Priority | |---|---|---| | SPF | Authentication | Critical | | DKIM | Authentication | Critical | | DMARC | Authentication | Critical | | DMARC Alignment | Authentication | High | | Subdomain DMARC | Authentication | High | | SPF Enforcement | Authentication | High | | DMARC Coverage | Authentication | Medium | | SPF Record Length | Authentication | High | | MX Records | Infrastructure | Critical | | PTR / Reverse DNS | Infrastructure | High | | Null MX | Infrastructure | Low | | DNSSEC | Security | Medium | | CAA Records | Security | Medium | | DANE/TLSA | Security | Medium | | Registrar Lock | Security | High | | Nameserver Change | Security | Critical | | Subdomain Lockdown | Security | High | | SSL Certificate | Certificate | Critical | | WHOIS / Domain Age | Certificate | Medium | | MTA-STS | Advanced | Medium | | TLS-RPT | Advanced | Low | | BIMI | Advanced | Low | | DKIM Key Strength | Security | High | | Google Bulk Sender | Compliance | High | | Subdomain DMARC (sp=) | Authentication | High |
Run these checks. Run them every hour. Know before your clients do.