What does the r= tag in DKIM actually mean?

You send an email, it passes authentication, and yet it lands in spam — or vanishes altogether. No bounce, no alert, just silence. One hidden clue might be lurking in the DKIM signature: the r= tag.

This tiny tag isn't a bug. It’s a signal. It means your domain used a DKIM signing algorithm not recognized or trusted by receiving servers. Modern email systems expect only a few standard algorithms — any deviation, even if it’s technically valid, often gets filtered.

Key takeaways

  • The r= tag in DKIM indicates the cryptographic algorithm used; its presence means the algorithm is non-standard or unsupported.
  • Receiving servers reject or flag emails with r= because it deviates from accepted standards like RSA-SHA256.
  • Fixing it involves switching to a standard algorithm in your email provider’s DKIM settings and verifying the updated signature.

Why does an r= tag cause delivery issues?

The r= tag in a DKIM signature specifies the algorithm used to generate the digital signature. If the receiver’s email system doesn’t recognize that algorithm—such as when it sees rsa-sha1 or an unregistered custom value—it treats the signature as invalid, even if the signature itself is mathematically correct. This mismatch commonly results in hard bounces or messages being filtered into junk folders.

How receivers validate DKIM signatures

When your email arrives at the recipient’s server, it runs a series of checks, including DKIM validation. The receiver looks up your domain’s DKIM public key and applies the algorithm specified in the r= tag to verify the signature. This process follows the standards defined in RFC 6376, which outlines the expected behavior for DKIM verification.

You might think that as long as the signature matches the content, the email should pass. But the r= tag acts like a gatekeeper. If it refers to an algorithm that’s not listed in the approved set—like rsa-sha1, which is deprecated—or an arbitrary algorithm like "custom-128"—the validation fails automatically. This is by design: receivers prioritize known, secure algorithms to prevent spoofing and tampering.

Why a mismatch still triggers delivery failure

Even if your message content is intact and your key is correct, a rejected DKIM signature means the receiver sees the email as untrusted. Most modern email providers—like Gmail, Outlook, and Apple Mail—don’t just log a failure. They apply strict policies, often marking the message as spam or outright bouncing it. According to industry data from Mimecast’s 2023 Email Security Report, DKIM failures rank among the top technical reasons for inbox placement drop-offs.

Some receivers also use the r= tag to assess your sender reputation. A mismatch may signal poor configuration or lack of security awareness, even if it’s accidental. This can indirectly affect your sender reputation, especially if it happens at scale across multiple domains or sending volumes.

Let’s be clear: r= tag issues aren’t about technical correctness alone. They’re about trust. You’re not just sending an email—you’re sending a digital promise. When that promise doesn’t match the receiver’s expectations, the system breaks down.

If you’re managing email lists or sending campaigns, catching these issues early saves time and improves deliverability. You can check individual addresses with our email checker or use our API to validate large lists before sending. For deeper testing, try our inbox placement tool to simulate real-world delivery conditions.

Which DKIM algorithms are actually supported?

Only rsa-sha1, rsa-sha256, and ecdsa-sha256 are widely accepted by major email providers. Using any other algorithm—even if mathematically valid—can trigger rejection due to policy, security standards, or compliance rules. The r= tag in DKIM indicates an algorithm mismatch when the server expects one of these standards but receives a different one.

Why only a few algorithms are trusted today

As email security evolves, providers like Gmail, Outlook, and Yahoo have phased out older or less secure algorithms. rsa-sha1, while once common, is now deprecated due to known cryptographic weaknesses. Major providers no longer accept it for new signatures and may reject messages with it, even if the key is valid.

rsa-sha256 and ecdsa-sha256 are the current standards. rsa-sha256 is widely supported across infrastructure, while ecdsa-sha256 offers stronger security with smaller key sizes, making it preferred in modern setups. These are the only algorithms you should ever use unless you’re working with a private or niche system that explicitly allows others.

How algorithm mismatches happen—and how to catch them early

When you sign an email with a non-standard or legacy algorithm, the receiving server checks the r= tag in the DKIM signature. If it doesn’t recognize the algorithm, it flags the email as invalid or risky. This isn’t always about math; it’s about policy. Even if a signature checks out, a mismatched algorithm can trigger spam filters, reduce deliverability, or cause the message to be dropped outright.

