# PowerDMARC DKIM checker: lookup and re-test workflow

> PowerDMARC DKIM checker workflow: identify the selector, inspect the published DNS record, correct sender-generated values, and re-test safely.

PowerDMARC lists a "DKIM Lookup" tool, but its public pages do not document the current input fields, result labels, or whether the lookup validates a delivered message. Use it as a starting point only after you have the exact sending domain and selector from your email provider or a real message. Then compare the published DNS evidence with the sender's generated record, correct only the affected record, and re-test after DNS caches update.

## Quick takeaways

- PowerDMARC publicly lists "DKIM Lookup" among its tools.
- A DKIM lookup and a delivered-message validation answer different questions.
- Use account-generated selector, key, CNAME, and verification values from the sending service that owns the sender.
- Do not copy a DKIM record from another domain, account, or tenant.
- A public DNS result does not prove that production mail is signed with the matching key.
- DNS caching can delay the result of a re-test after a record change.

## What this tool checks

PowerDMARC's public site lists [DKIM Lookup](https://powerdmarc.com) as an available tool, and its support portal lists a [Free DKIM Record Lookup](https://support.powerdmarc.com) under Tools. The public material reviewed for this workflow does not establish the tool's required input, selector-discovery method, result labels, or whether it checks DNS only.

That distinction matters. A published DKIM record is one piece of evidence. A real message can provide separate evidence about the path that actually sent mail. An end-to-end validator that receives a message can inspect the headers recipients see, as [DKIMValidator explains](https://dkimvalidator.com). Do not treat a record lookup as proof that every sender is signing, that every recipient will accept a message, or that DMARC will pass.

Before using any lookup, identify:

- The visible From domain used by the message.
- The DKIM signing domain and selector from the sending service, if that service exposes them.
- The exact sender or application that produced the message.
- Whether the task is DNS inspection or validation of a delivered production message.

For context on evaluating vendor and tool options, see [Palisade's comparison hub](/compare). If the domain is also being reviewed for sender authentication, a [DMARC record check](/tools/dmarc) is a separate DNS check with its own limits.

![Decision flow for a DKIM lookup and retest](/images/editorial/powerdmarc-dkim-checker/powerdmarc-dkim-checker-flow.webp "1200x829")

*Source: Palisade.*

## How to run the check

### 1. Identify the sending service

Find which service sends the mail you are investigating. Use that service's current domain-authentication setup page or its generated DNS instructions. PowerDMARC describes Hosted DKIM as a service to "Simplify DKIM selector and key management for multiple domains with this one-stop service," but that statement does not identify the configuration values for another sender.

If the sender is a third-party platform, use its account-generated DKIM instructions. PowerDMARC's support portal describes its [Third-Party Source Configuration category](https://support.powerdmarc.com) as covering DKIM, SPF, and DMARC implementation for third-party email vendors.

> Do not replace a record with a selector, CNAME target, public key, or token copied from another account. Those values can be specific to the sending service and account.

### 2. Record the exact domain and selector

Use the values generated by the sender that owns the email path. If you have a delivered test message, preserve a redacted copy of its authentication-related headers for comparison with the sending-service configuration.

The public PowerDMARC materials do not document whether its lookup accepts a domain, selector, email address, or another input. Follow the current instructions on the official tool page rather than assuming an input format from an older guide or screenshot.

### 3. Run a public DNS lookup

Submit only the domain and selector values that apply to the sender being investigated. Record the time, the queried name, and the returned answer or failure. This creates a baseline for the re-test.

You can also repeat a public DNS query independently. Replace the placeholders with your own sender-generated values.

```bash
dig +short TXT selector1._domainkey.yourdomain.com
```

This command returns a public DNS answer when one is available through the resolver used for the query. It does not prove that the sending application uses the selector, that a message signature validates, or that a mailbox provider made a particular delivery decision.

### 4. Preserve the result before editing DNS

Save the result in the change record with the sender name and timestamp. If the lookup does not return the expected record, first verify that the owner name matches the sender's generated instructions. Do not treat an empty result alone as evidence that the sender is broken. The domain, selector, DNS provider, or rollout state may still need confirmation.

## How to interpret the results

The available public PowerDMARC material does not document current checker result states or labels. The following interpretation matrix is therefore a method for assessing the DNS evidence you observe, not a description of PowerDMARC interface statuses.

### A record is returned for the expected owner name

This is DNS evidence that a public answer was returned for the name you queried. Compare the owner name and returned content with the exact values generated by the sending service. A match supports the DNS layer of the setup.

It does not establish the vendor layer, the delivered-message layer, or the DMARC-report layer. Send a real test message through the same production path and inspect the recipient's headers before concluding that the sender is signing correctly.

### No answer is returned for the expected owner name

First confirm the selector and domain with the sending service. Then verify that the DNS provider has published the exact owner name that the service generated. A typo, an omitted subdomain, or a record entered in the wrong DNS zone can produce a result that looks like a missing record.

Do not publish a replacement value from an example. The sender must generate the real record values for the account and domain.

### An answer is returned, but it differs from the sender's instructions

Treat this as a configuration mismatch until you can explain it. Determine whether the sender recently rotated keys, whether an old record remains published, or whether the DNS record was created for another service. Make one scoped correction based on the sender's current instructions, then preserve the previous value for rollback if your DNS process permits it.

A domain can have multiple email systems. Keep each sender's evidence separate. A valid result for one sender does not validate another sender's configuration.

### The DNS result looks correct, but the message still has a problem

Move to a delivered-message check and the sending-service status. A public lookup cannot show which key the application used when it sent the message. It also cannot establish a receiver's private spam or reputation decision.

For a broader sender-authentication review, use the [Palisade DKIM checker](/tools/dkim) after you have confirmed the applicable domain and selector. A public check can inspect DNS evidence, but it cannot prove the production sending path, continuous state, or future inbox placement.

## How to act on the result

Start with the smallest verified scope:

- If the queried name is wrong, correct the query input before changing DNS.
- If the DNS owner name is absent, return to the exact sending service and obtain its current generated record.
- If a published value differs from the sender's current instruction, correct only that record in the authoritative DNS zone.
- If DNS matches but a message still fails, inspect the sending-service configuration and a newly delivered message from the same application and sender identity.
- If several services send mail for the same domain, document each service, its selector, and its validation evidence separately.

A DNS host may show a successful save while public resolvers still return an older answer. DKIMValidator notes that DNS records are heavily cached and changes can require hours between tests. That is a caching consideration, not a promise about a specific provider or a fixed propagation time.

If the record is hosted in GoDaddy, the [DKIM record workflow for GoDaddy DNS](/learning/add-dkim-record-godaddy) can help you keep the DNS edit scoped to the sender-generated values. For Google sender requirements, [email authentication for Gmail](/learning/authenticate-email-for-gmail) explains why DNS configuration alone is not the complete validation step.

## How to retest

Repeat the same lookup with the same domain and selector after the authoritative DNS zone has been updated and caches have had time to refresh. Compare the new answer with the sender's current generated instructions, not with a record copied from another account.

Then validate at four layers where they apply:

- DNS: confirm the authoritative published record and at least one public-resolver result.
- Vendor: confirm the sender's own current authentication or verification status.
- Message: send a new message through the exact production application, sender, gateway, and recipient path, then inspect its received headers.
- DMARC: review aggregate-report evidence once reports have accumulated.

Keep the timestamps and inputs for each layer. A green DNS result is useful, but it does not replace a delivered-message check.

## Check the DNS record, then track the senders that still need work

Once you have the exact domain and selector, use Palisade's DKIM checker to inspect the public DNS side of the configuration. If one record is corrected, the ongoing question is which other production sending sources still use the domain and whether their authentication or alignment evidence supports the next DMARC policy stage.

[Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=powerdmarc&utm_content=powerdmarc-dkim-checker)

Palisade is agent-first DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose a next policy step when the evidence supports it, while a human reviews the evidence and applies the change. It does not change DMARC policy automatically, repair every sender, prove every future message will authenticate, or guarantee delivery.

## Sources and further reading

- [PowerDMARC](https://powerdmarc.com)
- [PowerDMARC support portal](https://support.powerdmarc.com)
- [DKIMValidator](https://dkimvalidator.com)
- [Palisade DKIM checker](/tools/dkim)

## Frequently asked questions

### Does PowerDMARC have a DKIM checker?

Yes. PowerDMARC publicly lists "DKIM Lookup," and its support portal lists "Free DKIM Record Lookup." Its public material does not document the current input flow, result labels, or whether the lookup validates a delivered message.

### Can a DKIM lookup prove that email is signing correctly?

No. A public lookup can provide DNS evidence for the name queried. A new delivered message from the exact production path is needed to assess what that sender actually used.

### Should I use a selector from another account to repair a missing record?

No. Obtain the selector and record values from the sending service and account that own the affected email path. Account-generated DKIM values can differ between tenants and services.

### Why does a corrected DKIM record not appear immediately?

DNS records are cached. A re-test can continue to show an older answer until caches refresh, so record the time of the change and repeat the same lookup later.

### Does a valid DKIM record prove that DMARC passes?

No. A valid public record is DNS evidence only. DMARC assessment also depends on a real message and its authentication or alignment evidence, followed by aggregate-report data as it accumulates.