DEV Community: InboxGreen

SPF ~all softfail: what it means and when to switch to -all

InboxGreen — Tue, 09 Jun 2026 16:15:00 +0000

When a checker flags ~all with a warning, a lot of people assume something is broken. It is not. SPF softfail is a valid and common configuration. The warning is a reminder that a stricter setting exists, not an error that needs immediate attention.

What the all mechanisms mean

~all: softfail. Emails from unlisted senders are flagged as suspicious but still delivered.
-all: hardfail. Emails from unlisted senders should be rejected.
?all: neutral. No guidance given to receivers. Avoid this.
+all: pass everything. Never use this.

When softfail is the right choice

~all is appropriate when:

You are still auditing which services send email on your behalf
You recently added a new sending platform and have not confirmed it is covered in your SPF record yet
You are in the early stages of setting up authentication

Softfail keeps mistakes recoverable. If you miss a sending service, hardfail blocks legitimate email. Softfail lets it through while still flagging that something looks off.

When to switch to -all

Switch to -all when you are confident every legitimate sending source is listed in your SPF record. Before switching:

Audit every service that sends email using your domain (transactional, marketing, support, calendar invites)
Confirm all of them are covered by an include: or ip4: mechanism in your record
Run a check at InboxGreen and confirm SPF passes cleanly

Then change ~all to -all in your existing record:

v=spf1 include:_spf.google.com include:sendgrid.net -all

No other changes needed. Save and wait a few minutes for propagation.

Does it matter if you have DMARC enforcement?

With DMARC at p=quarantine or p=reject, the practical difference between ~all and -all is small. DMARC enforcement handles failures regardless of the SPF all policy. The main reason to switch to -all is to give non-DMARC-aware providers a stronger signal and add a defense-in-depth layer.

Verify it

dig TXT yourdomain.com | grep spf

Confirm you still have exactly one SPF record and it ends with -all. Run a full check at InboxGreen to confirm SPF still passes after the change.

For the full guide with verification steps and common mistakes: SPF softfail: fix guide

Missing List-Unsubscribe header: what Gmail and Yahoo now require

InboxGreen — Sat, 06 Jun 2026 22:10:00 +0000

Since February 2024, Gmail and Yahoo require bulk senders (5,000+ emails per day) to include a List-Unsubscribe header in every marketing email. Miss it and you are in violation of their sender requirements. Even below that threshold, missing this header is one of the faster ways to accumulate spam complaints.

What the header does

List-Unsubscribe tells inbox providers where to send unsubscribe requests on behalf of the recipient. When present, Gmail shows a visible "Unsubscribe" link next to the sender name at the top of the email.

When a recipient clicks it, they unsubscribe cleanly instead of hitting "Report spam." Spam reports damage your sender reputation. Clean unsubscribes do not. This header converts would-be complainers into clean unsubscribes.

What you need to include

Two headers are required for full compliance:

List-Unsubscribe: <mailto:unsub@yourdomain.com>, <https://yourdomain.com/unsubscribe?uid=123>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

The List-Unsubscribe-Post header is what enables one-click unsubscribe, which is specifically what Gmail and Yahoo require. The mailto: is a fallback for older clients.

Your unsubscribe URL must handle a POST request and actually remove the contact from your list.

Adding it in PHP

$headers[] = 'List-Unsubscribe: <mailto:unsub@yourdomain.com>, <https://yourdomain.com/unsubscribe?uid=' . $uid . '>';
$headers[] = 'List-Unsubscribe-Post: List-Unsubscribe=One-Click';

In ESPs

Mailchimp: Added automatically when you use the standard unsubscribe footer. Do not remove it.

SendGrid: Settings > Tracking > Subscription Tracking. Enable it and SendGrid adds the header automatically. For API sends, add it manually in the headers object of your payload.

Verify it worked

Send a test to a Gmail address. If the header is present, Gmail shows "Unsubscribe" next to the sender name. You can also open Show original and search for List-Unsubscribe in the raw headers.

