DKIM q= Tag Fix | MailTester

Why Is Your DKIM q= Tag Causing Delivery Failures?

You’re sending transactional emails on time. Your list is clean. Yet some messages still vanish into spam folders—or never arrive at all. One silent culprit might be hiding in your DKIM signature: the q= tag.

The receiving server sees a q=d or no q= at all, and it raises a red flag. That single parameter signals whether the message was signed by your domain’s own infrastructure or by a third-party vendor. If it says q=d but you’re using a sending platform, the server assumes it’s self-signed—when it’s not.

If that assumption is wrong, the message gets scrutinized more. It may be tagged as suspicious, throttled, or rejected outright. In some cases, even high-reputation senders face inbox placement drops because of this one misconfiguration.

Key takeaways

Setting q= to d implies the domain signed the message itself, which can break trust if your email is sent via a third-party provider.
Receiving servers use the q= tag to verify the signing infrastructure identity—missing or incorrect values undermine DKIM validation.
Fixing q= to match your actual sending infrastructure (e.g., q=3 for third-party vendors) improves deliverability by reducing suspicion and increasing authentication alignment.

What Does the DKIM q= Tag Actually Mean?

The DKIM q= tag indicates how the message was signed: q=d means your domain signed the email directly using its own key, while q=i means a third party—like a marketing platform—signed on your behalf using a selector-based mechanism. This distinction affects how receiving mail servers validate your email and impacts deliverability.

q=d: Your Domain Signed the Message

If you see q=d in a DKIM signature, it means your organization’s own domain keys were used to sign the email. This is common when you manage your own email infrastructure, like with an in-house mail server or a hosted solution you fully control. It shows strong alignment between your domain and the sending infrastructure, which mail servers view favorably.

For example, if you’re sending from mail.yourcompany.com and your DKIM record is set up with your own selector._domainkey.yourcompany.com, the q=d tag is expected. It’s a clean path from domain to signature and is standard practice for direct senders.

q=i: Third-Party Signing (e.g., SendGrid, Mailchimp)

When you use a service like SendGrid, Mailchimp, or Amazon SES to send email, they typically sign the message on your behalf using a q=i tag. This means the signing key comes from their infrastructure (e.g., sendgrid._domainkey.yourcompany.com), not your own.

This is not a problem—it's standard. But receiving servers may look at q=i and check whether the third party is authorized to send on your behalf. That’s why you must properly configure your DMARC policy to include authorized senders. Without correct alignment (via SPF or DKIM), messages with q=i can be flagged as suspicious, especially if the sender isn’t in your SPF or DMARC allowlist.

Understanding the role of q= helps you audit your email infrastructure properly. If you’re not certain how your DKIM signatures are set up, you can verify the headers of a delivered email and check the q= value. A simple, real-time email check can reveal whether your DKIM alignment is correct and if any third-party signs are properly authorized.

For deeper analysis, tools like MxToolbox or the DKIM specification (RFC 6376) offer authoritative guidance. Using an email verification service like MailTester’s email checker lets you test individual addresses and validate signature structure before sending.

How Is the q= Tag Set in Practice?

The q= tag in DKIM signatures is determined by the signing mechanism used, not the From: domain. If your email is signed by a third-party ESP like SendGrid or Mailchimp, it typically sets q=i by default, indicating the signature was created on behalf of the sender. If you self-host your signing keys and sign at the domain level, the server will usually set q=d, meaning the key is hosted directly at the domain. This behavior is consistent with the DKIM specification (RFC 6376), which defines q as a way to distinguish between sender-controlled and third-party signed messages.

How ESPs Handle the q= Tag

When you use a third-party email service provider (ESP), they sign your emails on your behalf using their infrastructure. This standard setup results in q=i, which is expected and accepted by most receiving mail servers. You do not need to change this unless you're running a high-volume campaign where some providers require q=d for authentication consistency. In those cases, you must either switch to domain-level signing or request the ESP to support q=d, though not all allow this.

How Self-Hosted Key Signing Works

If you manage your own DKIM keys (e.g., via a mail server like Postfix or a custom sending system), the q= tag reflects the key’s location. When you sign messages using a key published at the domain level, the server sets q=d. This is the standard for organizations that control their own domains and signing processes, and it aligns with best practices for authentication transparency.

