How DKIM Signing Works On Native Sending Domains

DKIM is often described as an email authentication record, but that shorthand obscures the operational detail that matters most to senders: which domain signs the message.

A platform can add a valid DKIM signature using its own domain. That may prove the message passed through that platform, but it does not necessarily authenticate the domain a recipient sees in the From: address. Native DKIM signing changes that. The sending system signs with a domain that your organisation controls, usually the same domain or a related subdomain of the visible sender domain.

This distinction matters because DKIM is one of the ways a message can pass DMARC. It also gives a brand clearer control over its sending identity when email is split between a marketing platform, customer-data system, helpdesk, billing tool and corporate mailbox provider.

What “native sending domain” means in DKIM

“Native sending domain” is not a formal protocol term. In practice, it usually means that mail is DKIM-signed with a domain belonging to the sender rather than solely with a software provider’s shared domain.

Suppose a subscriber receives a campaign from:

From: Northern Goods <offers@northerngoods.co.uk>

There are two materially different DKIM outcomes:

DKIM-Signature: d=mailer-platform.example; s=shared1; ...
DKIM-Signature: d=northerngoods.co.uk; s=mkt2026; ...

The first signature may validate perfectly, but it authenticates mailer-platform.example. The second authenticates northerngoods.co.uk. The latter is native-domain signing because the signing domain is the sender’s own domain.

A native signing domain does not mean that the organisation must operate its own mail servers or keep the DKIM private key on its own infrastructure. A reputable email service provider can generate and protect the private key, then sign mail on the customer’s behalf. What matters to receivers is that the corresponding public key is published beneath the customer’s DNS domain and that the signature validates for the intended d= domain.

What happens when a message is DKIM-signed

DKIM, short for DomainKeys Identified Mail, applies a digital signature to a message. The signature is placed in a DKIM-Signature header before the message leaves the sending system. The receiving system retrieves the matching public key from DNS and uses it to verify the signature.

The protocol is defined in RFC 6376. In everyday operational terms, the sequence looks like this:

1. The sender selects a signing domain and selector. The domain appears in the DKIM header as d=; the selector appears as s=. For example, d=northerngoods.co.uk; s=mkt2026.
2. The sending system creates a signature. It signs selected message headers and a cryptographic representation of the body with the private key. Commonly signed headers include From, Subject, Date, To and MIME-related headers, but the precise list is shown in the signature’s h= tag.
3. The receiver looks up the public key in DNS. The lookup name is constructed as selector._domainkey.domain. In this example, the receiving server queries mkt2026._domainkey.northerngoods.co.uk.
4. The receiver verifies the signature. If the published public key verifies the signed parts of the message, DKIM passes. If the relevant signed content was changed after signing, the key is unavailable or the cryptographic check fails, it does not.

A simplified header might look like this:

DKIM-Signature: v=1; a=rsa-sha256;
 d=northerngoods.co.uk; s=mkt2026;
 h=from:to:subject:date:mime-version:content-type;
 bh=...; b=...

The important fields for a sender investigating native signing are d= and s=. Together they identify the DNS location of the public key. The long b= value is the signature itself; bh= is associated with the message body.

What DKIM proves, and what it does not

A passing DKIM result means that the message was signed by a system with access to the corresponding private key and that the signed portions survived the journey in a verifiable form. It does not mean the message is wanted, safe, relevant or destined for the inbox. It also does not, by itself, prove that the domain in the visible From: field is the domain that signed it.

That last limitation is why DMARC matters. DMARC evaluates the domain shown to the recipient and requires it to align with a domain authenticated by SPF or DKIM. Under relaxed DKIM alignment, a parent domain and its subdomain can align; under strict alignment, they must match exactly. The DMARC specification gives the example that a valid signature from example.com can align with alerts@news.example.com in relaxed mode, but not in strict mode.

Why native DKIM signing matters to deliverability

Native DKIM is primarily an authentication and identity-control measure. It is also a practical deliverability requirement for many senders because it enables DKIM alignment with the visible sender domain.

Google’s current sender guidance requires bulk senders to Gmail to use SPF and DKIM, publish DMARC and align the domain in the visible From: header with either SPF or DKIM for direct mail. Google also recommends DKIM keys of 2,048 bits where the DNS provider supports them. See Google’s email sender guidelines and its sender-guideline FAQ on alignment.

