Email deliverability checks explained

Email deliverability explains why an email that was successfully sent can still land in spam instead of the inbox.

For production systems, deliverability problems are expensive because they can reduce engagement and cause important transactional emails to land in spam.

This guide explains common checks used in deliverability reports and what each result usually means.

Quick checks

If you are having issues with email deliverability start with these checks:

Issue	First thing to check
SPF	Confirm the sending IP is included in the envelope sender domain's SPF record.
DKIM	Check the DKIM selector, signing domain, and matching DNS TXT public key.
DMARC	Confirm either SPF or DKIM passed and aligned with the visible From domain.
DNS	Review SPF, DMARC, MX, and PTR records for missing or inconsistent values.
Content	Look for excessive links, large attachments, missing text fallback, or unusual message size.

SPF

SPF stands for Sender Policy Framework. It checks whether the server that delivered the email is allowed to send mail for the envelope sender domain.

An SPF record is a DNS TXT record published on the sending domain. It usually looks like this:

v=spf1 include:example-sender.com -all

That record says: allow the servers authorized by example-sender.com; reject everything else.

If you use more than one sending service, combine them into one SPF record:

v=spf1 include:example-sender.com include:other-service.com -all

A domain should not publish multiple SPF records. Multiple v=spf1 TXT records can cause SPF to return a permanent error, even if each individual record looks valid.

Common SPF results:

• pass: the sending IP is authorized by the domain's SPF record.
• fail: the sending IP is explicitly not authorized.
• softfail: the sending IP is probably not authorized, but the domain is not asking receivers to reject it strictly.
• neutral: the domain did not make a clear pass or fail decision.
• none: no SPF record was found.

If a report says SPF failed because the record ended with -all, it means none of the allowed rules matched the sending IP, and the final rule told receivers to fail the message.

Common SPF issues:

• No SPF record exists for the envelope sender domain.
• The domain has more than one SPF record.
• The sending service is missing from the SPF record.
• The record has invalid syntax.
• The record exceeds SPF's 10 DNS lookup limit, usually from too many include, a, mx, exists, or redirect mechanisms.

After changing SPF, allow DNS time to propagate and test with an SPF validator or by sending a message to a deliverability testing address. The useful details are the same details a report should show: sending IP, envelope sender domain, SPF record, and matched mechanism.

DKIM

DKIM stands for DomainKeys Identified Mail. It verifies that a message was signed by a domain and that important parts of the message were not changed after signing.

DKIM uses three pieces:

• A private key used by the sending service to sign outbound mail.
• A DKIM-Signature header added to the email.
• A public key published as a DNS TXT record under a selector, such as selector._domainkey.example.com.

The selector comes from the s= value in the DKIM-Signature header. For example, if the signature says s=x and the signing domain is example.com, receivers look for the public key at:

x._domainkey.example.com

Use the selector your sending provider gives you; x is only an example.

The DNS value usually starts with:

v=DKIM1; k=rsa; p=...

When DKIM passes, the receiving server found the public key, verified the signature, and confirmed that the signed parts of the message still match.

Common DKIM issues:

• No DKIM-Signature header exists.
• The selector or signing domain is missing.
• The DKIM public key cannot be found in DNS.
• The public key was published under the wrong host, for example using x where the DNS provider expects x._domainkey, or appending the domain twice.
• The DNS provider changed the TXT value by adding duplicate quotes, backslashes, or splitting a long key incorrectly.
• The body hash does not match, meaning the body changed after signing.
• The signature is invalid.

If DKIM fails, first check the selector and domain in the signature, then confirm the matching TXT record exists in DNS. DNS changes can take several hours to propagate, so a newly added key may fail briefly even when the record is correct.

DKIM is especially important because DMARC can pass when either SPF or DKIM passes and aligns with the visible From domain.

DMARC

DMARC builds on SPF and DKIM. It checks whether the domain in the visible From header is protected by a DMARC policy, and whether SPF or DKIM passed in a way that aligns with that visible domain.

A DMARC record is published at:

_dmarc.example.com

It can look like this:

v=DMARC1; p=none; sp=none; adkim=r; aspf=r

