My DMARC policy is causing some of client mail servers to reject emails from my Syncro Ticketing System

Posted by DeejayCa@reddit | sysadmin | View on Reddit | 18 comments

Hi all. I'm going to be brutally honest, I only learned about DMARC recently but have always had SPF and DKIM configured for myself and clients (as I'm a small IT shop). Here's the story, my DMARC policy is set up like this: Type: TXT Host/Name: _DMARC.website.com Value: v=DMARC1; p=quarantine; rua=mailto:email@website.com; ruf=mailto:email@website.com; fo=d:s; pct=100; ri=7; adkim=r; aspf=r My SPF record is set up like this: v=spf1 include:_spf.google.com +ip4:168.245.102.208 ~all What confuses me is if my SPF policy includes obviously my primarily mail server (Google Workspace in this instance), but an IPv4 address, which is utilized by Syncro Service where tickets are emailed from, clients messages sometimes get rejected and caught as SPF fraud (specifically on some of the ProofPoint mail protection services). Is this because the mail may be sending from alternative IP's that Syncro mail servers use? Should I be using "email.syncroemail.com" instead of the IPV4 in my SPF record? Will changing to this utilize all IPv4's that Syncro uses and essentially permit sending on my domains behalf without being caught up in clients mail filtering? Any help would be appreciated.

Reply to Post

18 Comments

[-]

jacktwood@reddit

