DKIM Generator: Verify Your Emails and Prevent Spoofing

Key takeaways:

• DKIM adds a cryptographic signature to your outgoing emails — receiving servers use it to verify the email genuinely came from you and wasn’t tampered with in transit.
• A DKIM generator produces the correctly formatted DNS record you need to publish — but the private key that signs your emails is generated by your email provider, not the tool.
• You need a separate DKIM record for every service that sends email from your domain — one for Google Workspace, one for your outreach tool, one for your marketing platform.

You can have a clean list, a warmed domain, and a well-written email — and still have emails land in spam because receiving servers can’t verify the message actually came from you.

That’s the problem DKIM solves. DomainKeys Identified Mail is an email authentication protocol that attaches a cryptographic signature to every email you send. When the email arrives, the receiving server checks that signature against a public key you’ve published in your DNS. If they match, the email passes DKIM authentication — proof that it came from an authorized source and wasn’t modified in transit.

Without DKIM, receiving servers have no way to verify that your emails are genuine. Combined with SPF and DMARC, DKIM forms the authentication foundation that serious email delivery depends on.

Setting it up requires two things: a key pair generated by your email provider, and a DNS record that publishes the public half of that key. A DKIM generator handles the DNS record formatting — the part where most people make mistakes.

This guide explains how DKIM works, how to get your key from your email provider, how to use the generator to build your DNS record, and how to verify everything is working correctly.

Why DKIM matters for email delivery

SPF tells receiving servers which servers are allowed to send from your domain. DKIM tells them whether a specific email was actually sent by one of those servers and whether it was modified after sending. They solve different problems — which is why you need both.

Here’s what breaks without DKIM:

• DMARC authentication weakens significantly. DMARC requires email to pass either SPF or DKIM — ideally both. If DKIM isn’t set up, SPF becomes your only authentication mechanism. When SPF fails for any reason — forwarded email, misconfigured include — DMARC fails too, and your policy applies.
• Email forwarding breaks SPF but not DKIM. When someone forwards your email, the sending server changes — which breaks SPF alignment. DKIM survives forwarding because the signature travels with the email content, not the server. Without DKIM, forwarded email from your domain fails authentication entirely.
• Receiving servers trust DKIM-signed email more. Major providers like Gmail use DKIM as a positive signal in reputation scoring. Consistently DKIM-signed email from a domain with good engagement builds trust over time. Missing DKIM removes that signal.
• You can’t achieve full DMARC enforcement without it. If your goal is p=reject DMARC policy — the only level that fully protects against domain spoofing — you need DKIM passing reliably alongside SPF. One authentication mechanism isn’t enough for robust enforcement.

The practical impact: DKIM is not optional for any domain sending email at volume. It’s a baseline requirement for deliverability and the foundation of a complete authentication setup.

How DKIM works — the non-technical version

DKIM uses a public/private key pair. Here’s what that means in plain language:

Your email provider generates two mathematically linked keys. The private key stays with your email provider and is used to sign every outgoing email — adding a unique signature to the message header. The public key gets published in your domain’s DNS, where any receiving server can look it up.

When a receiving server gets your email, it finds the DKIM signature in the header, retrieves your public key from DNS, and uses it to verify the signature. If the signature matches, two things are confirmed: the email was sent using the matching private key (meaning it came from an authorized source), and the email content hasn’t been changed since it was signed.

If the public key doesn’t match the signature, DKIM fails — either the email wasn’t sent by an authorized source, or it was modified in transit.

The key point for setup: you don’t generate the private key yourself. Your email provider — Google Workspace, Microsoft 365, your outreach platform — generates and manages the private key on their end. What you do is publish the public key in your DNS so receiving servers can find it. That’s where the DKIM generator comes in — it helps you format that DNS record correctly.

How a DKIM generator works

A DKIM record is a TXT record published in your DNS at a specific location: selector._domainkey.yourdomain.com. The selector is a label that identifies which DKIM key is being referenced — useful when you have multiple DKIM records for different sending services.

The record contains your public key in a specific format that receiving servers can parse. A single formatting error in the record causes DKIM lookups to fail.

A DKIM generator produces the correctly formatted record based on the public key and settings you provide. Use the generator below:

To use the generator, you need:

Your public key — Get this from your email provider’s DKIM setup page. It’s a long string of characters, typically starting with MIIBIjANBgkqhkiG9w0B… for RSA keys. Copy it exactly.

Your selector — A label you choose (or that your provider assigns) to identify this key. Common selectors include google, mail, s1, s2, dkim. It can be anything — it just needs to match what’s in your DNS and what your provider is signing with.

Key type — RSA is standard. Most providers use RSA-2048.

