Email Deliverability: SPF, DKIM and DMARC Done Right

Most deliverability advice tells you to "set up SPF, DKIM and DMARC" and stops there. The records themselves are a few lines of DNS. What actually determines whether your mail lands is whether those records are correct under real conditions: forwarded messages, third-party senders, subdomains and the gradual rollout of enforcement that turns a misconfiguration from a warning into a silent outage.

What each record actually proves

SPF answers a narrow question: did this message originate from a server that the domain owner authorised? It is a list of IP addresses and includes, evaluated in order, capped at ten DNS lookups. It authenticates the envelope sender, not the visible From header, which is the detail most teams miss.

When a message is forwarded by a mailing list, the envelope sender is often rewritten, so SPF fails even though nothing is wrong.

DKIM takes a different approach. The sending server signs selected headers and the body with a private key, and publishes the public key in DNS at a selector you choose. Because the signature travels with the message, it survives forwarding intact.

This is why DKIM is the record that matters most in practice, and why a message can fail SPF and still pass authentication overall.

DMARC does not authenticate anything itself. It tells receiving servers what to do when SPF and DKIM disagree with the visible From domain, and where to send reports. That alignment requirement is the point: DMARC closes the gap where a message passes SPF for one domain while claiming to be from another.

The failure modes that do not show up in a checker

An online DNS checker will happily report all three records present and green while your mail still fails. The common reasons:

• Two SPF records. RFC 7208 permits exactly one. A second record causes a permanent error rather than a merge, and many DNS panels allow you to create it without complaint.
• Lookup limit exceeded. Includes are counted recursively. A record with several third-party includes can exceed ten lookups, at which point SPF returns a permanent error and fails outright.
• DKIM selector mismatch. Providers rotate keys and expect you to publish the new selector. If you only add, never remove, you accumulate stale selectors that some receivers still try to use.
• DMARC on the wrong subdomain. SPF and DKIM need SPF and DKIM records; DMARC is published at _dmarc.yourdomain and applies to subdomains only through its sp policy setting.
• Alignment failure. A third-party sender may pass SPF for its own domain and pass DKIM, yet still fail DMARC because neither aligns with your From domain.

Rolling out DMARC without losing mail

Do not begin at enforcement. Start at p=none with a reporting address, and collect aggregate reports for at least two weeks. The reports are XML and unreadable raw; use a parser. What you are looking for is every source sending mail as your domain, including ones you have forgotten about: an old marketing tool, an invoice system, a developer's laptop using a local SMTP relay.

Once the legitimate sources are all authenticating, move to p=quarantine with a percentage below 100 so you can watch the effect before it applies broadly. Only then move to p=reject. Teams that skip straight to reject frequently discover an unmonitored sending source the hard way, when transactional mail stops arriving and customers notice before the engineering team does.

How this looks inside Cresca

Cresca sends from your own authenticated domain. You publish the SPF include and the DKIM selector it provides, then verify. Because sending runs through a queued pipeline rather than synchronously, a mailbox provider throttling your connection does not cause lost messages; they are retried with backoff, and permanent failures are recorded so they stop consuming retry capacity.

Bounce and complaint events flow into the same event stream that drives automation and analytics. That matters for authentication work because a hard bounce recorded in one place and ignored in another is how a suppressed address gets mailed again, and repeat delivery attempts to addresses that no longer exist are one of the fastest ways to damage a sending reputation.

Subdomains and the sending-domain decision

A separate sending subdomain is usually worth the setup. It isolates your marketing reputation from your transactional reputation, so a complaint spike on a campaign does not affect password resets. It also gives you a clean reputation history to warm without dragging in whatever the root domain accumulated from previous tools.

The tradeoff is that a new subdomain starts with no history at all, which means slow ramp-up. If you already send marketing from the root domain and it has good standing, moving can temporarily reduce placement. Decide once and commit: switching sending domains repeatedly resets the clock each time.

A worked rollout order

The sequence matters, because each step depends on the previous one being verified.

1. Publish DKIM first. It survives forwarding, so it is the record that does the most work.
2. Fix SPF to exactly one record, and count the lookups to confirm you are under ten.
3. Send a test and read the headers. Confirm DKIM passes with the selector you published.
4. Publish DMARC at p=none with a reporting address and wait two weeks.
5. Work through the reports and authenticate every legitimate source you find.
6. Move to p=quarantine;pct=25, watch for a week, then raise the percentage.
7. Move to p=reject only once aggregate reports show full alignment for a sustained period.

If you send through multiple systems, repeat the authentication steps for each one. A single unauthenticated path is enough to fail DMARC for messages that look identical to your authenticated ones.

Verifying it actually works

Send to a seed address at each major provider and read the full headers. Look for Authentication-Results and confirm three outcomes: spf=pass, dkim=pass with the selector you expect, and dmarc=pass. A result of dmarc=pass via SPF only, with DKIM failing, means forwarding will break your alignment and you should fix DKIM before you enforce.

Repeat this after any change to DNS, any provider migration and any new sending integration. Authentication is not a one-time setup; it is a property that quietly decays as infrastructure changes around it.

Pricing

Authentication and deliverability tooling are included on every paid plan:

The short version

Publish exactly one SPF record and keep it under ten lookups. Publish DKIM and keep selectors current. Roll DMARC from p=none through quarantine, at partial percentage, to reject, with reporting active the whole way. Verify with real headers rather than a DNS checker, and re-verify after every infrastructure change. None of this is complicated, but all of it is easy to leave half-finished in a way that only becomes visible when mail stops arriving.