SPF & DKIM Configuration Service

SPF and DKIM are the foundation every other piece of email authentication stands on. DMARC cannot enforce anything without them, BIMI cannot render, and a sender that gets them wrong fails authentication no matter how good everything above looks. They are also deceptively easy to publish and genuinely hard to get right — SPF has a limit that silently breaks it at scale, and DKIM has an alignment subtlety that defeats most first attempts. This page explains what each one does, the specific ways they fail, and how a proper configuration gives DMARC the solid base it needs.

What are SPF and DKIM, and why both?

SPF and DKIM solve the same broad problem — proving mail is genuinely from you — in two different, complementary ways. SPF, the Sender Policy Framework, is a DNS record that lists which servers are authorised to send mail for your domain; a receiver checks the sending server’s IP against that list. DKIM, DomainKeys Identified Mail, attaches a cryptographic signature to each message using a private key, which the receiver verifies against a public key you publish in DNS, confirming the message was signed by you and not altered in transit. One authenticates the server, the other authenticates the message. Neither alone is sufficient: SPF says nothing about whether the content was tampered with and breaks when mail is forwarded, while DKIM on its own gives receivers no list of who may send. Together they cover each other’s gaps, and DMARC sits on top to tie both to the domain your recipients actually see.

The mailbox providers now expect both, not one or the other. Since the bulk-sender requirements took effect, SPF and DKIM together are the baseline, and a sender presenting only one is treated as incompletely authenticated.

The two differ in ways that explain why you need both:

Read across the table and the complementarity is obvious: SPF’s weakness on forwarding is DKIM’s strength, and DKIM’s reliance on correct signing is backstopped by SPF authorising the server. DMARC then requires that at least one of them not only pass but align with your From domain, which is why a setup needs both done well rather than either done adequately.

What is SPF, and how does it actually work?

An SPF record is a single DNS TXT entry beginning with v=spf1, listing the mechanisms that authorise senders — include for third-party services, a and mx for your own hosts, ip4 and ip6 for specific addresses — and ending with an all qualifier that says what to do with everything else. When a receiver gets mail claiming to be from your domain, it looks up this record and checks whether the sending server is authorised. There is one crucial subtlety that catches almost everyone: SPF authenticates the hidden return-path domain — the envelope sender — not the visible From address your recipients see. This is why SPF alone does not stop someone spoofing your From address, and precisely why DMARC’s alignment check exists. A message can pass SPF on a domain that has nothing to do with the From line, which looks fine to SPF and fails DMARC.

The 10-lookup limit that breaks SPF

This is the single most common SPF failure, and it is invisible until it happens. SPF allows a maximum of ten DNS lookups when evaluating a record, and several mechanisms — every include, a, mx, ptr, exists and redirect — count against that limit. The trap is that each include for a vendor can itself contain more includes, so adding a handful of email services quietly pushes you past ten. When that happens, SPF does not just ignore the extra lookups; it returns a PermError and fails entirely, taking all of your SPF authentication down with it. Worse, a record that was comfortably under the limit last year can cross it this year with no change on your side, simply because a vendor expanded the includes inside their own record. The remedy is to keep the record lean and, where necessary, flatten it — replacing includes with the literal IP ranges they resolve to — but flattening trades one problem for another, because those IPs change and a flattened record needs monitoring to avoid silently authorising the wrong servers or dropping legitimate ones. Managing the lookup budget is ongoing work, not a one-time edit.

Should SPF end in -all or ~all?

The final qualifier on an SPF record decides what receivers do with mail from servers not on your list, and the choice signals how confident you are. -all, the hardfail, instructs receivers to reject unauthorised mail outright. ~all, the softfail, tells them to accept it but treat it as suspicious. Neither +all, which authorises anyone and defeats the purpose, nor ?all, which is neutral, belongs on a real domain. The right choice depends on your stage: during initial setup, ~all is the safer qualifier because it will not bounce legitimate mail from a source you have not yet accounted for, while once DMARC is enforcing and your sending sources are confirmed, -all is stronger because it removes ambiguity and lets DMARC do the policy work cleanly. Defaulting to one without thought is how setups either stay permanently soft or break legitimate mail; we set it to match where you actually are.

What is DKIM, and why does alignment matter?

DKIM works by key pair. A private key, held by your sending system, signs each outgoing message, adding a DKIM-Signature header that names the signing domain (d=) and a selector (s=); the matching public key is published in DNS at selector._domainkey.yourdomain.com, where receivers fetch it to verify the signature. If the signature checks out, the receiver knows the message was signed by the holder of that key and was not altered in transit. So far, so straightforward — and then alignment enters and undoes most setups. DMARC does not just want DKIM to pass; it wants the signing domain to match your visible From domain. The default behaviour of many vendors is to sign your mail with their domain in the d= field, which passes DKIM perfectly but does not align with your From address, so DMARC fails anyway. The fix is to configure each sender to sign with your domain — usually through a CNAME delegation or hosted DKIM keys the vendor signs on your behalf — so the signature aligns. This is the difference between DKIM that merely passes and DKIM that actually supports DMARC, and it is the single most overlooked step in authentication.

