emails bounced by gmail all of a sudden with 550-5.7.26 error

I have been seeing something very similar the past few days! Not sure what's causing it either, but it's intermittent for me as well. What server/service are you using to provide email? Is it CPanel for the accounts that are then used through Outlook?

You can check your domain on MXToolbox https://mxtoolbox.com/

This will tell you if you have any major issues. Since you are hosted, it could be something that Network Solutions is doing on the back end as the email exits. Adding a SPF record is done to your Internet DNS records. It verifies the sending server is valid. It is used to prevent spamming. I would recommend you check your domain record with that tool and make any changes where the validation fails. 

so MXtoolbox says our domain resolves to the two Spamtitan IPs set up in Network solutions. No DMARC record found and DMARC quarantine policy not enabled but a check mark for DNS records published. Using Exchange 2010 and we host our email, it just goes through a smarthost to scan for spam, viruses etc. Nothing has changed on the server at all.

if your OUTGOING email fliws through spamtitan, your spf record shoul look like this

v=spf1 include:_include.spamtitan ~all

obviously the include can be named differently. spamtitan definitely has the correct name mentionned in the docs.

if spamtitan does not handle the outgoing email, use your own addresses with ip4:1.2.3.4 or something similar.

if you are unsure, it is perfectly legit to use both. spf rules starting with + or with no such prefix allow individual sources. just make sure to leave ~all or -all at the end of the record

if spamtitan is an internal soft rather than a saas provider. just use the ips you own

so exactly where do I go to enter this spf record?

it should be a public dns record of type TXT for your domain

assuming yoy own domain foo.bar anx you send email as user@foo.bar, you need

foo.bar IN TXT "v=spf1 ..."

if your dns is managed by a third party, they should provide you with a ui allowing to set an spf record.

if you need to specify a host such as www, mail or whatever in the ui while editing foo.bar zone, use "@" as the host name. this is the null record.

so i went to Network solutions and added this text record. 
Does this look right?

This appears to be the bogus "misinformation database match problem" which started 2x-3x months ago.

The reasons are numerous + also Google's classifier is buggy so for example is you have text in your message of the form...

#something

Select allOpen in new window

The classifier code incorrectly flags this as a bad URL (rather than correctly just text) which also raises the "authentication error" which is of itself super bogus, as the message should say "bad URL" or "you're an insurrectionist of Russian sympathizer engaged in misinformation".

And this would be far to simple.

Attach a copy of your full message (headers + body) for review.

Likely people in the know about fixing this type of problem can glance at message + suggest fixes.

Network Solutions says the spf entry doesn't need to be on their information. Maybe SpamTitan. I have a ticket in with them also.

For completeness, you can write your own code to determine the exact line, then exact word (whitespace delimited string) causing the error.

Here's the sequence I use when any "you aren't authenticated" messages emit... as there are many of these, an entire class of oddball messages...

1) First extract all the URIs (HTTPS + mailto) strings from the message, then send a message to any Gmail account.

I keep one around, so I just delete all the nonsense messages that get through.

2) Then send 1x URI by itself in a message to the Gmail account, so most will go through + when you get any "you aren't authenticated", then you know... you can never, ever, ever send any message containing this URI if you expect to get your message delivered.

Note: This is complex if you're promoting a Website where the related URL has been injected into the Misinformation Database.

There are ways around this... which are best never mentioned in public...

3) Usually #2 finds the offending string + sometimes not. So if no unauthenticated message error raises, then deeper testing is required.

At this point, I strip out each header line + each body line, inject the line into an empty message, then send the message,

4) Once you have the header/body line raising the error, split the line on whitespace, then inject each word into an empty message to send.

This is how I figure out the #something bogus Google classifier bug.

5) Once you figure out the word/string raising the error, remove this from your message + restart your sending.

You mentioned, "Network Solutions says the spf entry doesn't need to be on their information."

If you mean somehow a sending IP can be omitted from SPF, this is 100% wrong + will result in massive delivery problems.

And, if SPF IPs are missing Google returns a different message.

Testing shows "unauthenticated responses", which don't include the Google URL about bad SPF/DKIM/DMARC, all relate to matches to the Misinformation Database.

email/internet header of bounced email

Received: from cihproperties.com (192.168.0.3) by MailServer.sbs.local
 (192.168.0.6) with Microsoft SMTP Server id 14.3.399.0; Thu, 3 Mar 2022
 13:53:20 -0500
Received: from cloudq.spamtitan.com ([18.217.94.247]) by cihproperties.com
 with Microsoft SMTPSVC(6.0.3790.3959);    Thu, 3 Mar 2022 13:53:19 -0500