Receiving servers check the q= value to assess whether the signature is tied to the domain owner or an external provider. A mismatch—like q=i when you expect q=d—can trigger scrutiny, especially in strict filtering environments. While q=i is not inherently bad, consistency between your setup and expectations matters for long-term deliverability.

For teams troubleshooting DKIM alignment, it's useful to validate both the signature and the q= value. Tools like MailTester’s inbox placement testing can help you simulate real-world delivery and check how receiving servers interpret your DKIM signature, including the q= tag, in practice.

Common Mistakes That Lead to Incorrect q= Tag Assignment

You’re likely getting poor inbox placement or authentication warnings because your DKIM q= tag is set to d—even when it should be s—due to misconfigured keys, copied records, or assuming domain-level DNS settings equal signing behavior. The q= tag reflects the signing party, not just DNS setup. Let’s fix that.

Using Third-Party Senders with Self-Signed Keys

You're using a service like SendGrid or Amazon SES but manually generating a DKIM key without letting the service handle the signing—this forces you to set q=d even though the signature originates from a third-party.
Receiving servers treat q=d as “domain-signed,” but when the actual signature comes from a vendor, it breaks trust. This is why RFC 6376 requires the q= value to match the signing entity.
Never set q=d manually when your sender is a third-party service unless you’re actually signing with your domain’s private key—which you shouldn’t do if you’re outsourcing email delivery.

Copied or Misaligned DKIM Records

You copied a DKIM record from a provider’s guide but kept the q=d tag, even though your sending infrastructure is hosted elsewhere—this misleads receivers about who is responsible for the signature.
Some providers use q=s when signing on behalf of you (e.g., SendGrid with a s= selector), but if you copy the TXT record and assume it’s correct, you’re copying a misaligned configuration.
Always verify that the q= value corresponds to the actual sender identity. If you're not the signing party, q=d is incorrect and harms deliverability.

Assuming DNS-Level DKIM Records Override Signing Behavior

Just because you’ve added a DKIM TXT record to your domain doesn't mean your mail server is signing with q=d—the signing tool or service decides that.
Many systems (like Postfix or SendGrid) set q=s when they’re the signer, even if your DNS entry says q=d. The record is a validation target, not a behavioral rule.
Check your email platform’s documentation. You might need to explicitly enable a q=d or q=s mode in the sender config—and only if you’re signing with your own key should you ever use q=d.

Use MailTester’s email checker to spot-check if your DKIM configuration aligns with real-world delivery results before sending campaigns.

How to Correctly Set the DKIM q= Tag Based on Your Setup

If you’re seeing delivery issues due to a missing or incorrect DKIM q= tag, the fix depends on your email infrastructure: managed ESPs like Mailchimp or Klaviyo should sign with q=i, while self-hosted DKIM implementations must use q=d. Never override the value manually unless you fully control the signing pipeline. Verify real-world values using your ESP’s DMARC reports or email delivery dashboards.

Step-by-step: Set the correct q= value for your setup

Check your ESP’s documentation — If you use a managed platform like Mailchimp, Klaviyo, or SendGrid, confirm they sign with q=i. These services typically manage the DKIM signing layer for you, and setting q=i ensures the signature is properly tied to the individual sender (i.e., your domain or subdomain) rather than the infrastructure used to send the email. This improves trust and alignment with the domain’s DMARC policy.
Verify your DKIM signature headers — When sending directly via your own SMTP server or MTA, inspect outgoing headers. The d= tag identifies the domain, while q=d means the signature was generated by the domain’s own key. Using q=d is standard for self-hosted DKIM and is required if you are not using a third-party signing service. This ensures the receiving server can validate the signature against your published TXT record.
Use DMARC reports to confirm actual q= values — The most reliable way to verify what’s actually being sent is to analyze DMARC aggregate or forensic reports from receivers like Google or Microsoft. These reports show the true q= tag in the DKIM signature and can highlight mismatches between expected and actual behavior. Tools like DMARC.org provide guidance on interpreting these reports.
Do not manually override q= unless you own the signing infrastructure — Overriding the value breaks the trust model. An incorrect q= tag (e.g., forcing q=i for self-signed emails) will fail validation even if the signature is mathematically correct. Receiving servers use q= to determine whether the signature is tied to the signing domain or an ESP. Always let the system determine this.
Validate your setup with real-world testing — Before sending to production lists, test your DKIM configuration using inbox placement tools. Tools like MailTester’s inbox placement tester simulate real inbox delivery and check whether DKIM, SPF, and DMARC policies are respected by major mail providers.

