You have spent hours crafting the perfect email — a welcome message, an invoice, a password reset, or a marketing campaign. You hit send, and it vanishes into the void. No bounce, no error, no delivery. It just lands in spam, or worse, never arrives at all. Email deliverability is a complex system of authentication records, IP reputation, content analysis, and sending practices. When any piece fails, your emails go to spam.
This guide walks you through every aspect of email deliverability, from DNS authentication records to content optimization, with exact commands to diagnose and fix each issue. By the end, you will have a systematic checklist for ensuring your emails reach the inbox.
How Email Authentication Works
Modern email relies on three authentication systems that work together to verify the legitimacy of a message. Understanding how these three protocols interact is essential before you can fix deliverability issues.
Who can send
Message integrity
Policy & reporting
| Protocol | What It Does | DNS Record Type |
|---|---|---|
| SPF | Lists which IP addresses are authorized to send email for your domain | TXT record on root domain |
| DKIM | Adds a cryptographic signature to each email to prove it was not tampered with | TXT record on selector._domainkey subdomain |
| DMARC | Tells receiving servers what to do when SPF or DKIM fails, and where to send reports | TXT record on _dmarc subdomain |
Step 1: Check Your PTR Record (Reverse DNS)
The PTR record maps your server's IP address back to a hostname. This is the first thing receiving mail servers check. If your sending IP does not have a valid PTR record, many servers will reject the email outright.
$ dig -x 203.0.113.10 +short
mail.example.com.
# Verify the forward DNS matches
$ dig mail.example.com A +short
203.0.113.10
# Both should match! (Forward-confirmed reverse DNS)
If you see the bounce message "The IP address sending this message does not have a PTR record setup," your server lacks a PTR record. Contact your hosting provider or VPS provider to set it. PTR records are managed by the IP address owner, not your DNS provider. Point the PTR to a hostname like
mail.yourdomain.com, and make sure that hostname resolves back to the same IP.
Step 2: Verify SPF Record
SPF (Sender Policy Framework) is a DNS TXT record that lists which servers are authorized to send email for your domain. Without SPF, any server in the world can claim to send email from your domain.
$ dig example.com TXT +short | grep spf
"v=spf1 ip4:203.0.113.10 include:_spf.google.com -all"
Understanding SPF Syntax
| Mechanism | Purpose | Example |
|---|---|---|
ip4: | Authorize a specific IPv4 address or range | ip4:203.0.113.10 |
ip6: | Authorize a specific IPv6 address or range | ip6:2001:db8::/32 |
include: | Include another domain's SPF record | include:_spf.google.com |
a | Authorize the domain's A record IP | a |
mx | Authorize the domain's MX record IPs | mx |
-all | Hard fail — reject all non-matching senders | Recommended |
~all | Soft fail — accept but mark suspicious | Acceptable |
?all | Neutral — no policy | Useless |
SPF records are limited to 10 DNS lookups. Each
include:, a, mx, and redirect mechanism counts as a lookup. Exceeding 10 lookups causes a permanent SPF error (PermError), and many receivers treat this as a failure. If you use multiple email services (Google Workspace, Mailchimp, SendGrid, etc.), you can easily exceed this limit. Use tools like mxtoolbox.com/spf.aspx to count your lookups.
Google now requires bulk senders (5,000+ messages/day) to use
-all (hard fail) in their SPF records. The lenient ~all soft fail is no longer sufficient for full deliverability. If you send any volume of email, switch to -all.
Step 3: Verify DKIM Signing
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outgoing email. The receiving server uses your public key (published in DNS) to verify the signature, confirming the email was not modified in transit and was sent by an authorized server.
$ dig default._domainkey.example.com TXT +short
"v=DKIM1; h=sha256; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAO..."
# If you don't know your selector, check email headers:
# Look for: DKIM-Signature: ... s=selector; d=example.com
How to Find DKIM Issues in Email Headers
When you receive a bounced email or want to check DKIM for a sent message, look at the email headers. In Gmail, click the three dots on a message and select "Show original."
Authentication-Results: mx.google.com;
dkim=pass [email protected] header.s=default;
spf=pass (google.com: 203.0.113.10 is permitted by SPF);
dmarc=pass (p=QUARANTINE) header.from=example.com
# Failed DKIM (message was modified or key mismatch)
Authentication-Results: mx.google.com;
dkim=fail (body hash did not verify);
Body hash mismatch — a mailing list or forwarding service modified the message body after signing. Use
relaxed/relaxed canonicalization to tolerate minor modifications. Key not found — the DKIM DNS record is missing or not propagated. Signature expired — the signature has a timestamp and validity period that has passed. Wrong selector — the DNS record uses a different selector than the one in the signature.
Step 4: Verify DMARC Policy
DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together and tells receiving servers what to do when authentication fails.
$ dig _dmarc.example.com TXT +short
"v=DMARC1; p=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1"
| Tag | Purpose | Recommended Value |
|---|---|---|
p= | Policy for failing messages | quarantine or reject |
rua= | Aggregate report destination | mailto:[email protected] |
ruf= | Forensic report destination | mailto:[email protected] |
fo= | When to send forensic reports | 1 (on any failure) |
pct= | Percentage of messages to apply policy | 100 (default) |
adkim= | DKIM alignment mode | r (relaxed) |
aspf= | SPF alignment mode | r (relaxed) |
Start with
p=none to collect reports without affecting delivery. After analyzing reports for 2-4 weeks, move to p=quarantine (spam folder). Once confident, upgrade to p=reject (block completely). Never jump straight to reject without monitoring — you might block legitimate email from third-party services that send on your behalf.
Step 5: Check Blacklist Status
If your server IP address is listed on email blacklists (also called blocklists or DNSBLs), your emails will be rejected or sent to spam regardless of your authentication setup.
$ dig +short 10.113.0.203.zen.spamhaus.org A
(no output = not listed)
# If listed, you'll see something like:
127.0.0.2 (SBL - Spamhaus Block List)
127.0.0.4 (XBL - Exploits Block List)
127.0.0.10 (PBL - Policy Block List)
For comprehensive checking, use online tools that query multiple blacklists simultaneously:
MXToolbox Blacklist Check
Checks 100+ blacklists at once. Visit mxtoolbox.com/blacklists.aspx and enter your server IP.
Spamhaus Lookup
The most influential blacklist. Visit check.spamhaus.org — being listed here is the most damaging to your reputation.
Each blacklist has its own delisting procedure. Spamhaus usually deactivates listings automatically after the abuse stops. Other lists require manual delisting requests. Before requesting delisting, identify and fix the cause — if the issue persists, you will be relisted and future requests may be denied.
Step 6: IP Reputation and Warm-Up
If you are sending from a new IP address, email providers are inherently suspicious. A new IP with no sending history has zero reputation, and sending a large volume immediately looks like spam behavior.
Week 1: Seed Phase
Send 50-100 emails per day to your most engaged recipients — people who will open and interact with your emails. This establishes positive signals.
Week 2-3: Ramp Up
Double your volume every 2-3 days. Monitor bounce rates and spam complaints. If either exceeds 2%, slow down.
Week 4+: Full Volume
Gradually reach your target sending volume. Continue monitoring deliverability metrics.
| Day | Recommended Volume | Notes |
|---|---|---|
| 1-3 | 50-100 emails | Send to known, active recipients only |
| 4-7 | 200-500 emails | Monitor opens, clicks, bounces |
| 8-14 | 500-2,000 emails | Gradually include broader audience |
| 15-21 | 2,000-10,000 emails | Continue monitoring spam complaint rate |
| 22-30 | Target volume | Full sending capacity reached |
Step 7: Content Analysis
Even with perfect authentication, your email content can trigger spam filters. Content-based filtering analyzes the text, HTML structure, and formatting of your emails.
Common Content Triggers
Avoid These
- ALL CAPS in subject lines or body
- Excessive exclamation marks!!!
- Spam trigger phrases: "Act now", "Limited time", "Free money", "Click here"
- Image-only emails with no text
- Too many links (especially shortened URLs)
- Mismatched From address and Reply-To
- Missing unsubscribe link (for marketing)
- HTML-only with no text/plain alternative
Best Practices
- Maintain a good text-to-HTML ratio (60:40 minimum)
- Include a clear unsubscribe mechanism
- Use a recognizable From name
- Send both HTML and plain text versions
- Personalize when possible (reduces spam signals)
- Keep image sizes reasonable (under 1 MB total)
- Use full URLs instead of URL shorteners
- Include your physical address (CAN-SPAM requirement)
Step 8: Test Your Configuration
Before sending to real recipients, use testing tools to evaluate your full email setup.
mail-tester.com
Send a test email to the provided address and get a score out of 10. Checks SPF, DKIM, DMARC, blacklists, content, and formatting. Aim for a score of 9 or above.
Gmail Postmaster Tools
Free tool from Google that shows your domain's reputation, spam rate, authentication rates, and delivery errors. Requires domain verification and sufficient volume to show data.
MXToolbox Deliverability
Comprehensive suite that checks your DNS records, blacklist status, and mail server configuration in one pass.
Command-Line Testing
Send a test email and check the raw headers for authentication results. The Authentication-Results header shows SPF, DKIM, and DMARC pass/fail status.
$ echo "This is a test email." | mail -s "Test from server" [email protected]
# Check mail queue for stuck messages
$ mailq
Mail queue is empty
# Check mail logs for delivery status
$ tail -20 /var/log/mail.log
Mar 17 10:30:01 server postfix/smtp[1234]: ABC123: to=<[email protected]>,
relay=gmail-smtp-in.l.google.com[142.250.x.x]:25,
status=sent (250 2.0.0 OK)
Complete Deliverability Checklist
- PTR record exists and matches the forward DNS of your mail hostname
- SPF record published with all sending IPs and
-allat the end - SPF record has 10 or fewer DNS lookups
- DKIM signing is active with 2048-bit RSA key (minimum)
- DKIM public key is published in DNS and matches the private key
- DMARC record is published with at least
p=quarantine - DMARC reporting addresses (
ruaandruf) are configured - Server IP is not on any major blacklists
- Email content passes spam filter checks (mail-tester.com score 9+)
- Both HTML and plain-text parts are included in multipart emails
- Unsubscribe link is present in marketing emails
- Bounce handling is configured to remove invalid addresses
- New IP has been properly warmed up before high-volume sending
- TLS is enabled for outbound connections (
smtp_tls_security_level=may)
Automated DNS Authentication with Panelica
Configuring SPF, DKIM, and DMARC records correctly requires understanding both the DNS and mail server sides of the equation. Getting even one detail wrong — like a mismatched DKIM selector or an SPF record with too many lookups — can cause deliverability issues that are hard to diagnose.
Panelica's Mail DNS Sync feature automatically configures all six essential mail DNS records when you enable email for a domain: MX record, mail A record, SPF (with hard fail), DKIM (2048-bit RSA), DMARC (with reporting), and the mail subdomain SPF record for HELO identity. The built-in Postfix mail server supports proper DKIM signing through OpenDKIM, and TLS is enabled by default for secure mail delivery.
Email deliverability is not a single fix — it is a system of interconnected components that all need to work correctly. Start with the authentication fundamentals (PTR, SPF, DKIM, DMARC), verify you are not blacklisted, warm up new IPs gradually, and pay attention to content quality. Regular monitoring through tools like Gmail Postmaster Tools and periodic mail-tester.com checks will keep your emails landing in the inbox.