How to Fix Spam Notifications: A Technical Email Deliverability Guide

If you need to fix spam notifications, do not start by rewriting a subject line or randomly changing DNS records. Treat the notification as an operational signal: identify where the message failed, inspect the evidence, and correct the authentication, reputation, list-quality, or message-construction problem that caused it.

A spam notification can mean several different things. A recipient may report that a legitimate transactional email landed in Spam or Junk. Your sending service may warn that a mailbox provider is classifying traffic as spam. Or your SMTP/API logs may show a temporary deferral or permanent rejection with wording such as “message classified as spam,” “unauthenticated email,” or “unsolicited mail.” These are related problems, but they do not always have the same fix.

Start by identifying what the spam notification actually says

The fastest way to waste time is to treat every deliverability warning as a generic “spam problem.” Save the full notification, bounce payload, or event webhook record first. The exact SMTP reply, enhanced status code, recipient domain, sending IP, envelope sender, and timestamp tell you whether you are dealing with inbox placement, a temporary throttle, a hard block, or an authentication failure.

Spam folder placement versus delivery rejection

A message in the spam folder was accepted by the receiving system. The recipient can usually find it, and your sending provider may report the event as delivered because SMTP delivery succeeded. That does not mean the message reached the inbox, only that the recipient server accepted responsibility for it.

A rejection is different. Your mail transfer agent or email provider receives a failure response during the SMTP conversation. Typical examples include:

• 421 4.7.0 or another 4.x.x response: a temporary delivery problem, rate limit, reputation issue, or policy deferral. The sender should retry with backoff rather than immediately send the same message again.
• 451 4.7.1: a transient policy or anti-spam condition. It may clear after throttling, reputation recovery, or a recipient-side retry window.
• 550 5.7.1: a permanent policy rejection often associated with spam, authentication, content, or sender reputation. Read the accompanying text; 5.7.1 alone is not a complete diagnosis.
• 550 5.7.26: commonly used in Gmail-related authentication failures, especially when a message does not meet sender authentication requirements.
• 554 5.7.1: a permanent transaction failure that can indicate that a provider rejected the message as suspicious or unwanted.

SMTP’s first status digit is the useful first triage signal: 2 is success, 4 is transient, and 5 is permanent. Enhanced status codes add context, but mailbox providers can include their own wording and routing identifiers, so preserve the whole response rather than categorizing only by the number. Google publishes recipient-facing SMTP troubleshooting guidance and notes that its errors include gsmtp identifiers; the IANA registry defines the standardized enhanced-status-code framework. (support.google.com)

Collect the evidence before changing anything

For one affected message, gather the following in a ticket or incident document:

1. The recipient provider and address domain, such as Gmail, Outlook.com, Yahoo, or a corporate domain.
2. The full SMTP response or provider event payload, including 421, 451, 550, or 554 text.
3. The visible From: address, Reply-To:, envelope sender / Return-Path, and sending domain.
4. The full raw message headers from a delivered test message.
5. The sending IP and hostname, if you operate the SMTP infrastructure directly.
6. The API request ID, SMTP queue ID, or message ID used by your sending system.
7. A recent send-volume graph, bounce rate, complaint rate, and the affected message type.
8. The exact DNS TXT and CNAME records currently published for SPF, DKIM, and DMARC.

This evidence matters because the same customer-facing alert can have different root causes. A password-reset email that suddenly lands in spam after a release might have a malformed HTML part, a broken DKIM signature, or a new tracking redirect domain. A batch of invoices rejected by Gmail may instead be a volume spike from a previously quiet domain. Do not assume content is responsible until you have checked authentication and logs.

Fix spam notifications with a layered troubleshooting order

Email filtering is not a single score assigned by one universal scanner. Receivers combine authentication, alignment, sending reputation, recipient engagement, infrastructure, message content, URLs, historical patterns, and local user preferences. The practical response is to troubleshoot in a stable order: first prove identity, then check infrastructure, then control traffic, then inspect the message itself.

Use this priority order:

1. Authentication and domain alignment — SPF, DKIM, and DMARC must be present and operating as expected.
2. Sending identity and infrastructure — reverse DNS, TLS, HELO/EHLO identity, IP reputation, and stable domains.
3. Recipient and list quality — bounces, inactive addresses, recycled addresses, and complaint sources.
4. Traffic pattern — sudden volume changes, retries, bursts, and mixing unlike message streams.
5. Message construction — headers, links, HTML, attachments, copy, and unsubscribe behavior.
6. Provider-specific evidence — postmaster dashboards, feedback loops, bounce text, and recipient support reports.

This order is important. Changing your subject line will not repair a missing DKIM signature. Adding a DMARC record will not fix a compromised API key sending thousands of unwanted messages. Each layer should be verified independently before moving to the next.

Verify SPF without creating a broken record

SPF, or Sender Policy Framework, authorizes systems that may send mail using an envelope-sender domain. It is published as a DNS TXT record. SPF can help a receiver confirm that the server sending a message is permitted to use the domain in the SMTP MAIL FROM command, but SPF alone does not prove that the visible From: address is aligned.

A simple example for a domain using one sending provider might look like this:

example.com.  TXT  "v=spf1 include:spf.email-provider.example -all"

The record begins with v=spf1. The include: mechanism delegates authorization to the provider’s published SPF policy. The -all qualifier says that servers not matched by an earlier mechanism should fail SPF. Your provider’s actual include domain is provider-specific; copy it from its official sending-domain documentation rather than guessing.

Common SPF failures

The most common SPF configuration mistakes are operational, not theoretical:

• Publishing multiple SPF TXT records. A domain should have one SPF policy record. Two separate records beginning with v=spf1 can cause a receiver to return an SPF PermError.
• Forgetting another legitimate sender. If your application uses an email API while finance uses a helpdesk and marketing uses another platform, all authorized sources must be accounted for in one policy.
• Using the visible From domain instead of the envelope domain. SPF checks the envelope sender or HELO identity, depending on message construction. DMARC later evaluates alignment with the visible From domain.
• Exceeding the DNS lookup limit. SPF evaluation permits a maximum of 10 DNS-query-causing mechanisms and modifiers. A long chain of include: records can cause SPF to fail with a permanent error.
• Using +all. This effectively authorizes every sender on the internet and defeats SPF’s protective purpose.
• Leaving an obsolete IP range in the record. An old server can continue sending unwanted traffic under your domain if it remains authorized.

Do not convert ~all to -all merely because a checklist says it is “stricter.” First inventory every service that sends mail with your envelope domain, verify them in production, and inspect DMARC aggregate reports. An incorrect hard-fail policy can cause legitimate mail from a forgotten system to fail.

The technical roles of SPF, DKIM, and DMARC are distinct: SPF authenticates an authorized sending path, DKIM protects a signed message’s identity and integrity, and DMARC evaluates aligned authentication and publishes domain-owner policy. (nist.gov)

Set up DKIM and confirm that signatures survive delivery

DKIM, or DomainKeys Identified Mail, adds a cryptographic signature to outgoing mail. A receiver retrieves the public key from DNS and verifies that selected headers and body content were signed by a domain. In raw headers, a valid result is commonly visible in an Authentication-Results: field, for example:

Authentication-Results: mx.recipient.example;
       dkim=pass header.i=@example.com header.s=s1;
       spf=pass smtp.mailfrom=mail.example.com;
       dmarc=pass header.from=example.com

A DKIM public-key record typically sits below a selector label. The exact public key and selector are created by your provider or mail server, but the DNS shape resembles this:

s1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Some providers give you CNAME records instead, allowing them to host and rotate the DKIM key. For example:

s1._domainkey.example.com. CNAME s1.domainkey.provider.example.

Publish exactly the record type, host, and target your provider supplies. A TXT record cannot be substituted for a required CNAME, and a key pasted into the wrong DNS label will not validate.

How DKIM breaks in real systems

A DKIM record can exist in DNS while your mail still fails DKIM. Check these failure modes:

• The email platform is not configured to sign mail for the domain you use in From:.
• Your application changes the message after signing, such as by modifying MIME boundaries, adding a footer, or rewriting links downstream.
• A forwarder or security gateway alters a signed portion of the body or headers.
• The selector in DKIM-Signature: s= does not match the DNS record.
• The DNS key was truncated, split incorrectly, or has stale quotation marks from a control-panel copy-and-paste.
• Your provider rotated a selector but your DNS change never propagated or was added to the wrong zone.
• You sign with a domain unrelated to the visible From address, preventing DMARC alignment even though DKIM itself passes.

For transactional mail, prefer DKIM alignment with the domain customers see in the From: header. If your product sends from notifications@example.com, a DKIM d=example.com or aligned subdomain is generally more useful for DMARC than an unrelated shared provider domain.

Publish DMARC gradually, then enforce it deliberately

DMARC connects the visible From: domain to SPF and DKIM. To pass DMARC, the message must have at least one aligned authentication result: aligned SPF or aligned DKIM. That is why an SPF pass by a provider-owned bounce domain can still coexist with a DMARC failure for From: billing@example.com.

A starter DMARC record can be published as a TXT record at _dmarc:

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r; pct=100"

Here is what the key tags mean:

• v=DMARC1 identifies the record.
• p=none asks receivers to monitor rather than quarantine or reject failing mail.
• rua=mailto: specifies where aggregate XML reports should be sent.
• adkim=r and aspf=r use relaxed alignment, allowing aligned subdomains in common configurations.
• pct=100 applies the policy to all qualifying traffic.

After reviewing reports and confirming every legitimate sender authenticates and aligns, a staged enforcement policy might look like this:

_dmarc.example.com. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r; pct=25"

Later, after a sustained clean reporting period:

_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r; pct=100"

Do not jump directly to p=reject just because it is the strongest anti-spoofing posture. It can block legitimate mail from forgotten systems, including support desks, billing products, CRM automations, calendar tools, and legacy application servers. Start with reporting, identify all authorized sources, fix alignment, and escalate policy in controlled stages.

Google’s sender requirements call for SPF or DKIM for all senders and SPF, DKIM, and DMARC for domains that send roughly 5,000 or more messages per day to personal Gmail accounts. Google also requires appropriate authentication alignment and other delivery practices for bulk traffic. (support.google.com)

Inspect the raw message headers, not just your provider dashboard

Dashboards are useful for event counts, but raw headers show what the receiving mailbox actually evaluated. Send a production-equivalent test to a mailbox you control at Gmail, Outlook.com, and another provider relevant to your recipients. Open the original source and inspect these fields:

From: Example App <notifications@example.com>
Reply-To: support@example.com
Return-Path: <bounce@mail.example.com>
Message-ID: <unique-id@mail.example.com>
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1; ...
Authentication-Results: ...
Received: from ...

Look for spf=pass, dkim=pass, and dmarc=pass. Then compare domains, not merely pass/fail labels. If header.from=example.com but smtp.mailfrom=provider-mail.example, SPF may pass without aligning. If dkim=pass header.i=@provider-mail.example, DKIM may also pass without aligning. The most useful result is an aligned DKIM signature from example.com or an aligned envelope sender such as mail.example.com.

Check infrastructure identities when you run your own SMTP server

If you send through a managed transactional email service, it normally operates the outbound IP, SMTP hostname, and reverse DNS. If you run your own mail transfer agent or dedicated IP infrastructure, inspect these additional basics:

• The sending IP address has a PTR record resolving to a real hostname.
• The hostname resolves forward via A or AAAA back to the sending IP where practical.
• The SMTP server’s EHLO or HELO name is a valid hostname, not localhost or a private IP.
• TLS is offered and certificate validation is sound.
• The server is not an open relay.
• The IP is not listed on relevant DNS blocklists.