For a marketing sender, DKIM alignment is frequently more dependable than SPF alignment. The SMTP envelope sender, often displayed as Return-Path, may be a platform-controlled bounce domain such as bounce.provider.example. That is normal. A marketing platform can still sign with d=mail.northerngoods.co.uk while using its own return-path domain. If the visible sender is offers@mail.northerngoods.co.uk, the DKIM identity can align exactly.

Native signing should not be treated as an inbox-placement switch. Mailbox providers also assess complaint rates, recipient engagement, list quality, sending patterns, message content and domain or IP reputation. Authentication establishes a reliable identity on which those other signals can be evaluated; it does not outweigh poor permission, excessive contact pressure or an unhealthy audience.

Native domain signing with a third-party sending platform

Most established email platforms call this feature domain authentication, custom DKIM or authenticated sending domain. The setup normally follows one of two patterns.

Publishing a DKIM TXT record

The provider gives the customer a public key to publish directly in DNS, normally as a TXT record. It may resemble this:

mkt2026._domainkey.northerngoods.co.uk TXT
"v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

The platform retains the matching private key and uses it to sign mail. The organisation controls the DNS zone and decides whether the public key remains published.

Delegating the key lookup with a CNAME

Alternatively, the provider may ask for a CNAME record:

mkt1._domainkey.northerngoods.co.uk CNAME
mkt1.northerngoods.provider-dkim.example

The recipient still queries a name under northerngoods.co.uk, but DNS follows the CNAME to the provider-managed key record. This is common because it allows the platform to manage key material and, in some implementations, rotate keys without asking every customer to paste a new public key into DNS.

A CNAME at a selector host does not alter the organisation’s website, MX records or the rest of the domain. It delegates only that selector’s DKIM lookup. It does, however, mean the provider has operational control over the public key returned for that selector. Treat it as an authentication dependency: record the platform, selectors, DNS owner, purpose and rotation process in the same inventory as the sending service.

Microsoft 365 is one familiar example. Its custom-domain DKIM configuration uses two CNAME selectors, with one active selector and another available for future rotation. Microsoft’s custom-domain DKIM documentation stresses that the values should be retrieved from the tenant rather than copied from a generic example.

Choosing domains and subdomains

The simplest arrangement is to sign all mail as the organisational domain:

From: receipts@northerngoods.co.uk
DKIM d=: northerngoods.co.uk

For organisations with several independent mail streams, designated subdomains offer clearer separation:

From: offers@mail.northerngoods.co.uk
DKIM d=: mail.northerngoods.co.uk

From: support@help.northerngoods.co.uk
DKIM d=: help.northerngoods.co.uk

This can make it easier to assign ownership, distinguish marketing from service mail and contain the operational effects of a third-party system. Microsoft also recommends subdomains for email systems or services outside an organisation’s direct control, so issues with those services are less likely to affect the main domain’s reputation.

However, a subdomain is not an automatic reputation firewall. Recipient complaints, poor targeting or a compromised sending account can still damage that stream and create wider brand or authentication issues. Use subdomains to create understandable sending boundaries, not as a licence to take more risk.

Where DMARC is set to strict alignment, be exact. A message from offers@mail.northerngoods.co.uk signed as d=northerngoods.co.uk would not achieve strict DKIM alignment. When strict alignment is intentional, the visible From domain and d= domain should normally be identical.

Deploying native DKIM without losing visibility

The DNS change is often straightforward. The difficult part is ensuring that every real source of email is covered.

Start with a sending-system inventory

List every system that can send mail using the organisation’s domains: marketing automation, product notifications, receipts, password resets, customer support, CRM workflows, survey tools, event platforms, finance systems and employee mail. Include systems that only send occasional messages. A domain may appear fully authenticated in a campaign platform while support tickets or transactional mail still leave with only a provider signature.

For each system, document the visible From domain, envelope sender or return-path domain, DKIM d= domain, selectors, DNS record type, key or CNAME owner, and whether the platform signs after any downstream gateway modifies the message.

Publish exactly the records the sender specifies

Do not hand-build a record from a screenshot or reuse a selector from another platform. The selector name and target or public key must match the platform’s current configuration. DNS control panels vary: some append the zone name automatically, which can accidentally create names such as selector._domainkey.example.co.uk.example.co.uk. Confirm the fully qualified record actually published in public DNS.

Do not create both a TXT record and a CNAME at the same selector name. A CNAME is intended to be the sole record at that name. Also avoid replacing an existing selector record until the platform and change owner are identified; an apparently redundant record may still validate mail in transit or mail from a separate sender.

