Email Deliverability Checklist: MX, SPF, DKIM, and DMARC

Why Email Deliverability Matters

Email deliverability is the measure of how reliably messages sent from your domain reach recipients' inboxes rather than their spam folders — or fail to arrive at all. It is not simply a technical concern. Every transactional notification, sales outreach, invoice, and support reply depends on it. When deliverability breaks down, business operations slow, revenue is lost, and customer relationships erode.

The good news is that the vast majority of deliverability problems are preventable through correct configuration of four DNS-based systems: MX records, SPF, DKIM, and DMARC. This checklist walks through each one so you can verify your setup is solid, identify gaps, and know exactly what to fix.

Step 1 — MX Records

MX records tell the internet which servers accept inbound email for your domain. Without them, nobody can send to your domain. Even if you only send and never receive email from a domain, you should have MX records configured — or an explicit null MX record (0 .) to signal that the domain does not accept mail, which prevents bounce-handling confusion.

Check the following for each of your domains:

• At least one MX record exists and points to a valid, resolvable hostname.
• The MX record target is an A record, not a CNAME (a CNAME as MX target violates RFC 2181 and causes unpredictable failures).
• If multiple MX records exist, they have different priority values to control failover order.
• MX record TTL is set to a reasonable value — 3600 seconds (1 hour) is a common default that allows for timely propagation during changes without excessive DNS traffic.

Use the DMARCFlow MX Checker to verify your MX records with a live DNS lookup and flag any of the above problems automatically.

Step 2 — SPF Record

SPF (Sender Policy Framework) is a TXT record in your DNS that lists every IP address and service authorized to send email on behalf of your domain. When a receiving server gets a message claiming to be from your domain, it checks your SPF record to verify the sending IP is on the approved list. If it is not, the message fails SPF.

SPF checklist:

• Exactly one SPF record exists as a TXT record at your domain root (having two or more SPF records causes a permanent error — permerror).
• All email-sending services for this domain are included — your mail server, your marketing platform, your CRM, your transactional email provider, and any other service that sends mail with your From address.
• The record stays within the 10 DNS lookup limit. Each include:, a, mx, and ptr mechanism counts toward this limit. Exceeding 10 lookups causes a permerror that fails SPF for all recipients.
• The record ends with either ~all (softfail — treat unlisted senders as suspicious but deliver) or -all (fail — reject unlisted senders). Use -all once you are confident your record is complete; it provides stronger protection against spoofing.

A minimal example for a domain that sends only through Google Workspace:

v=spf1 include:_spf.google.com -all

Step 3 — DKIM Signing

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outgoing message. The receiving server retrieves your public key from DNS and uses it to verify the signature. A valid signature proves the message was sent by an authorized party and that the content was not modified in transit.

DKIM checklist:

• DKIM signing is enabled in your mail platform (Google Workspace, Microsoft 365, your transactional email service, etc.). Most providers offer a one-click enable option in their admin console.
• You are using a 2048-bit key. 1024-bit keys are considered weak and some major receiving systems now distrust signatures using them.
• The DNS TXT record for your DKIM selector exists and contains the correct public key. The selector is specified in the s= tag of the DKIM-Signature header in your outgoing mail, and the record lives at [selector]._domainkey.yourdomain.com.
• For each sending service that supports DKIM, a separate DKIM key and selector is configured and verified. Do not share a single DKIM key across multiple unrelated sending systems.

Step 4 — DMARC Policy

DMARC (Domain-based Message Authentication, Reporting & Conformance) ties SPF and DKIM together and tells receiving servers what to do when a message fails authentication. It also generates reports so you can see who is sending mail on behalf of your domain.

DMARC checklist:

• A DMARC record exists as a TXT record at _dmarc.yourdomain.com.
• The rua= tag points to an email address (or a service like DMARCFlow) that will receive aggregate XML reports. These reports are essential for understanding your sending landscape and moving through policy stages safely.
• You have progressed through the policy stages in order: start with p=none (monitoring only, no enforcement), move to p=quarantine (send failing messages to spam), and finally advance to p=reject (block failing messages outright) once reports confirm that all your legitimate mail is passing authentication.
• A p=reject policy provides the strongest protection against email spoofing and is required for BIMI logo display by some inbox providers.

A basic DMARC record to start monitoring:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

Step 5 — Blacklist Check

Even a perfectly configured domain can end up on a blacklist due to a compromised account, a data breach, or a neighbor on a shared IP behaving badly. Being listed on a major DNSBL can route your mail directly to spam folders or cause outright rejection — silently undermining all the authentication work you have done.

Check your sending domain and your outbound IP addresses against major blacklists regularly using the DMARCFlow Blacklist Checker. If you find a listing, investigate the root cause, resolve it, then request removal from each list that shows a hit.

Run All Checks at Once

Working through MX, SPF, DKIM, DMARC, and blacklist checks one tool at a time is time-consuming. The DMARCFlow Email Deliverability Checker consolidates all of these checks into a single lookup. Enter your domain and your sending IP, and get a comprehensive pass/fail report covering every layer of your deliverability stack — with specific, actionable guidance for any issues found.

This is particularly useful when onboarding a new domain, migrating to a new mail provider, or doing a periodic health check to catch configuration drift before it affects users.

Maintaining Deliverability Over Time

A healthy deliverability configuration is not a one-time task — it requires ongoing attention as your infrastructure and sending patterns evolve:

• Rotate DKIM keys annually. Generate a new 2048-bit key pair, publish the new public key to DNS under a new selector, switch your mail platform to sign with the new key, then remove the old selector from DNS after a few days to allow in-transit messages signed with the old key to be delivered.
• Update SPF when adding new sending services. Every time you connect a new marketing tool, CRM, or automation platform, check whether it sends email with your domain in the From header. If it does, add its SPF include mechanism to your record before enabling it. Missing even one service creates SPF failures for those messages.
• Monitor DMARC reports. Aggregate reports reveal new sending sources, forwarding configurations that are breaking alignment, and spoofing attempts. DMARCFlow parses and visualizes these XML reports automatically, making it practical to review them on a weekly basis rather than trying to interpret raw XML files.
• Check blacklist status after any incident. If you experience a security incident, a sudden spike in bounce rates, or a report of spam complaints, run a blacklist check immediately to determine whether any listings have occurred as a result.