Why Verifying DKIM Setup Is Essential — Even After Configuration

You can’t rely on a DNS record alone to ensure DKIM works in production. Even if your DKIM signature passes a basic check, issues like a missing or incorrectly set q= tag—especially when set to d—can cause delivery failures, particularly with strict receivers like Gmail or Microsoft. The receiving system validates the full signature chain: timing, selector, alignment, and crucially, the q= parameter. A misconfigured q= tag may pass a test but still trigger distrust.

DKIM Isn’t Just About DNS—It’s About the Full Signature Chain

Many tools show a successful DKIM test based only on DNS record presence or basic signature syntax. But that’s incomplete. Receiving mail servers, including those at Google and Microsoft, validate the complete chain: the timestamp, the selector, the domain alignment, and the q= value. The q= tag specifies the query method used during verification. If q= is not set at all, or is set to d (default), the receiver assumes no cryptographic signing occurred and may reject or flag the email.

When q= is set to d, it means “domain” — an instruction to query the domain’s DNS directly. While technically allowed, this method is not ideal for high-volume or time-sensitive delivery. It adds unnecessary verification steps and exposes the signature to delays or inconsistencies in DNS response times. More importantly, it signals to receivers that the sender isn’t using a stronger, authenticated method like a key fingerprint or a dedicated selector.

Real-World Failures Show What Tools Miss

A DKIM signature may look valid in a test, but if q= is set to d, the signal is weak. Receiving servers see this as an incomplete or low-trust authentication path. Gmail’s internal filtering systems prioritize mail with well-formed, well-documented DKIM signatures. A q= value of d can reduce inbox placement, especially when combined with other weak signals like poor reputation or unverified sender infrastructure.

Even if SPF and DMARC pass, a misconfigured DKIM q= tag can still break deliverability. This is where automated verification tools with deep validation come in. Tools that check only DNS or basic syntax miss these subtle but critical failures. The difference between pass and fail often lies in the detail: a correctly set q= tag, proper timestamp alignment, and a verified signing key are all part of the signal receivers use to make decisions.

Let’s be clear: DNS alone isn’t enough. You need end-to-end validation. Use a tool that checks the full signature during simulated delivery. MailTester’s inbox placement tests and real-time verification API let you test how your DKIM signature performs in authentic receiver environments. Test your DKIM setup against real inbox conditions before sending to your audience.

How to Test DKIM q= Tag in Real Messages Using MailTester

You can verify how your DKIM q= tag is being interpreted in live email delivery by sending a test message through MailTester’s inbox-placement tester. This tool delivers the message to real inboxes across major providers, lets you inspect the raw header, and confirms whether the q= value in the dkim-signature header matches your signing configuration. This is the only way to catch mismatches before they hurt deliverability.

Send a test email via MailTester’s inbox-placement tester. Go to inbox placement testing and send a real message as you would to your audience. This triggers delivery to actual email providers like Gmail, Outlook, and Yahoo, where DKIM is enforced.
Inspect the delivered message source. Once delivered, download the full message header. Look for the DKIM-Signature field. If your signing setup uses the q=canonical or q=relaxed mode, verify that it appears exactly as configured—no default fallback to q=d.
Compare results across domains and ESPs. Repeat the test using different sender domains or email service providers (ESPs). Some ESPs or recipients may normalize or strip q= values. Use this to identify if the issue is sender-specific or receiver-specific.
Validate delivery paths with the real-time API. Integrate MailTester’s verification API to pre-check delivery paths during list hygiene. This detects when the q= tag is missing or misreported before you send, reducing risk at scale.

Why q= matters in real-world delivery

