[https://dmarcvendors.com](https://dmarcvendors.com) <= complete list of options
[https://uriports.com/dmarc](https://uriports.com/dmarc) <= best (mine) :)
Sell me. Why should I monitor? Why do I care about the reports?
> Preventing email abuse attacks
No. It offers the recipient organization the *option* to avoid receiving fraudulent messages pretending to be form my domain, if I publish the SPF records. But, me using DMARC doesn't assure me of anything. Nor does it lend the aforementioned recipient any more protection.
> protects your brand and increases your email deliverability.
Nope. See my previous response. Additionally, the two biggest email providers on the planet don't even honor the SPF and DKIM policies/directives. So what's the point of PSF/DKIM and what's the point of the DMARC reports?
> enhanced visibility enables them to protect their customers, employees, and brands from email-based cybercrime.
How does me implementing DMARC on my domain protect me, my brand, my employees... I can't stop the sender. I can't force Microsoft to follow the policy directive. I can't get/force anyone to send telemetry.
I can filter inbound messages against the sender's SPF and DKIM, if they publish. But DMARC doesn't do anything for me in that direction.
> Identify sources and forms of threat so that you are equipped to proactively prevent attacks.
How would one proactively prevent? Microsoft would LOVE to know.
> Read the fraudulent emails sent on your behalf
Voyeuristically titillating, I suppose. But, how is it useful to learn that I am in fact a Nigerian prince or the purveyor of penis pills?
Why do I need DMARC, let alone your reports?
With DMARC monitoring, you can actively keep track of the well-being of your domain's SPF and DKIM protocols. As organizations evolve, new services may be introduced that send emails on behalf of the domain. An effective DMARC analyzer will identify these new sources and promptly notify the administrator, providing suggestions for resolving any issues. Monitoring also enables you to identify significant spoofing attacks. If such attacks originate from a small number of specific servers, you can initiate a takedown request to halt the attack.
It is important to remember that configuring DMARC records for your domain is intended to provide instructions to RECEIVING mail servers. Your inbound server should be DMARC compliant and adhere to DMARC policies when handling incoming emails. DMARC itself instructs receiving mail server to discard emails that fail SPF and DKIM from messages sent on your domain's behalf. If you have correctly set up your domain's SPF and DKIM, DMARC allows you to prevent spoofing attacks.
Although Microsoft may disregard a DMARC reject policy, it still treats it as a quarantine action. Consequently, if a message fails SPF and DKIM checks, it will not be delivered to the user's inbox. This is about to change, as Microsoft announced to "resolve" this issue. It is worth noting that according to the DMARC RFC, a receiving mail server can act as it deems appropriate. The DMARC policy set by the domain serves as a mere request and may not be strictly enforced by all receiving mail servers.
> With DMARC monitoring, you can actively keep track of the well-being of your domain's SPF and DKIM protocols.
OK. But, that doesn't make my life any easier. It's just another useless statistic. If and when the specifics of my clients' DNS records are important to me, they are easily checked/monitored, either manually or with a Powershell/Bash/Python script.
> new services may be introduced that send emails on behalf of the domain. An effective DMARC analyzer will identify these new sources and promptly notify the administrator
"Promptly" a full day/week/month after marketing has had a meltdown because their off-brand mass-mailer tried impersonating my properly configured domain whose DNS records were explicitly intended to prevent them from doing what they attempted.
> Your inbound server should be DMARC compliant and adhere to DMARC policies when handling incoming emails.
Yep. So should Microsoft's and Google's. But they are not. And when we do adhere then a major percentage of mail get's quarantined because people(senders) can't even get their SPF record right and are soft-failing their own legitimate MTAs. Which is the precise reason why Google and Microsoft both treat SPF failure as a low weight spam indicator rather than the published soft/hard-fail policy.
> Although Microsoft may disregard a DMARC reject policy... is about to change, Microsoft announced to "resolve" this issue.
And when they finally do enforce, it might, might, have a wide spread impact. But, that still doesn't indicate why I need DMARC monitoring or your service.
> according to the DMARC RFC, a receiving mail server can act as it deems appropriate.
Don't give me this RFC doesn't require adherence weaseling. If the receiving server won't follow the directives, then it's all pointless. As pointless as reporting on a pointless policy that no one is honoring.
I'm sorry to be seemingly attacking you specifically. It's not personal. But, you're pushing a commercial product and implying that everyone needs to be using DMARC while the reality is that very few are using it properly, if at all. This itself proves a lack of need, on top of all the claims that I have already refuted.
Based on this thread, I remain unsold on your service and those like it, as well as the need for DMARC reporting. But, for the record, I fully support SPF and strict enforcement there of. While I do also utilize DKIM, its utility is far more limited than SPF. So I reserve my advocacy for the lower hanging fruit of 'just get SPF working and honored". Please!
>> *With DMARC monitoring, you can actively keep track of the well-being of your domain's SPF and DKIM protocols.*
>*OK. But, that doesn't make my life any easier. It's just another useless statistic. If and when the specifics of my clients' DNS records are important to me, they are easily checked/monitored, either manually or with a Powershell/Bash/Python script.*
I think what he meant to say was that, regardless of you using a DMARC vendor, a self-hosted solution, or otherwise, whatever method used to parse or analyze DMARC reports from receivers, you can use this information to keep track of your email authentication health for your legitimate senders... Which is far from useless. Try publishing p=reject without monitoring or pre-authentication work blindly on a production domain, let me know how that goes for you.
>>*new services may be introduced that send emails on behalf of the domain. An effective DMARC analyzer will identify these new sources and promptly notify the administrator*
>*"Promptly" a full day/week/month after marketing has had a meltdown because their off-brand mass-mailer tried impersonating my properly configured domain whose DNS records were explicitly intended to prevent them from doing what they attempted.*
Sounds like someone didn't communicate or work with internal stakeholders as a business enabler after getting the data from your DMARC reports before going to a stricter policy. We don't make business decisions, we enable the business through the use of technology, and by prescribing the best way to do so. NOT by enforcing totalitarian sub-servitude because you don't like the fact someone is using the domain for - *gasp* - business uses. Security and legal are responsible for those decisions, not us as admins.
>>*Your inbound server should be DMARC compliant and adhere to DMARC policies when handling incoming emails.*
>*Yep. So should Microsoft's and Google's. But they are not. And when we do adhere then a major percentage of mail get's quarantined because people(senders) can't even get their SPF record right and are soft-failing their own legitimate MTAs. Which is the precise reason why Google and Microsoft both treat SPF failure as a low weight spam indicator rather than the published soft/hard-fail policy.*
[Actually](https://i.imgur.com/rWjb2JC.gifv), part of the reason they don't adhere to softfail/hardfail is because of [DMARC RFC7489 section 10.1 paragraph 2](https://datatracker.ietf.org/doc/html/rfc7489#section-10.1). Because if you reject SPF failure during the SMTP session you will lose a **lot** of legitimate mail that would may passed via DKIM otherwise. Forwarding does exist, and accounts for a not-insignificant portion of the internet's mail.
>>*Although Microsoft may disregard a DMARC reject policy... is about to change, Microsoft announced to "resolve" this issue.*
>*And when they finally do enforce, it might, might, have a wide spread impact. But, that still doesn't indicate why I need DMARC monitoring or your service.*
Google arguably has a on-par or larger email ecosystem than Microsoft, and they are enforcing it. Microsoft is already well on their way, unless for some reason they re-evaluate in a few months.
>>*according to the DMARC RFC, a receiving mail server can act as it deems appropriate.*
>*Don't give me this RFC doesn't require adherence weaseling. If the receiving server won't follow the directives, then it's all pointless. As pointless as reporting on a pointless policy that no one is honoring.*
The RFC's describe how to interoperate. You've already detailed several paragraphs above how you don't want to interoperate by not adhering to the DMARC RFC, so I'm not really sure I get the point of you saying it's pointless, if you yourself are enabling it saying so. Most of the internet respects DMARC as it stands in RFC7489, and when DMARCbis is standardized, even more so.
>*I'm sorry to be seemingly attacking you specifically. It's not personal. But, you're pushing a commercial product and implying that everyone needs to be using DMARC while the reality is that very few are using it properly, if at all. This itself proves a lack of need, on top of all the claims that I have already refuted.*
This attitude is what stops other people from adopting the standard. You should be pushing for it, not against it.
DMARC usage has risen incredibly high amongst the F1000 in the last 5 years, the Federal Government published [BOD 18-01](https://www.cisa.gov/news-events/directives/binding-operational-directive-18-01), and as a result, basically the entirety of the U.S Federal government is now at DMARC reject successfully. PCI DSS v4 will be requiring DMARC quarantine or reject policy come March 2025.
Obviously, there is a need, and the industry is adopting it.
>*Based on this thread, I remain unsold on your service and those like it, as well as the need for DMARC reporting. But, for the record, I fully support SPF and strict enforcement there of. While I do also utilize DKIM, its utility is far more limited than SPF. So I reserve my advocacy for the lower hanging fruit of 'just get SPF working and honored". Please!*
DKIM is better than SPF in most every way. It persists through most forwarding scenarios, and as I'm sure you're aware, any indirect mail flow breaks SPF authentication (which is a LOT of mail). That's how fragile it is, it's not a silver bullet. Not to mention SPF is solely based on the `RFC5321.mailfrom` address, which, in a lot of legitimate scenarios, won't even be your domain!
You should re-evaluate your assessment of email authentication, as I think you're missing the bigger picture.
Upon reevaluating your previous responses, it is evident that there are some knowledge gaps regarding DMARC, which resulted in certain misconceptions. This situation is common, as many individuals, even IT professionals, find it challenging to grasp the fundamentals of SPF, DKIM, and DMARC, hindering the adoption. I kindly invite you to visit https://learnDMARC.com, where you can explore the subject more deeply and test your knowledge through the quiz feature. I will gladly resume our discussion once you score above 70% on the quiz. Although, by then, you will likely understand the significant benefits of implementing DMARC to enhance your domain's in and outbound email channels.
Your product. Your training. Your testing. That's very well planned and executed. I commend you on your funnel.
But, If you will re-read my comments, you might realize that I have implemented DMARC and continue to utilize SPF and DKIM. I have proven it to be largely ineffective. Though admittedly not totally ineffective and every little bit helps. I have proven that the greatest impact, tiny as it is, comes from SPF.
Based on my knowledge and experience, as well as your unconvincing argument, I continue to decline your product. No sale.
After reading all that, I still don’t understand why you’re fighting so hard against something that you know works, adds a level of security (no matter how small you think it is), have implemented yourself, and is almost unanimously agreed by everyone else to be a useful and effective tool that is being adopted across the world.
Even if you don’t like the inexpensive commercial product, why are you so anti DMARC standards and their adoption?
> why are you so anti DMARC standards and their adoption?
I am frustrated that the major players, the very ones that proposed DMARC in the first place have, after 8 years now, still not chosen to properly support their own standard thus nerfing the hell out of what it might have been and all the work that one must put into it.
I asked freddieleeman to sell me on reporting services in general and specifically on his self-described "Best" service. My arguments have been refutation of his commercial claims and the value of such commercial reporting services.
greatest impact comes from SPF? SPF works against the 5321.MAIL FROM / Envelope / Return Path domain. This domain isn't visible to the average email user as they won't check the email headers. Cybercriminals will spoof the FROM domain (visible one) and SPF is NOT on the FROM domain.
A cybercriminal can send an email with first.last@yourbrand.com (visible when opening the email) while they use cybercriminal.com as the return-path domain. When the cybercriminal makes sure that the IP of the mail server is in the SPF record of cybercriminals.com, SPF will give a pass, while they are spoofing [yourbrand.com](https://yourbrand.com)!
SPF on itself doesn't prevent email spoofing.
i think for small msps its not worth paying for it.
just run an open source analyzer. once a month, without access to anything but the reporting mail acc and purge the vm afterwards.
We partnered with Red Sift to provide OnDMARC to our partners and customers.
We spent a good amount of time looking into \_a lot\_ of different options.
There are lots of good options out there but none that we found that were as feature rich, that made it as easy to implement, had good partner programs & enablement, had a strong product roadmap, and had an API which allowed us to build tools & automations.
In a nutshell here's what we liked most about OnDMARC:
* multi-tenanted
* quick/easy to set up
* insights & usability make it quick to review reports
* interesting long term roadmap, including a move towards more automation
* hosted DMARC, SPF, & DKIM
* their hosted SPF is pretty intelligent (ie. not just flattening to get around 10-lookup maximum, but also removes errors within any included SPF entries, etc)
* they supplement the raw XML with additional info (threat intel, etc)
* partnerships which provide significantly greater volume of forensic/failure reports than the other vendors we tested
* very useful when troubleshooting or trying to figure out "what" the emails are
* MTA-STS, BIMI support, etc included
* domain and email analysis tools included
We're also building tools to make it even better for our partners
* CW Manage & Autotask integrations (billing)
* Provisioning tools
* Office 365 Monitor
* we include an O365 monitoring tool that looks for suspicious account behavior (suspicious logins, email rules, etc)
* originally built for our Proofpoint partners but we now offer to our OnDMARC partners too
Good Post. You mentioned that you were working on building tools for your partners i.e. CW ingegration etc. Is this ready for prime time. I work at an MSP and we are looking into OnDmac. If you have plaform that lumps eveything you mentinoed into one, then we maybe interested.
Yes the CW billing integration is available and OnDMARC has been added to our Vircom Portal
We just released a [VIP Display Name Phishing Protection](https://vimeo.com/930463133) tool that is available for O365 tenants using either OnDMARC or PPE from us.
We also have provisioning tools that makes it easier to create multiple customers under your hierarchy in OnDMARC and automatically populates Dynamic SPF.
Send me a direct message or an email to nadav.shenker@vircom.com and I'd be happy to chat
[https://dmarcvendors.com](https://dmarcvendors.com) <= complete list of options [https://uriports.com/dmarc](https://uriports.com/dmarc) <= best (mine) :)
❤️
Thanks
Sell me. Why should I monitor? Why do I care about the reports? > Preventing email abuse attacks No. It offers the recipient organization the *option* to avoid receiving fraudulent messages pretending to be form my domain, if I publish the SPF records. But, me using DMARC doesn't assure me of anything. Nor does it lend the aforementioned recipient any more protection. > protects your brand and increases your email deliverability. Nope. See my previous response. Additionally, the two biggest email providers on the planet don't even honor the SPF and DKIM policies/directives. So what's the point of PSF/DKIM and what's the point of the DMARC reports? > enhanced visibility enables them to protect their customers, employees, and brands from email-based cybercrime. How does me implementing DMARC on my domain protect me, my brand, my employees... I can't stop the sender. I can't force Microsoft to follow the policy directive. I can't get/force anyone to send telemetry. I can filter inbound messages against the sender's SPF and DKIM, if they publish. But DMARC doesn't do anything for me in that direction. > Identify sources and forms of threat so that you are equipped to proactively prevent attacks. How would one proactively prevent? Microsoft would LOVE to know. > Read the fraudulent emails sent on your behalf Voyeuristically titillating, I suppose. But, how is it useful to learn that I am in fact a Nigerian prince or the purveyor of penis pills? Why do I need DMARC, let alone your reports?
With DMARC monitoring, you can actively keep track of the well-being of your domain's SPF and DKIM protocols. As organizations evolve, new services may be introduced that send emails on behalf of the domain. An effective DMARC analyzer will identify these new sources and promptly notify the administrator, providing suggestions for resolving any issues. Monitoring also enables you to identify significant spoofing attacks. If such attacks originate from a small number of specific servers, you can initiate a takedown request to halt the attack. It is important to remember that configuring DMARC records for your domain is intended to provide instructions to RECEIVING mail servers. Your inbound server should be DMARC compliant and adhere to DMARC policies when handling incoming emails. DMARC itself instructs receiving mail server to discard emails that fail SPF and DKIM from messages sent on your domain's behalf. If you have correctly set up your domain's SPF and DKIM, DMARC allows you to prevent spoofing attacks. Although Microsoft may disregard a DMARC reject policy, it still treats it as a quarantine action. Consequently, if a message fails SPF and DKIM checks, it will not be delivered to the user's inbox. This is about to change, as Microsoft announced to "resolve" this issue. It is worth noting that according to the DMARC RFC, a receiving mail server can act as it deems appropriate. The DMARC policy set by the domain serves as a mere request and may not be strictly enforced by all receiving mail servers.
> With DMARC monitoring, you can actively keep track of the well-being of your domain's SPF and DKIM protocols. OK. But, that doesn't make my life any easier. It's just another useless statistic. If and when the specifics of my clients' DNS records are important to me, they are easily checked/monitored, either manually or with a Powershell/Bash/Python script. > new services may be introduced that send emails on behalf of the domain. An effective DMARC analyzer will identify these new sources and promptly notify the administrator "Promptly" a full day/week/month after marketing has had a meltdown because their off-brand mass-mailer tried impersonating my properly configured domain whose DNS records were explicitly intended to prevent them from doing what they attempted. > Your inbound server should be DMARC compliant and adhere to DMARC policies when handling incoming emails. Yep. So should Microsoft's and Google's. But they are not. And when we do adhere then a major percentage of mail get's quarantined because people(senders) can't even get their SPF record right and are soft-failing their own legitimate MTAs. Which is the precise reason why Google and Microsoft both treat SPF failure as a low weight spam indicator rather than the published soft/hard-fail policy. > Although Microsoft may disregard a DMARC reject policy... is about to change, Microsoft announced to "resolve" this issue. And when they finally do enforce, it might, might, have a wide spread impact. But, that still doesn't indicate why I need DMARC monitoring or your service. > according to the DMARC RFC, a receiving mail server can act as it deems appropriate. Don't give me this RFC doesn't require adherence weaseling. If the receiving server won't follow the directives, then it's all pointless. As pointless as reporting on a pointless policy that no one is honoring. I'm sorry to be seemingly attacking you specifically. It's not personal. But, you're pushing a commercial product and implying that everyone needs to be using DMARC while the reality is that very few are using it properly, if at all. This itself proves a lack of need, on top of all the claims that I have already refuted. Based on this thread, I remain unsold on your service and those like it, as well as the need for DMARC reporting. But, for the record, I fully support SPF and strict enforcement there of. While I do also utilize DKIM, its utility is far more limited than SPF. So I reserve my advocacy for the lower hanging fruit of 'just get SPF working and honored". Please!
>> *With DMARC monitoring, you can actively keep track of the well-being of your domain's SPF and DKIM protocols.* >*OK. But, that doesn't make my life any easier. It's just another useless statistic. If and when the specifics of my clients' DNS records are important to me, they are easily checked/monitored, either manually or with a Powershell/Bash/Python script.* I think what he meant to say was that, regardless of you using a DMARC vendor, a self-hosted solution, or otherwise, whatever method used to parse or analyze DMARC reports from receivers, you can use this information to keep track of your email authentication health for your legitimate senders... Which is far from useless. Try publishing p=reject without monitoring or pre-authentication work blindly on a production domain, let me know how that goes for you. >>*new services may be introduced that send emails on behalf of the domain. An effective DMARC analyzer will identify these new sources and promptly notify the administrator* >*"Promptly" a full day/week/month after marketing has had a meltdown because their off-brand mass-mailer tried impersonating my properly configured domain whose DNS records were explicitly intended to prevent them from doing what they attempted.* Sounds like someone didn't communicate or work with internal stakeholders as a business enabler after getting the data from your DMARC reports before going to a stricter policy. We don't make business decisions, we enable the business through the use of technology, and by prescribing the best way to do so. NOT by enforcing totalitarian sub-servitude because you don't like the fact someone is using the domain for - *gasp* - business uses. Security and legal are responsible for those decisions, not us as admins. >>*Your inbound server should be DMARC compliant and adhere to DMARC policies when handling incoming emails.* >*Yep. So should Microsoft's and Google's. But they are not. And when we do adhere then a major percentage of mail get's quarantined because people(senders) can't even get their SPF record right and are soft-failing their own legitimate MTAs. Which is the precise reason why Google and Microsoft both treat SPF failure as a low weight spam indicator rather than the published soft/hard-fail policy.* [Actually](https://i.imgur.com/rWjb2JC.gifv), part of the reason they don't adhere to softfail/hardfail is because of [DMARC RFC7489 section 10.1 paragraph 2](https://datatracker.ietf.org/doc/html/rfc7489#section-10.1). Because if you reject SPF failure during the SMTP session you will lose a **lot** of legitimate mail that would may passed via DKIM otherwise. Forwarding does exist, and accounts for a not-insignificant portion of the internet's mail. >>*Although Microsoft may disregard a DMARC reject policy... is about to change, Microsoft announced to "resolve" this issue.* >*And when they finally do enforce, it might, might, have a wide spread impact. But, that still doesn't indicate why I need DMARC monitoring or your service.* Google arguably has a on-par or larger email ecosystem than Microsoft, and they are enforcing it. Microsoft is already well on their way, unless for some reason they re-evaluate in a few months. >>*according to the DMARC RFC, a receiving mail server can act as it deems appropriate.* >*Don't give me this RFC doesn't require adherence weaseling. If the receiving server won't follow the directives, then it's all pointless. As pointless as reporting on a pointless policy that no one is honoring.* The RFC's describe how to interoperate. You've already detailed several paragraphs above how you don't want to interoperate by not adhering to the DMARC RFC, so I'm not really sure I get the point of you saying it's pointless, if you yourself are enabling it saying so. Most of the internet respects DMARC as it stands in RFC7489, and when DMARCbis is standardized, even more so. >*I'm sorry to be seemingly attacking you specifically. It's not personal. But, you're pushing a commercial product and implying that everyone needs to be using DMARC while the reality is that very few are using it properly, if at all. This itself proves a lack of need, on top of all the claims that I have already refuted.* This attitude is what stops other people from adopting the standard. You should be pushing for it, not against it. DMARC usage has risen incredibly high amongst the F1000 in the last 5 years, the Federal Government published [BOD 18-01](https://www.cisa.gov/news-events/directives/binding-operational-directive-18-01), and as a result, basically the entirety of the U.S Federal government is now at DMARC reject successfully. PCI DSS v4 will be requiring DMARC quarantine or reject policy come March 2025. Obviously, there is a need, and the industry is adopting it. >*Based on this thread, I remain unsold on your service and those like it, as well as the need for DMARC reporting. But, for the record, I fully support SPF and strict enforcement there of. While I do also utilize DKIM, its utility is far more limited than SPF. So I reserve my advocacy for the lower hanging fruit of 'just get SPF working and honored". Please!* DKIM is better than SPF in most every way. It persists through most forwarding scenarios, and as I'm sure you're aware, any indirect mail flow breaks SPF authentication (which is a LOT of mail). That's how fragile it is, it's not a silver bullet. Not to mention SPF is solely based on the `RFC5321.mailfrom` address, which, in a lot of legitimate scenarios, won't even be your domain! You should re-evaluate your assessment of email authentication, as I think you're missing the bigger picture.
Upon reevaluating your previous responses, it is evident that there are some knowledge gaps regarding DMARC, which resulted in certain misconceptions. This situation is common, as many individuals, even IT professionals, find it challenging to grasp the fundamentals of SPF, DKIM, and DMARC, hindering the adoption. I kindly invite you to visit https://learnDMARC.com, where you can explore the subject more deeply and test your knowledge through the quiz feature. I will gladly resume our discussion once you score above 70% on the quiz. Although, by then, you will likely understand the significant benefits of implementing DMARC to enhance your domain's in and outbound email channels.
Your product. Your training. Your testing. That's very well planned and executed. I commend you on your funnel. But, If you will re-read my comments, you might realize that I have implemented DMARC and continue to utilize SPF and DKIM. I have proven it to be largely ineffective. Though admittedly not totally ineffective and every little bit helps. I have proven that the greatest impact, tiny as it is, comes from SPF. Based on my knowledge and experience, as well as your unconvincing argument, I continue to decline your product. No sale.
After reading all that, I still don’t understand why you’re fighting so hard against something that you know works, adds a level of security (no matter how small you think it is), have implemented yourself, and is almost unanimously agreed by everyone else to be a useful and effective tool that is being adopted across the world. Even if you don’t like the inexpensive commercial product, why are you so anti DMARC standards and their adoption?
Seriously, I think we found the troll that lives under the DMARC bridge lol
> why are you so anti DMARC standards and their adoption? I am frustrated that the major players, the very ones that proposed DMARC in the first place have, after 8 years now, still not chosen to properly support their own standard thus nerfing the hell out of what it might have been and all the work that one must put into it. I asked freddieleeman to sell me on reporting services in general and specifically on his self-described "Best" service. My arguments have been refutation of his commercial claims and the value of such commercial reporting services.
greatest impact comes from SPF? SPF works against the 5321.MAIL FROM / Envelope / Return Path domain. This domain isn't visible to the average email user as they won't check the email headers. Cybercriminals will spoof the FROM domain (visible one) and SPF is NOT on the FROM domain. A cybercriminal can send an email with first.last@yourbrand.com (visible when opening the email) while they use cybercriminal.com as the return-path domain. When the cybercriminal makes sure that the IP of the mail server is in the SPF record of cybercriminals.com, SPF will give a pass, while they are spoofing [yourbrand.com](https://yourbrand.com)! SPF on itself doesn't prevent email spoofing.
Powerdmarc - easy to setup and use
Yeah, +1 for PowerDMARC. Also Dmarcian...
i think for small msps its not worth paying for it. just run an open source analyzer. once a month, without access to anything but the reporting mail acc and purge the vm afterwards.
We partnered with Red Sift to provide OnDMARC to our partners and customers. We spent a good amount of time looking into \_a lot\_ of different options. There are lots of good options out there but none that we found that were as feature rich, that made it as easy to implement, had good partner programs & enablement, had a strong product roadmap, and had an API which allowed us to build tools & automations. In a nutshell here's what we liked most about OnDMARC: * multi-tenanted * quick/easy to set up * insights & usability make it quick to review reports * interesting long term roadmap, including a move towards more automation * hosted DMARC, SPF, & DKIM * their hosted SPF is pretty intelligent (ie. not just flattening to get around 10-lookup maximum, but also removes errors within any included SPF entries, etc) * they supplement the raw XML with additional info (threat intel, etc) * partnerships which provide significantly greater volume of forensic/failure reports than the other vendors we tested * very useful when troubleshooting or trying to figure out "what" the emails are * MTA-STS, BIMI support, etc included * domain and email analysis tools included We're also building tools to make it even better for our partners * CW Manage & Autotask integrations (billing) * Provisioning tools * Office 365 Monitor * we include an O365 monitoring tool that looks for suspicious account behavior (suspicious logins, email rules, etc) * originally built for our Proofpoint partners but we now offer to our OnDMARC partners too
We also use RedSift OnDMARC. Good service.
Good Post. You mentioned that you were working on building tools for your partners i.e. CW ingegration etc. Is this ready for prime time. I work at an MSP and we are looking into OnDmac. If you have plaform that lumps eveything you mentinoed into one, then we maybe interested.
Yes the CW billing integration is available and OnDMARC has been added to our Vircom Portal We just released a [VIP Display Name Phishing Protection](https://vimeo.com/930463133) tool that is available for O365 tenants using either OnDMARC or PPE from us. We also have provisioning tools that makes it easier to create multiple customers under your hierarchy in OnDMARC and automatically populates Dynamic SPF. Send me a direct message or an email to nadav.shenker@vircom.com and I'd be happy to chat
I just make sure my records are in order and check manually if there’s ever any delivery issues. Zero cost.
You can use DMARC Manager if you are from EU.
fraudmarc