Many email systems assume you’re using a standard algorithm. If you’re not, and you haven’t updated your signing process, you might not notice the issue until bounces or low inbox placement start piling up. You can test this directly with real-world inbox placement tools before sending to real users.

Use our inbox placement tester to validate how your DKIM-signed messages are handled across major providers. It checks more than just deliverability—it reveals how your signature, headers, and authentication stack up in practice. For teams managing large lists, our bulk email verification catches invalid or improperly configured addresses early, including those with mismatched or unsupported DKIM algorithms. This reduces risks before they impact sender reputation.

How do you detect the r= tag in your DKIM signatures?

You can detect the r= tag in DKIM signatures by examining the raw email headers using a tool like MxToolbox or your mail server logs. Look for the DKIM-Signature header and scan for the r= tag. If it appears without a valid algorithm value like rsa-sha256, it indicates that your signing process is using an unsupported or undefined algorithm, which can cause authentication failures and reduce deliverability.

Step-by-step detection process

  1. Fetch raw email headers from your outbound messages. If you’re testing a sent email, use a mail server log, a monitoring service, or a tool like MxToolbox’s DKIM Checker to extract the full headers.
  2. Locate the DKIM-Signature header. It typically appears in the email headers with a structure like DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail;. Look carefully for any r= tag inside this line.
  3. Check the value after r=. If it’s empty, missing, or set to an unsupported value (such as r=unknown or r=sha1), this indicates an algorithm mismatch. According to RFC 6376, the r= tag is intended for algorithm negotiation, but when misused or left undefined, it causes receivers to reject the signature.
  4. Verify algorithm support. The r= tag without a valid algorithm like rsa-sha256 or ecdsa-sha256 suggests your signing mechanism isn’t aligned with current standards. This can impact inbox placement and trigger spam filters.
  5. Test with a live message. Send a test email to a known inbox tester like Mail-Tester and review the results. A failed DKIM check with a note about "r= tag" or "algorithm mismatch" confirms the issue.

Common causes and what to fix

Many email platforms or legacy systems generate DKIM signatures with outdated or malformed algorithm tags. The r= tag is only meaningful if your signing system knows the correct algorithm to use during validation. If your system defaults to r= without assigning a real value, it breaks DKIM verification.

Let’s be clear: you don’t need the r= tag at all unless you’re implementing algorithm negotiation (which most senders don’t). The best course is to ensure your DKIM signing process explicitly specifies the correct algorithm, such as a=rsa-sha256, and avoids leaving r= blank or misused.

If you’re validating your entire list before sending, checking for these signatures is part of good mail hygiene. You can test how your messages are received with MailTester’s inbox placement tool, which simulates real-world inboxes and reports on DKIM and SPF issues.

Why does a mismatch between algorithm and expectation occur?

When a DKIM signature uses an r= tag with an algorithm that doesn’t match what the receiving server expects, it fails validation. This often happens because legacy systems default to outdated algorithms like rsa-sha1, while modern mail systems require stronger ones like rsa-sha256. The mismatch isn’t always a flaw—it can stem from outdated configurations, non-standard implementations, or third-party tools injecting signatures with unapproved algorithm tags.

Legacy systems and default algorithm choices

Older mail servers and some poorly maintained systems still default to legacy digital signature algorithms, especially rsa-sha1, which was widely used before security improvements. Even though rsa-sha1 is considered insecure by today’s standards and deprecated by RFC 8301, some systems still emit it—especially in environments where updates are infrequent.

Because the receiving server expects a modern algorithm like rsa-sha256, a signature using rsa-sha1 will fail validation. This isn’t a bug in the sender—it’s a mismatch in expectations. It’s like sending a letter in a format no one else supports anymore. You can’t fix the sender’s decision by changing the receiver’s rules, but you can align them.

Non-standard or third-party implementations

Some ESPs, inbound gateways, or email routing tools insert DKIM signatures without following the RFC standards strictly. For example, a service might define a custom algorithm tag (like r=custom-sha3) or use r= incorrectly—even though the standard only allows registered algorithm identifiers.

When such non-standard values appear in the r= tag, mail servers that strictly validate DKIM signatures reject the message. This breaks deliverability even if the signature itself is valid. The issue isn't with the encryption—it’s with the metadata. These mismatches often appear in automated systems where developers skip full validation during integration.