X-Virus-Scanned: by SpamTitan at us-east-2.compute.internal
X-Spam-Flag: NO
X-Spam-Score: 0.899
X-Spam-Level:
X-Spam-Status: No, score=0.899 tagged_above=-999 required=5
   tests=[ANY_BOUNCE_MESSAGE=0.1, BAYES_50=0.8, BOUNCE_MESSAGE=0.1,
   HTML_MESSAGE=0.001, KAM_DMARC_STATUS=0.01, MIME_HTML_MOSTLY=0.1,
   RCVD_IN_SPFWL=-0.2, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001,
   T_SCC_BODY_TEXT_LINE=-0.01] autolearn=no autolearn_force=no
Authentication-Results: cloudq.spamtitan.com;
        spf=pass smtp.mailfrom="" smtp.helo=cloud-out-c.spamtitan.com
Received-SPF: pass
        (cloud-out-c.spamtitan.com: 34.236.127.150 is authorized to use 'cloud-out-c.spamtitan.com' in 'helo' identity (mechanism 'ip4:34.236.127.150' matched))
        receiver=cloudq.spamtitan.com;
        identity=helo;
        helo=cloud-out-c.spamtitan.com;
        client-ip=34.236.127.150
Received: from cloud-out-c.spamtitan.com (cloud-out-c.spamtitan.com
 [34.236.127.150])   (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256
 bits)    key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest
 SHA256)   (No client certificate requested)   by cloudq.spamtitan.com (Postfix)
 with ESMTPS id 48111A0574E   for <MLudwig@cihproperties.com>; Thu,  3 Mar 2022
 13:53:14 -0500 (EST)
Received: by cloud-out-c.spamtitan.com (Postfix)   id 263B73824B1; Thu,  3 Mar
 2022 18:53:14 +0000 (UTC)
Date: Thu, 3 Mar 2022 18:53:14 +0000
From: Mail Delivery System <MAILER-DAEMON@spamtitan.com>
Subject: Undelivered Mail Returned to Sender
To: <MLudwig@cihproperties.com>
Auto-Submitted: auto-replied
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
   boundary="E0F2E3824A2.1646333594/cloud-out-c.spamtitan.com"
Content-Transfer-Encoding: 8bit
Message-ID: <20220303185314.263B73824B1@cloud-out-c.spamtitan.com>
Return-Path: <>
X-OriginalArrivalTime: 03 Mar 2022 18:53:19.0941 (UTC) FILETIME=[F34E8F50:01D82F2F]
X-MS-Exchange-Organization-SCL: 2
X-MS-Exchange-Organization-AuthSource: MailServer.sbs.local
X-MS-Exchange-Organization-AuthAs: Anonymous

Nothing jumps out in headers + the full body is required to guess, as most problems occur in message bodies.

body of test message to myself

Delivery has failed to these recipients or groups:
mludwig49@gmail.com
 Your message wasn't delivered because the recipient's e-mail provider rejected it.
The following organization rejected your message: gmail-smtp-in.l.google.com.

 
 
 
 
Diagnostic information for administrators:
Generating server: cloud-out-c.spamtitan.com
mludwig49@gmail.com
 gmail-smtp-in.l.google.com #<gmail-smtp-in.l.google.com #5.7.26 smtp; 550-5.7.26 This message does not have authentication information or fails to 550-5.7.26 pass authentication checks. To best protect our users from spam, the 550-5.7.26 message has been blocked. Please visit 550-5.7.26 https://support.google.com/mail/answer/81126#authentication for more 550 5.7.26 information. bc9-20020a05622a1cc900b002e01c14f670si763576qtb.367 - gsmtp> #SMTP#
Original message headers:

Return-Path: <MLudwig@cihproperties.com>

Select allOpen in new window

X-Virus-Scanned: by SpamTitan at spamtitan.com

Select allOpen in new window

Authentication-Results: cloud-out-c.spamtitan.com;

Select allOpen in new window

        x-trusted-ip=pass

Select allOpen in new window

Received: from cihproperties.com (mail.cihproperties.com [50.242.234.98])       by

Select allOpen in new window

 cloud-out-c.spamtitan.com (Postfix) with ESMTP id D288738248A        for

Select allOpen in new window

 <mludwig49@gmail.com>; Thu,  3 Mar 2022 18:53:12 +0000 (UTC)

Select allOpen in new window

Received: from MAILSERVER.sbs.local ([192.168.0.6]) by cihproperties.com with

Select allOpen in new window

 Microsoft SMTPSVC(6.0.3790.3959);     Thu, 3 Mar 2022 13:53:12 -0500

Select allOpen in new window

Received: from MAILSERVER.sbs.local ([2002:32f2:ea61::32f2:ea61]) by

Select allOpen in new window

 MailServer.sbs.local ([2002:32f2:ea61::32f2:ea61]) with mapi id

Select allOpen in new window

 14.03.0399.000; Thu, 3 Mar 2022 13:53:11 -0500

Select allOpen in new window

From: Mark Ludwig <MLudwig@cihproperties.com>

Select allOpen in new window

To: "mark w. ludwig" <mludwig49@gmail.com>

Select allOpen in new window

Subject: test 1210

Select allOpen in new window

