Forem: InboxGreen

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.

DMARC p=none vs p=quarantine vs p=reject: what to use and when

InboxGreen — Sat, 23 May 2026 04:42:27 +0000

If you have set up DMARC on your domain, you have probably seen the p= tag and wondered what each value actually does. The difference matters a lot. The wrong policy can mean your legitimate emails get rejected, or that spoofed emails from your domain land in inboxes without any consequence.

Here is what each policy does and how to decide which one to use.

What DMARC does

DMARC tells receiving mail servers what to do when an email claiming to be from your domain fails authentication. An email fails DMARC when it fails both SPF and DKIM alignment checks.

The p= tag sets the policy for those failures.

p=none

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

This is the monitoring policy. When a message fails DMARC, nothing happens to it — it gets delivered normally. But you receive aggregate reports (via rua=) showing you who is sending email from your domain and what is passing or failing.

Use p=none when:

You are setting up DMARC for the first time
You want to understand your email traffic before enforcing anything
You have third-party senders (CRMs, ESPs, support tools) that you need to authenticate first

p=none does not protect your domain from spoofing. Anyone can spoof your domain and the email will be delivered. The only benefit is visibility.

p=quarantine

v=DMARC1; p=reject; rua=mailto:

Emails that fail DMARC are rejected outright. They do not arrive. The sending server gets a bounce.

Use p=reject when:

You have reviewed your DMARC reports and confirmed all legitimate email is passing
You want the strongest protection against domain spoofing and phishing
You understand that any misconfigured sender will start bouncing

p=reject is the goal. It is what Google, Microsoft, and most large domains use. It is what blocks phishers from impersonating your brand.

The right progression

The standard path is:

Start with p=none and add an rua= address to receive reports
Review reports over 2-4 weeks and identify all services sending as your domain
Make sure each service has SPF or DKIM configured correctly
Move to p=quarantine once you are confident in your legitimate traffic
Move to p=reject once you see no failures from legitimate senders

Skipping straight to p=reject without monitoring first is how organizations accidentally block their own transactional email.

Check your current DMARC record

You can look up your current DMARC record and see exactly what policy you are running with InboxGreen's free DMARC checker. It will also flag any syntax issues and show you whether SPF and DKIM are passing alongside it.

No login required.

Why your emails go to spam (and how to check SPF, DKIM and DMARC in 60 seconds)

InboxGreen — Fri, 22 May 2026 21:37:00 +0000

Every developer has been there. You send a transactional email, a password reset, an invoice and it lands in spam. Or worse, it disappears completely.

The reason is almost always one of three DNS records: SPF, DKIM, or DMARC. Here is what each one does and how to check them instantly.

SPF (Sender Policy Framework)

SPF tells receiving mail servers which IP addresses are allowed to send email for your domain. If your email goes out through SendGrid, Mailgun, or Google Workspace but your SPF record does not include them, the receiving server has no way to verify the email is legitimate.

A basic SPF record looks like this:

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

The ~all at the end means "soft fail" emails from unlisted sources are accepted but flagged. Use -all for a strict policy.

DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to every email you send. The receiving server looks up your public key in DNS and verifies the signature matches. If it does, the email is confirmed as untampered.

Without DKIM, Outlook in particular will silently move your emails to junk , even if SPF passes.

DMARC (Domain-based Message Authentication)

DMARC ties SPF and DKIM together and tells receiving servers what to do when emails fail both checks. It also sends you reports so you can see who is sending email from your domain.

A basic DMARC record:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Start with p=none to collect data, then move to p=quarantine and eventually p=reject once you are confident all your legitimate senders are covered.

How to check all three in 60 seconds

You can look up each record manually with dig or nslookup, but the fastest way is to use a free checker that tests all three at once and explains what each result means.

I built InboxGreen (https://inboxgreen.email) specifically for this. Paste your domain, hit check, and you get a plain-English breakdown of every pass, fail, and warning no account needed.

It also checks major blacklists, analyzes email headers, and has 28 free DNS tools including a DMARC analyzer, SPF generator, DKIM generator, and more.

The order of operations

If you are starting from scratch:

Set up SPF first, add your sending providers
Enable DKIM in your email provider dashboard, they generate the keys
Add DMARC with p=none to start collecting reports
Check your results and fix any failures
Move DMARC to p=quarantine after 2-3 weeks of clean reports

Most deliverability problems are fixed at step 1 or 2. DMARC is the layer that protects your domain long term.

One more thing

Check your domain now even if you think everything is fine. It is common to have a working SPF record that was set up years ago but no longer includes a sending service you added later. Silent failures are the worst kind.

Forem: InboxGreen

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

DMARC p=none vs p=quarantine vs p=reject: what to use and when

What DMARC does

p=none

p=quarantine

The right progression

Check your current DMARC record

Why your emails go to spam (and how to check SPF, DKIM and DMARC in 60 seconds)

SPF (Sender Policy Framework)

DKIM (DomainKeys Identified Mail)

DMARC (Domain-based Message Authentication)

How to check all three in 60 seconds

The order of operations

One more thing

The `all` directive