The generator produces a formatted TXT record that looks like this:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA…

Published at: yourselector._domainkey.yourdomain.com

That’s the record you add to your DNS.

How to get your DKIM key from your email provider

This is the step most guides skip — and where most people get stuck. The DKIM public key comes from your email provider, not from the generator. Here’s where to find it for the most common platforms:

Google Workspace Go to Admin Console → Apps → Google Workspace → Gmail → Authenticate email. Select your domain, generate a new key if one doesn’t exist, and copy the TXT record value Google provides. Google will also tell you the selector to use (usually google).

Microsoft 365 Go to Security → Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM. Select your domain, enable DKIM, and copy the CNAME records Microsoft provides. Note: Microsoft uses CNAME records, not TXT records — follow Microsoft’s specific instructions for publishing.

Reply.io Check your Reply.io account settings under email configuration. Reply.io provides the specific DKIM record you need to publish for emails sent through their infrastructure.

SendGrid In your SendGrid account, go to Settings → Sender Authentication → Domain Authentication. SendGrid provides the DKIM records to publish as part of domain authentication setup.

Mailchimp Mailchimp handles DKIM signing through domain authentication. Go to Account → Domains and follow the verification process — Mailchimp provides the records to publish.

Custom mail server If you’re running your own mail server (Postfix, Exim, etc.), you generate the key pair yourself using tools like opendkim-genkey. The private key goes on your server. The public key gets formatted into a DNS record using the DKIM generator.

How to generate a DKIM record and publish it — step by step

Here’s the full process from getting your key to having a working DKIM record in DNS.

Step 1: Get your public key from your email provider

Follow the provider-specific steps above to find or generate your DKIM key. Copy the public key string exactly — it’s long and any missing character will break the record. Some providers let you generate dkim record values directly from their admin panel — if that’s the case, you may be able to skip the generator and publish their pre-formatted record directly.

Step 2: Choose your selector

If your provider assigns a selector, use that. If you’re choosing your own, pick something simple and descriptive — mail, s1, google, reply. Write it down — you’ll need it for the DNS record hostname and you’ll need to know it when troubleshooting later.

If you’re adding DKIM for a second sending service on the same domain, use a different selector. Each sending service gets its own DKIM record at its own selector subdomain.

Step 3: Open the DKIM generator and enter your details

Open the dkim record generator, paste in your public key, enter your selector, and confirm the key type (RSA in almost all cases). The generator produces the formatted TXT record value.

Double-check the output:

• It should start with v=DKIM1; k=rsa; p=
• Followed by your public key
• No extra spaces or line breaks within the key string

Step 4: Publish the record in your DNS

Log into your DNS management interface and add a new TXT record:

• Host/Name: yourselector._domainkey — for example, if your selector is google, the host is google._domainkey (your DNS provider may auto-append your domain)
• Type: TXT
• Value: the full record string from the generator
• TTL: 3600

Save and wait for DNS propagation — typically a few hours.

Step 5: Verify the record is live

Use MXToolbox DKIM Lookup or a similar tool. Enter your domain and selector, and confirm the tool retrieves your public key correctly.

If the lookup fails, check:

• The host field in your DNS entry — the selector subdomain format is the most common source of error
• Whether your DNS provider stripped any characters from the key string — some interfaces have character limits that truncate long TXT records

Step 6: Send a test email and check the headers

Send a test email to a Gmail address. Open the email, click the three dots, select “Show original,” and look for Authentication-Results. You should see dkim=pass with your domain listed.

If you see dkim=fail, the record is published but something is wrong with the key or the alignment. Check that the public key in DNS exactly matches what your provider is using to sign.

Setting up DKIM for multiple sending services

This is where most setups get complicated — and where create dkim record mistakes happen most often.

Every service that sends email from your domain needs its own DKIM record. One record for Google Workspace doesn’t cover emails sent through Reply.io, SendGrid, or any other platform. Each service signs with its own private key and needs its corresponding public key published in your DNS.

The good news: having multiple DKIM records on one domain is straightforward. Each one lives at a different selector subdomain:

google._domainkey.yourdomain.com    → Google Workspace DKIM

s1._domainkey.yourdomain.com        → SendGrid DKIM

reply._domainkey.yourdomain.com     → Reply.io DKIM

They don’t conflict with each other. Receiving servers use the selector in the email’s DKIM signature header to know which DNS record to look up — so each service’s emails are verified against the right key automatically.

The practical checklist:

• Primary business email (Google Workspace or Microsoft 365) — DKIM published
• Outreach and sales engagement platform (Reply.io) — DKIM published
• Marketing email platform (Mailchimp, HubSpot, etc.) — DKIM published
• Transactional email service (SendGrid, Mailgun, Postmark) — DKIM published
• Any other service that sends email as your domain — DKIM published