The q= tag in DKIM determines how the signature handles whitespace and line breaks during validation. If set to d (default) instead of relaxed or canonical, even minor formatting changes can cause validation to fail. This is especially common when passing through ESPs or gateways that modify content.

According to RFC 6376, the q= tag is used to define the canonicalization algorithm applied during signature verification. Most modern systems expect q=relaxed for both headers and body. If you see q=d in a real message, it indicates misconfiguration or a fallback behavior from an outdated or poorly implemented signing setup.

Spot inconsistencies early

Use MailTester to run periodic checks on your sending domains. A consistent q=relaxed result across providers confirms alignment. A mismatch—like q=d in Gmail but q=relaxed in Outlook—signals a potential issue with your signing chain or ESP handling. Correcting this before a large send avoids bounces, spam placement, and inbox rejection.

How MailTester Helps Fix DKIM q= Issues Before They Impact Delivery

You can catch DKIM q= tag mismatches before they hurt inbox placement by testing real delivery scenarios across Gmail, Outlook, and iCloud. MailTester’s inbox-testing feature simulates actual delivery and reports the exact DKIM signature values received—including q=—so you can validate your configuration against what real mail systems see. It’s not a dry-run; it’s a live envelope check.

What You Can Verify with MailTester

Inspect the exact DKIM signature value (including q=) that arrives in Gmail, Outlook, or iCloud—no guessing, no assumptions.
Check the full header chain and envelope: MailTester validates the complete email path, including sender IP, SPF, DKIM, and DMARC, to catch misconfigurations early.
Identify if the q= tag is missing or incorrectly set to d—common with some older or misconfigured email platforms—before it triggers filters or rejects your message.
Use the inbox tester to simulate delivery to major providers, seeing exactly how your message appears on the receiving end, including any DKIM validation failures.
Validate your DKIM setup against real-world behavior. A dry-run check might pass, but MailTester shows what actually lands in the inbox.

Why This Matters for Delivery

According to RFC 6376, the DKIM q= tag defines the query mechanism. When it’s missing or set to d (default), some receivers may apply stricter validation, especially if alignment or key fetching fails. This can silently reduce inbox placement. You might not know until your deliverability drops.

MailTester’s inbox tester doesn’t just report “valid” or “invalid”—it tells you why it failed. The platform’s 98.9% accuracy rate comes from testing against actual receiving systems, not heuristics. It detects subtle misconfigurations that other tools miss, like incorrect q= values, signature alignment issues, or key retrieval problems.

Once you know the exact fault, you can fix it before sending to real users. For example, if q= is set to d but your domain doesn’t support key retrieval, changing it to a valid value or updating your DNS record can resolve the issue. And unlike some tools that only validate a single point in the chain, MailTester checks the full stack: the entire header chain and envelope, not just the DKIM signature.

Integrations with SendGrid, Mailchimp, and HubSpot let you run full-stack inbox tests without switching tools. Test your campaign before launch, or verify a new list via the bulk list verification tool—then confirm the delivery behavior with inbox placement testing.

For real-time validation during development or onboarding, use the email verification API. You can check individual addresses or lists and see their DKIM signal before sending. Test inbox placement and see how your messages land in real inboxes—before you send them to customers.

What If Your q= Tag Is Correct but You Still Have Bounce or Spam Reports?

If your DKIM q= tag is set correctly but you're still seeing bounces or spam reports, the issue likely isn’t just DKIM—other factors like misaligned SPF, weak DMARC policies, poor sender reputation, or bad list hygiene can still trigger filters. Even with perfect authentication, sending to invalid, disposable, or role-based addresses can damage your reputation and reduce inbox placement.

Beyond DKIM: The Hidden Drivers of Email Rejection

DKIM is necessary but not sufficient. Even if your q= tag is set to dkim or dns appropriately, your messages may still fail if SPF doesn’t align with the sending domain or DMARC isn’t enforced. A misconfigured DMARC policy—especially one set to none—can allow spoofing and erode trust with receiving servers, which treat inconsistent policies as red flags.

