Hosted DKIM management

DKIM is the part of email authentication that proves a message really came from your domain and was not altered on the way. It works by attaching a cryptographic signature to each message and publishing the matching public key in your DNS. Unlike SPF, a DKIM signature keeps verifying after a message is forwarded, which is why it carries most of the weight when mailbox providers decide whether to trust you. Hosted DKIM from DMARC Engine generates the keys, publishes the selectors, and tracks which of your sending services are actually signing as your domain.

What DKIM actually is

DKIM stands for DomainKeys Identified Mail. When a sending server processes a message, it hashes selected headers and the body, signs that hash with a private key, and adds the result as a DKIM-Signature header. The receiving server reads the header, fetches the matching public key from DNS, and checks the signature. If the signature verifies, the receiver knows two things: the message was authorised by whoever controls the signing domain, and the signed content was not changed in transit.

The public key lives in a TXT record at a predictable location. If your signing domain is yourcompany.com and the signature names the selector s1, the receiver looks up s1._domainkey.yourcompany.com. The private key never leaves the sending service. That asymmetry is the whole point: anyone can verify, only you can sign.

Anatomy of a signature

A real DKIM-Signature header packs several tags into one line. The ones that matter most are the signing domain (d=), the selector (s=), the list of headers that were signed (h=), and the signature itself (b=). A simplified example:

DKIM-Signature: v=1; a=rsa-sha256; d=yourcompany.com; s=s1; h=from:to:subject:date; bh=...; b=...

The d= value is the claim being made: this domain takes responsibility for the message. The receiver pulls the key from s1._domainkey.yourcompany.com, recomputes the hash over the headers in h= plus the body, and compares. If a forwarding server adds a footer or rewrites the subject, the body hash no longer matches and the signature breaks. Good signing services know to sign a stable set of headers and to use relaxed canonicalisation, which tolerates harmless whitespace changes.

Why DKIM survives forwarding and SPF does not

This is the practical reason DKIM exists alongside SPF. SPF checks the IP address of the server that connected, against the list of IPs you authorised. The moment a message is forwarded, the connecting IP changes to the forwarder, and that IP is not in your SPF record, so SPF fails. A mailing list, a university alumni address that redirects to a personal inbox, an accounts@yourcompany.com alias that fans out to three people: all of these break SPF.

DKIM does not care which server made the connection. The signature travels inside the message. As long as the forwarder does not mangle the signed headers or the body, the signature still verifies at the final destination. For DMARC to pass, you need either SPF or DKIM to align, and because SPF is fragile across forwarding, a properly aligned DKIM signature is what keeps your legitimate forwarded mail from being marked as a failure.

Neither replaces the other. Read more on the hosted SPF page for how flattening keeps you under the lookup limit, and on how alignment works for the rule that ties both back to your From address.

Selectors and why they let you rotate without downtime

A selector is just a label that points to one key. You can publish several at once: s1._domainkey, s2._domainkey, a per-service name like google._domainkey, or a dated one like 2026q2._domainkey. The signature names which selector signed it, so the receiver always knows which key to fetch.

That design is what makes key rotation safe. To rotate, you publish the new key at a new selector, switch the signing service to use it, confirm that fresh mail verifies against the new selector, and only then remove the old key from DNS. At no point is there a gap where mail in flight cannot be verified, because both keys are live during the changeover. Trying to rotate a single key in place, by overwriting the same record, guarantees a window where messages signed with the old key fail against the new public key. Selectors exist precisely to avoid that.

Key length: 1024 versus 2048-bit

DKIM keys are RSA. The standard allows 1024-bit and 2048-bit keys. A 1024-bit key was the common default for years and many old setups still use one. The problem is that 1024-bit RSA is now considered weak, and several large mailbox providers have moved to expecting 2048-bit keys. A weak key is a real exposure: if an attacker factored your key, they could forge signatures that pass DKIM as your domain.

There is one historical reason people stayed on 1024-bit. A 2048-bit public key is longer, and some DNS providers used to struggle with TXT records over 255 characters, which forced the value to be split into multiple quoted strings. Modern DNS hosts handle this without trouble. The recommendation today is straightforward: generate 2048-bit keys, and treat any 1024-bit selector still in use as something to rotate out.

DKIM alignment for DMARC

