Why Are My Emails Going to Spam? SPF, DKIM, and DMARC Explained

Start by finding out what actually failed

A message in spam, a rejected message, and a message that was never sent are three different problems. Before changing DNS records, establish which one you have. A missing password-reset email could be an application error before the email provider ever receives it. An accepted message could still be filtered by the recipient.

Follow one specific message through its journey: did your application request a send, did the provider accept it, and what happened at the receiving server? Save the timestamp, recipient domain, provider message ID, and any delivery or bounce response. Use those details to investigate the same event rather than mixing evidence from several attempts.

Authentication is an important checkpoint, but a successful authentication result is not an inbox guarantee. This guide explains how to separate configuration problems from message-level failures and audience issues so you can fix the part that is actually broken.

The three identities behind a single email

A reader sees a From address such as receipts@example.com. Behind that visible identity, the sending system also uses an envelope sender for handling bounces. A DKIM signature can name yet another domain. These identities may legitimately differ when you send through a newsletter platform, transactional provider, or support system.

SPF checks whether the connecting server is authorized for the envelope-sender domain, with a HELO identity used in certain cases. DKIM checks a signature associated with a signing domain. DMARC connects authentication to the domain in the visible From address. Simply finding all three records in DNS does not establish that a particular message uses them correctly.

• Visible From: the identity your recipient sees in the message header.
• Envelope sender: the SMTP identity commonly reflected in Return-Path on a delivered message.
• DKIM signing domain: the d= value inside a DKIM-Signature header.

SPF: permission for a sending server

SPF publishes the sending hosts allowed to use a domain's SMTP identity. Its record often delegates some authorization to a provider through include terms. Publish one SPF policy for a given name rather than adding a separate v=spf1 record whenever you connect another service; multiple SPF records at that name cause an error.

The often-quoted ten-lookup limit is more precise than ten arbitrary DNS packets. SPF limits the evaluated DNS-querying terms, including nested include processing and redirect. Exceeding that limit produces permerror. The SPF specification describes the rules. A short-looking record can still depend on a long chain underneath it.

When adding a provider, compare its current setup instructions with the existing policy. Do not delete another sender's authorization merely to remove a warning. First identify which application owns each entry and whether it still sends mail.

DKIM: a published key is different from a verified message

DKIM signs selected message content and headers using a private key. The receiver retrieves a public key using the signature's selector and signing domain. For example, s=mail2026 with d=example.com points to mail2026._domainkey.example.com. The DKIM specification explains this selector-based lookup.

Finding that DNS key proves it is published, not that your provider signed the message or that the received signature verified. Conversely, failing to find a few common selector names does not prove DKIM is absent. Read s= and d= from a real test message or obtain the selector from your provider, then check that exact name.

This matters when two applications share your brand. A newsletter may be configured correctly while receipts from a different provider use an unconfigured signing identity. Test each mail stream independently rather than assuming one successful message covers everything.

DMARC alignment: why SPF and DKIM can pass while DMARC fails

DMARC requires an authentication pass aligned with the visible From domain: either aligned SPF or aligned DKIM can satisfy it. Under relaxed alignment, the relevant domains share an organizational domain; strict alignment requires an exact domain match. The DMARC specification describes both modes.

Consider this fictional receipt. The visible sender is receipts@example.com. SPF passes for bounce.delivery.example.net, and DKIM passes with d=delivery.example.net. Both checks can pass for the provider's identities while neither aligns with example.com. That combination can produce a DMARC failure despite two reassuring pass labels.

Now suppose the provider signs with d=example.com and that signature verifies. That gives the message an aligned DKIM pass. The repair is configuring the provider's supported custom-domain authentication and verifying a new message, rather than adding unrelated DNS records until a dashboard looks green.

Inspect a received message, not just the provider's setup screen

Send a test through the exact route that is failing: the actual receipt flow, password-reset flow, or newsletter service. In the receiving mailbox, open the original message or full headers. Look at the receiving provider's authentication summary and Authentication-Results, then compare the visible From domain with the authenticated identities.

Use results added by the receiving service you trust. Arbitrary header text copied into an email is not evidence of successful authentication. If the message was rejected before delivery, use the sender's delivery log and the recipient server's response instead of expecting headers that never reached a mailbox.

