Email Deliverability: SPF, DKIM, DMARC and List Hygiene

An SPF record is a TXT record at the root of the sending domain that lists the servers, IP addresses and include mechanisms allowed to send mail for that domain. Receivers look it up against the envelope sender (the Return-Path), not the visible From header, which is exactly why SPF alone cannot stop a spoof of the From address (Valimail).

A working record usually looks like this:

mail.example.com.  3600  IN  TXT  "v=spf1 include:_spf.provider-a.com include:_spf.provider-b.com -all"

Two design points matter more than the syntax. First, the total number of DNS lookups the record triggers is limited to 10; once you include several vendors, each of which includes more domains, you can exceed the limit and cause a permerror. That is a common cause of "SPF fails only sometimes" tickets. Second, use -all (hard fail) rather than ~all (soft fail) once you have verified the inventory, because soft fail gives receivers a weaker signal.

Check the record with a public lookup tool after every change, and check again after any vendor migrates infrastructure. Providers do change IP ranges, and an SPF record that references a stale range silently fails for a portion of your mail.

DKIM attaches a cryptographic signature to each message. The sending system holds the private key and signs selected headers and the body; the public key sits in DNS at a selector you choose, so receivers can verify both that the message came from someone holding the key and that it was not altered in transit (Valimail). Yahoo asks for a minimum key length of 1024 bits and notes that signatures let the receiver associate mail with the signer and confirm the content has not changed (Yahoo Sender Hub).

Setup is usually a copy and paste job inside your email platform:

1. Generate a key pair in the platform (most providers do this for you) and pick a selector such as s1 or mail.
2. Publish the TXT record the platform gives you at selector._domainkey.yourdomain, for example s1._domainkey.mail.example.com.
3. Send a test message to a Gmail address you control and inspect the original. You want dkim=pass with the domain matching your sending subdomain.
4. Rotate keys on a documented schedule and keep the old public key published for a grace period so in-flight mail still verifies.

DKIM is the record most likely to survive forwarding, because it signs content rather than the envelope. It can still break when a mailing list rewrites headers or the body, another reason SPF and DKIM are complements rather than alternatives.

DMARC is a TXT record at _dmarc.yourdomain that tells receivers what to do when a message fails authentication, and it adds reporting. The allowed policies are none (take no action), quarantine (send to spam) and reject (refuse delivery) (Google Workspace Help).

The concept that decides whether DMARC actually works for you is alignment. DMARC passes only if an authenticated identifier matches the domain in the visible From header. With relaxed alignment (the default), a subdomain of your organizational domain matches. With strict alignment, the domains must match exactly (Adaptive Security). This is where third-party senders cause trouble: an ESP that signs DKIM with its own domain, or rewrites the Return-Path, will authenticate the message but fail alignment for yourdomain, so DMARC fails anyway.

A conservative starting record:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; pct=100; adkim=r; aspf=r"

Then progress in three stages, and do not skip the first:

Bulk senders must publish a valid DMARC policy with at least p=none, must include an rua tag so reports actually arrive, and must ensure the From domain aligns with either SPF or DKIM; relaxed alignment is acceptable (Yahoo Sender Hub). Gmail's rule set is the same shape: SPF, DKIM and DMARC for bulk senders, SPF or DKIM for everyone else, and From alignment with the SPF or DKIM domain (Gmail Help). AWS summarized the shift as three buckets: stricter domain authentication, easy unsubscribe, and complaint rates below 0.3 percent (AWS Messaging blog).

Read your aggregate reports before you enforce. They are XML files, so use a free parser or your ESP's DMARC dashboard. Look for two things: sources you did not know about (fix by adding them to SPF or moving them to your DKIM domain), and forwarders that break alignment (fix with ARC, which Yahoo recommends for forwarders, or by accepting that forwarded mail may fail).

A worked example with numbers

Say your list is 40,000 subscribers and you send four campaigns a month, so 160,000 messages monthly to personal Gmail accounts, or roughly 5,300 a day averaged across the month. You are over the 5,000-per-day line, so you are a bulk sender.

Now suppose 1 percent of that monthly volume fails DMARC alignment because an old CRM instance is still sending with its own Return-Path. That is 1,600 messages a month landing in spam or being rejected once you enforce, including password resets and order confirmations to customers who think you have gone silent. On the sending subdomain alone, 400 newsletter messages a month (1 percent of 160,000 is 1,600 total; if a quarter of that is newsletter traffic, 400) would disappear. Fixing the CRM record costs one DNS change. That is the entire argument for staged enforcement.

Bounces are not all equal, and treating them the same is how lists rot.