To catch these issues early, you can test your email's actual DKIM signature using a tool like our inbox placement tester. It checks not just delivery, but also whether DKIM tags like r= align with expected algorithms across major inboxes.

Ultimately, the root cause is outdated configurations or non-compliance with established standards like those in RFC 6376. Ensuring your mail server uses rsa-sha256 and verifying your signature output before sending can prevent these failures before they impact your deliverability.

How to fix the r= algorithm mismatch in DKIM

The r= tag in DKIM indicates the signing algorithm didn’t match the one expected by the verifier. To fix it, ensure your email server or email service provider (ESP) signs messages using only rsa-sha256 or ecdsa-sha256. Check your DNS TXT record for the DKIM selector to confirm it points to the correct public key. Re-sign all outgoing messages with a compliant algorithm—especially if you’re using a bulk sender or integration. If you use SendGrid, Mailgun, or similar, confirm their default signing policy uses standard algorithms and update it if needed.

Verify your email infrastructure uses approved algorithms

  • You must ensure your mail server, ESP, or integration signs outbound messages with rsa-sha256 or ecdsa-sha256. Use of older or non-standard algorithms like rsa-sha1 or dsa-sha1 triggers r= errors.
  • Check your ESP’s documentation. Some providers default to legacy algorithms. If you’re using an older integration (e.g., a custom app), verify the signing library isn’t using deprecated options.
  • For systems using SMTP or API senders, confirm the signing step explicitly configures a compliant algorithm. This is common in tools that don’t enforce modern standards by default.

Validate DNS and key configuration

  • Inspect your DKIM DNS TXT record. It must reference the public key that corresponds to the private key used during signing. A mismatch here results in verification failure, even if the algorithm is correct.
  • Use tools like MXToolbox’s DKIM Lookup to validate the record format and ensure no extra characters or incorrect line breaks are present.
  • Check that the selector in your DKIM record (e.g., default._domainkey.yourdomain.com) aligns with the one your sending system is using. A mismatch leads to failed verification.

For bulk senders, re-signing all messages may be required after policy changes. If you’re unsure whether your current setup is compliant, test the outcome with a real inbox placement tool. MailTester’s inbox placement test simulates real-world delivery and identifies r= errors before they affect large campaigns.

What happens if you ignore the r= tag?

If you ignore the r= tag in DKIM, your emails risk being rejected by major providers like Gmail, Outlook, or Apple Mail, especially if the email client detects an algorithm mismatch during signature validation. This often leads to hard bounces, spam filtering, or reduced deliverability—especially in bulk sends. Over time, repeated validation failures can hurt your sender reputation. Addressing it early prevents reputation damage and keeps your messages in the inbox.

Reputation and delivery impact

When email providers like Gmail or Apple Mail encounter an r= tag indicating a mismatch between the signing and verification algorithm, they treat it as a red flag. Even if the address is valid, this mismatch can trigger spam filters or rejection policies. The more often this happens across your sending volume, the more likely your IP or domain gets flagged as unreliable.

Providers use signals like DKIM alignment failures to assess sender trust. Ignoring the r= tag means you’re sending messages that don’t meet the full cryptographic standard. This can trigger automatic rejection during bulk sends—even with otherwise perfect addresses. You may see hard bounce rates climb above 3% in high-volume campaigns, which is a red flag to platforms tracking engagement and bounce trends.

Real-world consequences

According to RFC 6376 (the standard defining DKIM), the r= tag is used to signal algorithm mismatches. Providers like Gmail use this to reject messages where the algorithm used to sign doesn’t align with the one expected. If you’re unaware of this tag, you’re essentially flying blind on signature consistency. This is especially common when switching between signing systems or using third-party services that alter the signature process.

Let’s say you’re using a list you didn’t verify and it contains addresses that were signed with one algorithm but verified with another. The r= tag will appear, and your message gets dropped. Over time, your entire domain may be penalized even if individual addresses are valid.

Use tools that test both syntax and cryptographic alignment before sending. MailTester’s bulk verification checks for issues like this—including DKIM mismatches—before you send. It helps you catch problems like the r= tag in advance, so you don’t waste sends on addresses that are technically valid but delivery-failed due to protocol mismatches. With over 98.9% accuracy, it identifies invalid, catch-all, and risky addresses early, reducing bounce rates and protecting your domain reputation.