Bad sender reputation follows from sending to non-deliverable or suspicious addresses. Role accounts like support@, admin@, or sales@ often get flagged as spam sources, especially if they receive high volumes of mail without engagement. Disposable email domains (like @temp-mail.org) are notorious for high bounce rates and abuse, and consistently sending to them harms your overall sender score.

Proactive Testing and Remediation

Let’s be honest: no single check guarantees deliverability. Use MailTester’s bulk email verification to test entire lists before sending. It checks for validity, catch-all status, disposable domains, and role accounts—all contributors to poor deliverability. You’ll catch problems before they hit your sender reputation.

Even after setup, reputation isn’t static. Sending to a previously clean list can fail if the recipient’s filters have updated or if other senders using the same infrastructure were flagged. That’s why continuous monitoring is critical. Use MailTester’s inbox placement testing to simulate delivery across major providers and detect filtering early.

Industry-standard practices, like those outlined in RFC 6376 for DKIM and RFC 7483 for SPF, are foundational—but they’re just one part of a broader deliverability strategy. Always test, verify, and monitor. It’s not about perfection. It’s about consistency, cleanliness, and accountability.

Final Check: Does Your DKIM q= Tag Match Your Infrastructure?

The q= tag in your DKIM signature must align with how your email infrastructure handles authentication. If you're using an ESP, confirm they’re using q=i in signatures—this is required for proper validation by most receivers. Using q=d with modern ESPs breaks alignment and can reduce inbox placement.

If you’re self-hosting, ensure q=d is consistently applied across all outbound messages from your domain. Inconsistencies confuse receiving servers and trigger validation failures. Don’t rely solely on DNS checks—validate real message headers to confirm the q= tag matches your setup.

Discrepancies in q= tags are especially damaging during domain warm-up or when sending to large lists. A single misaligned signature can trigger anti-spoofing filters. Correct it before sending bulk campaigns to protect sender reputation and deliverability.

Sources

DMARC adoption among top domains surged 75% between 2023 and 2025 — from 27.2% to 47.7% — in the wake of Google and Yahoo's bulk-sender authentication requirements. — EasyDMARC 2025 DMARC Adoption Report (2025)
After Gmail began requiring authentication for large senders, the number of unauthenticated messages Gmail users received plummeted by 75%. — Google (The Keyword blog) (2023)

Keep reading

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

Frequently asked questions

What happens if DKIM q= is missing in a signature?

Receiving servers may reject the message or treat the signature as untrustworthy, especially if SPF and DMARC disagree with the result.

Can setting q=d harm delivery when using a third-party sender?

Yes — it falsely claims the domain signed the message, which breaks the trust model. Receiving systems see this as a sign of misconfiguration or spoofing.

How do I know what q= value a message should have?

It depends on who signed it. ESPs use q=i. Self-hosted keys using the domain's own selector use q=d.

Does DKIM with q=d guarantee inbox placement?

No — it's one factor. Poor list hygiene, low engagement, spam traps, or weak sender reputation can still block delivery.

Can MailTester detect if my DKIM q= value is wrong?

Yes — its inbox-placement tests validate the exact signature header in real email deliveries and report q= values.

Why does q=i appear in some DKIM signatures but not others?

It indicates a third-party signing party, like an email service provider. This is normal and expected for hosted solutions.

Is changing the q= tag something I should do manually?

Only if you control the signing infrastructure. Most platforms set q= automatically; overriding it manually creates delivery issues.

Can incorrect DKIM q= cause my domain to be blocked?

Indirectly — consistent signature mismatches can trigger spam filters and lead to domain reputation damage over time.

What should I check if my email is going to spam despite correct DKIM?

Verify SPF alignment, DMARC policy enforcement, sender reputation, list quality, and engagement rates — DKIM is just one part.

How often should I test my DKIM q= setup?

Before sending to new lists, after changing ESPs, or when adjusting DNS records. Use real-time testing to catch issues early.

Do all mail providers check the q= value?

Not all publicly confirm, but major providers like Google, Microsoft, and Apple use it in their filtering logic to validate sender authenticity.

Can I have both q=d and q=i in the same domain?

Yes — if different services sign messages on your behalf (i.e., one self-hosted, one third-party). But q=d should only be used if the domain itself signs.