Gmail’s guidelines explicitly call out valid forward and reverse DNS for sending domains or IPs, as well as TLS for transmission. MXToolbox offers DNS, blacklist, reverse-DNS, and SMTP-oriented diagnostics that can help identify visible infrastructure errors. (support.google.com)

Separate transactional, marketing, and risky traffic

A single sender reputation is often affected by the least welcome mail sent through it. Password resets, login codes, receipts, security alerts, release notifications, newsletters, sales outreach, and bulk import confirmations do not have the same recipient expectations or engagement patterns. Combining them under one stream makes troubleshooting harder and can allow poor bulk-mail practices to harm essential transactional delivery.

At a minimum, separate message classes by subdomain and operational stream:

Transactional From: notifications@example.com
Transactional envelope sender: bounce@mail.example.com
Marketing From: news@example.com
Marketing envelope sender: bounce@news.example.com

You do not need a different root domain for every stream. Often, subdomains provide enough separation while retaining a recognizable brand. The goal is to make authentication, bounce handling, recipient expectations, and analytics clear.

For an application that supports both REST API sending and SMTP relay sending, keep the same policy controls regardless of transport. A message sent with an HTTP API can create the same reputation damage as one submitted over SMTP if it uses the same domain, sender identity, recipient source, and content pattern. Centralize sender authorization, restrict API keys or SMTP credentials, and log which service generated each message.

Watch for abuse and credential compromise

A sudden spam notification can be a security incident. Check whether a compromised API token, SMTP password, web form, or application endpoint began sending unexpected mail. Warning signs include:

• A sharp volume increase outside normal business hours.
• New recipient countries or domains that do not match your product footprint.
• Unusual templates, display names, or reply-to addresses.
• High 550 5.1.1 invalid-recipient bounces alongside spam complaints.
• Many messages with nearly identical content sent to unrelated addresses.
• A new sender address or subdomain that nobody on the team recognizes.

Immediately disable or rotate the suspected credential, pause the affected sender, and stop retrying rejected messages. Then identify the event source in application logs. Do not “warm up” a compromised stream by continuing to send; the first job is containment.

Reduce complaints by fixing recipient quality and expectations

Authentication lets recipients verify who you are. It does not make unwanted mail wanted. Mailbox providers learn from complaints, deletes without reading, low engagement, invalid-address bounces, and other signals. The most sustainable way to fix spam notifications is to send only mail recipients reasonably expect.

For transactional email

Transactional mail should be directly tied to a user action, account state, or necessary service event. A user who requests a password reset expects one reset email. A customer who completes an order expects a receipt. A user who never created an account does not expect a “welcome” sequence.

Avoid turning a transactional template into a disguised campaign. A receipt can include a modest relevant account link, but adding multiple promotional blocks, aggressive cross-sells, or unrelated product announcements creates ambiguity and complaints. If a message’s primary purpose is promotion, classify it as marketing and give recipients the corresponding controls.

For marketing and product announcements

Use confirmed, documented permission wherever possible. Suppress recipients who unsubscribe, complain, hard bounce, or remain inactive for your business’s defined re-engagement window. Never re-add an unsubscribed address after an import unless the person explicitly opts in again through a valid process.

Before a large campaign, validate old or imported addresses. Syntax validation alone is not enough: a syntactically valid mailbox can be abandoned, role-based, disposable, or risky. You can use a free address verification tool as one screening step, but treat verification as hygiene rather than consent. A deliverable address is not necessarily an address you are permitted—or wise—to email.

Control volume, retries, and sender reputation recovery

Mail systems expect legitimate senders to behave predictably. A new sending domain that sends 50 messages one day and 500,000 the next looks materially different from an established stream with steady, engaged traffic. The risk is especially high when addresses are old, imported, or unverified.

Use deliberate rate control

When launching a new domain, IP, message type, or major product notification, start with your most active and clearly opted-in recipients. Increase volume in measured steps while watching deferrals, complaint metrics, inbox placement, and domain-specific bounces. There is no universal safe daily number because recipient quality, domain history, message purpose, and mailbox-provider mix differ widely.

