Authentication

DKIM signing — automatic rotation, no DNS arguments.

Every outbound mail is signed with a domain-specific key. MailGuard generates the keys, rotates them yearly with a 30-day DNS lead time and hands the operator the ready-to-paste DNS TXT record. Operator clicks "Activate", everything else runs automatically.

Why DKIM at all

DKIM (DomainKeys Identified Mail, RFC 6376) is the industry standard for authenticating outbound mail. Together with SPF and DMARC it forms the three pillars of modern mail authentication. Without DKIM:

  • Microsoft 365, Gmail and every major recipient mail server flag your mail as suspicious or drop it straight to spam
  • DMARC reject policies of other domains protecting against you become impossible (DKIM is a prerequisite)
  • Spoofing attacks against your domain cannot be defended technically
  • Marketing senders (newsletters, transactional mail) suffer from poor deliverability

How the workflow runs

  1. Add domain — operator creates a new domain in the UI, MailGuard generates an RSA-2048 or ed25519 key immediately (selectable).
  2. Copy DNS record — the UI shows the ready TXT record the operator pastes at their DNS provider: default._domainkey.example.com with the public key.
  3. Activate — operator clicks "Activate DKIM". MailGuard checks via DNS lookup that the record is live and switches signing on if so.
  4. Sign outbound — every mail going through MailGuard is signed with the private key. Recipient mail servers verify against the DNS public key.

Automatic yearly rotation

Key material ages. NIST and IETF recommend yearly DKIM rotation — a key that has been in DNS for five years and lives on the disks of former employees is a risk. MailGuard automates rotation:

  1. Day 335 (30 days before expiry): MailGuard generates a new key and shows the operator the DNS record for the new selector in the UI. The old key remains active and continues signing outbound mail.
  2. Day 335 – 365: the operator has 30 days to publish the new DNS record. The UI shows the status ("New key in DNS — ready to activate" or "Waiting for DNS").
  3. Day 365: operator clicks "Activate new key". From now on signing uses the new key. The old key DNS record can be removed after another 30 days (by then in-flight mails are safely delivered).

If the operator does nothing, the old key keeps running — no hard cliff edge. UI reminders nudge about open DKIM rotations.

RSA 2048 or ed25519?

Selectable per domain. Recommendation:

  • RSA 2048 — universally supported, every recipient mail server understands it. Default for new domains.
  • ed25519 — shorter signatures, faster verification, modern. Caveat: some older mail recipients (Exchange Server <2019) don't verify ed25519. RSA 2048 is the safe bet when recipient diversity is unclear.

Multi-domain in a cluster

In a cluster with multiple tenants every domain has its own keys. Key synchronisation between cluster nodes happens automatically — mail leaving on node 2 is signed with the same key as if it had left on node 1. The operator manages keys in one central place, all nodes pick up the change.

DKIM without operator maintenance windows.

Key generation, rotation, DNS workflow — automated. Per-domain keys in a multi-domain setup.

See pricing