Been through this a few times, dmarc is a bit of a journey. Once spf/dkim are sorted you need to.. set the policy to none to monitor the mail flow for a bit, then upgrade to quarentine, but only a certain percentage, the go to reject. [https://documentation.mailjet.com/hc/en-us/articles/20531905163419-Understanding-DMARC](https://documentation.mailjet.com/hc/en-us/articles/20531905163419-Understanding-DMARC) Do lots of reading on it.

[-]

jacktwood@reddit

Example journey over time.. `v=DMARC1;p=none;rua=email@email.com``,` `mailto:email@email.com;ruf=mailto:email@email.com``,` `mailto:email@email.com` `v=DMARC1;p=quarantine;pct=20;rua=email@email.com``,` `mailto:email@email.com;ruf=mailto:email@email.com``,` `mailto:email@email.com` `v=DMARC1;p=quarantine;pct=60;rua=email@email.com``,` `mailto:email@email.com;ruf=mailto:email@email.com``,` `mailto:email@email.com` `v=DMARC1;p=reject;rua=email@email.com``,` `mailto:email@email.com;ruf=mailto:email@email.com``,` `mailto:email@email.com`

[-]

therealmofbarbelo@reddit

What's the benefit of specifying a percentage of mail to be quarantined or rejected? Seems like this would just cause intermittent issues if you aren't completely sure if all of your services are passing dmarc and that would make it hard to troubleshoot delivery issues. Why not just go from a policy of none, then to quarantine and then to reject for 100% of emails?

[-]

jacktwood@reddit

I followed advice from experts, made sense to me too. Feels sensible not to quarantine everything while it's finding its feet, no? Keep building and monitoring. Then move to 100% reject when sure all settings are aligned and confirmed with all regularly used servers. Spent hours pouring over the logs to be sure. Useful process. That said, your mail flow is your mail flow, only you know what's best for you. This worked for me.

[-]

Gtapex@reddit

My bet is that you need to get DKIM running I’d start by testing the emails sent by your syncro system using one or so of these methods: How to verify your domain’s Email Authentication settings in under 90 seconds - https://kb.smalltechstack.com/en-US/verify-your-domain-email-authentication-in-90-seconds-383221

[-]

DeejayCa@reddit (OP)

So I used learndmarc.com and sent a test ticket email to their system and this is what I got back: https://imgur.com/a/tmTUaew I redacted areas which is my actual domain name. What would I need to modify for these to pass?

[-]

Gtapex@reddit

You are not the only one feeling this pain: \- [https://community.syncromsp.com/t/send-syncro-notifications-and-ticket-lead-notifications-that-are-dmarc-compliant/6425/51](https://community.syncromsp.com/t/send-syncro-notifications-and-ticket-lead-notifications-that-are-dmarc-compliant/6425/51)  Looks like Syncro has a beta going for DMARC compliance that you can sign up for here: \- [https://docs.google.com/forms/d/e/1FAIpQLScZvJ2fueGjczIjnU5asV9eBUoSRWz0znj-TDJXk44yY8rp2g/viewform](https://docs.google.com/forms/d/e/1FAIpQLScZvJ2fueGjczIjnU5asV9eBUoSRWz0znj-TDJXk44yY8rp2g/viewform)

[-]

DeejayCa@reddit (OP)

Hmm thanks for this information, I think I'll hold off on fully setting up the DMARC policy until I can get this properly sorted.

[-]

Gtapex@reddit

Yep… I’d leave the record in place so that you can monitor, but change the policy to “none” until you’ve reached a “steady-state”

[-]

Remarkable_Air3274@reddit

This might work.

[-]

DeejayCa@reddit (OP)

Perfect, will do.

[-]

J_de_Silentio@reddit

Thanks for the learndmarc.com site. Good info on it. But holy shit that site is annoying.

[-]

jaaydub42@reddit

One thing that will get you on enforcing DMARC policies is the Return-Path address in your headers. Even if the SPF allows for the use of the SMTP server as a sender for your domain, and the message is properly signed with DKIM, if the address in the Return-Path header isn't for your domain, the message will fail the DMARC check. This can be problematic with SaaS senders. Some are better at handling this than others. For handling various external SaaS services and senders, I've found its best plan a policy that separates corporate email (end user) allowing for the base domain (i.e. user@example.com), and for 3rd party senders, to send from a subdomain (user@service.example.com, user@e.example.com, etc...). It adds a little bit more work, but leaves you with cleaner SPF records, rather than a set littered with includes from who knows where.

[-]

cspotme2@reddit

It sounds like you didn't test dmarc with p=none and then set ruf/rua to send a copy of emails for review that didn't meet your dmarc policy. When you have 3rd party vendors who send as you, you need to test and review first.

[-]

iwinsallthethings@reddit

Seen a lot more posts on this lately and it's a good thing. People should understand where their email is coming from and who is sending it. SPF is based on DNS. Hostnames and IPs. DKIM is essentially certificate signing emails using DNS as a reference but does not rely upon IP/Hostname in the same way. The benefit of using DKIM is that it protects the email by generating a hash to verify the mail is not modified during transport. It also does not rely upon being sent from strict IP/Hostnames. You create an email, the sending server with DKIM setup hashes out the email and the header. Receiving server sees a dkim entry in the email, looks up the public key, compares hash/alignment and then either agrees you are authorized as a sender or not. Your SPF record has a single IP which is owned by Sendgrid. Likely that IP address is shared by your ticketing provider and gets blacklisted sometimes. Proofpoint can be pretty aggressive at times with their blacklisting, especially on products like the sendgrid. It's also possible that Synchro is using more than just that single IP address in which case you would also fail dmarc. Open a ticket with synchro and find out what they say. The number of times i've had companies come to me or employees to add to our spf is way too high. Even companies that deal in email don't seem to understand it.

[-]

DeejayCa@reddit (OP)

Yea it does seem to be more common now. Thanks for your time in writing this post. I'm going to do some more digging and work with Syncro to get a proper solution in place when they've officially deployed it.

[-]

Ad-1316@reddit

Syncro Service - should be able to tell you what you need in the SPF and DKIM.

[-]

badlybane@reddit

Either the the ip is out of range, if their sending server isn't going to use your dkim then it will fail. The last thing is if is modifies the email it can break dkim.  syncro should have spf documentaion found where someone got it working " email.syncroemail.com designates 168.245.102.208 as permitted sender) % dig txt syncroemail.com +short | grep spf "v=spf1 include:sendgrid.net include:mailgun.org \~all "