If a service is sending email from your domain without a corresponding DKIM record, those emails are unsigned and failing DKIM authentication. Check your DMARC reports — they’ll show which sources are passing and which are failing.

What to look for in a free DKIM generator

A free dkim generator covers the core job: format your public key into a correctly structured DNS record. Here’s what separates useful tools from ones that create more problems than they solve.

• Key validation — The tool should check that the public key you’ve entered is syntactically valid before producing output. A malformed key produces a broken record — better to catch it in the tool than after publishing.
• Selector field — The generator should include a selector input and use it to show you the exact hostname to publish the record at. This is the detail most people get wrong — knowing the value isn’t enough if you don’t know exactly where to put it.
• Clear output formatting — The generated record should be a single, clean string ready to paste into DNS. Some tools produce multi-line output that DNS interfaces don’t handle correctly — the key should be on one line.
• 2048-bit key support — 1024-bit DKIM keys are considered weak and are being deprecated by major providers. A good dkim creator defaults to or clearly supports 2048-bit keys.

If you’re using Reply.io and need to generate dkim configuration for its sending infrastructure, check Reply.io’s help documentation — they provide step-by-step instructions specific to their platform setup.

Who needs DKIM set up?

Best practices

• Use 2048-bit keys — 1024-bit keys are weak and being phased out. Always generate or request 2048-bit DKIM keys from your provider.
• Set up DKIM for every sending service — One record doesn’t cover everything. Audit every service that sends email from your domain and confirm each has a published DKIM record.
• Rotate keys periodically — DKIM private keys should be rotated every 6–12 months as a security practice. When you rotate, generate dkim DNS record with the new public key and publish it before switching the private key — give it time to propagate first.
• Use your DMARC reports to audit DKIM coverage — DMARC aggregate reports show whether DKIM is passing or failing for each sending source. If a source is failing, either the record is missing or there’s a misconfiguration.
• Don’t delete old DKIM records immediately after rotation — Emails signed with the old key that are still in transit or in recipient mail queues will fail verification if you remove the old key immediately. Wait a few days before deleting the previous record.
• Verify after every DNS change — Any edit to your DNS can accidentally affect other records. After publishing or editing a DKIM record, run a lookup to confirm it’s correct.

Full process at a glance:

Troubleshooting

DKIM lookup returns “record not found.” The record isn’t published at the right location. Check the Host/Name field in your DNS entry — the format should be yourselector._domainkey with the domain appended automatically by your provider, or yourselector._domainkey.yourdomain.com if your provider requires the full hostname. Confirm the selector matches exactly what your email provider is using.

DKIM lookup finds the record but returns a syntax error. The record value has a formatting issue. Common causes: the public key was truncated by a DNS interface character limit, or line breaks were introduced when copying the key. Some DNS interfaces require long TXT records to be split into multiple quoted strings — check your provider’s documentation for how to handle long TXT values.

Test email shows dkim=fail in headers. The public key in DNS doesn’t match the private key your provider is using to sign. Either the key was entered incorrectly during setup, or your provider has rotated the private key since you published the DNS record. Re-retrieve the public key from your provider and update the DNS record.

DKIM is passing but emails still land in spam. DKIM passing is necessary but not sufficient for good deliverability. Check that SPF and DMARC are also configured correctly. Review sender reputation, list quality, and content. DKIM is one signal — deliverability depends on all of them together.

I need to add DKIM for a new sending service but I don’t know its selector. Check the service’s documentation or DKIM setup guide — they’ll specify the selector to use. Alternatively, send a test email through the service and check the email headers for the DKIM-Signature field — it will contain s=yourselector showing what selector the service is signing with.

Conclusion

DKIM is the authentication layer that ties your email identity to your sending infrastructure cryptographically. SPF says which servers can send from your domain. DKIM proves that a specific email actually came from one of those servers and wasn’t touched in transit. Together with DMARC, they form a complete authentication setup that protects your domain and supports consistent deliverability.

Setting it up is straightforward once you understand the pieces: get the public key from your provider, format it into a DNS record using the generator, publish it at the right selector subdomain, and verify it’s working. Repeat for every service that sends email from your domain.

The part that trips most people up isn’t the technical complexity — it’s the completeness. One missed sending service means emails from that service are failing DKIM. Your DMARC reports will tell you exactly where the gaps are.

Get DKIM right across all your sending sources, pair it with SPF and DMARC, and your domain has the authentication foundation that serious outbound email requires.

Reply.io works best on a fully authenticated domain — proper DKIM, SPF, and DMARC setup means your sequences land where they should and your sender reputation builds over time.