Enable signing only after DNS is visible

Once the TXT or CNAME record resolves publicly, enable the platform’s custom DKIM setting and send representative tests. The test should cover ordinary campaigns and automated messages, because some platforms route transactional and marketing traffic through different infrastructure.

In the received message source, find Authentication-Results and each DKIM-Signature header. A successful result typically includes:

dkim=pass header.d=northerngoods.co.uk
From: offers@northerngoods.co.uk

Do not stop at “DKIM: pass”. Confirm that the passing header.d is the expected domain and that it aligns with the visible From domain. A message can contain multiple signatures; an unrelated platform signature may pass while the intended native signature is absent or failing.

Common failures and what they indicate

Observed result	Likely cause	Operational response
DKIM is missing	Custom signing was never enabled, the message used a different sending route, or the platform cannot sign that mail type.	Check the actual source system and route, then enable native signing for that specific stream.
DKIM fails with no key found	The selector, DNS hostname, CNAME destination or public key is wrong or unavailable.	Compare d= and s= in the received message with the public DNS result.
DKIM fails despite a valid DNS record	A gateway, footer service, mailing list or security product modified headers or body content after signing.	Identify where the signature is applied and ensure material modification occurs before signing where possible.
DKIM passes but DMARC fails	The valid signing domain is not aligned with the visible From domain, or SPF and DKIM alignment both fail.	Configure native signing for the From domain or the appropriate aligned subdomain.
Signing stopped after a DNS update	An old selector was deleted too early, overwritten, or a provider CNAME was altered.	Restore the verified record and review the change process before attempting rotation again.

Selectors, key size and rotation

A selector is a label that lets one domain publish more than one DKIM public key. That makes it possible to use different keys for different sending systems and to rotate keys safely. The protocol specifically supports a transition in which the old and new public keys coexist while messages signed with the former key may still be in transit.

Use a new selector for a new key rather than replacing key material under an existing selector. Reusing a selector makes later investigation harder: a failed old signature could be a legitimate message signed before the key was replaced, a forged message or an ordinary configuration fault. The selector guidance in RFC 6376 advises against reusing selectors in this way.

Key rotation should be an owned process, not an ad hoc DNS edit. The M3AAWG DKIM key-rotation guidance recommends rotation at least every six months. Some platforms rotate managed keys on their own schedule, while others require customer action. In either case, keep the outgoing selector published until the agreed transition period has passed and verification of new traffic is complete.

For RSA DKIM keys, use 2,048 bits where supported. Google accepts keys of 1,024 bits or longer for mail to personal Gmail accounts and recommends 2,048 bits where DNS support permits it. The key type, DNS provider limitations and receiver compatibility should be assessed with the sending platform rather than changed blindly in production.

Where deliverability review fits

Native DKIM is best reviewed as part of a wider authentication and sending-infrastructure assessment. The useful questions are not only whether one record exists, but whether every permission-based mail stream signs as expected, passes DMARC alignment and retains that configuration through platform changes, DNS changes and key rotation.

For senders dealing with inconsistent authentication across several systems, Email Foundry’s authentication and infrastructure checks can help establish that inventory and validate live headers, DNS records and alignment. That work is most valuable when it sits alongside audience quality, suppression and contact-pressure controls, because technically correct DKIM cannot compensate for mail that recipients did not expect or no longer want.

Frequently asked questions

Can a message have more than one DKIM signature?

Yes. A platform may add its own signature and a native signature for the customer’s domain. For DMARC, at least one passing DKIM signature must align with the domain in the visible From address.

Does a CNAME-based DKIM setup mean the provider owns my domain?

No. A CNAME under selector._domainkey delegates only the DKIM key lookup for that selector. Your organisation still controls the domain zone, but the provider may manage the key record and associated rotation at the destination.

Should marketing and transactional email use the same DKIM selector?

They can, but separate selectors or subdomains are often easier to operate where streams use different platforms, teams or risk profiles. The important requirement is that every source signs with an appropriate, aligned domain and that ownership is documented.

Why does DKIM pass but DMARC still fail?

A DKIM pass only authenticates the domain in the DKIM d= tag. DMARC also requires that domain to align with the visible From domain, unless aligned SPF provides the passing path instead.

Sources and further reading

• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures — IETF
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — IETF
• Email sender guidelines — Google
• Email sender guidelines FAQ — Google
• How to use DKIM for email in your custom domain — Microsoft Learn
• M3AAWG DKIM key rotation best common practices — M3AAWG