Email Deliverability Explained: SPF, DKIM, DMARC and Sender Reputation

Your users never see the OTP (one-time password), the invoice or the password reset, so they think your app is broken. The mail left your server fine, but the receiving mailbox did not trust it. That is an email deliverability problem, and it usually starts in DNS.

Picture a common setup. A small team sends sign-up OTPs and order receipts from [email protected] through an email provider, and it works for months. Then marketing sends a large campaign from the same domain through a new tool nobody set up in DNS. Those messages bounce with 550 5.7.26, complaints pile up, and soon the OTPs land in spam too. The setup is made up, but the code is real: Gmail uses it for unauthenticated mail and for mail blocked by DMARC.

Email deliverability is the share of your mail that reaches the inbox. It depends on two things. First, can the receiver prove the mail really came from your domain? Second, does your domain have a good record of sending mail people want? This guide covers both, on this one running example.

Email has two sender addresses, and most confusion starts here. One is on the envelope that servers use, and one is on the letter that people read.

Servers pass mail to each other with SMTP (Simple Mail Transfer Protocol). Every SMTP reply carries a three-digit code, such as 250 for accepted or 550 for refused. Keep the envelope sender and the header From apart in your head. SPF checks the first. Readers only see the second. DMARC is the rule that ties them together.

For email deliverability, the three checks answer three questions. SPF says which servers may send for a domain. DKIM proves a domain signed the message and nobody changed it. DMARC checks that one of those passes for the From domain.

An everyday picture: a parcel at a gated society

Think of the security guard at a gated housing society receiving a parcel labelled with a sender's name. SPF is the list of delivery agents that sender registered with the gate. DKIM is a tamper-evident seal stamped with the sender's own mark. DMARC is the sender's standing note to the guard. It says: accept the parcel only if the agent or the seal matches the name on the label. Otherwise hold it or send it back, and send me a daily log.

Where the picture breaks: the guard checks the seal with maths, not by eye, and anyone can read the agent list because it sits in public DNS. Forwarding is like a neighbour handing the parcel on. The agent changes, so SPF fails, but the seal survives if nobody opens the box.

SPF is one TXT record on your domain that lists the IP addresses and services allowed to send mail for it. The receiver looks up the record for the envelope sender's domain and checks the connecting IP against it.

example.com.  TXT  "v=spf1 ip4:192.0.2.10 include:_spf.mailer.example.com -all"

Read it left to right. ip4 allows one address. include pulls in another domain's SPF record, which is how you allow an email provider. The final all says what happens to everyone else.

SPF never looks at the From line the reader sees. RFC 7208 checks the envelope sender and the HELO name, which is the name the sending server gives when it connects. That gap is why SPF alone cannot stop someone faking your From line.

The 10-lookup limit that breaks quietly

RFC 7208 caps SPF at 10 DNS lookups. The include, a, mx, ptr and exists terms count, and so does the redirect modifier. The ip4, ip6 and all terms are free. Going over the limit gives permerror, which DMARC treats as no SPF pass.

Each include also counts the lookups inside the record it pulls in. Our test record allowed the main server with a and mx, plus three vendors whose records each held two more includes. That is 2 plus 3 times 3, which makes 11 lookups.

What just happened? pyspf counts lookups while it evaluates, left to right, and stops at the first match. So the broken record looked fine for your main server and failed only for the vendor listed last. RFC 7208 also evaluates mechanisms left to right and applies the limit during evaluation. So the bug hides from your main server's mail. Treat any record over 10 as broken.

The usual fix is to remove includes for services you no longer use and to replace a and mx with fixed ip4 entries. Copying a vendor's IPs straight into your record also works, but it breaks silently when the vendor changes its addresses.

DKIM adds a signature header to each message, made with a private key that only your sending system holds. The receiver fetches the matching public key from your DNS and checks the signature. If the signed headers or the body changed on the way, the check fails.

The public key lives at a name built from a selector, which is a label you choose so you can run more than one key. With selector s2026, the key sits at s2026._domainkey.example.com. The signature header names the domain in d= and the selector in s=.

This short script signs a message as example.com with a throwaway key, then checks it twice. It ran on dkimpy 1.1.8 with Python 3.13. A small function stands in for DNS, so it needs no network.

# pip install dkimpy==1.1.8 cryptography
import base64
import dkim
from cryptography.hazmat.primitives import serialization
from cryptography.hazmat.primitives.asymmetric import rsa

# 1. Make a throwaway 2048-bit key pair (never reuse it)
key = rsa.generate_private_key(public_exponent=65537, key_size=2048)
private_pem = key.private_bytes(
    serialization.Encoding.PEM,
    serialization.PrivateFormat.TraditionalOpenSSL,
    serialization.NoEncryption(),
)
public_der = key.public_key().public_bytes(
    serialization.Encoding.DER,
    serialization.PublicFormat.SubjectPublicKeyInfo,
)
txt_value = "v=DKIM1; k=rsa; p=" + base64.b64encode(public_der).decode()

