Bounce back emails

Discussion in 'Business & Enterprise Computing' started by NinjaPirate, Mar 6, 2021.

  1. NinjaPirate

    NinjaPirate Member

    Joined:
    Jul 6, 2010
    Messages:
    58
    Hi,

    Any assistance on the below issue would be greatley apprecaited.

    I have 2 clients getting the same bounce back email when sending to iinet or westnet emails address.
    Error below. It mentions the spf record being the issue. Both clients are using Office 365 as their email hosting. I thought at first it was an issue at iinet but I managed to send emails succesfully through my O365 email hosting. Any ideas what may have changed to cause this? Do I need to make a change to my clients SPF record through O365? I've checked the DNS records and they report healthly with no obvoius issues.

    Error from Cleint 1:

    iinet.net.au couldn't confirm that your message was sent from a trusted location.

    Janet

    Office 365

    muscak

    Action Required

    Recipient




    SPF validation error


    How to Fix It

    Your organization's email admin will have to diagnose and fix your domain's email settings. Please forward this message to your email admin.



    More Info for Email Admins

    Status code: 550 5.7.23

    This error occurs when Sender Policy Framework (SPF) validation for the sender's domain fails. If you're the sender's email admin, make sure the SPF records for your domain at your domain registrar are set up correctly. Office 365 supports only one SPF record (a TXT record that defines SPF) for your domain. Include the following domain name: spf.protection.outlook.com. If you have a hybrid configuration (some mailboxes in the cloud, and some mailboxes on premises) or if you're an Exchange Online Protection standalone customer, add the outbound IP address of your on-premises servers to the TXT record.

    For more information and instructions about configuring SPF records see Customize an SPF record to validate outbound mail sent from your domain and also External Domain Name System records for Office 365.



    Error Details

    Reported error:

    550 5.7.23 The message was rejected because of Sender Policy Framework violation -> 550 #5.7.1 SPF unauthorized mail is prohibited.

    DSN generated by:

    ME1PR01MB1634.ausprd01.prod.outlook.com

    Remote server:

    icp-osb-irony-in7.iinet.net.au


    Message Hops

    HOP

    TIME (UTC)

    FROM

    TO

    WITH

    RELAY TIME

    1

    5/03/2021
    7:33:11 AM

    MEXPR01MB1782.ausprd01.prod.outlook.com

    MEXPR01MB1782.ausprd01.prod.outlook.com

    mapi

    *

    2

    5/03/2021
    7:33:11 AM

    MEXPR01MB1782.ausprd01.prod.outlook.com

    ME1PR01MB1634.ausprd01.prod.outlook.com

    Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384)

    *
     
  2. fad

    fad Member

    Joined:
    Jun 26, 2001
    Messages:
    2,614
    Location:
    City, Canberra, Australia
    Use mx toolbox and check your spf records

    Try spf:your domain.com in the field
     
    Last edited: Mar 6, 2021
  3. natedoggydog

    natedoggydog Member

    Joined:
    Oct 17, 2007
    Messages:
    36
    Location:
    Perth
    I've been having the same issue for at least two of my clients. I thought it was a transient issue that iinet would fix as well. Seems to be fixed for one of them, but the other still has issues. The remote server is the same as the one you have. It's definitely an issue iinet need to fix. I loathe to call them about this, to try and get hold of someone who can fix it, but that seems the next logical step.
     
  4. PabloEscobar

    PabloEscobar Member

    Joined:
    Jan 28, 2008
    Messages:
    14,638
    This isn't an issue for IInet to fix - They are probably doing what the sending domains SPF records is instructing them to do.
    Post the domain, and I'll show you why their SPF records are probably wrong.

    SPF in a nutshell, allows organisations to say "My E-mail only comes from <These> servers
    It also allows organisations to define what they would like to happen to mail that doesn't come from said servers.

    I'd be dollars to donuts the SPF record for the sending domain includes -all, which tells recieving mail servers to "Hard fail" any messages that aren't included.
    If they have moved to O365 and not added include:spf.protection.outlook.com to their SPF record, then any mail sent, to servers that are checking SPF records, will bounce.
     
  5. ir0nhide

    ir0nhide Member

    Joined:
    Oct 24, 2003
    Messages:
    4,594
    Location:
    Adelaide
    The answer for this problem is to do DNS properly in the first place.
     
    dave_dave_dave and mooboyj like this.
  6. elvis

    elvis Old school old fool

    Joined:
    Jun 27, 2001
    Messages:
    45,352
    Location:
    Brisbane
    Takes me back to my July 1, 2008 rant post.
     
    mooboyj likes this.
  7. DavidRa

    DavidRa Member

    Joined:
    Jun 8, 2002
    Messages:
    3,091
    Location:
    NSW Central Coast
    Oh, hell. Yeah I have this too.

    Fuck it, doxxing myself a little but check out the result for [redacted].com.au. Email source that fails is [redacted].225 or [redacted].226.

    MXtoolbox is fine with the record, it validates perfectly, not too many lookups etc. And just for S&G, it used to be ~all, and is now -all. iiNet has been useless.

    Edit: Fixed the source IPs... And redacted now that someone else has seen it and not been able to point out stupidity.
     
    Last edited: Mar 21, 2021
  8. dave_dave_dave

    dave_dave_dave Member

    Joined:
    Mar 17, 2004
    Messages:
    2,894
    Location:
    Gold Coast
    I've had some issue in the past with failed email sends even though spf is correct, most of the time setting up DKIM and DMARC resolved the issue.
     
  9. DavidRa

    DavidRa Member

    Joined:
    Jun 8, 2002
    Messages:
    3,091
    Location:
    NSW Central Coast
    Yeah this domain is fully configured - DKIM and DMARC should be in play (valid last I looked at least). But the error is fairly specific - SPF failure, not DKIM or DMARC or IP reputation. iiNet seemed to confirm (I had a long and fairly heated discussion with them Thursday) that it's SPF-related. Refused to escalate from general business support, and provided an internal KB about what SPF is for that was just completely wrong. Gems like, "SPF exists to ensure that the emails go back to the same person that sent them" and so on.
     
  10. wazza

    wazza Member

    Joined:
    Jun 28, 2001
    Messages:
    3,761
    Location:
    NSW
    Probably just put the wrong IPs on here, but are you sure the sending servers are .25 and .26? SPF allows .225 and .226 which do come back to your domain, but 25 and 26 aren't allowed.
    Also try emailing ping@tools.mxtoolbox.com and it will auto respond with some diag info including which IPs it detected the email coming from, if your SPF passed or failed etc.
     
  11. DavidRa

    DavidRa Member

    Joined:
    Jun 8, 2002
    Messages:
    3,091
    Location:
    NSW Central Coast
    Yeah .225 and .226 darn it... I'm going to go test that now thanks (that's something I wasn't aware of).
     
  12. DavidRa

    DavidRa Member

    Joined:
    Jun 8, 2002
    Messages:
    3,091
    Location:
    NSW Central Coast
    OK on the back of a generous iiNet engineer's log dives, check the DNS zone for people who've added malformed or extra TXT records for other names in the domain - someone had added a broken second record for the server name, and it looks like iiNet may be looking up the SPF for the name specified in the reverse DNS record for the connecting server. I've made changes to the customer zone and have asked the customer to retest ...

    For clarity: say your SMTP server's external IP is 203.1.2.11, and the reverse DNS for that IP resolves to smtp1.example.com.au. The logs seem to suggest the iiNet MTA will look up the SPF for smtp1.example.com.au in place of, or in addition to, the sending address. If that's not valid then it looks like you'll get the quoted error.

    Here's hoping.

    If it's not clear (it's Friday, I'm tired) feel free ask for clarification on what I did.
     

Share This Page

Advertisement: