DEV Community: Petr Michal

The SPF redirect trap: why -all can make redirect= useless

Petr Michal — Tue, 25 Aug 2026 12:03:53 +0000

The SPF `redirect` trap: why `-all` can make `redirect=` useless

SPF records often look simple until you start combining mechanisms and modifiers.

One particularly easy mistake is to write a record like this:

v=spf1 include:_spf.google.com -all redirect=_spf.example.com

At first glance, it seems reasonable:

authorize Google,
reject everything else,
and use another SPF policy through redirect=.

But the redirect= part will never be used.

The reason is an important detail of how SPF evaluation works.

`redirect=` is not a fallback after `-all`

An SPF record is evaluated mechanism by mechanism.

For example:

v=spf1 ip4:192.0.2.10 include:_spf.google.com -all

The receiver checks the mechanisms until one matches.

The all mechanism is special because it always matches.

That means:

-all

effectively says:

If nothing before this matched, return SPF Fail.

Now consider this record again:

v=spf1 include:_spf.google.com -all redirect=_spf.example.com

Once SPF reaches -all, it already has a result.

There is no reason to evaluate redirect=.

The redirect modifier is only used when none of the mechanisms in the record produce a match.

Because all always matches, a record containing all prevents redirect= from being used.

What `redirect=` is actually for

The redirect modifier is useful when several domains should share one central SPF policy.

Imagine these domains:

example.com
example.net
example.org

Instead of maintaining the same SPF configuration independently on every domain, they can redirect to a central policy.

For example:

example.com TXT "v=spf1 redirect=_spf.example.com"
example.net TXT "v=spf1 redirect=_spf.example.com"
example.org TXT "v=spf1 redirect=_spf.example.com"

And the central record might contain:

_spf.example.com TXT "v=spf1 ip4:192.0.2.10 include:_spf.google.com -all"

Now the sending policy can be maintained in one place.

This is very different from include:.

`redirect=` vs `include:`

These two are easy to confuse.

`include:`

Use include: when you want to authorize senders defined by another SPF record as part of your own policy.

Example:

v=spf1 include:_spf.google.com ip4:192.0.2.10 -all

This says:

Google is allowed, this IP is allowed, and everything else should fail.

Your domain still owns the final policy.

`redirect=`

Use redirect= when another domain should provide the entire remaining SPF policy.

Example:

v=spf1 redirect=_spf.example.com

A useful mental shortcut is:

include:  → add another policy
redirect= → use another policy

That distinction matters when debugging SPF records.

A common broken configuration

Consider this:

v=spf1 ip4:192.0.2.10 -all redirect=_spf.provider.com

Someone may expect the following behavior:

allow 192.0.2.10,
if it does not match, check _spf.provider.com,
otherwise fail.

But SPF does not work that way.

The real evaluation is:

check ip4:192.0.2.10,
if it does not match, evaluate -all,
all matches every sender,
return SPF Fail,
redirect= is never used.

If you really want the provider to define the policy, the record should instead look like:

v=spf1 redirect=_spf.provider.com

If you want both your own IP address and the provider's authorized senders, include: is usually the appropriate mechanism:

v=spf1 ip4:192.0.2.10 include:_spf.provider.com -all

The position of `redirect=` can be misleading

Another subtle point is that redirect= is a modifier, not a mechanism.

So it should not be read as if SPF simply processes it from left to right like ip4, include, mx, or all.

This record:

v=spf1 redirect=_spf.example.com -all

does not mean:

Try redirect first, then -all.

The presence of the all mechanism still means SPF can produce a result without using the redirect.

A good mental model is:

Evaluate the SPF mechanisms first.
Only if none of them match can redirect= provide another SPF record to evaluate.

Why this matters in production

A broken SPF redirect can be surprisingly difficult to notice.

The DNS record is syntactically valid.

A DNS lookup succeeds.

The domain has an SPF record.

