DKIM explained for small businesses.

What does it do?

When your outbound mail server sends a message, it takes the important headers (From, To, Subject, Date, Message-ID) and the body, hashes them, and signs the hash with a private key. The signature goes into a header named DKIM-Signature. Receiving servers fetch the matching public key from a TXT record at <selector>._domainkey.yourdomain.com.au and verify the signature. If the verification passes, the receiver knows two things: the message really came from a system that holds your private key, and nothing important has changed since the signature was added.

The clever piece is the selector. You can publish multiple keys at the same time under different selector names. That is how providers rotate keys without an outage: they bring a new selector online, switch signing to it, then retire the old one once mail in flight has been delivered. It is also how a single domain can have many different services signing on its behalf in parallel without stepping on each other.

DKIM does not authorise senders by IP, the way SPF does. Instead it proves that whoever sent the message had access to the private key. That distinction matters when a message gets forwarded through a mailing list or a forwarding rule: the IP changes, SPF breaks, but the DKIM signature keeps verifying so long as the body and signed headers were left alone.

Why it matters

Consider a small Brisbane web agency that sends quotes from Microsoft 365 and invoices from Xero. DKIM is configured for Microsoft but never set up for Xero. A client's receiving server applies DMARC strictly, sees that the Xero invoice passes SPF for Xero's envelope but has no DKIM signature from the agency's domain, fails alignment, and quarantines the message. The invoice goes unpaid for three weeks because the client never looks in junk. The agency only discovers it when chasing the overdue payment. A working DKIM selector published for Xero in DNS removes the entire problem.

DKIM also protects messages that forward. SPF breaks the moment a recipient forwards your message to a different mailbox, because the forwarding server is not on your SPF list. DKIM survives forwarding intact, because the signature travels with the message. For any business whose customers forward emails to their accountant, lawyer or insurer, DKIM is the only auth result that actually stays valid.

How to set it up

Every modern mail and marketing platform gives you a DNS record to copy. The shape is always the same: a TXT record at a selector subdomain, containing the public key. You usually do not generate the key yourself — the provider does, and hands you the matching public half to publish.

• A typical Google Workspace DKIM record:

google._domainkey.yourdomain.com.au.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0..."

• Generate the key inside the provider console (Google Admin, Microsoft 365 Defender, Xero, Mailchimp).
• Publish the supplied TXT record at the supplied selector name.
• Enable signing in the provider console only after DNS has propagated.
• Repeat for every service that sends mail from your domain.

Test by sending a message to a Gmail address and looking at the Authentication-Results header. You want dkim=pass with header.d=yourdomain.com.au. If the d= value is your ESP's domain instead of yours, alignment will fail and DMARC will not credit the result.

Common mistakes

• Keys shorter than 1024 bits. Replace them with 2048-bit keys.
• Signing succeeds but the d= domain is not yours, so DKIM cannot align under DMARC.
• Selectors left over from former platforms. Old keys clutter DNS and can be harvested by attackers.
• Multiple TXT records on the same selector name. Most receivers will silently drop both.

How AttackEdge checks it

The AttackEdge scan probes for the common DKIM selectors used by major providers, verifies key strength, and flags weak or stale keys. We do not have a way to discover custom selectors that nobody publicises, so if your provider uses an unusual one, tell us inside the app. Full methodology on /what-we-check, with a live SPF, DKIM and DMARC scan available at the DMARC checker.