If you receive 421 or 451 responses, do not immediately retry thousands of messages at full speed. Use exponential backoff with jitter, cap concurrent retries, and stop retries after a reasonable expiry for the message type. A password-reset link that arrives six hours later is no longer useful; a receipt may deserve a longer retry window. Your queue policy should understand message urgency.

Recover after a spam event

Reputation recovery is usually slower than reputation damage. A practical recovery plan is:

1. Stop the problematic campaign, sender, credential, or integration.
2. Identify the affected domain, IP, template, recipient source, and mailbox providers.
3. Fix authentication and alignment failures before restarting.
4. Remove hard bounces, complaint recipients, unsubscribes, and suspect imported segments.
5. Resume only essential, expected transactional mail first.
6. Gradually restore other traffic to recently engaged recipients.
7. Monitor recipient-provider responses daily and document the trend.

Do not create a fresh domain solely to evade a damaged reputation while keeping the same poor list or sending behavior. That can repeat the problem and makes brand trust harder to build.

Review content, links, and MIME structure after authentication passes

Content rarely explains every spam notification, but it can be decisive once identity and list quality are sound. Focus on signals that make a message hard to trust or technically malformed—not mythical “spam words.”

Build messages that look like legitimate application mail

Use a recognizable display name and a stable From address. Include a plain-text alternative for HTML email. Use valid HTML with descriptive links, a real physical contact address where required for your mail type and jurisdiction, and an obvious support path. Make the Reply-To address functional if you set one.

Avoid these high-risk patterns:

• A visible From domain that differs from every link and image domain without a clear reason.
• URL shorteners or redirect chains that conceal the final destination.
• Links to domains with no established relationship to your brand.
• HTML-only messages with large images and almost no meaningful text.
• A large attachment sent to many recipients without an expected business reason.
• Misleading subject lines such as fake “Re:” or “Fwd:” prefixes.
• Excessive urgency, alarming claims, or requests for passwords and payment credentials by email.
• Hidden text, tiny text, keyword stuffing, or deceptive CSS intended to influence filters.

For commercial or subscription mail, add a clear unsubscribe mechanism. Gmail’s bulk-sender guidance includes one-click unsubscribe requirements for applicable promotional and subscription traffic; do not apply an unsubscribe footer to critical security notifications in a way that prevents needed account communication, but do separate promotional mail from operational mail so recipients can control it appropriately. (support.google.com)

Test the exact production message

A local preview does not show the delivered message after provider signing, tracking, MIME encoding, and recipient filtering. Send the exact production payload to a controlled test address. Services such as mail-tester.com can assess spam-related characteristics, malformed content, and mail-server configuration; use the result as a diagnostic checklist, not as a guarantee of inbox placement at every provider. (mail-tester.com)

Test variations one at a time. If you simultaneously change the subject, template, sending domain, IP pool, and recipient segment, you will not know what improved or worsened delivery.

Use DNS and command-line checks to validate the published state

DNS control panels can display a record you entered even when the public authoritative DNS does not return the expected value. Query the records independently after changes. On macOS, Linux, or Windows with suitable tools installed, examples include:

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT s1._domainkey.example.com
dig +short -x 203.0.113.25

On Windows PowerShell, you can use:

Resolve-DnsName -Type TXT example.com
Resolve-DnsName -Type TXT _dmarc.example.com
Resolve-DnsName -Type TXT s1._domainkey.example.com

Check the result against the provider’s required values character by character. DNS tools may display quoted TXT strings in segments; that does not necessarily mean the record is wrong. What matters is the assembled TXT value returned by DNS. Be especially cautious with DKIM public keys, where a single missing character invalidates verification.

DNS propagation is also not a reason to assume a change succeeded. Confirm the authoritative zone, wait for the configured TTL where applicable, query again, and send a fresh test message. If a sending platform verifies a domain before activating it, complete its verification process only after public DNS resolves correctly. For implementation-specific API and SMTP setup details, consult the provider’s email API reference and setup guides.

Build an ongoing spam-notification monitoring routine

