SPF records

[Diver300]

I've got three domains registered with easily.co.uk. One is a .me.uk domain and the other two are .co.uk.  I use the webmail at ionos.co.uk for emails for all three domains

Gmail is often rejecting emails from the .co.uk domains. The returned emails have links from Gmail (https://support.google.com/mail/answer/81126#authentication) about making sure my SPF record is up to date. I looked at the SPF records and all three domains had this:-

"v=spf1 include:spfc51.megamailservers.com ~all"

Ionos recommend this:-

"v=spf1 include:_spf-eu.ionos.com ~all"

so that is what I changed all three to.

However, half an hour later, emails are still being bounced.

Questions:-
1) Am I looking at the right things to change, or am I barking up the wrong tree completely?
2) Is the problem because I am using webmain from ionos.co.uk but the SPF record is for ionos.com
3) Will there be a problem using emails from my iPhone that sends via auth.smtp.1and1.co.uk, the older name for Ionos?
4) Am I being a bit too hasty and I need to leave it a day or so after changing the SPF record before Gmail notices?

[Kim]

The first law of DNS propagation is that it always takes far longer than you want it to when you're  a) testing something or  b) trying to resolve a fuckup.  24 hours is a typical TTL for a DNS zone record (unless someone has done Forward Planning and shortened it in advance of making changes) so it can take a day or two to update.

auth.smtp.1and1.co.uk has address 212.227.15.163
auth.smtp.1and1.co.uk has address 212.227.15.179

v=spf1 ip4:212.227.126.128/25 ip4:82.165.159.0/26 ip4:212.227.15.0/25 ip4:212.227.17.0/27 ip4:217.72.192.64/26 ?all

Looks like that's included, so the phone shouldn't be a problem.

[Afasoas]

The first law of DNS propagation is that it always takes far longer than you want it to when you're  a) testing something or  b) trying to resolve a fuckup.  24 hours is a typical TTL for a DNS zone record (unless someone has done Forward Planning and shortened it in advance of making changes) so it can take a day or two to update.

It's even worse than that with Microsoft/Outlook mail servers, as they cache SPF/DMARC records for even longer which means it can take quite some time for them to stop bouncing mail.


As you are using ~all (soft fail) instead of -all, email should be treated as spam rather than being outright rejected. You are lucky if you are getting rejections ... Google's MO is to usually, or at least used to be, to silently drop the email making it a PITA to resolve these sorts of problems.

2) Is the problem because I am using webmain from ionos.co.uk but the SPF record is for ionos.com

This is not significant. The include statement is telling the receiving email server to treat the mail servers listed in the SPF record for the given domain as authorised for your domain. That record resolves as:

Code: [Select]

_spf-eu.ionos.com. 10800 IN TXT "v=spf1 ip4:212.227.126.128/25 ip4:82.165.159.0/26 ip4:212.227.15.0/25 ip4:212.227.17.0/27 ip4:217.72.192.64/26 ?all"

So, as long as your email is coming from any of the IPs in this range, you are golden (at least as far as SPF goes):

Code: [Select]

212.227.126.129-212.227.126.254
82.165.159.1-82.165.159.62
212.227.15.1-212.227.15.126
212.227.17.1-212.227.17.30
217.72.192.65-217.72.192.126


[Diver300]

Thanks to both Kim and Afasoas for explaining things.

No luck yet, but I'll leave it a couple of days to see if it works.

[Kim]

What's your DKIM situation?  That's the other thing you generally need for Google not to get sniffy about your emails.

[Diver300]

What's your DKIM situation?  That's the other thing you generally need for Google not to get sniffy about your emails.

I don't know what DKIM is, or what my DKIM situation is.

From what I can see, Gmail is happy with either DKIM or SPF, but I'm not sure. The bounces include like this:-

550-5.7.26  Authentication results:
550-5.7.26  DKIM = did not pass
550-5.7.26  SPF [mtrak.co.uk] with ip: [212.227.17.13] = did not pass

[Diver300]

On the domains, the SPF is a text entry in the list of DNS records. There is no mention of DKIM.

[Kim]

I've recycled most of the neurons since I set it up, but it's a public-key cryptography thing, with the public key in a DNS TXT record, and the private key used by the outgoing SMTP server to sign messages.  The recipient can therefore fetch the key from DNS and verify the signature is correct for the domain the email claims to be coming from.

As such it's a lot more of a headache to set up than SPF, and Google requiring it is an effective embrace-extend-extinguish strategy.


There's also DMARC, which is an SPF-like thing that tells the recipient how strict it should be about the SPF and DKIM checks.


SMTP: The clue is no longer in the name.

[Diver300]

Well it's been 48 hours and emails to Gmail are still bouncing.

I guess I will have to try to set up DKIM.

bugger

[Afasoas]

What's your DKIM situation?  That's the other thing you generally need for Google not to get sniffy about your emails.

I don't know what DKIM is, or what my DKIM situation is.

From what I can see, Gmail is happy with either DKIM or SPF, but I'm not sure. The bounces include like this:-

550-5.7.26  Authentication results:
550-5.7.26  DKIM = did not pass
550-5.7.26  SPF [mtrak.co.uk] with ip: [212.227.17.13] = did not pass

212.227.17.13 is in one of the ranges included by the SPF record for _spf-eu.ionos.com.   
If mtrak.co.uk is the FQDN for your mail server, it doesn't look like an SPF record is getting returned?

https://mxtoolbox.com/SuperTool.aspx?action=spf%3amtrak.co.uk&run=toolpage

And Kim is absolutely right, SPF and DKIM are the bare minimum for mail deliverability with Google.
Low volume mail servers with very little/no reputation are difficult with the large cloudy mail providers. It kind of works if you persevere for long enough - and I'm a hold out on this because I refuse to let the large cloudy providers win.