Bad SPF record, locking me out of account

This is a new account so I can post.

I did a real doozy here. I added an incorrect SPF record causing my company to not be able receive email at all.

When I try to login to Cloudflare to fix the DNS record, it is sending the 2FA code to my company email, which doesn’t work. I am working remotely and cannot get to a device that has a recognised IP.

We are on the “pro” plan, so I cannot call emergency support. If I re-set the 2FA, then we have to wait 5 days to get our emails back.

Please help!

I actually can’t even re-set the 2FA as it wants to send me an email to verify…

Can you share the name of a domain in your account?

Yes of course, winzum(dot)co

Any email from outside a google domain (it is connected to Googles mail servers) fails. I cannot send from my protonmail account. Cloudflare mail is not getting through to me. I have checked all quarantine, there is nothing there.

While I do see an error* in your SPF, the only effect it should have is to render the record invalid. The result should be identical to having no SPF record and should have no effect on receiving email. SPF serves only to identify sources authorized to send as your domain.

Have you verified that there are no settings in your GMail configuration that could be blocking external email? It is a common security practice to block direct SMTP when using a third-party party hosted email security solution like Proofpoint Essentials or MailProtector. When implemented with such restrictions the domain MX need to point to the hosted filtering platform.

Once you get this matter resolved, I encourage you to securely store a set of one-time-use backup codes and switch to using a TOTP 2FA app to remove email from your regular 2FA strategy. If you can spring for a hardware key like a Yubikey, that’s an even better option.

* In case you don’t recognize the SPF error, it is the self-referential include statement which causes an infinite loop.

Hmm, thank you for your insight. I am going to do some more reading on the three policies (SPF, DKIM and DMARC). I’ll be honest I find them quite confusing!

Could the issue be the DMARC record set to reject everything?
v=DMARC1; p=reject; rua=mailto:[email protected]

The issues did arise shortly after I added these records, it would be odd for it to be unrelated.

" What risks are associated with implementing DMARC? - If DMARC us implemented incorrectly, the policy will drop legitimate mail messages . It is important to start the policy at the lowest level (None) and move to the highest level (Reject) once all legitimate mail message issues are resolved."

I am going to assume this is what I have done, it is setup incorrectly and now all mail is being rejected.

@cloonan - can anyone help me, please? I believe I can send you an email from an @winzum address to prove I am indeed with the company. I need to get back into my account to fix this. I cannot login. :frowning:

In the future, once you’ve regained access to your account, I’d advice you to change the account email. It is generally bad practice to use an @example.com email address for the account used to manage DNS or registrar for example.com - exactly because of situations like this.

No. Your DMARC is used to mitigate unauthorized senders that impersonate your domain. Your DMARC policy tells receiving mailservers what to do with email that claims to be from your domain and fails to prove it based on your SPF or DKIM policies. It has no relation to the handling of emails that are sent to your domain from other domains.

Ok thank you, I am just going to contact Google now as I have no idea what’s going on then.

Google’s mailservers handle all of my mail.

100% This is the first thing I am going to do :joy: Such a rookie mistake! One I shall never make again.

Ok so I now understand the problem. Because the email address in question is a Google Group Alias, which it then forward to the team members, the forwarding is failing due to the DMARC.

I have just spoken to Google:

“Please refer to the error message - Unauthenticated email from winzum(dot)co is not accepted due to domain’s 550-5.7.26 DMARC policy. Please contact the administrator of winzum(dot)co domain 550-5.7.26 if this was a legitimate mail. Please visit 550-5.7.26 xxxxx to learn about the 550 5.7.26 DMARC initiative. t26-20020a67f5da000000b003ce935241e6sor1096848vso.67 - gsmtp”

So I need to get into my account to remove it, and I cannot.

Are you using Google Workspace with a Google Group compromised only of your domain emails?

I understand the error message, but that condition should not be applicable to a purely internal list.

While it’s too late now, one of the most important steps in any DMARC strategy is an observational stage prior to implementing an enforcement policy. There are a lot of good resources for learning how to implement DMARC. I’m fond of dmarcian who have a forum where you can have more in depth conversations on the topic than are appropriate in the Cloudflare Community.

Yes that’s right. There are no external mails in the Workspace group. I agree I am suprised that internal routing on Google’s own network is checking the DMARC policy (now that I understand truly what it is).

I seem to have stumbled across a comedy of errors setup that has resulted in probably the only way I can think of getting locked out of one’s Cloudflare, the combination of Workspace Group email and bad DMARC.

I of course feel the fool and did not do enough research before implementing something I clearly did not fully understand, that’s on me!

The question does remain though, how the ■■■■ do I get into my account :laughing: Support have stopped replying to me emails on the ticket…

To expedite resolution, I would delete the Google Group, or, if that is not practical, assign it a new email address temporarily. That should free up the email address for use as an alias on a single mailbox until you can correct the external configuration issues.

I would also look into how to configure message delivery to the Group. DMARC shold only be checked at the edge, and the message should not contain your domain in the RFC 5322 sender to even trigger your domain DMARC policy. All of that is off topic for the Cloudflare Community, but is still something you will benefit from exploring.

You sir, are a genius, why did I not think of that. I will just kill the group and create a proper inbox for that address.

I cannot thank you enough kind sir for all your input, you have been the only person really willing to listen to my plight! If I could send you money for you time I would happily do so.

I will report back to confirm I have access again.

2 Likes

I am in, thank you so much.

I will read the resources you shared and update my knowledge.

2 Likes