• Hard bounce: the address does not exist or the domain refuses mail permanently. Remove it from all active sending immediately and never mail it again. Repeatedly hitting dead addresses is a classic spam signal.
• Soft bounce: a temporary failure such as a full mailbox, a greylisted server or a timeout. Retry on a schedule, typically a few attempts over 24 to 72 hours, then move the address to a hold status rather than deleting it.
• Block bounce: the receiving server refused the message for policy reasons. Investigate reputation before you retry.

For context on normal rates, Mailchimp publishes average bounce and complaint figures by industry alongside open and click rates, and its all-user averages show open rate around 35.6 percent and click rate around 2.6 percent (Mailchimp benchmarks). Use those as a sanity check, not a target, since open rates are inflated by privacy features that preload images. Clicks and replies are the honest engagement signals, as Letterhead notes when it argues open rates have become a directional signal rather than a precise measure (Letterhead).

A simple suppression policy that holds up under scrutiny:

1. Hard bounce: suppress after the first permanent failure.
2. Soft bounce: retry three times across 72 hours, then suppress.
3. Complaint (spam button): suppress after the first complaint, no exceptions.
4. Unsubscribe: honor within two days, which is what Yahoo requires (Yahoo Sender Hub).

Gmail and Yahoo both publish a hard threshold: keep spam complaint rates reported in Postmaster Tools below 0.3 percent, or risk rejections and spam placement (Gmail Help). Yahoo states the same 0.3 percent ceiling and adds that its calculation is based on mail delivered to the inbox, not total mail sent (Yahoo Sender Hub).

Operators who work with the Postmaster dashboard daily recommend a lower working ceiling of 0.1 percent, with 0.1 to 0.3 percent treated as a warning band and anything above 0.3 percent handled as a reputation incident (Suped). The dashboard measures manual spam reports on inboxed mail to personal Gmail accounts, is delayed, and can show gaps on low-volume days, so a single bad reading is not proof of a crisis.

Here is the arithmetic that makes the threshold matter. If you send 20,000 messages to Gmail inboxes in a month, 0.1 percent is 20 complaints and 0.3 percent is 60. Twenty complaints across a month is roughly five a week. A single poorly targeted campaign to a re-engaged segment can generate that in an hour. Track the rate per campaign and per segment, not just monthly, or you will see the spike after the damage.

Google's Postmaster Tools now includes a compliance status view where you can check whether your domain meets the bulk sender requirements, which pairs with the spam rate dashboard (Gmail sender guidelines FAQ). Register your sending domain there on day one.

Authentication gets you into the inbox. List quality keeps you there. Three processes do most of the work.

Validate at signup. Use double opt-in or at minimum an email verification step. Do not sign people up with a pre-checked box; Yahoo explicitly flags purchased lists and pre-checked opt-in boxes as practices to avoid (Yahoo Sender Hub). Watch for role addresses (info@, sales@) and known disposable domains, and require the confirmation click to be an actual action rather than an automated scan.

Prune on a schedule. Define engagement windows that match your cadence. A newsletter that sends weekly might keep addresses engaged in the past 180 days and move the rest to a monthly digest or re-permission campaign. A quarterly sender needs a longer window. Then:

1. Identify subscribers with zero opens and zero clicks over the window.
2. Send a short re-permission email with a single clear action ("keep receiving this, click here").
3. Suppress anyone who does not respond within two weeks.
4. Never re-add suppressed addresses, including via a new import.

Segment by engagement at send time. When you mail your most recent engagers first and your dormant tail last (or not at all), you keep complaint rates low on the segment most likely to complain. This is the same segmentation logic that industry guides put first in any list-building list, and the payoff is measurable in complaint rate rather than open rate.

The growth tactics that fill a list matter here too, because a list built on giveaways and popups carries lower intent. Guides to newsletter growth that emphasize a narrow reader and a clear promise produce cleaner lists than broad lead-magnet campaigns, and the result shows up as fewer complaints per thousand sends (Founderpath).

Set up a weekly review that takes fifteen minutes and covers five numbers: complaint rate in Postmaster Tools for each sending domain, hard and soft bounce rates from your ESP, DMARC aggregate report failures by source, click rate per campaign, and unsubscribe rate. Then run this checklist before you change any DNS record.

That last row matters more than most people expect: Gmail requires all senders to have SPF or DKIM plus valid forward and reverse DNS records, and bulk senders to have both (Gmail Help). If you send through a shared ESP you do not control the PTR, which is another reason to use a reputable provider and to verify its hostnames rather than assume.

When you need to test all of this at once, run a seed test. Send the campaign to a handful of addresses across Gmail, Outlook, Yahoo and Apple, then read the raw headers for each. You are checking for pass results on each authentication method and alignment to your From domain. A seed test takes minutes and catches most misconfigurations before a real campaign does.

If the operational side is not where you want your engineering hours to go, describe the setup you need and let a specialist build it with you at Quanta. The work is a checklist, not a research project, but the DNS records have to be right the first time you enforce.