• Record the tested mail stream, time, and recipient provider so the result is reproducible.
• Check the SPF result and the domain it evaluated, rather than reading only the word pass.
• Check the DKIM result, signing domain, and selector; one message can carry multiple signatures.
• Check the DMARC result for the visible From domain and identify which aligned method passed.
• Retest after a change using a newly generated message, not an old message's unchanged headers.

Use the DNS checker as a configuration audit

StatFlare's Email Deliverability Checker inspects public DNS configuration: MX, SPF, DMARC, and a set of common DKIM selectors. It highlights findings such as duplicate SPF records, lookup-budget concerns, published policies, and discovered selector keys. Results can come from a short-lived cache, so review the observation time when checking a recent DNS edit.

The checker does not send a test email, inspect your provider account, or verify a delivered message's DKIM signature. Its score summarizes the configured checks; it is not a measured inbox-placement percentage. Use its findings alongside message headers and delivery logs rather than treating the score as a verdict on every email.

A useful result is specific: this hostname has two SPF policies, this lookup chain needs investigation, or this selector was not among those detected. Turn that finding into a question for the sending provider instead of applying a generic record to every domain.

Move toward enforcement after testing every legitimate sender

A monitoring DMARC policy, p=none, does not request quarantine or rejection of failing mail. It is useful during an inventory and observation phase; it does not automatically generate useful reports unless reporting is configured and receivers send them. Before tightening policy, test support replies, billing, newsletters, forms, and infrequent services such as account recovery.

Keep a copy of the current DNS configuration and document which system owns each sender. Review reports with someone who can distinguish expected services from unauthorized traffic. Then change policy in a controlled way and watch both authentication results and delivery failures. A stronger policy applied before legitimate senders are aligned can disrupt real mail.

Quarantine and reject express requested handling, not a guarantee that every receiver will behave identically. Strong authentication also cannot prevent someone using a lookalike domain or a compromised legitimate account. Keep those risks separate from whether your own domain's mail authenticates.

If authentication passes, investigate audience and delivery evidence

Stop editing authentication records once message-level evidence shows the intended setup works. Next compare affected and unaffected mail: which recipient providers are involved, which stream is affected, and whether failures began with a new list, provider, or sending pattern. Preserve a working sample and a failing sample so you can compare them.

Check whether recipients asked for these messages, whether unsubscribe handling works, and whether old or invalid addresses are repeatedly mailed. Ask your provider to interpret its bounce, complaint, and rate-limit evidence. Avoid declaring a domain blacklisted solely because one recipient found one message in spam.

Requirements are recipient-specific and change over time. For Gmail recipients, consult Google's current sender guidelines, including the additional requirements for bulk senders. Authentication is one part of those guidelines; mailing practices and unsubscribe support matter too. A promotional campaign and a password reset should also be investigated as distinct mail streams.

A checklist to keep with your next delivery incident

Keep a short incident note with evidence and one next action. This prevents a common debugging cycle: change DNS, send a different kind of message, observe a different outcome, and assume the change caused it. A controlled comparison gives you something you can explain to your provider or a colleague.

• State the symptom precisely: never submitted, bounced, delayed, or delivered to spam.
• Identify the application, sending provider, visible From domain, and affected recipient provider.
• Save a message ID, timestamp, delivery response, and a redacted header sample where available.
• Audit DNS, then confirm actual authentication and alignment on a newly received test message.
• Change one identified cause, retest the same flow, and record what improved or remained unresolved.
• Repeat the check for other legitimate sending services before tightening domain-wide policy.

Frequently asked questions

Does passing SPF guarantee inbox delivery? No. SPF evaluates one authentication identity; it does not measure audience consent or guarantee a receiving provider's delivery decision.

Do both SPF and DKIM have to align for DMARC to pass? DMARC can pass through either aligned SPF or aligned DKIM. A receiving provider may separately require both authentication methods under its sender rules.

Why does StatFlare report DKIM as unverified when my provider says it is enabled? The checker probes common selectors. A custom selector can be missed; inspect the exact selector in a received message and confirm the receiver's signature result.

Can I copy another company's SPF or DKIM records? No. Use records issued for your own services and domain. Another setup can authorize the wrong sender or publish a key unrelated to your messages.

Will changing MX fix outbound spam placement? MX describes inbound mail routing. It is not proof that outbound messages are authenticated or wanted by recipients.

Should I switch directly to p=reject to fix spam? First inventory and validate legitimate mail streams. Tightening a domain policy is not a general fix for inbox placement and can disrupt unaligned legitimate mail.