cancel
Showing results for 
Search instead for 
Did you mean: 

Recent Plus.Net Email Changes causing problems with DMARC and SPF policy

old_fogey
Dabbler
Posts: 16
Thanks: 6
Registered: ‎31-10-2016

Recent Plus.Net Email Changes causing problems with DMARC and SPF policy

I am a plus.net subscriber at home, and also help a small charity that uses plus.net business broadband and hosts their own Exchange server.  Shortly after getting an email from plus.net at home about how they are changing their email policy and you need to send email through the plus.net servers (which the charity were doing anyway), the charity started getting issues with silent non-delivery of emails.  They used gmail as a workaround for some troublesome emails.

The charity uses SPF, DKIM and DMARC and yesterday I tracked the issue down - I think - to SPF failures.  For some reason, although the email header has the origin IP address as the charity exhcange server and correctly identifies this IP address in their DNS SPF record, when we send emails to gmail and dkimvalidator.com we see from the received headers that SPF is failing as it is being checked on avasoutXX.plus.net (which is not in our SPF record) rather than the charities record.

As a temporary work around I've added 'include:plus.net' to the charities SPF record on DNS and both gmail and dkimvalidator.com now show that SPF is passing. 

No offense, but I don't wan't to allow any plus.net subscriber to send spam emails that pass SPF, and the charity has only one exchange server.  ANy ideas what should either we do or plus.net do to solve the problem?  (I have looked at the guidance note from plus.net obviously and there is no informaiton on SPF records on DNS for those running their own email servers).

 

3 REPLIES 3
Optimatts
Plusnet Alumni (retired)
Plusnet Alumni (retired)
Posts: 442
Fixes: 19
Registered: ‎25-09-2018

Re: Recent Plus.Net Email Changes causing problems with DMARC and SPF policy

Hi there @old_fogey,

 

From what you suggested a few times could you clarify if the charity is using its own server? Or are you using the plusnet server (relay.plus.net)?

"I am a plus.net subscriber at home, and also help a small charity that uses plus.net business broadband and hosts their own Exchange server." 

 

"the charity has only one exchange server.  ANy ideas what should either we do or plus.net do to solve the problem?  (I have looked at the guidance note from plus.net obviously and there is no informaiton on SPF records on DNS for those running their own email servers)."

 

 

old_fogey
Dabbler
Posts: 16
Thanks: 6
Registered: ‎31-10-2016

Re: Recent Plus.Net Email Changes causing problems with DMARC and SPF policy

Hi Optimatts,

Thanks for the quick reply and sorry for any confusion, the answer is both using its own server and using the plusnet servers behind relay.plus.net (whose name implies is supposed to be relaying messages....).  To be more precise:

- they have their own domain (registered at godaddy), and set up A, MX, SPF, DKIM and DMARC records there

- they have a 'static IP' address from plus.net business broadband

- incoming smtp messages come straight to their server as specified in the MX record.  This has always worked and continues to do so.

- outgoing smtp messages are sent via relay.plus.net, as if they try to send them direct they are (and have always been in the ~4 years they are a plus.net customer) blocked by plus.net.  No issue with that, very sensible, nearly all ISPs do it and it is to help prevent email spam.

- outgoing smtp messages sent via relay.plus.net used to be received by customers very reliably.  Email headers on test messages I sent to my personal gmail last week show they come via avasoutXX.plus.net (where XX is a number under 10).  Outgoing email has worked well for roughly 4 years

- very recently, selected outgoing messages sent via relay.plus.net were not received and no indication that they hadn't been received was obtained.

- I investigated further and found at least some of those organisations not receiving mail from the charity were implementing a 'delete message' policy for SPF failures

- the charities spf record was (from memory) 'v=spf1 mx -all'.  The MX record points to the one email server they have at the plus.net static IP address.  Emails from that sever should not fail an SPF test.

- I tried a few test messages to the test system at dkimvalidator.com.  I could see that messages showed an SPF 'reject' because avasoutxx.plus.net was not in the SPF policy for the charity, even though the email headers showed that the email didn't come from avasoutxx.plus.net, but was originated at the charities exchange server at their static plus.net static IP address.

- I changed the SPF record to 'v=spf1 mx include:plus.net -all'.  SPF now passes at dkimvalidator.com as we have allowed any and every *.plus.net server to send email on our behalf. 

- the issue I have with this 'workaround' is that the only server that should be authorised to send email is the one specified in the MX record.  If (and only if) receiving organisations use DKIM then I guess all parties are still protected as only genuine emails will be signed by the charities private key.

- the question is therefore, what should the charity do so that they can implement a tight SPF rule and still have outgoing messages sent via relay.plus.net delivered reliably?

Hope this is crystal clear!

REgards

Andy

 

 

MisterW
Superuser
Superuser
Posts: 10,107
Thanks: 2,776
Fixes: 209
Registered: ‎30-07-2007

Re: Recent Plus.Net Email Changes causing problems with DMARC and SPF policy

the question is therefore, what should the charity do so that they can implement a tight SPF rule and still have outgoing messages sent via relay.plus.net delivered reliably?

Exactly what you have done.Smiley

outgoing smtp messages are sent via relay.plus.net,

You are sending via relay.plus.net, so the Plusnet servers must be in your SPF record.

- the issue I have with this 'workaround' is that the only server that should be authorised to send email is the one specified in the MX record.

It's not a workaround, you ARE sending via relay.plus.net and therefore the PN servers must be authorised in the SPF record. In fact you never send directly from your server so it doesn't actually need to be in the SPF record. The MX record defines the server for INCOMING messages, which it appears you do receive directly.

Hope that helps

Superusers are not staff, but they do have a direct line of communication into the business in order to raise issues, concerns and feedback from the community.