How can you test DKIM and r= compatibility before sending?

You can test DKIM and r= tag compatibility before sending by sending a test email through an inbox-placement tool that analyzes headers, SPF, DKIM, and DMARC together—tools like MailTester’s inbox-placement feature detect r= tags and signature validation failures in real time, letting you catch algorithm mismatches before they hit inboxes. Reviewing full email headers post-send confirms whether DKIM signing aligns with your policy and if the r= tag appears due to algorithm mismatch.

Use inbox-placement testing tools that analyze full email headers

Not all verification tools check the full header set. Only tools that inspect actual email headers (from submission to delivery) detect r= tags and signature validation failures tied to algorithm mismatches. This is crucial because some systems accept a DKIM signature even if the key algorithm doesn’t match—resulting in false positives.

Standard email validation tools often miss this. For instance, a domain might pass SPF and DKIM validation based on DNS checks alone, but fail in practice when the r= tag appears due to a mismatched signing algorithm. This is why header-level analysis is industry-standard for accurate deliverability testing.

Use tools that simulate real inbox delivery and examine all technical layers—SPF, DKIM, DMARC, and how they interact. The DKIM standard (RFC 6376) explicitly defines how the r= tag signals algorithm inconsistency. Tools that parse this tag correctly are rare, so testing in a live environment is essential.

  1. Send a test email via MailTester’s inbox-placement feature to analyze full headers. This tool checks DKIM signatures in real-world conditions and surfaces r= tags when algorithms don’t match. It also validates alignment with SPF and DMARC policies, which can otherwise hide or mask signature issues.
  2. Review the full email headers post-send using the tool’s header inspection view. Look for the r= tag in the DKIM signature. If present, it signals that the signing algorithm (e.g., rsa-sha256) doesn’t match the one in the public key. You’ll also see if the signature passes validation but fails alignment—common when systems accept the signature without enforcing algorithm consistency.
  3. Compare the signing method with the DNS public key. Use tools like MXToolbox to retrieve and inspect the DKIM DNS record. Ensure the algorithm specified (e.g., rsa-sha256) matches exactly the one used in signing. Even a small typo (like “sha256” vs “sha256”) breaks compatibility.
  4. Fix the mismatch and retest. Update your signing configuration to use the correct algorithm. Then resend via inbox-placement testing to verify the r= tag disappears and the signature passes validation across all checks.

When to use a tool like MailTester for DKIM and signing checks

You should use a tool like MailTester when validating bulk email lists or setting up automated campaigns where sender reputation and inbox placement matter. It checks that DKIM signatures are correctly formed, use only supported algorithms, and avoid r= tag mismatches by verifying the full signing chain in real time—before you send.

Why DKIM signing checks are critical at scale

When sending to hundreds or thousands of addresses, a single malformed DKIM signature can hurt your sender reputation. Tools like MailTester catch issues like incorrect algorithm tags (r=) early, especially in mass campaigns or integrations with platforms like SendGrid or HubSpot. This isn't just about compliance—it's about preventing your messages from being rejected or marked as spam.

Digital signatures in email rely on standards like RFC 6376 and RFC 8301, which define acceptable signing algorithms. If a DKIM signature uses an unsupported or improperly tagged algorithm, the receiving server may reject it, or worse, flag the sender as suspicious. The r= tag specifically indicates the signature algorithm used; mismatched or missing values break validation.

Real-time checks prevent delivery failures and reputational damage

During integration testing or when building automated workflows, you need fast, reliable feedback. MailTester’s real-time verification API lets you validate email addresses and their DKIM signatures on the fly, catching r= issues before they go live. This is especially useful when syncing customer data from CRM or e-commerce platforms.

For example, if your system generates a DKIM signature using SHA-256 but the r= tag still references SHA-1, your message may be rejected by strict filters. MailTester helps you spot and resolve such discrepancies before sending. It’s like running an inbox test before the campaign—except it checks the digital signature itself.

Using the real-time email verification API lets you integrate these checks directly into your sending pipeline, ensuring only properly signed and validated addresses proceed. You’re not just filtering invalid emails—you’re validating the full trust signature chain.