Spam notifications are easiest to fix before they become an outage. Make deliverability observability part of normal email operations rather than something used only after customers complain.

Track at least these metrics by sender domain, message type, recipient provider, and application source:

• Accepted, delivered, deferred, bounced, and rejected counts.
• SMTP response code and enhanced status-code distribution.
• Hard-bounce and soft-bounce rate.
• Spam complaints and feedback-loop events where available.
• DKIM, SPF, and DMARC pass rates from header samples and aggregate reports.
• Send volume over time, including new-recipient versus existing-recipient traffic.
• Unsubscribe rate for promotional streams.
• Time-to-delivery and retry-attempt counts for important transactional messages.

Set alerts on meaningful changes, not only absolute thresholds. A jump from 0.02% to 0.3% hard bounces might matter for a mature transactional stream even if the raw count is small. Likewise, a sudden increase in 421 4.7.x deferrals at one mailbox provider can be an early warning before permanent blocks appear.

Maintain a sender inventory as well: every product, environment, domain, subdomain, provider account, API key, SMTP credential, and person responsible for it. This avoids the common situation where a DMARC report exposes a legitimate but undocumented sender and nobody knows whether to authorize, migrate, or retire it.

A practical incident checklist

When a customer, provider, or monitoring system reports spam, run this checklist in order:

1. Classify the symptom: spam-folder placement, temporary deferral, permanent rejection, or provider warning.
2. Capture raw evidence: full SMTP response, headers, event payload, recipient domain, and message ID.
3. Pause suspicious traffic: especially unexplained volume spikes, new integrations, or potential credential abuse.
4. Confirm SPF: one valid record, correct authorized senders, no lookup-limit problem.
5. Confirm DKIM: valid DNS selector, active signature, and passing verification on a delivered sample.
6. Confirm DMARC: published record, aligned SPF or DKIM, and reports going to a monitored mailbox or processor.
7. Check headers: verify actual receiver results rather than dashboard assumptions.
8. Check infrastructure: PTR/rDNS, HELO identity, TLS, IP reputation, and blacklist indications if you operate the sending host.
9. Review recipients: remove bounces and complaints; audit imports, consent, and transactional triggers.
10. Review the payload: sender identity, links, HTML/text structure, attachments, and unsubscribe implementation for promotional mail.
11. Control retries and rate: back off on 4xx responses and restart gradually after remediation.
12. Retest and monitor: use fresh messages and track results separately by mailbox provider.

The goal is not to “beat” spam filters. It is to produce mail that recipient systems can authenticate, recipients can recognize, and your own logs can explain.

FAQ

Why do my emails say delivered but customers find them in Spam?

“Delivered” usually means the recipient mail server accepted the message over SMTP. Inbox versus spam-folder placement happens after acceptance and can vary by recipient, provider, reputation, authentication alignment, and engagement history. Inspect raw headers and test with representative recipient providers.

Does SPF passing mean my email cannot be marked as spam?

No. SPF is one authentication signal and only evaluates the envelope-sender or HELO identity. A message can pass SPF but fail DMARC alignment, have a broken DKIM signature, come from a poor-reputation stream, or be unwanted by recipients.

What is the fastest DNS configuration to add first?

Start by correctly configuring the sending provider’s SPF and DKIM records, then publish DMARC in monitoring mode with p=none. Verify the actual mail headers, collect reports, and only move toward quarantine or reject after you know every legitimate sender is aligned.

Should I retry a 550 5.7.1 spam rejection?

Usually no. A 5xx response is generally permanent for that message and retrying unchanged traffic can worsen the problem. Preserve the entire response text, correct the underlying issue, and retry only if the recipient system or your provider specifically indicates that a later retry is appropriate.

Can a transactional email provider fix a bad recipient list?

No. A provider can supply reliable SMTP or API transport, signing support, event logs, and infrastructure, but it cannot turn unsolicited, stale, or complaint-prone traffic into wanted mail. Authentication, recipient permission, list hygiene, and stable sending behavior remain the sender’s responsibility.