Run a full check at InboxGreen to verify alongside SPF, DKIM, and DMARC.

For the full guide with code examples and common mistakes: List-Unsubscribe missing: fix guide

We Checked SPF, DKIM, and DMARC on 186 Popular Domains. Only 69% Passed All Three.

InboxGreen — Sat, 06 Jun 2026 11:47:58 +0000

In June 2026, we ran automated SPF, DKIM, and DMARC checks against 186 publicly
known domains across email tools, SaaS platforms, Shopify stores, WordPress hosting
providers, and developer infrastructure companies.

The goal was simple: how well do well-known, technical companies actually handle
email authentication on their own domains?

The answer was worse than expected.

The numbers

90.3% had a passing SPF record
86% had detectable DKIM (on standard selectors)
81.7% had enforced DMARC (p=quarantine or p=reject)
69.4% passed all three checks together

Nearly 1 in 3 well-known domains had at least one gap.

What each check means

SPF tells receiving mail servers which IP addresses are allowed to send email
for your domain. A missing or misconfigured SPF record means any server can send
as you.

DKIM adds a cryptographic signature to outgoing mail. Receivers verify the
signature against a public key in your DNS. If DKIM is missing, spoofed messages
are indistinguishable from real ones.

DMARC ties SPF and DKIM together and tells receivers what to do when mail
fails both checks. p=none means do nothing. p=quarantine means send to spam.
p=reject means block it entirely.

Category breakdown

Category	Domains	All Three Pass
Developer Tools	12	92%
Email Service Providers	24	83%
SaaS Platforms	38	71%
E-commerce	16	75%
Shopify Stores	28	57%
WordPress Hosting	18	61%

Developer tool companies (Cloudflare, Vercel, Netlify, DigitalOcean, GitHub) had
the strongest authentication hygiene by a significant margin. Shopify stores and
WordPress hosts had the worst.

Some findings worth noting

Bluehost, Dreamhost, and Hostgator all had DMARC at p=none on their own
domains. These three companies actively recommend DMARC to their customers in
their own documentation.

Backlinko.com had SPF returning a fail result and DKIM not detected on any
tested selector. This is a widely-read SEO publication that covers email
deliverability topics.

Flywheel (WordPress hosting) had no DMARC record at all.

Three email marketing platforms (ConvertKit, Drip, Campaign Monitor) had
DMARC at p=none. These are companies that send email on behalf of their
customers and publish guidance on DMARC best practices.

How we ran the checks

All checks used DNS lookups against public records. No emails were sent. No
private systems were accessed.

DKIM is checked by probing a predefined list of common selectors: selector1,
selector2, default, google, mail, smtp, amazonses, sendgrid,
mailgun, postmark, sparkpost, zoho, protonmail, and others. A DKIM
fail in this report means no valid record was found on any of those selectors.
Domains using custom selectors not in our list may appear as failing even if
DKIM is actually configured.

Date of scan: June 3, 2026. DNS records change over time.

Check your own domain

The tool we used is free and takes about 10 seconds. No signup required.

Run a free check on your domain

Full report with category breakdown, domain table, and raw CSV download:

Email Authentication Report 2026

DMARC alignment failure: SPF and DKIM pass but DMARC still fails

InboxGreen — Fri, 05 Jun 2026 22:05:00 +0000

You check your email headers. SPF shows pass. DKIM shows pass. But DMARC shows fail. How is that possible?

The answer is alignment. DMARC does not just check whether SPF or DKIM passed. It checks whether they passed for the right domain, specifically the domain in your From header.

What alignment means

When you send email, multiple domain identifiers are in play:

The visible From address (what your recipient sees)
The Return-Path or envelope sender (used by SPF)
The d= domain in the DKIM-Signature header (used by DKIM)

DMARC requires at least one of these to match your From domain. If SPF passes for mail.sendingservice.com but your From is you@yourdomain.com, that is a misalignment and DMARC fails even though SPF technically passed.

Why this happens most often