The p value is the policy:

• none: monitor only.
• quarantine: ask receivers to treat failing mail as suspicious.
• reject: ask receivers to reject failing mail.

p=none is the safest starting point because it does not ask receivers to block or quarantine mail. It still tells receivers that the domain has a DMARC policy, and it lets you confirm SPF and DKIM alignment before enforcing stricter rules.

DMARC can fail even when SPF technically passes if the SPF domain does not align with the visible From domain. That distinction matters because users see the From header, not the SMTP envelope sender.

Alignment can be relaxed or strict:

• adkim=r: relaxed DKIM alignment, allowing a signed subdomain to align with the organizational domain.
• adkim=s: strict DKIM alignment, requiring the DKIM signing domain to exactly match the visible From domain.
• aspf=r: relaxed SPF alignment.
• aspf=s: strict SPF alignment.

Common DMARC issues:

• No DMARC record exists.
• The policy is only p=none, which is useful for monitoring but not enforcement.
• Neither SPF nor DKIM produced an aligned pass.
• DKIM alignment could not be verified.
• The record uses strict alignment before all legitimate senders are configured correctly.
• Reports are enabled with rua or ruf, but nobody is reading or processing them.

A cautious rollout is usually:

1. Publish p=none with relaxed alignment.
2. Confirm all legitimate sending services pass SPF or DKIM with alignment.
3. Add aggregate reports with rua=mailto:dmarc@example.com if you have a mailbox or report analyzer ready.
4. Move to p=quarantine with a low pct value, such as pct=10.
5. Increase enforcement gradually, then move to p=reject only when legitimate mail is consistently passing.

Reporting is optional. Aggregate reports are XML summaries and can be noisy, so they are most useful when sent to a dedicated mailbox or DMARC analysis service. Forensic reports with ruf can contain detailed failure data and are less commonly used.

Content checks

Content checks look at the message itself. These are not a replacement for inbox-provider filtering, but they help catch obvious problems before they become deliverability issues.

Examples of useful content signals:

• Message size.
• Attachment count.
• URL count.
• Suspicious or excessive links.
• Very large messages.
• Missing or weak plain text fallback.

Content alone rarely tells the whole story. A normal transactional email with a reset link should not be a problem. But a large email with many links, no text version, and attachments from a poorly authenticated sender is more likely to look suspicious.

DNS checks

DNS checks look at the sending or visible domain's public records.

Common records include:

• A: IPv4 addresses for the domain.
• AAAA: IPv6 addresses for the domain.
• MX: mail exchangers for receiving email.
• TXT: text records, including SPF.
• _dmarc: DMARC policy.
• PTR: reverse DNS for the sending IP.

Missing DNS records do not always mean an email will fail delivery. For example, a domain can send email without having an MX record. But DNS gaps often explain why a message looks less trustworthy.

PTR records are especially useful for SMTP senders. A missing or strange reverse DNS result can make a sender look poorly configured.

How to read a deliverability report

Start with the overall status, but do not stop there. Deliverability is a collection of signals, not one single pass/fail result.

A practical order is:

1. Check SPF, DKIM, and DMARC first.
2. Confirm the details: sending IP, envelope sender, visible From domain, DNS records, and DKIM selector.
3. Look at the DNS and sender details to understand what infrastructure was actually involved.
4. Review content signals if authentication looks correct but the email still seems risky.

The details matter as much as the status. A message like “SPF failed” is only useful when you can also see the sending IP, SPF record, envelope domain, and matched rule.

Wrap-up

Email deliverability is not magic. Most problems can be traced back to a small set of signals: SPF, DKIM, DMARC, DNS, and content.

When you can see both the result and the details behind it, the report becomes much easier to act on. Instead of seeing a generic failure, you can answer the useful question: which domain, IP, record, or header caused this result?

Using Mailisk deliverability reports

Mailisk can generate deliverability reports for received emails. Open an email in the dashboard and use the Deliverability tab to start or view the report.

The report shows SPF, DKIM, DMARC, DNS, and content checks, along with the details used for each section. That makes it easier to debug whether the problem is authentication, DNS, or message content.