How to Test Email Deliverability Before You Send

To test email deliverability before you send, you must verify the chain of authentication records, inspect the message headers after a test send, and check the receiving server’s response. The goal is to confirm that your mail passes SPF, DKIM, and DMARC, and that the remote server accepts the message without complaint. The practical method is to send a real message to an address you control, then examine every step from the envelope to the final header.

Why the protocol matters for email deliverability

Email deliverability is not a binary state. A message can be accepted by the remote server, then silently filed into spam, or rejected outright during the SMTP conversation. The difference often comes down to authentication records. SPF (Sender Policy Framework) declares which IP addresses are allowed to send for your domain. DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to each message, proving the body and key headers were not altered. DMARC (Domain-based Message Authentication, Reporting, and Conformance) tells the receiver what to do if SPF or DKIM fails. Without all three aligned, many receiving servers will treat your mail as suspicious. You can test each record yourself using command line tools before you ever send a single message.

Check your DNS records first

Start with the records themselves. Use dig to query SPF, DKIM, and DMARC. For SPF, look for a TXT record on your domain. For DKIM, you need the selector your mail server uses, often something like default or mail. For DMARC, the record lives at _dmarc.yourdomain.com. Run these commands and inspect the output carefully.

dig TXT yourdomain.com
dig TXT default._domainkey.yourdomain.com
dig TXT _dmarc.yourdomain.com

The SPF record should list your sending IPs or include a third party mail service’s include mechanism. The DKIM record should contain a p= tag with a long base64 string. The DMARC record should have v=DMARC1 and a policy tag such as p=none, p=quarantine, or p=reject. If any of these return empty, or if the SPF record contains +all, fix the DNS before proceeding. A misconfigured record is the most common cause of failed deliverability, and it is entirely within your control.

Send a test message and read the headers

DNS records being correct is necessary but not sufficient. The actual message must pass validation. Send a test email to an address you own, preferably on a different provider than your sending server. Then open the raw message source. In most clients, this is an option like “Show original” or “View source”. Look for the Authentication-Results header. This header is added by the receiving server and tells you exactly what passed and what failed. It will look something like this:

Authentication-Results: mx.example.net;
       spf=pass (sender IP is 192.0.2.10) [email protected];
       dkim=pass header.d=yourdomain.com;
       dmarc=pass action=none

If you see spf=fail, dkim=fail, or dmarc=fail, the receiving server has told you the problem. Common causes are a mismatched envelope sender, a DKIM signature using the wrong selector, or a DMARC policy that is too strict for your current SPF alignment. The header also shows the Received chain, which reveals the path your message took. Each Received line has a with clause that shows the protocol, for example with ESMTP or with ESMTPS. If you see with SMTP and no TLS indication, some servers may penalize that, though it is not a hard rule.

Use the SMTP conversation to see rejection reasons

Headers are useful after the fact, but you can also test the SMTP handshake directly. Connect to your destination’s mail exchanger using telnet or nc and issue commands manually. This shows you the exact response codes. A 250 means the server accepted the message. A 550 means it rejected it, and the text after the code often explains why. Run this from a terminal, replacing the example domain and IP with your own.

telnet mx.example.net 25
EHLO testclient.local
MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
DATA
Subject: test
This is a test.
.
QUIT

Watch the responses. If the MAIL FROM gets a 550 with a message about policy or reputation, the server is blocking your IP or domain. If RCPT TO fails with 550, the address may be invalid or the server has a recipient policy. If everything returns 250, the message was accepted at the protocol level, but that does not guarantee inbox placement. Spam filtering happens after acceptance, which is why header inspection remains essential.

Check your sending IP reputation

Even with perfect DNS and a clean SMTP exchange, your IP address can be blacklisted. Several public DNS blocklists track known spam sources. Query them directly using dig. The format is reversed IP octets followed by the list domain. For example, to check the IP 192.0.2.10 against a common list, you would run:

dig +short 10.2.0.192.list.example.org

A response of 127.0.0.2 or similar indicates a listing. A NXDOMAIN or empty answer means the IP is not on that list. Run this against several major blocklists, but be aware that not all lists use the same return codes. Some use 127.0.0.1, others use 127.0.0.4. Read the list’s documentation to interpret the result. Also check your domain’s reputation using a lookup tool that aggregates multiple sources, but do not rely on a single query. A domain with a fresh IP and no history can still be flagged if the IP range is shared with spammers, which is common with low cost providers.

Test with a dedicated validation service

Command line tools give you raw data, but they do not simulate the full path a message takes through a spam filter. For that, use a dedicated deliverability testing service. These services send a message to a network of test mailboxes on major providers and report whether each one lands in the inbox, spam folder, or is rejected. You will need to add a special header or a unique subject line to identify the test. The service then returns a report showing SPF, DKIM, and DMARC results per provider, along with any content based filtering flags. This is the closest you can get to real world behavior without sending to actual customers.

When you run such a test, send from the exact server and domain you plan to use for production mail. Do not test from your laptop or a staging server, because the IP and reverse DNS will be different. Also send a few test messages with plain text, HTML, and a small attachment to see if any content triggers a filter. The service will show you the raw headers from each test mailbox, which is valuable for spotting provider specific quirks.

How to test email deliverability iteratively

Email deliverability is not a one time check. It changes as your sending volume, IP reputation, and content evolve. Build a repeatable routine. First, verify DNS records with dig every time you change a mail server or add a new sending service. Second, send a test message to a mailbox you control and inspect the Authentication-Results header manually. Third, run an SMTP handshake against your destination to catch immediate rejections. Fourth, query blocklists for your IP. Finally, use a validation service before any large campaign or when you switch providers. Keep a log of the results, because a gradual decline in deliverability is easier to spot when you have a baseline.

What to do next: set up a dedicated test address on a free webmail service that you do not use for anything else, and make a habit of sending a test message there after every configuration change. Also configure your mail server to add a Feedback-ID header, which some providers use to associate bounces and complaints with specific campaigns. Then, run the full sequence described above once a week, even if nothing changed. The discipline will save you from discovering a deliverability problem only after your real recipients stop seeing your mail.