When you send through an ESP (Mailchimp, SendGrid, HubSpot) without setting up custom domain authentication, the ESP sends with its own domain in the Return-Path and signs DKIM with its own selector. Authentication passes for the ESP's domain, not yours.

The fix

Enable custom domain authentication in your ESP. Every major ESP supports this.

Mailchimp:
Account > Domains > verify your sending domain > add the CNAME records they provide.

SendGrid:
Settings > Sender Authentication > Authenticate Your Domain > add the CNAME records.

Google Workspace:
Admin console > Apps > Google Workspace > Gmail > Authenticate email > enable DKIM. Google signs with your domain automatically once active.

Once complete, the ESP signs outgoing email with your domain in the d= tag. DKIM alignment passes. DMARC passes.

Verify it worked

Send a test from your ESP to a Gmail address. Open Show original and look for:

dkim=pass header.d=yourdomain.com
dmarc=pass

If header.d= still shows the ESP's domain, either the DNS records have not propagated yet or custom authentication was not fully enabled.

You can also run a full check at InboxGreen.

For the full guide with per-ESP steps and common mistakes: DMARC alignment failure: fix guide

DMARC p=none is not protecting your domain: when to upgrade

InboxGreen — Thu, 04 Jun 2026 22:25:00 +0000

p=none is the right place to start with DMARC. It is not the right place to stay.

Most teams add a DMARC record, see it show as passing, and move on. But p=none means receiving servers do nothing when authentication fails. They log it, maybe send you a report, and deliver the email anyway. Someone spoofing your domain while you are on p=none has a clear path to your recipients' inboxes.

What the policy tag controls

The p= tag tells receiving servers what to do with emails that fail DMARC evaluation:

p=none: no action, monitor and report only
p=quarantine: deliver to spam or junk folder
p=reject: refuse delivery entirely

None of these affect emails that pass DMARC. The policy only kicks in on failures.

When to upgrade

Before moving off p=none, you need confidence that SPF and DKIM are passing for all your legitimate sending streams:

You have been on p=none for at least two to four weeks and are receiving aggregate reports
The reports show no legitimate sources failing authentication
DKIM is enabled for every service that sends on your behalf

Skip this and go straight to p=reject and you risk blocking your own email.

The safe upgrade path

Do not jump straight to p=reject. Use the pct tag to roll out gradually:

v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@yourdomain.com

pct=10 applies the quarantine policy to only 10% of failing emails. Monitor your reports for a week or two. If no legitimate email is affected, increase to pct=50, then pct=100. Move to p=reject when you are confident nothing legitimate is failing.

Check your current setup

dig TXT _dmarc.yourdomain.com

Or run a full scan at InboxGreen, which shows your current policy, pct value, and alignment settings in one view.

For the full guide with rollout steps and common mistakes: DMARC p=none upgrade guide

SPF PermError from too many DNS lookups: what the 10-lookup limit means

InboxGreen — Wed, 03 Jun 2026 22:20:00 +0000

SPF has a hard limit of 10 DNS-querying mechanisms per record. Hit that limit and you get a PermError, the same hard failure as having two SPF records. Your record can look perfectly normal from the outside while silently failing for anyone who queries it.

What counts as a lookup

Not every mechanism in an SPF record triggers a DNS lookup.

These count toward the limit:

include:
a
mx
ptr
exists
redirect=

These do not count:

ip4:
ip6:
all

The catch is that include: mechanisms are recursive. If your record has include:sendgrid.net and SendGrid's SPF record itself contains three more include: entries, those all count toward your limit. You can hit 10 with just four or five top-level includes on a typical SaaS stack.

How to count your current lookups

dig TXT yourdomain.com | grep spf

Then trace each include: manually, or run a check at InboxGreen which counts the full resolved lookup depth automatically.

The fix: replace includes with IP addresses

ip4: and ip6: mechanisms do not count as lookups. The goal is to replace include: entries with the actual IP ranges they resolve to.

Before:

v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org include:servers.mcsv.net ~all

After:

v=spf1 include:_spf.google.com ip4:198.37.144.0/20 ip4:198.21.0.0/21 ip4:209.61.151.0/24 ~all