Ultimately, email reputation is fragile. A single failed DKIM check doesn’t always mean a bounce—but it accumulates. Regular, automated checks with a tool like MailTester keep your domain’s trust score stable. As email authentication becomes more enforced by providers, proactive validation isn’t optional anymore.

How MailTester helps catch r= errors during deliverability checks

You don't need to wait for bounces or spam complaints to find r= tag issues in DKIM signatures. MailTester scans email headers in real-time across multiple test inboxes, flagging unsupported or malformed r= tags before you send to real recipients. This prevents algorithm mismatches that can break authentication and hurt sender reputation.

Real-time header scanning catches technical flaws early

When you send mail, the DKIM signature includes a tag like r= to specify the algorithm used. If your email provider uses an unsupported or misconfigured algorithm, this tag can trip up receivers. MailTester checks how your emails appear in real inboxes — including Gmail, Outlook, and Yahoo — using actual test accounts that mirror end-user behavior.

This means you’re not relying on theoretical models or black-box reports. You’re seeing exactly how your email renders in inbox environments where DKIM validation occurs.

Accuracy and proactive verification

With 98.9% accuracy, MailTester detects anomalies like malformed r= tags, unsupported algorithms, or mismatches between the signature and the digest. These flaws often go unnoticed until deliveries fail or your domain gets flagged.

By catching them before the send, you avoid reputation damage caused by failed authentication. It’s not just about fixing one broken message — it’s about ensuring consistent alignment across every email in a campaign.

Let’s say you’re setting up automated sends through a CRM or marketing platform. Without pre-sending checks, an r= error could go live with thousands of messages. MailTester’s inbox placement tester lets you simulate delivery across major providers and catch those issues before a single message goes out.

For developers, the real-time verification API integrates directly into your workflow. As new addresses enter your system, it validates the full email stack — including DKIM’s r= tag behavior — and gives you clear, actionable feedback.

Think of it as a dry run for your domain’s deliverability. It’s not enough to have a valid DKIM key. The implementation must follow standards — like those outlined in RFC 6376. That’s where MailTester adds clear value: you don’t just know if an email is valid — you know why it works or fails.

The bottom line: algorithm consistency prevents delivery failure

The r= tag in DKIM is not a formality—it’s a signal. When it matches the actual signing algorithm, it confirms the signature is both valid and recognized by receiving servers.

A valid signature isn’t enough. If the algorithm used doesn’t match what the r= tag claims, messages may fail silently or be marked as suspicious—even if the signature verifies mathematically.

Consistent algorithm usage across your sending infrastructure reduces risk. Use tools that test for r= mismatches and validate signatures using realistic, real-time conditions.

Sources

Keep reading

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

What does r= mean in a DKIM signature?

The r= tag in DKIM specifies the cryptographic algorithm used. If it lists an unsupported value, it can trigger delivery failures.

Is r= required in every DKIM signature?

No, it is optional and only included when the algorithm is non-default or non-standard.

Can r= cause an email to be rejected?

Yes, if the algorithm specified by r= is not supported by the receiving server, the email may be rejected or marked as spam.

Which DKIM algorithms are still accepted?

rsa-sha256 and ecdsa-sha256 are the only widely accepted current standards. rsa-sha1 is deprecated.

How do I update my DKIM signature to fix r= errors?

Reconfigure your email system or ESP to sign messages using only rsa-sha256 or ecdsa-sha256, then re-run test sends.

Can a third-party tool like MailTester detect r= issues?

Yes, MailTester analyzes full email headers during inbox-placement tests and flags anomalies like unsupported r= tags.

Does every email have a DKIM signature with r=?

No—only signatures using non-standard algorithms include the r= tag. Standard ones omit it.

Why do some old email systems still use rsa-sha1?

Legacy systems may not be updated, or administrators might not be aware of current security requirements.

What’s the risk of sending emails with unsupported r= values?

High risk of spam filtering, low inbox placement, and long-term damage to sender reputation.

Can MailTester help with DKIM setup overall?

Yes—it doesn’t set up DKIM but detects faults in signatures, including r= tag mismatches, during delivery testing.

Do all ESPs support rsa-sha256 for DKIM?

Most modern ESPs do. Check your provider’s documentation for current signing policy defaults.

Why does MailTester offer a free verification tier?

To help users detect invalid or problematic emails—like those with flawed DKIM signatures—before sending.