Thread-Topic: test 1210

Select allOpen in new window

Thread-Index: AdgvIZMDlDRAJWIlQyKlVPia7beC7Q==

Select allOpen in new window

Date: Thu, 3 Mar 2022 18:53:11 +0000

Select allOpen in new window

Message-ID: <3C9ED6C626EE3B44B4993B860D0459C301535E996A@MailServer.sbs.local>

Select allOpen in new window

Accept-Language: en-US

Select allOpen in new window

Content-Language: en-US

Select allOpen in new window

X-MS-Has-Attach:

Select allOpen in new window

X-MS-TNEF-Correlator:

Select allOpen in new window

x-originalarrivaltime: 03 Mar 2022 17:10:36.0610 (UTC)

Select allOpen in new window

 FILETIME=[99ACE220:01D82F21]

Select allOpen in new window

authentication-results: cloud-out-c.spamtitan.com;        x-trusted-ip=pass

Select allOpen in new window

x-virus-scanned: by SpamTitan at spamtitan.com

Select allOpen in new window

Content-Type: multipart/alternative;

Select allOpen in new window

        boundary="_000_3C9ED6C626EE3B44B4993B860D0459C301535E996AMailServersbs_"

Select allOpen in new window

MIME-Version: 1.0

Select allOpen in new window

you maywant to add mail.cihproperty to the spf record. also note that caches may induce a couple of days before the changes are effective at google's

i found a rather weird blog entry suggesting
+include:spf.gzo.com
is the correct include for spamtitan

using a or mx may help if you are lucky but do not do this haphazardly

adding the cloudout above host will probably work

+a:cloudout...

The return SMTP detail referring to https://support.google.com/mail/answer/81126#authentication means this is an infrastructure failure, rather than a Misinformation Database match.

https://support.google.com/mail/answer/81126#authentication is clear the problem is one of these.

1) IPrev missing or failed.

2) SPF missing or failed.

3) DKIM DNS missing or DKIM signature in message failed.

4) DMARC policy is incongruent with #1-#3.

Best first step debugging this is to use the Port25 Verifier.

https://www.experts-exchange.com/questions/29233684/Email-fails-to-be-sent-to-a-specific-domain-errors-5-1-0-5-7-0.html covers how to use the Port25 Verifier.

port25 verifier is relevant to INBOUND traffic.

i do second the issue is with spf, dkim, dmarc and the likes. a proper spf record ought to be good enough but dkim would also help.

first line of question states, "Last two days I have intermittently had emails sent to gmail accounts blocked."

Gmail requires various infrastructure must be correct for messages to be accepted.

So Port25 surely applies to having clues for how to fix this.

@david : no. inbound and outbound email traffic are not related in any way. actually some domains only feature one of them. that said some blacklists reference open relays or people who ignore messages to postmaster or abuse. some filters send probes back with a reverse turing test to verify the sender is human or use VRFY or similar techniques. those are the sole cases where the inbound traffic could indirectly have inpact on delivery. gmail does not use such techniques and the error would be different anyway.

1) If you send a message to Gmail...

2) And Gmail blocks your message...

3) Your infrastructure is broken + requires fixing... because...

4) Gmail doesn't just randomly return the https://support.google.com/mail/answer/81126#authentication block... indiscriminately... for no reason...

The specifically returned Gmail URL about authentication specifically states IPrev/SPF/DKIM... one of these is broken...

The simple way (takes around 10 seconds) to have a good clue about what's broken is to use the Port25 Verifier or some similar system... then just fix what's broken...

Nothing complex about diagnosing the problem (roughly 10 seconds of time).

Complexity arises if something very odd is occurring like an invalid DKIM signature... which will turn up using the Port25 Verifier...

added correct spf record and it was resolved

just in case other spamtitan/o365 customers experience similar issues

$ host -t TXT cihproperties.com
cihproperties.com descriptive text "v=spf1 mx a:owa.cihproperties.com include:_spf_cd.spamtitan.com ~all"

$ host -t TXT _spf_cd.spamtitan.com
_spf_cd.spamtitan.com descriptive text "v=spf1 ip4:34.236.127.150 ip4:52.45.19.177 ip4:54.164.100.18 ip4:52.2.95.112 ip4:52.4.138.46 ip4:52.5.202.67 ip4:18.207.12.57 ip4:52.45.214.19 ip4:54.157.90.193 ip4:18.205.228.94 ip4:34.194.51.1 ip4:34.230.214.253 -all"

Select allOpen in new window

i am unsure where _spf_cd comes from but it apparently includes the required outgoing addresses of spamtitan

a:owa.DOMAIN.TLD allows office 365 to send email on DOMAIN.TLD's behalf. i suppose owa's outgoing traffic exits through owa.DOMAIN.tld. the record either allows owa to send email directly to the recipient domain or through spamtitan.

"mx" is most likely useless but won't harm much in this case ( the mxs are cloud11-12 of spamtitan )