Deliverability is an operating discipline, not a settings page.

Authentication foundations

Three mechanisms carry almost all of the authentication signal a receiving mailbox provider uses. They do different jobs and they fail in different ways, which is why deploying only one of them tends to produce confident but incorrect conclusions.

SPF

SPF publishes, in DNS, the set of hosts permitted to send mail for a domain. The critical and frequently misunderstood detail is which domain it checks: SPF validates the envelope sender — the MAIL FROM address, also called the Return-Path — and separately the HELO/EHLO identity. It does not look at the From: header that the recipient sees.

example.eu.  IN TXT  "v=spf1 include:_spf.provider.example ip4:203.0.113.0/28 -all"

Two constraints shape every SPF record we write:

• The ten-lookup limit. Evaluating a record may trigger at most ten DNS-querying mechanisms (include, a, mx, ptr, exists, and redirect). Exceeding it yields a permerror, which many receivers treat as a failure. Nested include chains from large SaaS vendors consume this budget quickly, and a record that passed last year can silently break when a vendor expands their own record.
• SPF does not survive forwarding. When a message is forwarded, the forwarding host typically keeps the original envelope sender while sending from its own IP, so SPF fails at the destination. This is expected behaviour, not a misconfiguration, and it is the single strongest reason not to build a DMARC policy that depends on SPF alone.

We generally publish -all (hard fail) once the sending-source inventory is complete and verified, and ~all (soft fail) while that inventory is still being established.

DKIM

DKIM attaches a cryptographic signature over selected headers and the message body, carried in a DKIM-Signature header. The signing domain appears in the d= tag and the key is located by the s= selector, published at <selector>._domainkey.<d=domain>.

s1._domainkey.example.eu.  IN TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

Practical guidance we apply:

• Use 2048-bit RSA keys. 1024-bit keys are still accepted almost everywhere but are no longer a defensible choice. A 2048-bit public key exceeds the 255-character limit of a single DNS character-string, so the TXT record must be split into multiple quoted strings — a common source of "the key looks right but validation fails".
• Rotate selectors, do not edit keys in place. Publish a new selector, begin signing with it, and retire the old key only after messages signed with it have aged out of any plausible retry window.
• Avoid the l= body-length tag. It permits content to be appended below the signed portion without breaking the signature, which is a real abuse vector and buys almost nothing.
• Ed25519 signatures are specified and attractively compact, but receiver support remains uneven. Where they are used at all, they should be sent alongside an RSA signature rather than instead of one.

DKIM's decisive advantage is that a signature survives simple forwarding, because it travels in the message rather than depending on the connecting IP. It breaks when an intermediary modifies the message — the classic case being a mailing list that appends a footer or rewrites the subject.

DMARC

DMARC ties the other two mechanisms to the address the recipient actually sees, and tells receivers what to do when that tie fails. The policy lives at _dmarc.<domain>.

_dmarc.example.eu.  IN TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.eu; adkim=r; aspf=r; fo=1"

Alignment, and why it is where audits fail

Alignment comes in two modes, set independently for each mechanism via adkim and aspf:

• Relaxed (r, the default) requires only that the organizational domains match. mail.example.eu aligns with example.eu.
• Strict (s) requires an exact match. Here mail.example.eu does not align with example.eu.

The overwhelmingly common failure we find in audits is a third-party platform that authenticates correctly under its own domain and is therefore reported as "passing SPF" by every basic checking tool, while producing zero aligned DMARC passes. The bounce domain is the vendor's, the DKIM d= is the vendor's, and the From: is yours. Nothing aligns. The fix is a delegated subdomain and a customer-specific DKIM key — supported by essentially every serious platform, and switched on by remarkably few of their customers.

Because DKIM survives forwarding and SPF does not, we treat aligned DKIM as the primary path to a DMARC pass and aligned SPF as a useful secondary. Estates that reach enforcement on SPF alignment alone tend to generate a long tail of complaints from users whose mail is auto-forwarded to a personal account.

Getting to enforcement without breaking mail

Enforcement means a published policy of p=quarantine or p=reject. Reaching it safely is a measurement exercise, and the only acceptable starting point is p=none with aggregate reporting enabled.

1. Publish p=none with rua=. Collect aggregate reports for at least two full billing or campaign cycles. Monthly senders — invoicing, payroll, statutory notices — will not appear in a two-week sample.
2. Build the sending-source register. Every source that appears in the reports gets an owner, a business justification and a target authentication state. Sources nobody can account for get investigated, not blocked on sight.
3. Fix alignment source by source, starting with the highest volume. Delegated subdomains and per-tenant DKIM keys resolve most of it.
4. Handle the intermediaries. Mailing lists and forwarding services that modify messages will keep failing. ARC lets a participating receiver see that authentication passed before the message was altered, but it is an input to the receiver's judgement, not a guarantee.
5. Move subdomains first. Set sp=quarantine while the organizational domain remains at none. This exercises enforcement against a smaller blast radius. A separate tag for non-existent subdomains is available in current DMARC implementations and lets you reject mail from subdomains that never legitimately send.
6. Ramp deliberately. Move to p=quarantine and hold for several weeks with reporting under active review before considering p=reject. The pct= tag is widely honoured today and is useful for a partial ramp, though the DMARC revision progressing through the IETF removes it — so treat a percentage ramp as a temporary aid rather than a permanent configuration.

