Default DKIM Architectures: Auditing SES, SendGrid, and Mailgun

Most administrators treat domain keys as a compliance hurdle rather than a cryptographic asset. They paste a handful of CNAME records into their DNS zone, wait for the vendor dashboard to glow green, and permanently erase the task from their memory. But if you actually parse the headers of the emails leaving your corporate domain, you will find that the architectural choices made by your Email Service Provider dictate your real-world security posture.

The default settings a vendor chooses for cryptographic algorithms, selector obfuscation, and key rotation schedules tell you exactly whether their engineering culture prioritizes ease of onboarding or actual defense. A platform that defaults to static text records is optimizing for fewer support tickets, while a platform mandating delegated authority is anticipating the inevitability of key compromise. Attackers know exactly how these providers construct their signatures out of the box, and they use that predictable infrastructure mapping to identify stale keys and domain takeover opportunities.

We are going to rip open the default configurations of the major transactional email platforms to see how their cryptographic defaults stack up. By examining the bare minimum requirements they force on new domains, we can identify exactly where their out-of-the-box settings leave enterprise defenders exposed to spoofing and alignment failures.

The Default Posture: Reading the Cryptographic Tea Leaves

Every signed message includes a selector, denoted by the s tag in the signature header, which tells the receiving mail transfer agent exactly where to query DNS for the public key. The composition of that header, defined in RFC 6376, is a public fingerprint of your internal security maturity. When an incident responder looks at an authentication results header and sees a 1024-bit RSA signature tied to a highly predictable selector name, they immediately know the sending organization relies entirely on vendor defaults.

The Threat Model for Static Keys

Cryptographic keys degrade over time. If an ESP generates a single keypair during the onboarding flow and requires you to publish the public key directly as a TXT record, that key will inevitably become permanent infrastructure. IT administrators are terrified of touching DNS records that affect email delivery, leading to environments where a single 1024-bit key signs corporate communications for a decade. In the event of a breach at the vendor level, or an accidental private key exposure via an overly broad GitHub commit, the lack of an automated rotation mechanism means an attacker has indefinite spoofing capability that perfectly aligns with your DMARC policy.

Forward-thinking providers have recognized that static infrastructure is indefensible. They push customers toward delegated CNAME records, allowing the vendor to manage the rotation of the underlying TXT records without requiring customer intervention. This completely abstracts the cryptographic lifecycle away from the client domain, but it requires profound trust in the vendor's internal key management system.

Analyzing AWS SES: Strict Enforcement and Alignment Traps

Amazon Simple Email Service is fundamentally designed for infrastructure engineers. Their Easy DKIM feature mandates CNAME delegation out of the gate, requiring you to publish three distinct records in your DNS zone. This structure allows AWS to rotate the underlying 2048-bit RSA keys automatically on a fixed schedule. They have completely deprecated the generation of 1024-bit keys for new domains, forcing a secure baseline that prevents downgrade attacks.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=example.com; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; t=1698765432; bh=...; h=Date:To:Subject:From; b=... — Standard AWS SES DKIM header snippet

Notice the selector string. SES generates thirty-two character alphanumeric obfuscated selectors by default. This makes passive DNS enumeration significantly harder for an external attacker. Unless an adversary has a copy of a signed email, they cannot easily guess the active or deprecated selectors associated with the domain, limiting their ability to hunt for abandoned legacy keys that might still be valid in the AWS control plane.

The SPF Fallback Problem

The operational catch with SES lies in how it handles the RFC 7489 DMARC alignment requirement. By default, SES routes messages using an amazonses.com return-path. This means SPF will always pass at the envelope level, but it will fail the DMARC alignment check against the domain in your From header. Consequently, your DMARC compliance relies entirely on the Easy DKIM signature surviving the transit. If a recipient configures a strict mail filter that alters the message body or rewrites a link, the DKIM body hash will mismatch, the signature will fail, and the message will hardfail DMARC because there is no aligned SPF result to act as a fallback. Administrators must proactively configure a custom MAIL FROM domain in SES to establish dual alignment, a step that is frequently skipped in initial deployments.

Analyzing SendGrid: Automated Security and Predictable Patterns

SendGrid addresses the onboarding friction of domain authentication by heavily promoting their Automated Security feature. Similar to AWS, this relies on CNAME delegation, allowing their backend systems to execute key rotation without requiring DNS tickets from the customer. When analysts compare sendgrid vs mailgun dkim architectures, the primary point of divergence is how aggressively the vendor forces you into this managed rotation path over direct key publication.

However, SendGrid makes a highly distinct architectural choice regarding selector nomenclature. Instead of obfuscated alphanumeric strings, SendGrid historically defaults to heavily predictable selector names. If you configure a domain today, you are highly likely to see selectors formatted as s1 and s2, or variations incorporating the customer account name. While this makes manual debugging significantly easier for IT staff, it completely removes the barrier to passive discovery.

Predictable selectors are a gift to adversaries conducting infrastructure reconnaissance. If an attacker wants to map the entire attack surface of your third-party email integrations, they can simply script DNS queries for s1._domainkey.yourdomain.com and instantly confirm your reliance on SendGrid. Furthermore, if a customer later disables SendGrid but forgets to strip the CNAME records from their zone file, those lingering delegations become a critical vulnerability. An attacker who compromises a dormant SendGrid tenant could potentially reactivate the routing and inherit full DMARC-aligned signing authority.

Analyzing Mailgun: Developer Flexibility Meets Operational Drift

Mailgun targets a demographic of developers who demand absolute control over payload routing and authentication headers. That ethos extends to their authentication defaults, which offer extreme flexibility at the cost of built-in guardrails. Unlike platforms that railroad you into CNAME delegation, Mailgun allows you to authenticate domains by publishing the raw public key directly in a TXT record, or by utilizing their managed CNAME authority.

The Danger of Legacy TXT Bindings

The operational reality is that flexibility breeds technical debt. Thousands of legacy domains configured on Mailgun years ago are still utilizing 1024-bit RSA keys published via direct TXT records. Because the customer holds the record directly in their zone, Mailgun cannot automatically upgrade the key length or rotate the cryptographic material. These legacy configurations often utilize the default pic or krs selectors, which act as immediate indicators of a potentially stale authentication posture.

When customers do opt for the newer delegated authority model, Mailgun performs admirably, generating secure keypairs and managing the lifecycle. But the simple fact that the platform allows direct TXT publication as an equal-class citizen in the onboarding flow means defenders must constantly audit their environment for drift. A junior developer spinning up a new subdomain for a marketing application is highly likely to choose the TXT method simply because it feels more transparent, inadvertently bypassing the organization policy for automated cryptographic rotation.

Scoring the Defaults: The Analyst Rubric

Evaluating an ESP requires looking past their marketing material and directly at the DNS query outputs they mandate. A defensible default architecture must satisfy three specific criteria before it should be allowed to sign messages on behalf of a corporate domain. First, it must strictly enforce 2048-bit RSA keys at a minimum. The compute required to factor 1024-bit keys is increasingly trivial, and any platform still issuing them is putting operational convenience ahead of baseline cryptography. While Ed25519 signatures detailed in RFC 8463 are the technical ideal, widespread receiver support is not yet sufficient to demand them as a strict vendor default.

Second, the platform must utilize obfuscated selectors. Debugging convenience is not a valid justification for broadcasting your vendor supply chain via passive DNS. Selectors should be long, randomly generated alphanumeric strings that change entirely upon rotation. If your vendor requires a selector named exactly after their product, you should immediately push back during procurement.

Finally, the architecture must enforce key rotation without requiring human intervention. CNAME delegation, despite its inherent risk of sub-domain takeover if abandoned, is operationally superior to manual TXT updates. If a vendor requires you to open a Jira ticket with your network team every time a key needs to be cycled, that key is never going to be rotated.

The takeaway

Your vendor defaults are merely a starting point, not a destination. Accepting out-of-the-box configurations without reviewing the actual cryptographic material they generate is an architectural failure. The major transactional email platforms all offer the capability to run secure, rotating, 2048-bit keypairs with properly aligned sender identities, but they rarely force you into the optimal configuration on day one.

Defenders must move beyond the green checkmarks in the vendor portal and actively monitor the telemetry generated by their outbound mail flow. If you want to see exactly how your third-party senders are signing your traffic, and catch body hash mismatches before they cause delivery incidents, plug your DMARC reports into MailSleuth.AI and audit the actual signatures hitting your receivers.