How to Test Whether Your Domain Email Setup Actually Sends

To test email deliverability on your own domain you have to send a real message from that domain to a mailbox you control at a large provider, then read the headers that come back. Nothing else tells you the truth, because a local mail log only shows that your server handed the message off, not that the receiving side accepted it into the inbox.

The distinction matters because there are two separate events. Your server can accept a message for delivery, queue it, and report success to your application, while the receiving provider quietly files it as spam or rejects it after the fact. Only the receiving side knows what happened, and the only way to see its decision is to look at the message as it arrived.

Send from the domain, not to it

The most common mistake is testing the wrong direction. Pointing a tool at your own mailbox and checking that mail arrives from somewhere else proves nothing about your domain. You need a mailbox at a major provider that you can log into, and you need to originate the message from an address at your own domain.

Start with a plain text message and no attachments. Attachments add parsing and filtering variables you do not want in the first test. Send the same message to several providers, because they do not share filtering logic and a setup that passes one can fail another.

If you have shell access on the host that runs your mail, you can inject a message directly and watch the SMTP conversation. This bypasses your application and tells you whether the problem is in the sending stack or in the code that calls it.

swaks --to [email protected] \
      --from [email protected] \
      --server mail.yourdomain.com \
      --header "Subject: deliverability test" \
      --body "plain text only"

The output is a transcript of the SMTP dialogue. You want to see the receiving server answer the final dot with a 250 and a queue identifier. A 4xx is a temporary failure and the message will be retried. A 5xx is permanent and the message is gone. If you get a 5xx at the RCPT TO stage, the problem is reputation or policy, not content.

Read the headers, not the folder

Where the message landed is a weak signal. Spam folders are heuristic and users move things around. The headers are the record of what the receiving server actually concluded, and they survive forwarding and filing.

In most clients you can view the raw source of a message. Look for the Authentication-Results header that the receiving provider added at the top of the trace. It is one line and it summarises the whole verdict.

Authentication-Results: mx.example-provider.com;
       spf=pass smtp.mailfrom=yourdomain.com;
       dkim=pass header.d=yourdomain.com;
       dmarc=pass header.from=yourdomain.com

Three results, three questions answered. spf=pass means the sending IP was authorised by your domain's SPF record. dkim=pass means the signature your server applied survived the trip and validated against the public key in your DNS. dmarc=pass means at least one of those aligned with the domain in the visible From header, which is the part users actually see.

If dkim shows fail or none, the signature is broken or missing. A very common cause is a relay or mailing list that rewrote the subject line or appended a footer after signing. Another is a key rotated in the sending software but not published in DNS. If spf shows softfail or fail, the message left through an IP that your SPF record does not list, which usually means an application is sending through a different host than you think.

The Received headers below the authentication results show the path the message took. Read them bottom to top, since each server prepends its own line. You are looking for unexpected hops, long delays between hops, and any server that is not one you recognise. A message that sat in a queue for an hour before delivery will often be filtered on that alone, because providers treat slow, irregular sending as a spam signal.

Check the DNS records the test depends on

Before you blame the receiving provider, confirm what your own DNS actually publishes. Query it directly rather than trusting a control panel display, because panels cache and sometimes show a record that is not live.

dig +short TXT yourdomain.com
dig +short TXT selector._domainkey.yourdomain.com
dig +short TXT _dmarc.yourdomain.com

The first should return your SPF record as a single string beginning v=spf1. Watch for multiple SPF records on the same name, which is invalid and causes a permanent error at many receivers. The second returns the DKIM public key, and the selector in the query must match the selector your sending software uses, since a mismatch produces a silent dkim=none. The third returns your DMARC policy. If that query returns nothing, you have no DMARC record and you are relying entirely on SPF and DKIM alignment being judged on their own.

Also confirm that the hostname your sending IP resolves back to matches the name that IP announces. Forward confirmed reverse DNS is a basic requirement at most large providers now, and a mismatch produces rejections that look like reputation problems but are not.

Interpret the result honestly

A single message to a single mailbox is an anecdote. Providers weight behaviour over time, so a brand new domain or a new sending IP will be treated with suspicion regardless of how correct the records are. If your first test lands in spam with all three authentication results passing, the likely cause is sending history, not configuration, and the answer is to send consistently and let recipients engage.

Run the test to several providers at once and record the authentication results for each. If one provider passes and another fails, compare the failing provider's Received chain and its authentication line against the passing one. The difference usually points at a specific record or a specific hop rather than at your whole setup.

Repeat the test after any change to your sending infrastructure, and keep a copy of the headers from a known good run. When something breaks later, a diff against that baseline tells you which header changed and therefore which component moved.

Next, set up a mailbox at two or three large providers that you check on a schedule, and send a test message from your domain to all of them whenever you change DNS, rotate a DKIM key, or move a sending host. Read the authentication results every time rather than just looking at the inbox. That habit catches most delivery problems while they are still cheap to fix.