Keep include: only for services like Google Workspace that rotate IPs and maintain their own SPF record. Flatten everything else to direct IP ranges.

One downside of flattening: provider IP ranges change over time. Check once a quarter and update, or use a service like AutoSPF that handles updates automatically.

Verify the fix

dig TXT yourdomain.com | grep spf

Then run a full scan at InboxGreen to confirm the lookup count is now under 10 and the PermError is gone.

For the full guide with verification steps and common mistakes: SPF too many DNS lookups: fix guide

Two SPF records on one domain causes a PermError: how to merge them

InboxGreen — Tue, 02 Jun 2026 22:15:00 +0000

This is one of the most common email authentication mistakes, and it almost always happens when a developer follows a setup guide without checking whether an SPF record already exists.

You add Mailchimp, follow their DNS setup instructions, and add the SPF record they specify. Six months later you set up SendGrid, follow their guide, and add another SPF record. Now you have two TXT records starting with v=spf1 at your domain root and SPF is completely broken.

Why two records break everything

RFC 7208 (the SPF specification) is explicit: a domain must not publish more than one SPF record. When a receiving server queries your domain and gets two records back, it returns a PermError.

PermError is not a soft failure. It means SPF evaluation cannot be completed and the result is treated as a hard failure by most providers. Both records could contain perfectly valid entries and it would not matter. Two records equals PermError equals broken SPF.

How to check if you have this problem

dig TXT yourdomain.com | grep spf

If you see two lines starting with v=spf1, you have a problem. You can also run a check at InboxGreen which flags this specifically in its results.

The fix: merge into one record

Take every include:, ip4:, and ip6: mechanism from both records and combine them into a single record.

Before:

v=spf1 include:_spf.google.com ~all
v=spf1 include:sendgrid.net ~all

After:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Edit the first record with the merged value. Delete the second record entirely. Order does not matter.

Verify the fix

dig TXT yourdomain.com | grep spf

You should see exactly one result. Run a full check at InboxGreen to confirm the PermError is gone.

For the full guide with steps for Cloudflare, Namecheap, and GoDaddy: Multiple SPF records: fix guide

DKIM selector not found: how to enable DKIM signing for your domain

InboxGreen — Mon, 01 Jun 2026 22:10:00 +0000

DKIM selector not found means a checker looked at the common selector locations for your domain and found no public key. This is one of the more confusing email authentication problems because the fix lives in two separate places: your email provider's admin panel and your DNS.

How DKIM works

Your mail server signs each outgoing email with a private key. The matching public key is published in DNS at a record like:

google._domainkey.yourdomain.com

When a receiving server gets your email, it looks up that record and uses the public key to verify the signature. If the record does not exist, DKIM returns none and verification cannot happen.

Why both steps are required

This is where most people get stuck. You need to:

Enable DKIM signing in your email provider's admin panel so outgoing mail gets signed
Add the TXT or CNAME record to your DNS so receiving servers can verify the signature

Missing either step means DKIM will not pass. Adding the DNS record without enabling signing in the provider does nothing. Enabling signing without the DNS record means every verification attempt fails.

Provider-specific steps

Google Workspace:
Admin console > Apps > Google Workspace > Gmail > Authenticate email > Generate new record. Copy the TXT record name and value, add to DNS, then click Start authentication.

Microsoft 365:
Admin Center > Security > DKIM > select your domain > Enable. Microsoft gives you two CNAME records to add to DNS.

SendGrid:
Settings > Sender Authentication > Authenticate Your Domain. Two CNAME records, add both to DNS, then click Verify.

After adding the records

DNS propagation usually takes 5 to 30 minutes. Google Workspace can take up to 48 hours to confirm the key is active on their end. Do not assume it is broken after 10 minutes.

To verify, send a test email to a Gmail address and open Show original. Look for dkim=pass in the Authentication-Results header.

You can also run a full scan at InboxGreen, which checks all common selectors automatically.

