The Ultimate Guide to Email Deliverability: SPF, DKIM, DMARC, and Beyond

Why Email Deliverability Matters

Email deliverability isn't just about "not being spam." It's the aggregate result of your domain's reputation, your DNS configuration, your sending infrastructure, and how receiving MTAs interpret all of the above.

The consequences of poor deliverability compound quickly:

• Transaction failures: Password resets, 2FA codes, and payment receipts that never arrive erode user trust within minutes.
• Deliverability death spirals: Low engagement from spam-foldered email signals to mailbox providers that your domain is low-quality, which further depresses inbox placement.
• Brand impersonation risk: Without proper authentication records, attackers can spoof your domain — and the resulting phishing damage becomes your reputation problem.
• Compliance gaps: DMARC is increasingly required by regulations (e.g., BIMI as a prerequisite for domain-based brand verification in some jurisdictions).

The fix starts with DNS. Let's look at the records that matter.

The Big 3: SPF, DKIM, and DMARC

These three DNS records form the baseline of email authentication. If you configure nothing else, configure these.

SPF (Sender Policy Framework)

What it does: SPF tells receiving MTAs which IP addresses are authorized to send email on behalf of your domain. It's an outbound-only allowlist published in DNS.

How it works: The receiving server looks up the TXT record at the root of your domain, parses the SPF mechanism, and evaluates whether the sending IP matches.

Practical configuration:

example.com. IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.0/24 -all"

Key points:

• -all (hard fail) vs ~all (soft fail): Use -all in production. Soft fail (~all) is acceptable during rollout but provides weaker enforcement.
• The 10-lookup limit: SPF has a maximum of 10 DNS-resolution lookups per record. Each include or a or mx mechanism costs a lookup. Exceeding this limit causes SPF to permanently fail. Flatten includes from third-party providers if you're nearing the limit.
• ip4/ip6 mechanisms bypass lookups: Prefer explicit IP ranges over include when possible to stay under the limit.

DKIM (DomainKeys Identified Mail)

What it does: DKIM adds a cryptographic signature to every outgoing email. The receiving server retrieves the public key from DNS and verifies that the email wasn't altered in transit and actually originated from your infrastructure.

How it works: Your MTA (or ESP) signs the message with a private key and publishes the corresponding public key at <selector>._domainkey.<domain>.

Practical configuration:

mailcheck._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Key points:

• Key rotation: Generate fresh key pairs annually. Publish the new selector alongside the old one for overlap, then remove the old selector after a transition period.
• Selector naming: Use meaningful selector names (e.g., sendgrid2026, mailgun) to track which signing service each key belongs to.
• Key length: Use 2048-bit RSA at minimum. 4096-bit is preferred. Some older MTAs truncate TXT records over 255 bytes, so check that your DNS provider supports long TXT values.

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

What it does: DMARC ties SPF and DKIM together and tells receiving MTAs what to do when authentication fails. It also provides a reporting mechanism so you can see who's sending email as your domain.

How it works: The receiving server evaluates SPF and DKIM independently. DMARC then checks alignment — whether the domains in the From header, the envelope sender (SPF), and the DKIM signature all match. If alignment fails for both, DMARC policy is applied.

Practical configuration:

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100; adkim=s; aspf=s;"

Key points:

• Rollout in stages: Start with p=none (monitor only), move to p=quarantine, then p=reject. Each stage needs 1–2 weeks of monitoring aggregate reports to identify legitimate senders you've missed.
• rua is critical: Without aggregate reporting addresses, you're flying blind. Use a dedicated mailbox or a DMARC analytics provider.
• adkim=s and aspf=s (strict alignment): Requires exact domain match. Relaxed alignment (r) allows subdomain matches. Strict is recommended unless you have subdomain sending requirements.

MTA-STS and TLS-RPT: The Next Frontier

SPF, DKIM, and DMARC authenticate who sent the message. They say nothing about how the message is transported between MTAs. SMTP opportunistic TLS means connections can be silently downgraded to plaintext — or intercepted via STARTTLS stripping attacks.

MTA-STS (SMTP MTA Strict Transport Security)

What it does: MTA-STS tells sending MTAs that your domain supports TLS and that connections must use a valid certificate. If TLS cannot be negotiated, delivery must fail rather than fall back to plaintext.

How it works: You publish a policy via HTTPS at https://mta-sts.<domain>/.well-known/mts-sts.txt and signal its existence via a DNS TXT record.

DNS signal:

_mta-sts.example.com. IN TXT "v=STSv1; id=2026042501;"

HTTPS policy (hosted on your web server):

version: STSv1
mode: enforce
max_age: 604800
mx: mail.example.com
mx: mx.sendgrid.net

Set mode: testing initially and monitor TLS-RPT for policy violation reports before switching to enforce.

TLS-RPT (TLS Reporting)

What it does: TLS-RPT provides a mechanism for receiving MTA-to-MTA TLS failure reports — analogous to DMARC aggregate reports, but for transport encryption.

Practical configuration:

_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-report@example.com;"