# 2. Pretend DNS: the verifier asks for s2026._domainkey.example.com
def fake_dns(name, timeout=5):
    if name == b"s2026._domainkey.example.com.":
        return txt_value.encode()
    return None

message = (
    b"From: [email protected]\r\n"
    b"To: [email protected]\r\n"
    b"Subject: Your OTP\r\n"
    b"\r\n"
    b"Your one-time password is 482913.\r\n"
)

# 3. Sign as example.com with selector s2026
signature = dkim.sign(
    message, b"s2026", b"example.com", private_pem,
    canonicalize=(b"relaxed", b"relaxed"),
    include_headers=[b"from", b"to", b"subject"],
)
signed = signature + message

# 4. Verify the untouched message, then a tampered copy
print("untouched:", dkim.verify(signed, dnsfunc=fake_dns))
tampered = signed.replace(b"482913", b"111111")
print("tampered: ", dkim.verify(tampered, dnsfunc=fake_dns))

Expected output: untouched: True on the first line and tampered: False on the second. Changing one six-digit OTP in the body broke the signature, because the body hash in bh= no longer matched.

What breaks a DKIM signature and what does not

Canonicalization means tidying the message the same way on both sides before hashing. RFC 6376 defaults to simple, so set c=relaxed/relaxed when you configure signing yourself. RFC 6376 also requires the From header to be signed.

Key size is set by RFC 8301, which updated DKIM in 2018. Signers must use RSA keys of at least 1024 bits and should use 2048. The older rsa-sha1 algorithm must not be used. A 2048-bit public key, with its tags, is about 410 characters in the TXT value, which is more than one 255-character DNS string can hold. DNS tools show it as two quoted strings, and verifiers join them.

DMARC passes when SPF passes for a domain that matches the From domain, or DKIM passes for a domain that matches it. One aligned pass is enough. The domain owner publishes the rule as a TXT record at _dmarc.example.com.

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

Matching is called alignment. Relaxed alignment, the default, accepts any name under the same organisational domain, which is the registered name such as example.com. So bounce.example.com aligns with example.com. Strict alignment needs the exact same name. You set them with aspf for SPF and adkim for DKIM.

Row B is the trap. Both checks pass, but for the provider's domains, so nothing is aligned and DMARC fails. This is why you set up DKIM for your own domain at the provider before you send.

What the three policies ask receivers to do

The rua tag gives an address for aggregate reports. These are summaries from receivers, usually daily, listing which IPs sent mail as your domain and whether each passed. They are how you find the forgotten CRM or helpdesk tool sending as you.

You move in stages, reading reports at each one, and you only tighten the policy when every real sender passes. The steps below assume one domain and a few sending services.

1. 1

   List every sender

   Write down each system that sends as your domain: app server, email provider, CRM, helpdesk, billing and office mail.

2. 2

   Publish SPF and DKIM for each

   Keep SPF under 10 lookups. Ask each service to sign DKIM with your domain, not its own.

3. 3

   Publish p=none with rua

   Collect aggregate reports for a few weeks so you see traffic you did not know about.

4. 4

   Fix what fails

   For each failing source, either set up aligned DKIM or stop it sending as your domain.

5. 5

   Move to quarantine

   Change p=none to p=quarantine and keep watching reports and support tickets.

6. 6

   Move to reject

   Switch to p=reject once quarantine causes no real mail to go missing. Keep reading reports afterwards.

DMARC became a Standards Track specification in May 2026, when the RFC Editor published RFC 9989. It obsoletes RFC 7489, the 2015 version, which was only an Informational document, not a formal standard. Aggregate reports moved to RFC 9990 and failure reports to RFC 9991.

The tree walk means receivers find your organisational domain by querying _dmarc names in DNS, moving up one label at a time. RFC 9989 also says receivers must ignore tags they do not recognise, so an old pct tag in your record should not break it.

Both ask every sender for basic authentication and ask bulk senders for SPF, DKIM, DMARC and one-click unsubscribe. Gmail counts you as a bulk sender once you send close to 5,000 messages in 24 hours to personal Gmail accounts. That status is permanent.

Gmail says enforcement ramped up in November 2025, including temporary and permanent rejections. Its FAQ notes that alignment is not required for forwarded and mailing list mail. Gmail measures the spam rate in its Postmaster Tools dashboard.

One-click unsubscribe in two headers

RFC 8058 defines one-click unsubscribe with two headers. The List-Unsubscribe header holds one HTTPS link, such as https://example.com/u/abc123, written inside angle brackets. A second header, List-Unsubscribe-Post, carries the exact value List-Unsubscribe=One-Click.

