| SYSTEM INFORMATION | |
|---|---|
| OS type and version | Debian Linux 12 |
| Usermin version | 2.400 |
| Virtualmin version | 7.40.0 |
| Theme version | 25.01 |
| Nginx version | 1.22.1 |
| Package updates | All installed packages are up to date |
"v=spf1 a mx a:domain.me.uk ip4:xxx.42.228.244 ip6:nnnn:3c03::f03c:93ff:fe19:a2ab ?all"
as produced by Virtualmin in `DNS Settings and placed in the external DNS as a TXT record that it fails SPF checks?
Switch from neutral to fail: "v=spf1 a mx a:domain.me.uk ip4:xxx.42.228.244 ip6:nnnn:3c03::f03c:93ff:fe19:a2ab -all"
The SPF record has designated the host as NOT being allowed to send but is in transition. Will be rejected.
Or less aggressive use a softfail: "v=spf1 a mx a:domain.me.uk ip4:xxx.42.228.244 ip6:nnnn:3c03::f03c:93ff:fe19:a2ab ~all"
The SPF record has designated the host as NOT being allowed to send. Will be accepted but marked.
Tx - but still fails, after replacing ?all with ~all
testing at https://www.learndmarc.com/
>> Running SPF
------------------
I couldn't find a valid SPF policy at domain.me.uk using the identity RFC5321.MailFrom. The Auth Result is none.
The entry is valid, as long as you’re not actually using domain.me.uk… 
and use -all like @Steini says. This has recently been set as the default in virtualmin (been banging on about this for years 
), any of the other options are pointless.
if you are using SPF you want to control who can send using it you need -all
"v=spf1 a mx a:domain.me.uk ip4:xxx.42.228.244 ip6:nnnn:3c03::f03c:93ff:fe19:a2ab ?all"
I think this is a still fault with virtualmin, but if the record is on the domain.me.uk DNS you don’t actually need a:domain.me.uk, you technically could also get rid of the ip4: definition, but it does not harm adding these extras just prevents uneeded lookups.
Also, if any part of your spf record does not resolve i.e. dead domain then the record will fail.
Is it reporting from the correct DNS, also I have had some name server services not needing the quotations, they add it themselves ie.
v=spf1 a mx a:domain.me.uk ip4:xxx.42.228.244 ip6:nnnn:3c03::f03c:93ff:fe19:a2ab ?all
Who are you using?
Swap ?all to -all otherwise your spf record is pointless.
That shouldn’t cause a lookup not finding a record though.
That shouldn’t cause a lookup not finding a record though.
correct
it is hard to fix an SPF record issue without the domain name to test.
the real domain is obscured (sort of) and the actual ip4 ip6 but it is a .me.uk tld.
I have changed to a -all record and tested using a different “service” https://www.mimecast.com/products/dmarc-analyzer/spf-record-check/
and the record still Fails
Annoying when this all used to work 
if you want to pm me the domain I can have a quick look.
Registrar by Porkbun (as previous registrar abandoned owner and total failed to support)
NS records point to Linode (all ns1 to ns5)
Linode give full access to DNS records (and their support also open port 25 on request)
I have several other domains through them some with working email.
it seems just this one that is causing problems SPF → DKIM → DMARC (with Gmail and now wth Hotmail) but it seems that external mail from other sources and from backups (Virtualmin to domain owner) is being delivered.
gmail, hotmail/outlook and probably yahoo all have strict rules on SPF/DKIM/DMARC.
internally routed emails are probably not tested against the SPF/DMARK/DKIM records.
“unable to find an SPF record”, means there isn’t an SPF record, or you searched with wrong/other domain
what does dig TXT your_domain output? (online tool available at : https://digwebinterface.com/ - choose type TXT)
not always, it could just be badly formed. remember they are usually TXT records and not a specific SPF record type anymore, so unless it is formed correctly it will not appear as a SPF record.