A valid signature is not automatically useful for DMARC. DMARC requires alignment, which means the d= domain in the signature must match the domain in the visible From address. A message from hello@yourcompany.com signed with d=yourcompany.com aligns. The same message signed only with d=mail.sendingplatform.com verifies as a perfectly valid signature, but it does not align, because the signing domain is not your From domain.

This is the trap with shared sending platforms. Many email service providers sign every customer's mail with a generic provider domain by default. The signature passes DKIM, the provider's deliverability looks fine, but for your DMARC record the result is a failure on the DKIM side. If SPF is also unaligned, the message fails DMARC outright, and once you move to p=quarantine or p=reject it gets filtered or refused.

The fix is to set up your own domain DKIM with each provider, so they sign as d=yourcompany.com using a selector they control under your DNS. Almost every reputable platform supports this, often labelled "custom DKIM", "authenticated domain", or "dedicated signing domain". Once configured, the signature aligns and DMARC counts it as a pass.

Per-sender DKIM: every service signing as you

Most organisations send from more than one place. A typical estate might include a primary mailbox provider for staff mail, a marketing platform for newsletters, a transactional service for receipts and password resets, a help-desk tool, a CRM, and a billing or payroll system. Each of these is a separate sending service, and each needs its own DKIM setup so it signs as your domain.

That usually means a different selector per service. Your marketing tool might sign with mkt._domainkey, your transactional service with txn._domainkey, and your mailbox provider with its own. They all sign as d=yourcompany.com but with separate keys, which is exactly what you want: independent keys you can rotate one at a time, and clear visibility over which service signed any given message.

The common failure is the forgotten sender. A team signs up for a new tool, starts sending invoices through it, and nobody configures DKIM. That mail goes out unsigned or signed with the vendor's domain, fails alignment, and either lands in spam or gets rejected once your policy is at enforcement. The only reliable way to catch this is to read your DMARC aggregate reports, which list every source sending as your domain and whether each one passes. That is what the hosted DMARC service is for.

Rotation hygiene and the risk of stale keys

Keys are not set-and-forget. Good practice is to rotate signing keys on a regular cadence, commonly every six to twelve months, and immediately if you suspect a private key has been exposed. Rotation limits how long a single key is worth attacking and keeps your setup current with provider expectations.

Stale keys cause two separate problems. A key left at 1024-bit is a weakness in its own right. Worse is the abandoned selector: a _domainkey record for a service you stopped using months ago, still live in DNS, whose private key may be sitting in a decommissioned system or an old vendor account. If that private key leaks, an attacker can forge aligned, DKIM-passing mail as your domain. Removing selectors you no longer use is as important as adding the ones you do.

What hosted DKIM with DMARC Engine does

Doing all of this by hand across half a dozen senders is where most setups slip. Hosted DKIM gives you one place to manage the whole estate.

• Generate key pairs. We create 2048-bit key pairs and hand you the exact public key record to publish, or publish it for you on a delegated domain.
• Publish and name selectors. Each sending service gets its own selector, named consistently so you can tell at a glance which key belongs to which sender.
• Track signed and aligned senders. By reading your DMARC reports, we show which services are signing as your domain, which are aligned, and which are quietly failing.
• Prompt rotation. We flag keys that are due for rotation, still at 1024-bit, or attached to a selector that no longer signs any mail, so weak and stale keys do not linger.

DKIM is one leg of a larger posture. It pairs with SPF and rolls up into DMARC, which is the policy that finally lets you tell receivers to reject anything that fails. Enforcement is a one-time fee of £200 as an introductory offer, with ongoing monitoring at £19 per month; see pricing for the detail.

Getting started

If you are not sure what is currently signing as your domain, start with a free check. A free scan reads your public DNS and shows which selectors exist, what key length they use, and where DKIM is present at all. From there you can fix the gaps in order: get every sender signing as your own domain, move any 1024-bit keys to 2048-bit, and retire selectors that no longer earn their place. When you are ready to manage it properly, you can sign up and let hosted DKIM keep the keys, selectors and rotations in order.

DKIM is the quiet workhorse of email authentication: a signature that proves authorship and integrity, and the one signal that holds up when your mail is forwarded. Its value depends entirely on the details, signing as your own domain so the result aligns, using 2048-bit keys, and keeping selectors current as senders come and go. Get those right and DKIM becomes the dependable foundation that DMARC enforcement is built on.