When the reader clicks unsubscribe, the mailbox sends an HTTPS POST to that link. That POST alone should unsubscribe the user, with no extra page or login. The RFC says the request carries no cookies, your server must not redirect it, and both headers must be covered by your DKIM signature.

Receivers judge you by how you behave, not only by whether you pass authentication. Mailing addresses that do not exist, mail people mark as spam and hits on spam traps all say you do not manage your list.

Bounces

SMTP replies starting with 4 are temporary errors, so you retry later. Replies starting with 5 are permanent. Gmail's 550 5.1.1 means the account does not exist, and you should never mail that address again.

• Hard bounce: a 5xx reply such as 550 5.1.1. Add the address to a suppression list, a table of addresses you never send to.
• Soft bounce: a 4xx reply such as 421 4.7.0, try again later. Retry with backoff, waiting longer each time, and suppress the address if it keeps failing.
• Rate warnings: Gmail's 421 4.7.28 says it saw an unusual rate of mail from you. Slow down rather than retrying harder.
• Authentication errors: 550 5.7.26 means unauthenticated or DMARC-blocked mail. Fix DNS, not the retry logic.

Google's own advice is to reduce volume when bounces or deferrals rise, and to unsubscribe recipients who bounce several times automatically. Yahoo asks senders to remove invalid recipients promptly.

Spam traps

A spam trap is an address used to catch senders with poor list practices. Spamhaus describes several kinds. Pristine traps were never given to a real person. Seeded traps are scattered where address scrapers will find them. Dead-address traps were real addresses that were shut down and later turned into traps. Typo traps sit on look-alike domains.

Seeded traps catch senders who buy or scrape lists. Dead-address traps catch senders who keep mailing addresses that stopped working. Spamhaus advises confirmed opt-in, where the user clicks a link to confirm the address, rather than hunting for traps. Gmail and Yahoo also recommend confirming addresses before you subscribe them.

Warming up means starting with low volume to your most engaged users and raising it slowly, so receivers can build a picture of you. Gmail says to avoid sudden spikes if you have no history of sending large volumes.

As of 24 October 2026, neither Gmail's sender guidelines nor Yahoo's best-practices page gives a day-by-day warm-up schedule. Treat any fixed table you find as someone's opinion. A sensible rule is to raise volume only while bounces, deferrals and complaints stay low, and to pause when 4xx codes appear.

• Shared IP: your provider's IP is used by many senders. Gmail notes that everyone's behaviour on a shared IP affects its reputation.
• Dedicated IP: only you send from it, so the reputation is yours alone. It starts with no history and needs warming.
• Separate streams: Gmail suggests a different IP for each message type and the same From address within one category.

Picture our team again. Before the big campaign, they could have sent it from a marketing subdomain such as news.example.com, starting with recent buyers. The OTP stream on [email protected] would then keep its own clean history.

Look up the three DNS records, then read the authentication results on a real message you sent to yourself. These dig commands ran against a local test server serving made-up example.com records.

$ dig +short TXT example.com
"v=spf1 ip4:192.0.2.10 include:_spf.mailer.example.com -all"

$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=none; rua=mailto:[email protected]"

$ dig +short TXT s2026._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEF..." "...rest of the key"

Check three things in that output. There is exactly one line starting v=spf1. The DMARC line starts v=DMARC1. The DKIM key may arrive as two quoted strings, which is normal for a 2048-bit key.

Next, send a message to a mailbox you own and open its full headers. Receivers add an Authentication-Results header, defined in RFC 8601. You want to see results like this, with your own domain after each method.

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

If header.d shows your provider's domain, DKIM is not aligned. You are then relying on SPF alone, or you are in row B of the DMARC table. Fix that before you raise volume.

Treat it as part of a notification system: authentication in DNS, reputation in behaviour, and feedback loops in code. Interviewers want to hear that you separate mail streams and handle bounces.

1. 1

   Name the goal

   Inbox placement for OTPs and receipts first, marketing second, measured by bounces, complaints and delivery time.

2. 2

   Authenticate the domain

   SPF under 10 lookups, DKIM with your own domain and a 2048-bit key, DMARC from p=none towards p=reject.

3. 3

   Separate streams

   Transactional mail on one subdomain and IP pool, marketing on another, so one cannot hurt the other.

4. 4

   Close the feedback loop

   Process bounces and complaints from webhooks, keep a suppression list, and honour unsubscribes within 48 hours.

5. 5

   Protect reputation

   Warm up new IPs slowly, use confirmed opt-in, and alert when complaint rates rise towards 0.1%.

6. 6

   Mention the trade-offs

   Dedicated IPs give control but need warm-up; strict alignment is safer but breaks more third-party senders.