For the full step-by-step guide per provider including common mistakes and FAQ: DKIM selector not found: fix guide

SPF record not found: why this quietly breaks email delivery

InboxGreen — Sun, 31 May 2026 22:05:00 +0000

SPF not found does not immediately bounce your email. It returns a result of none, which most providers treat as a weak negative signal rather than a hard failure.

The problem is compounding. Pair a missing SPF with a missing DKIM or a strict receiving policy and your mail starts disappearing into spam with no bounce notification and no way to know it happened.

What SPF does

SPF (Sender Policy Framework) is a TXT record at your domain root that lists which mail servers and services are authorized to send email from your domain.

When a receiving server gets your email, it checks this record against the IP that sent the message. No record means no list. The check returns none and the provider has nothing to verify against.

Adding your first SPF record

The record goes at the root of your domain using @ as the host:

Type:  TXT
Name:  @
Value: v=spf1 include:YOUR-PROVIDER ~all

Common provider values:

Google Workspace: include:_spf.google.com
Microsoft 365: include:spf.protection.outlook.com
SendGrid: include:sendgrid.net
Mailgun: include:mailgun.org

If you send through multiple services, combine them into one record:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

One rule you must not break

Only one TXT record starting with v=spf1 is allowed per domain. If you add a second one, SPF returns a PermError and fails completely regardless of what either record says. If you already have an SPF record, edit the existing one instead of creating a new one.

Start with ~all

The ~all at the end is a softfail. It flags but still delivers mail from unlisted senders. Use this while you are confirming all your sending services are covered. Switch to -all once nothing legitimate is missing from the record.

Verify it worked

dig TXT yourdomain.com | grep spf

You should see exactly one line starting with v=spf1. You can also run a full check at InboxGreen to see SPF, DKIM, and DMARC together in one scan.

For the full guide with provider-specific steps and common mistakes: SPF record not found: fix guide

Your domain has no DMARC record: what that means for your email

InboxGreen — Sun, 31 May 2026 10:32:40 +0000

If you run dig TXT _dmarc.yourdomain.com and get nothing back, your domain has no DMARC record. That single missing DNS entry has real consequences for inbox placement and domain security.

What DMARC actually does

DMARC (Domain-based Message Authentication, Reporting and Conformance) is a DNS policy that tells receiving mail servers what to do when an email claiming to be from your domain fails SPF or DKIM checks.

Without it, providers like Gmail and Outlook make their own call. That call often involves the spam folder.

Beyond delivery, DMARC is the only mechanism you have to prevent domain spoofing. Without a record, anyone can send email that appears to come from your domain and receiving servers have no policy to block it.

The Gmail and Yahoo requirement

Since February 2024, Gmail and Yahoo require a DMARC record for senders sending more than 5,000 emails per day. Below that threshold it is still best practice.

Missing DMARC is one of the first things bulk email infrastructure checks when deciding whether to trust a sender.

The minimum record to add

You do not need a strict policy to start. This is enough to pass the check and begin receiving reports:

Type:  TXT
Name:  _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Replace the rua address with a real mailbox you can read. p=none means no action is taken on failures, but you start receiving aggregate reports showing exactly what is authenticating and what is not.

Once SPF and DKIM are passing consistently, upgrade to p=quarantine or p=reject.

Where to add it

Cloudflare: DNS > Records > Add record > TXT, name _dmarc
Namecheap: Advanced DNS > Add New Record > TXT, host _dmarc
GoDaddy: DNS > Manage Zones > Add Record > TXT, name _dmarc

Most panels prepend your domain automatically. Use just _dmarc, not _dmarc.yourdomain.com.

Verify it worked

After saving, wait 5 to 30 minutes, then run:

dig TXT _dmarc.yourdomain.com

You should see your record in the answer section. You can also run a free scan at InboxGreen, which checks DMARC alongside SPF, DKIM, and List-Unsubscribe in one go.

For the full step-by-step guide including common mistakes and FAQ: DMARC record not found: fix guide

SPF record syntax explained: a practical guide for developers