When combined with MTA-STS, TLS-RPT lets you detect STARTTLS failures, certificate mismatches, and policy violations across your receiving infrastructure.

BIMI: Your Brand Logo in the Inbox

What it does: BIMI (Brand Indicators for Message Identification) lets you display your brand logo next to emails in supporting inboxes (Gmail, Apple Mail, Yahoo, and others). It's a visual trust signal that increases open rates and reduces phishing risk.

How it works: BIMI works only when DMARC is enforced at p=quarantine or p=reject. You publish a DNS record pointing to an SVG logo, and mailbox providers display it alongside authenticated messages from your domain.

Practical configuration:

default._bimi.example.com. IN TXT "v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/certificate.pem;"

Key points:

• SVG requirements: The logo must be a specific SVG Tiny PS profile. Most vector tools export incompatible SVGs. Use a BIMI-specific validator before publishing.
• VMC certificate: Gmail requires a Verified Mark Certificate (VMC) — a digital certificate that proves you own the trademark displayed in the logo. Obtain this from a BIMI-qualified certificate authority (DigiCert, Entrust, etc.) after registering your trademark.
• DMARC prerequisite: BIMI is irrelevant without DMARC enforcement. Fix authentication first; brand logos second.

Common Misconfigurations and How to Fix Them

These are the misconfigurations we see most often when auditing domains through mailcheck:

bash# Check your SPF lookup count with mailcheck
curl -s https://korpo.pro/api/v1/check/example.com | jq '.spf'

bashdig TXT mailcheck._domainkey.example.com +short

How to Check Your Domain with the mailcheck API

mailcheck provides a free API to audit your domain's email authentication posture across SPF, DKIM, DMARC, MTA-STS, TLS-RPT, and BIMI.

Quick Check

bashcurl -s https://korpo.pro/api/v1/check/example.com | jq .

This returns a comprehensive JSON report:

json{
  "domain": "example.com",
  "spf": {
    "status": "pass",
    "record": "v=spf1 include:_spf.google.com -all",
    "dns_lookups": 1,
    "warnings": []
  },
  "dkim": {
    "status": "pass",
    "selector": "google",
    "key_length": 2048,
    "warnings": []
  },
  "dmarc": {
    "status": "pass",
    "policy": "reject",
    "pct": 100,
    "rua": ["dmarc@example.com"],
    "alignment_spf": "s",
    "alignment_dkim": "s"
  },
  "mta_sts": {
    "status": "pass",
    "mode": "enforce",
    "max_age": 604800,
    "mx": ["mail.example.com"]
  },
  "tls_rpt": {
    "status": "pass",
    "rua": ["tls-report@example.com"]
  },
  "bimi": {
    "status": "pass",
    "logo_url": "https://example.com/bimi/logo.svg",
    "vmc_url": "https://example.com/bimi/certificate.pem"
  }
}

Check Specific Records

bash# Inspect just SPF
curl -s https://korpo.pro/api/v1/check/example.com | jq '.spf'

# Inspect DMARC policy and alignment
curl -s https://korpo.pro/api/v1/check/example.com | jq '.dmarc.policy, .dmarc.alignment_spf, .dmarc.alignment_dkim'

# Verify MTA-STS enforcement mode
curl -s https://korpo.pro/api/v1/check/example.com | jq '.mta_sts.mode'

# Check BIMI readiness
curl -s https://korpo.pro/api/v1/check/example.com | jq '.bimi'

Batch Check Multiple Domains

For multi-tenant SaaS platforms or agencies managing multiple sending domains:

bash#!/bin/bash
# batch-check.sh — audit multiple domains via mailcheck
DOMAINS=("example.com" "app.example.com" "staging.example.com")

for domain in "${DOMAINS[@]}"; do
  echo "=== $domain ==="
  curl -s "https://korpo.pro/api/v1/check/$domain" | jq '{spf: .spf.status, dkim: .dkim.status, dmarc: .dmarc.status, mta_sts: .mta_sts.status, bimi: .bimi.status}'
  echo
done

Integrate into CI/CD

Add email authentication checks to your deployment pipeline to catch regressions before they hit production:

yaml# .github/workflows/email-auth.yml
name: Email Authentication Check

on:
  push:
    paths:
      - 'dns/**'

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - name: Audit email authentication records
        run: |
          STATUS=$(curl -s https://korpo.pro/api/v1/check/example.com | jq -r '.dmarc.policy')
          if [ "$STATUS" != "reject" ]; then
            echo "::error::DMARC policy is $STATUS, expected reject"
            exit 1
          fi

Actionable Checklist for Sysadmins

Print this out. Run through it for every domain you manage.

Closing Thoughts

Email deliverability is infrastructure, not marketing. The protocols are well-defined, the DNS records are straightforward, and the tools for validation are free. There is no excuse for a domain that authenticates email poorly in 2026.

Start with SPF, DKIM, and DMARC. Graduate to MTA-STS and TLS-RPT. Add BIMI once you've earned the DMARC enforcement badge. Use mailcheck to audit your domain at every stage:

bashcurl -s https://korpo.pro/api/v1/check/yourdomain.com | jq .