We do not move a client to p=reject before a Friday, before a month-end close, or before anyone's holiday. This is not superstition; it is that enforcement failures are invisible to the sender and are reported by recipients, who need someone available to report them to.

The full sequence, with the specific report fields we key on, is written up in Getting DMARC to enforcement without breaking mail.

Reputation monitoring

Mailbox providers score senders on observed behaviour. Domain reputation has steadily grown more important than IP reputation, which matters because a domain carries its history across an infrastructure change while an IP does not.

The signals we track, roughly in order of influence:

• Complaint rate. The proportion of delivered messages marked as spam. Sustained rates above roughly 0.3% of delivered mail attract active filtering at the major providers; a healthy operational target is below 0.1%.
• Unknown-user rate. Repeatedly sending to addresses that do not exist is read as a signal that the list was not collected properly. This is the fastest self-inflicted reputation damage available.
• Spam trap hits. Recycled traps are formerly valid addresses that have been abandoned and repurposed — hitting one indicates stale list hygiene. Pristine traps have never been valid or opted in, and hitting one indicates scraped or purchased data. The second is far more damaging.
• Engagement. Opens, replies, moves out of spam and deliberate deletions without reading all feed provider-side models. Recipients who consistently ignore your mail suppress placement for the recipients who do not.
• Volume consistency. Steady, predictable volume reads as legitimate. A sender who transmits nothing for six weeks and then dispatches 200,000 messages looks exactly like a compromised account.
• Authentication consistency. Not merely passing, but passing reliably from a stable set of sources.

We enrol every client in the free postmaster tooling the major providers publish — Google Postmaster Tools and Microsoft SNDS being the ones with the widest reach — and monitor blocklist position continuously. On blocklists we are selective: a handful genuinely influence delivery, and a great many exist mainly to sell delisting. We alert on the former and record the latter without waking anyone.

We also separate sending streams by subdomain. Transactional mail (password resets, invoices, delivery notifications) should not share reputation with marketing mail, because the two have entirely different engagement profiles and the transactional stream is the one that must never be delayed.

Warmup strategy

A new IP address or a newly sending domain has no reputation, and unknown senders are treated conservatively. Warmup is the process of establishing a track record at a volume the receiver will accept.

• Ramp gradually. Begin at a low daily volume and increase over two to six weeks depending on target volume. Roughly doubling daily volume, while watching deferral rates, works well; back off a step whenever 4xx deferrals rise rather than pushing through them.
• Send to your best recipients first. Start with the segment that has opened or replied most recently. Early positive engagement is what the receiving models are looking for, and the order matters more than the total.
• Ramp per provider, not in aggregate. Each major mailbox provider maintains its own view. A domain can be in good standing at one and throttled at another on the same day.
• Warm the domain, not just the IP. If the sending domain is also new, it needs its own history. Moving a well-warmed domain onto a new IP is considerably less disruptive than the reverse.
• Have authentication complete before the first message. Warming up while SPF and DKIM are still being fixed means building a reputation that partly reflects failed authentication.

Warmup is also the correct time to decide against a dedicated IP. Below roughly a few hundred thousand messages a month, a well-managed shared pool usually produces better placement than a dedicated address that never accumulates enough volume to establish a stable reputation.

Bounce and complaint handling

Bounce processing is the least interesting part of deliverability and the part most often left half-built. The distinction that matters is between a permanent and a transient failure.

The classification must be automatic and it must feed a suppression list that every sending system consults. Parsing the enhanced status code from the delivery status notification is more reliable than pattern-matching the human-readable text, though in practice a well-maintained rule set for the largest providers is needed alongside it, because the free-text portion often carries the actual reason.

Suppression lists must be shared across sending platforms. An address that hard bounced from the invoicing system and is still being mailed by the CRM three weeks later is the most common cause of an unknown-user rate that will not come down.

Finally, a sunset policy: recipients who have not engaged in a defined period stop receiving non-transactional mail. This is uncomfortable to propose and reliably improves placement for everyone still on the list.

Feedback loops and unsubscribe handling

A feedback loop delivers a report to the sender when a recipient marks a message as spam. Enrolment differs by provider and by whether you send on your own infrastructure or through a platform:

• Several large providers offer direct enrolment tied to the sending IP ranges, delivering complaint reports in ARF format to a nominated address.
• Others provide aggregate complaint-rate reporting rather than per-message reports, and expose per-stream detail only to registered high-volume senders who tag their traffic with a header identifying the campaign or stream.
• Where mail is sent through a platform, complaints usually arrive via the platform's own reporting rather than directly. Verifying that this data actually reaches your suppression list is part of every audit we run.

Alongside feedback loops, one-click unsubscribe is now effectively mandatory for bulk senders at the major consumer providers. That means both a List-Unsubscribe header offering an HTTPS endpoint and the List-Unsubscribe-Post header that lets a mail client complete the unsubscribe without the recipient visiting a page — and the request must be honoured promptly, within two days, without a confirmation step or a login.

Review cadence

Deliverability degrades quietly. New sending sources appear when a department buys a tool, vendor SPF includes expand past the lookup limit, and DKIM keys get rotated by someone who did not know the old selector was still in use. Retainer clients get a fixed cadence: