What receiving servers are actually checking

An email has two "from" addresses. The envelope sender (also called MAIL FROM or Return-Path) is used during the SMTP conversation and is where bounces go. The header From is what the user sees in their mail app. Many API providers set the envelope sender to a bounce-handling domain of their own, so the two often differ.

• SPF asks: is the server that connected to me allowed to send mail for the envelope sender's domain? It looks up a TXT record on that domain and checks the connecting IP against it.
• DKIM asks: was this message signed with a key published in DNS, and did the signed headers and body arrive unaltered? The signature carries a domain (d=) and a selector (s=), and the receiver fetches the public key from <selector>._domainkey.<d>.
• DMARC asks: did SPF or DKIM pass for a domain that aligns with the header From, and what does the domain owner want done if neither did? It also says where to send reports.

Alignment is the part people miss. SPF can pass for bounces.yourprovider.net and DKIM can pass for yourprovider.net, and DMARC will still fail for example.com, because neither of those identities matches what the user sees.

• SPF aligns when the envelope sender (Return-Path) domain matches the From domain.
• DKIM aligns when the signature's d= domain matches the From domain.
• Relaxed alignment (the default, aspf=r / adkim=r) only needs the same organizational domain, so d=mail.example.com aligns with From: noreply@example.com. Strict (s) needs an exact match.

DMARC passes if either aligned SPF or aligned DKIM passes. For transactional mail sent through an API, DKIM signed with your own domain is usually what carries the result. If your provider's Return-Path stays on its own domain, SPF can pass without aligning, and that's fine as long as DKIM aligns.

The three records, line by line

Here is a typical set for example.com. Use placeholder s1 for the selector here; in practice, copy the exact names and values your provider gives you.

DKIM (name s1._domainkey.example.com):

s1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...IDAQAB"

p= is the public key. The selector and key are unique to your domain, so never retype them by hand.

SPF (on the domain itself, shown as @ in most DNS panels):

example.com.  TXT  "v=spf1 include:amazonses.com ~all"

This is the record Sendaro's docs show (sending runs on Amazon SES); your provider will give you its own include:. The all at the end decides what happens to everything not listed:

• ~all (softfail): "probably not us, treat with suspicion". Receivers usually accept the message but count it against it.
• -all (fail): "definitely not us". Some receivers reject on that alone, before DMARC is even evaluated.

~all is the common choice once DMARC is in place, because DMARC then decides what happens to unauthenticated mail and you get reports about it. -all is fine if you're confident your list of senders is complete.

DMARC (name _dmarc.example.com):

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

p=none means "don't act on failures, just report". rua= is where receivers send daily aggregate reports (XML summaries of who sent mail as your domain and whether it passed). If the rua address is on a different domain, that domain has to publish an authorization record, for example example.com._report._dmarc.reports.example.net TXT "v=DMARC1", or receivers won't send to it.

Mistake #1: two SPF records

A domain may have only one SPF record. If a DNS lookup returns two TXT records starting with v=spf1, SPF evaluation returns permerror, and receivers treat it as no valid SPF at all. This happens constantly: Google Workspace or Microsoft 365 set one up, then a transactional provider tells you to "add this record", and you add a second.

Merge them instead:

example.com.  TXT  "v=spf1 include:_spf.google.com include:amazonses.com ~all"

The second trap is the 10 DNS-lookup limit. Every include:, a, mx, ptr, exists and redirect= costs a lookup, and nested includes count too. ip4:, ip6: and all don't. Go over 10 and SPF returns permerror. A domain with Workspace, a CRM, a helpdesk and two email tools can cross it without anyone noticing. Before adding an include, count what you already have, and drop includes for tools you no longer use.

Mistake #2: records that look right but aren't

DNS panels are inconsistent about quoting and names:

• Some panels append your domain automatically, so entering _dmarc.example.com creates _dmarc.example.com.example.com. Enter just _dmarc (or s1._domainkey) if that's what the panel expects.
• Long DKIM keys (2048-bit) exceed the 255-character limit for a single TXT string. The fix is several quoted strings in one record, which resolvers join with no spaces. Splitting the key across two separate TXT records breaks it.
• Smart quotes pasted from a doc, or a stray space inside p=, will also break DKIM.

Check what the world actually sees, not what the panel shows:

dig +short TXT example.com                 # expect exactly one "v=spf1 ..." line
dig +short TXT s1._domainkey.example.com   # your DKIM key
dig +short TXT _dmarc.example.com          # your DMARC policy

# ask a public resolver directly, to bypass local caches
dig +short TXT _dmarc.example.com @1.1.1.1

Then send yourself a real message and read the Authentication-Results header (in Gmail: "Show original"). You want spf=pass, dkim=pass with header.d=example.com, and dmarc=pass.

Propagation and verification

DNS changes aren't instant. Depending on the TTL of the old record and your provider, it can take minutes to hours. The common mistake is deleting and re-creating a record that's correct but not yet visible, which resets the wait and sometimes leaves duplicates behind. Check with dig, wait, and check again.

Keep transactional and bulk mail apart with subdomains

Reputation is tracked largely per domain. If your newsletter and your password resets share example.com, a complaint spike on a marketing send can push your resets toward spam too. Splitting them is cheap:

• Receipts and resets on example.com (or mail.example.com)
• Product updates and newsletters on news.example.com

Each sending subdomain needs its own DKIM record (for example s1._domainkey.news.example.com) and its own SPF if the envelope sender uses it. For DMARC, a subdomain without its own _dmarc record falls back to the parent's policy, and the parent's sp= tag, if set, overrides p= for subdomains.

Rolling out DMARC without blocking yourself

1. Start at p=none with rua. Leave it for at least two to four weeks so you see weekly and monthly senders (invoicing tools, CRMs, that one cron job).
2. Read the aggregate reports. Raw XML is painful, so use a free report viewer or parser. Look for sources sending as your domain that fail alignment.
3. Fix or remove each unknown sender. Add DKIM for legitimate tools, and stop the ones that shouldn't be sending as you.
4. Move to p=quarantine, keep reading reports, then p=reject once failures are only things you actually want blocked.

A note on pct=: older guides suggest ramping with pct=25, pct=50 and so on. The current DMARC spec, RFC 9989 (May 2026), marks pct as historic, because partial percentages were never applied consistently. Its replacement is t=y ("testing"), which asks receivers to apply one level below your policy: p=reject; t=y behaves like quarantine. Receivers still on the old spec ignore t, so during the transition some guides publish pct=0 alongside t=y. If that's more nuance than you need, the staged none → quarantine → reject path above works without either tag.

Unsubscribe headers are for bulk mail, not resets

Since 2024, Gmail and Yahoo require bulk senders to authenticate with SPF and DKIM, publish DMARC (at least p=none) with the From domain aligned, keep spam complaints low (Google cites a rate under 0.3%), and support one-click unsubscribe via the List-Unsubscribe and List-Unsubscribe-Post headers on marketing mail. Password resets, receipts and sign-in links don't need an unsubscribe link. Don't add one there; nobody should be able to opt out of their own password reset.

After DNS: keeping reputation clean

Authentication gets you in the door; behaviour keeps you there.

• Suppress hard bounces and complaints. Repeatedly mailing dead addresses or people who marked you as spam is one of the fastest ways to damage reputation. Most providers keep a suppression list; make sure yours is on, or keep one yourself.
• Watch bounce and complaint rates per domain, not just in aggregate, so a problem on news. doesn't hide behind healthy transactional volume.

Checklist

[ ] Exactly one SPF record on each sending domain (dig +short TXT example.com)
[ ] SPF has 10 or fewer DNS lookups, including nested includes
[ ] SPF ends in ~all (or -all if your sender list is complete)
[ ] DKIM record present at <selector>._domainkey.<domain>, copied exactly
[ ] Test message shows dkim=pass with header.d = your domain
[ ] DMARC at _dmarc.<domain> with p=none and a rua= address you actually read
[ ] External rua domain has its _report._dmarc authorization record
[ ] Separate subdomain per mail stream (transactional vs newsletter)
[ ] Each subdomain has its own DKIM (and SPF where needed)
[ ] One-click unsubscribe on bulk mail only
[ ] Hard bounces and complaints suppressed automatically
[ ] Bounce and complaint rates monitored per domain
[ ] DMARC moved to quarantine, then reject, after reviewing reports

Three TXT records won't fix a bad sending practice, but getting them right, and knowing what each one proves, removes the most common reason legitimate password resets end up in spam.