The reason this trips up so many setups is that everything looks correct from the outside. The vendor’s documentation says DKIM is enabled, an authentication checker shows DKIM passing, and the mail sends without obvious problems — so the gap is invisible right up until DMARC moves to enforcement and that stream starts failing. We check alignment explicitly, per sending source, rather than trusting that “DKIM is on” means “DKIM aligns,” because the two are different claims and only the second one lets DMARC do its job. Where a vendor genuinely cannot sign with your domain, that is itself a finding worth knowing before you tighten DMARC, not after legitimate mail starts bouncing.

Key length and the 2048-bit standard

DKIM key length matters, and the bar moved. The 1024-bit keys that were standard years ago are now considered a security risk, weak enough that the major providers expect 2048-bit keys, and a setup still on 1024-bit is overdue for an upgrade. The practical snag is purely about DNS: a 2048-bit public key is longer than the 255-character limit of a single DNS TXT string, so it has to be published as several quoted strings concatenated together. Plenty of setups stumble here, hitting a “value too long” error from the DNS provider and assuming something is broken, when the key is fine and only needs splitting correctly. We generate 2048-bit keys, publish them in the right split format for your DNS host, and verify they validate end to end rather than leaving you to discover the formatting problem later.

Selectors and key rotation

The selector is the part of DKIM that makes good key hygiene possible. Because the signature names a selector and the public key lives at that selector’s DNS location, you can publish several keys at once under different selectors — one per sending service, which keeps vendors independent, and a fresh one when you rotate. Rotation matters because a private key that never changes is a standing risk: if it is ever exposed, every message it can forge stays forgeable until the key is retired. Rotating safely uses selectors to avoid any gap — you publish a new key under a new selector, switch signing to it, confirm mail is validating on the new key, and only then retire the old selector, so no message is ever left unsigned. Many teams rotate on a six-to-twelve-month cadence, and some platforms automate it. The contrast that matters is between a setup where keys are placed once and forgotten and one where rotation is routine; we configure selectors so rotation is a planned operation rather than an emergency after a leak.

The subtle ways SPF and DKIM fail

Beyond the headline issues, a handful of quieter failure modes account for most of the remaining trouble. SPF authenticates the return-path, not the From, so mail can pass SPF on an unrelated domain — a gap only DMARC alignment closes. Forwarding breaks SPF entirely, because the forwarding server’s IP is not in your record, which is why DKIM alignment is prioritised for DMARC since DKIM survives forwarding when the message is unmodified. Subdomains do not inherit the root domain’s SPF, so each sending subdomain needs its own record. Publishing two v=spf1 records on one domain is itself a PermError, not a redundancy. And the recurring DKIM failure is the unaligned vendor signing with its own domain. None of these is exotic, and all of them are invisible in casual testing — they surface as a fraction of mail quietly failing, which is exactly what a careful configuration prevents.

# mcsnet · spf/dkim check · brand.example
spf record   1 record · v=spf1 … -all
spf lookups  8 / 10  (lean · flattened mailwizz include)
dkim         selector s1 · 2048-bit · published (split ok)
dkim align   d=brand.example  aligned to From
vendor dkim  crm signing with own domain → FIX (delegate)
next         delegate crm dkim to align before dmarc reject

How we configure SPF and DKIM

Our setup is methodical because the failure modes are specific. We inventory every service that sends as your domain, then build a single SPF record that authorises all of them while staying safely under the lookup limit — flattening where a vendor’s includes would push you over, and monitoring those flattened ranges so they do not silently drift. We generate 2048-bit DKIM keys and, critically, configure each sending service to sign with your domain so the signatures align, delegating via CNAME where the vendor supports it. We set the SPF qualifier to match your stage, lay out selectors so future rotation is clean, and verify the whole configuration in independent checkers. Because we also host your sending infrastructure and run your DMARC rollout, the signing and the alignment are fixed at the source rather than negotiated through vendor support tickets — which is the difference between SPF and DKIM that merely exist and the kind DMARC can actually enforce on.

Why work with us?

Two reasons. First, data and consent: we configure authentication on your infrastructure hosted in Toronto under PIPEDA, with a CASL-aware approach that treats authentication as part of legitimate sending. Second, operator depth: SPF and DKIM punish small mistakes invisibly — a lookup over budget, a key that did not split, a vendor signing with the wrong domain — and you get operators who know exactly where these break and fix them at the source. Pairing the people who run your sending with the people who authenticate it keeps the two aligned as your sending landscape changes, which is harder when authentication is handled by a separate party who cannot see the infrastructure.

Who this is for, and who it is not

It is for any sender that needs SPF and DKIM done correctly as the foundation for DMARC — bulk senders meeting the mandatory requirements, teams whose SPF is failing with PermErrors or whose DKIM passes but will not align, and anyone with multiple vendors where the lookup budget and per-sender signing are real work. It is also for senders still on 1024-bit keys who need to upgrade safely. It is not strictly necessary for a tiny single-platform sender whose provider already publishes a correct SPF record and aligned 2048-bit DKIM — though a quick check is worthwhile, since the lookup limit and alignment gaps hide easily. SPF and DKIM are the base of the stack: they sit beneath DMARC, inside the broader authentication setup, and alongside PTR and reverse DNS configuration. Get them lean, aligned and rotating, and everything above them has something solid to stand on.