Yet mail from an expected sender may still fail SPF because the redirected policy was never evaluated.

This becomes especially confusing when organizations centralize SPF records across many domains.

A small mistake in the parent policy can affect multiple domains at once.

When debugging this kind of issue, check:

whether the record contains an all mechanism,
whether redirect= is actually reachable,
whether you really need redirect= or should use include:,
the SPF result returned by the redirected domain,
the total number of DNS-querying SPF terms.

A simple rule to remember

If your SPF record contains:

-all

and also:

redirect=...

you should take a closer look.

In most cases, that combination indicates that the redirect is not doing what the author intended.

Use:

redirect=

when another domain should define the SPF policy.

Use:

include:

when another SPF policy should be incorporated into your own.

And use:

-all

when you are ready to explicitly fail senders that did not match any previous mechanism.

If you are debugging a more complex configuration, I wrote a more detailed guide to the SPF redirect modifier, including redirect= vs include:, DNS lookup behavior, common errors, and practical examples.

You can also inspect an SPF record directly with the MXFend SPF checker.

How BIMI Inspection Actually Works: DNS Records, Selectors, SVG Logos and DMARC

Petr Michal — Wed, 19 Aug 2026 20:28:54 +0000

How BIMI Inspection Actually Works: DNS Records, Selectors, SVG Logos and DMARC

BIMI looks simple at first glance: publish a DNS record, point it at a logo, and wait for mailbox providers to display it.

In practice, there are several independent pieces that have to line up:

the BIMI Assertion Record must exist at the expected DNS name;
the correct selector has to be queried;
the logo location has to be reachable;
the SVG has to meet BIMI-specific constraints;
the optional evidence document has to be valid for the intended use;
DMARC must meet BIMI's enforcement prerequisite;
and even then, mailbox providers can still apply their own eligibility, reputation, and policy checks.

This article walks through the inspection process from the DNS query outward.

1. Start with the BIMI DNS name

The conventional BIMI selector is default.

For a domain such as:

example.com

the first DNS name to inspect is:

default._bimi.example.com

A BIMI implementation can use a non-default selector, but it should not blindly guess or enumerate selectors. A specific selector is normally relevant when the message or sender configuration actually requests one.

That distinction matters because "no record at default" and "BIMI is not configured anywhere for this domain" are not necessarily the same statement.

2. Inspect the published BIMI Assertion Record

A BIMI record is published as DNS TXT.

A simplified record may look like:

v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/evidence.pem;

The important parts are:

v= — BIMI version;
l= — logo location;
a= — evidence document location, when present.

An inspector should not stop at "a TXT record exists." It should also check whether the record is structurally usable and whether there are ambiguous or conflicting records.

Multiple BIMI records for the same selector are especially important to surface rather than silently merging or choosing one.

3. The selector is part of the inspection

The selector is not just a UI detail.

It changes the DNS name being queried:

<selector>._bimi.example.com

For example:

default._bimi.example.com
marketing._bimi.example.com

Those are two different DNS records.

A useful BIMI inspector should therefore show the selector it actually queried and the resulting DNS name, so the operator can verify that the inspection matches the sender's intended configuration.

4. Follow the logo location

The l= value points to the logo asset.

An inspector can check things such as:

whether the URL is present;
whether it is reachable;
whether the response is actually an SVG;
whether the SVG is structurally compatible with BIMI expectations;
whether obvious asset problems make the BIMI setup unusable.

This is where many apparently "valid" DNS configurations fail in practice.

The DNS record may parse correctly while the referenced logo is unavailable or unsuitable.

5. SVG Tiny PS is not the same as "any SVG"

A normal SVG that renders perfectly in a browser is not automatically suitable for BIMI.

BIMI expects a restricted SVG profile. That means an inspection step should treat "valid XML/SVG" and "BIMI-compatible SVG" as separate questions.

This distinction is useful when troubleshooting a setup that looks correct from DNS alone but still does not satisfy BIMI requirements.

6. Inspect the evidence document separately

The a= location is conceptually separate from the logo.

Depending on the BIMI setup, it may point to an evidence document such as a certificate-related artifact.

A robust inspector should report the evidence location independently rather than treating the logo and evidence document as one combined resource.

This also makes troubleshooting easier:

DNS record: OK
Logo: OK
Evidence location: problem

is much more actionable than a generic "BIMI failed."

7. Check the DMARC prerequisite

BIMI does not operate in isolation from email authentication.

A domain may have a syntactically correct BIMI record and a valid logo, but still not meet BIMI's DMARC enforcement prerequisite.

That is why BIMI inspection should include DMARC state rather than only checking _bimi DNS.

The useful question is not merely:

Does this domain have DMARC?

but rather:

Does the DMARC configuration meet the enforcement prerequisite expected for BIMI?

This is an important difference for domains that are still in monitoring-only mode.

8. A technically correct setup still does not guarantee logo display

This is probably the most important operational point.

Passing all structural checks does not mean Gmail, Yahoo, Apple Mail, or another provider must display the logo.

Mailbox providers can apply additional requirements and their own reputation, eligibility, certificate, or policy rules.

So the result of an inspector should be interpreted as:

The published BIMI configuration is structurally ready

not:

Your logo is guaranteed to appear

That distinction avoids false confidence and makes the tool more useful for debugging.

9. A practical inspection flow

When troubleshooting BIMI, I prefer this order:

Determine the selector.
Query <selector>._bimi.<domain>.
Confirm exactly one usable BIMI Assertion Record.
Parse the logo and evidence locations.
Check the logo resource and BIMI SVG compatibility.
Check the evidence document location when present.
Verify the DMARC enforcement prerequisite.
Only then investigate provider-specific eligibility or reputation issues.

This order separates DNS/configuration failures from provider-side display decisions.

10. Inspect a real domain

I built a free BIMI Inspector in MXFend that follows this workflow and shows the queried selector, BIMI record, logo/evidence locations, SVG compatibility, and DMARC prerequisite in one place.

MXFend BIMI Inspector:

https://mxfend.com/bimi-inspector/

There is also a simpler BIMI Checker for a faster basic check:

https://mxfend.com/bimi-checker/

The distinction is intentional:

BIMI Checker — quick configuration check;
BIMI Inspector — deeper record, selector, logo/evidence, and DMARC inspection.

Closing thought

BIMI troubleshooting becomes much easier once you stop treating it as one binary DNS check.

It is really a chain:

selector
  -> BIMI DNS record
  -> logo
  -> SVG compatibility
  -> evidence document
  -> DMARC prerequisite
  -> mailbox-provider policy

Inspecting each layer separately gives you a much clearer answer to the only question that matters during debugging:

Which exact layer is preventing this BIMI configuration from being ready?

Originally published on MXFend.

HELO vs EHLO: Why Your SMTP Greeting Can Hurt Email Delivery

Petr Michal — Fri, 07 Aug 2026 07:44:23 +0000

HELO vs EHLO: Why Your SMTP Greeting Can Hurt Email Delivery

Your SPF, DKIM, and DMARC records may all look correct while your mail server still introduces itself as:

EHLO localhost

or:

EHLO server1.internal

That greeting happens before the message body is transmitted and can become one of the first identity signals a receiving server evaluates.

What HELO and EHLO actually do

When one mail server connects to another, the receiving server first sends an SMTP banner:

220 mx.receiver.example ESMTP

The sending server then identifies itself:

EHLO mail.sender.example

HELO is the older SMTP greeting.

EHLO is the modern Extended SMTP greeting. It also allows the receiving server to advertise capabilities such as:

STARTTLS
SIZE
8BITMIME
PIPELINING
DSN

Modern mail servers normally try EHLO first and fall back to HELO only when necessary.

What a valid EHLO hostname should look like

A good EHLO identity is normally a publicly resolvable fully qualified domain name:

mail.example.com

It should not be:

localhost
server1
mail.local
127.0.0.1

A strong configuration creates a consistent identity chain:

Sending IP
    ↓ PTR
mail.example.com
    ↓ A or AAAA
Same sending IP
    ↓ EHLO
mail.example.com

This is commonly described as forward-confirmed reverse DNS.

Why PTR and EHLO should agree

Suppose the sending connection comes from:

203.0.113.20

Its PTR record returns:

mail.example.com

But the SMTP session announces:

EHLO host123.provider.example

The server may still deliver mail, but the identity is inconsistent.

Receiving systems can combine that inconsistency with other signals:

IP reputation
blocklist status
SPF, DKIM, and DMARC results
TLS configuration
complaint history
sending patterns

A HELO mismatch is rarely the only reason a message lands in spam, but it can make an already marginal sender look less trustworthy.

Common HELO and EHLO mistakes

Using `localhost`

This often happens after installing Postfix, Exim, or another MTA without setting the public hostname.

Using an internal hostname

Names such as mail.internal or server1.lan cannot be verified through public DNS.

Missing forward DNS

The PTR points to mail.example.com, but that hostname does not resolve back to the sending IP.

Using the wrong identity on a multi-IP server

A server sends from several IP addresses but announces the same hostname for all of them, even though each IP has a different PTR record.

Assuming the From domain must match

The EHLO hostname does not necessarily need to equal the visible From domain.

For example, this can be valid:

EHLO mail.example.net
From: billing@example.com

What matters most at this layer is that the server identity is valid, resolvable, and consistent with the sending infrastructure.

How to check your configuration

Start with the actual outbound IP address, not only the domain used in the From header.

Find the IP used for outbound SMTP.
Resolve its PTR record.
Resolve the returned hostname back to an IP.
Inspect the EHLO value used by the sending server.
Verify that the complete identity chain is consistent.
Check STARTTLS and the server certificate.
Then verify SPF, DKIM, and DMARC separately.

Example commands

Check reverse DNS:

dig -x 203.0.113.20 +short

Check forward DNS:

dig mail.example.com A +short

Inspect an SMTP greeting:

openssl s_client -starttls smtp -connect mail.example.com:25

The exact tests available depend on whether the remote server accepts connections from your network and whether port 25 is blocked.

HELO is not a replacement for email authentication

A correct EHLO identity does not replace:

SPF
DKIM
DMARC

These mechanisms work at different layers.

HELO/EHLO and PTR describe the connecting server.

SPF, DKIM, and DMARC authenticate domains and messages.

For reliable delivery, both layers should be configured correctly.

Read the complete guide

The original guide includes more context about HELO, EHLO, DNS identity, and common configuration mistakes:

Read the complete HELO and EHLO guide on MXFend

You can also use the MXFend SMTP TLS Checker to inspect STARTTLS and related mail-server configuration.

Disclosure: I built MXFend. The diagnostic tools are free to use and do not require an account.

Why SPF Breaks After Adding One More Email Provider

Petr Michal — Mon, 27 Jul 2026 07:43:47 +0000

Why SPF Breaks After Adding One More Email Provider

Your SPF record may look valid and still produce a PermError.

This often happens after connecting one more service:

Google Workspace
Microsoft 365
Mailchimp
Zendesk
a CRM
a support platform

Each include: can trigger additional DNS lookups. SPF allows no more than 10 DNS-triggering mechanisms during one evaluation.

A simple-looking record

v=spf1 include:_spf.google.com include:servers.mcsv.net include:mail.zendesk.com -all

The record contains only three include: mechanisms, but each included record may contain more:

include
redirect
a
mx
exists

The limit applies to the complete evaluation tree, not only to the mechanisms visible in the root record.

What happens after the limit is exceeded

The receiving mail server may return an SPF PermError.

That does not necessarily mean every message will be rejected. The final outcome depends on:

the receiving provider,
whether DKIM passes,
whether SPF or DKIM aligns with DMARC,
the receiver's local spam-filtering rules.

This is why the problem can appear inconsistent:

one provider accepts the message,
another sends it to spam,
another reports an authentication failure.

How to diagnose it

Expand every include: recursively.
Count all DNS-triggering mechanisms in the full tree.
Identify senders and providers that are no longer used.
Check whether multiple services authorize the same infrastructure.
Look for nested includes that consume more lookups than expected.
Avoid blindly flattening records without understanding how the provider updates its IP ranges.

Common mistakes

Counting only visible includes

Three visible include: mechanisms do not necessarily mean three DNS lookups.

An included record may trigger several additional lookups of its own.

Adding a second SPF record

A domain should publish a single SPF policy.

Adding another TXT record beginning with v=spf1 does not extend the existing policy. Multiple SPF records can instead cause a PermError.

Flattening and forgetting

Flattening can reduce DNS lookups by replacing includes with IP addresses, but it also creates a maintenance obligation.

If the provider changes its sending infrastructure and the flattened record is not updated, legitimate mail may stop passing SPF.

A safer way to fix it

Start by mapping the complete lookup tree.

Then:

remove obsolete providers,
remove duplicate authorization paths,
simplify unnecessary mechanisms,
confirm which systems still send mail for the domain,
flatten only where you understand the update and monitoring strategy.

The goal is not only to get below 10 lookups today. The SPF policy should remain correct when providers change their infrastructure.

Test the full lookup tree

I built a free SPF lookup visualizer for this type of diagnosis:

Open the MXFend SPF Lookup Visualizer

It expands the recursive lookup tree and helps show where the SPF lookup budget is being consumed.

You can also browse more SPF guides in the
MXFend SPF knowledge base.

Disclosure: I built MXFend. The visualizer is free to use and does not require an account.

DEV Community: Petr Michal

The SPF redirect trap: why -all can make redirect= useless

The SPF redirect trap: why -all can make redirect= useless

redirect= is not a fallback after -all

What redirect= is actually for

redirect= vs include:

include:

redirect=

A common broken configuration

The position of redirect= can be misleading

Why this matters in production

A simple rule to remember

How BIMI Inspection Actually Works: DNS Records, Selectors, SVG Logos and DMARC

How BIMI Inspection Actually Works: DNS Records, Selectors, SVG Logos and DMARC

1. Start with the BIMI DNS name

2. Inspect the published BIMI Assertion Record

3. The selector is part of the inspection

4. Follow the logo location

5. SVG Tiny PS is not the same as "any SVG"

6. Inspect the evidence document separately

7. Check the DMARC prerequisite

8. A technically correct setup still does not guarantee logo display

9. A practical inspection flow

10. Inspect a real domain

Closing thought

HELO vs EHLO: Why Your SMTP Greeting Can Hurt Email Delivery

HELO vs EHLO: Why Your SMTP Greeting Can Hurt Email Delivery

What HELO and EHLO actually do

What a valid EHLO hostname should look like

Why PTR and EHLO should agree

Common HELO and EHLO mistakes

Using localhost

Using an internal hostname

Missing forward DNS

Using the wrong identity on a multi-IP server

Assuming the From domain must match

How to check your configuration

Example commands

HELO is not a replacement for email authentication

Read the complete guide

Why SPF Breaks After Adding One More Email Provider

Why SPF Breaks After Adding One More Email Provider

A simple-looking record

What happens after the limit is exceeded

How to diagnose it

Common mistakes

Counting only visible includes

Adding a second SPF record

Flattening and forgetting

A safer way to fix it

Test the full lookup tree

The SPF `redirect` trap: why `-all` can make `redirect=` useless

`redirect=` is not a fallback after `-all`

What `redirect=` is actually for

`redirect=` vs `include:`

`include:`

`redirect=`

The position of `redirect=` can be misleading

Using `localhost`