InboxGreen — Sat, 23 May 2026 05:22:40 +0000

SPF (Sender Policy Framework) is a DNS record that tells receiving mail servers which servers are allowed to send email on behalf of your domain. If a server not on that list sends email claiming to be from your domain, the receiving server can reject or flag it.

Understanding the syntax makes it easier to set it up correctly and avoid common mistakes like accidentally hitting the 10-lookup limit.

The basic structure

An SPF record is a TXT record on your domain's DNS. It always starts with:

v=spf1

After that, you list your authorized senders as mechanisms, then end with an all directive.

A typical SPF record looks like this:

v=spf1 include:_spf.google.com include:spf.sendinblue.com ip4:203.0.113.50 ~all

Mechanisms

ip4: and ip6:

Authorizes a specific IP address or CIDR range.

ip4:203.0.113.50
ip4:203.0.113.0/24
ip6:2001:db8::1

Use this when you know the exact IP of a mail server you control.

include:

Delegates to another domain's SPF record. Each include: causes one DNS lookup.

include:_spf.google.com
include:sendgrid.net
include:spf.mailchimp.com

Most third-party email services give you an include: value to add. Each one authorizes all IPs in that service's SPF record.

a:

Authorizes the A record of a domain. If the domain's A record matches the IP the email came from, it passes.

mx:

Authorizes the MX records of a domain. Less common, typically used when your mail server and MX records are the same host.

ptr:

Avoid this one. It is slow, unreliable, and deprecated in practice.

The `all` directive

The all at the end controls what happens to mail from servers not on your list:

~all (softfail) — fail but usually deliver anyway, marking as suspicious
-all (hardfail) — reject the email
+all (pass all) — authorizes everything, which defeats the purpose of SPF entirely
?all (neutral) — no policy, same as having no SPF

For most senders, ~all is the safe starting point. Once you are confident your record is complete, switch to -all for stronger protection.

The 10-lookup limit

SPF has a hard limit of 10 DNS lookups per evaluation. Each include:, a:, mx:, and ptr: costs one lookup. Exceed 10 and the SPF check returns permerror, which effectively means the record fails.

This is a common problem when a domain uses multiple services: Google Workspace plus Mailchimp plus SendGrid plus a CRM can easily push you over the limit.

To fix it:

Audit your record and count your lookups
Remove services you are no longer using
Flatten the record by replacing include: values with the raw IPs they resolve to (but you will need to update this when the provider changes their IPs)
Use an SPF flattening service if you have many senders and cannot reduce them

InboxGreen's SPF lookup tool shows your current record and flags lookup count issues.

Common mistakes

Multiple SPF records: You can only have one TXT SPF record per domain. A second record breaks SPF validation entirely. Merge them into one.

Wrong domain: SPF needs to match the domain in the From: header for DMARC alignment. If you send from noreply@mail.yourdomain.com, the SPF record needs to be on mail.yourdomain.com.

Forgetting subdomains: SPF on yourdomain.com does not cover mail.yourdomain.com or info.yourdomain.com. Each sending subdomain needs its own record.

Missing all: Every SPF record must end with some form of all. Without it, the result is undefined.

Checking your record

InboxGreen's free checker pulls your SPF record, parses the mechanisms, and runs an authentication check against your domain. No login required.

How to check if your domain is on an email blacklist (and what to do if it is)

InboxGreen — Sat, 23 May 2026 05:18:17 +0000

If your emails are suddenly going to spam or not arriving at all, a blacklist is one of the first things to rule out. Blacklists are databases of IP addresses and domains that have been flagged for sending spam. Major email providers check these lists before deciding where to deliver your mail.

Here is how to check if you are listed and what to do about it.

What gets blacklisted

Both your sending IP address and your domain can be blacklisted independently. An IP blacklisting affects every domain that sends through that IP. A domain blacklisting follows your domain regardless of what IP you send from.

Common reasons for being blacklisted:

Sending to addresses that have not opted in
High spam complaint rates (anything above 0.1% with Gmail will hurt you)
Sending to spam trap addresses
A sudden spike in sending volume from a new domain
Your shared hosting IP was blacklisted by a different tenant (common on shared servers)

How to check

The fastest way is to use a blacklist lookup tool. InboxGreen has a free blacklist checker that checks your domain against the major lists used by Gmail, Outlook, and other providers.

You can also check manually:

Spamhaus (spamhaus.org/lookup) is the most important one. Gmail and Microsoft weight Spamhaus heavily. If you are listed here, expect significant deliverability damage.

Barracuda (barracudacentral.org/lookups) matters mainly for corporate email delivered through Barracuda gateways, which is common in enterprise environments.

MXToolbox (mxtoolbox.com/blacklists) checks against around 100 blacklists at once. Free, no account needed, good for a broad sweep.

If you are on shared hosting (Namecheap, Bluehost, SiteGround), always check the IP address of your mail server too, not just your domain name.

How to get delisted

Each blacklist has its own removal process.

Spamhaus: Go to spamhaus.org/lookup, enter your IP or domain, and follow the removal link. For legitimate senders who ended up listed by mistake, removal is usually granted within 24-48 hours if you can explain what happened.

Barracuda: Fill out the removal request at barracudacentral.org/lookups. Approved within a few hours for clean IPs.

SORBS: Slower process, often requires waiting out the listing period and demonstrating clean sending behavior over time.

Before requesting removal from any list, fix the underlying problem first. If you request removal without stopping whatever caused the listing, you will be relisted quickly and future removal requests may be ignored or delayed.

Staying off blacklists

The best approach is prevention:

Keep spam complaint rates below 0.08% (Google's threshold before they start filtering)
Never send to purchased or scraped lists
Set up SPF, DKIM, and DMARC — authenticated domains are less likely to be listed
Warm up new domains gradually, starting at 20-50 emails per day and scaling over 4-6 weeks
Remove unengaged contacts regularly before complaint rates climb

Checking your deliverability setup before it becomes a problem is much easier than recovering from a blacklisting. InboxGreen's full domain check covers SPF, DKIM, DMARC, and blacklist status in one scan, no login required.

DEV Community: InboxGreen

SPF ~all softfail: what it means and when to switch to -all

What the all mechanisms mean

When softfail is the right choice

When to switch to -all

Does it matter if you have DMARC enforcement?

Verify it

Missing List-Unsubscribe header: what Gmail and Yahoo now require

What the header does

What you need to include

Adding it in PHP

In ESPs

Verify it worked

We Checked SPF, DKIM, and DMARC on 186 Popular Domains. Only 69% Passed All Three.

The numbers

What each check means

Category breakdown

Some findings worth noting

How we ran the checks

Check your own domain

DMARC alignment failure: SPF and DKIM pass but DMARC still fails

What alignment means

Why this happens most often

The fix

Verify it worked

DMARC p=none is not protecting your domain: when to upgrade

What the policy tag controls

When to upgrade

The safe upgrade path

Check your current setup

SPF PermError from too many DNS lookups: what the 10-lookup limit means

What counts as a lookup

How to count your current lookups

The fix: replace includes with IP addresses

Verify the fix

Two SPF records on one domain causes a PermError: how to merge them

Why two records break everything

How to check if you have this problem

The fix: merge into one record

Verify the fix

DKIM selector not found: how to enable DKIM signing for your domain

How DKIM works

Why both steps are required

Provider-specific steps

After adding the records

SPF record not found: why this quietly breaks email delivery

What SPF does

Adding your first SPF record

One rule you must not break

Start with ~all

Verify it worked

Your domain has no DMARC record: what that means for your email

What DMARC actually does

The Gmail and Yahoo requirement

The minimum record to add

Where to add it

Verify it worked

SPF record syntax explained: a practical guide for developers

The basic structure

Mechanisms

The all directive

The 10-lookup limit

Common mistakes

Checking your record

How to check if your domain is on an email blacklist (and what to do if it is)

What gets blacklisted

How to check

How to get delisted

Staying off blacklists

The `all` directive