I'll second what Franck has said - Once we we figured out all of the 3rd parties we needed to talk to, virtually everyone was happy to work with us to find a solution. The biggest problem we've had, by far, was internals who couldn't be bothered to figure out how mail works, and then suddenly their big email push explodes and it's all MY fault.
On Mon, Sep 26, 2016 at 4:34 PM, Franck Martin via dmarc-discuss < dmarc-discuss@dmarc.org> wrote: > We do enforce inbound policy, in fact this has been very useful, when you > send to yourself a copy of the failure reports, It allows you to find > problems with your email streams before they become real problems (as well > as all the details helping you to fix them). > > cf: https://github.com/linkedin/lafayette/wiki/Screenshots > > I had to put one or two companies in a local policy exception, but they > were emailing only our employees, not the whole world. > > Many third parties can abide to your DMARC policy, but you need to spell > it out what you want them to do, as many do not understand what DMARC is. > > I have used that FAQ entry a lot with all 3rd parties: https://dmarc.org/ > wiki/FAQ#My_organization_uses_third-parties_senders.2C_how_ > can_I_get_them_DMARC_compliant.3F > > On Mon, Sep 26, 2016 at 9:03 AM, Payne, John <jpa...@akamai.com> wrote: > >> >> On Sep 22, 2016, at 10:34 PM, Franck Martin <fmar...@linkedin.com> wrote: >> >> https://engineering.linkedin.com/email/dmarc-new-tool-detect >> -genuine-emails >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__engineering.linkedin.com_email_dmarc-2Dnew-2Dtool-2Ddetect-2Dgenuine-2Demails&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=VZB3mxoaHOufiSM5PmcFdSC3X7QyR-UqbTVl9O2GXVI&m=klV6EMNwQMR-SLjw1Y6EMpKCOL2cOUzCfRhYlKqIsZk&s=Vk1IAqiPW_HhrMpaN7jpo7ofj3cE-yod0vWmR1RVSlY&e=> >> https://engineering.linkedin.com/email/dmarc-moving-monitor-reject-mode >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__engineering.linkedin.com_email_dmarc-2Dmoving-2Dmonitor-2Dreject-2Dmode&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=VZB3mxoaHOufiSM5PmcFdSC3X7QyR-UqbTVl9O2GXVI&m=klV6EMNwQMR-SLjw1Y6EMpKCOL2cOUzCfRhYlKqIsZk&s=hxBXMPfwpVPp9OjNX5g_MGRP3WAYgVlfJZZ57lQuKOM&e=> >> >> google.com >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__google.com&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=VZB3mxoaHOufiSM5PmcFdSC3X7QyR-UqbTVl9O2GXVI&m=klV6EMNwQMR-SLjw1Y6EMpKCOL2cOUzCfRhYlKqIsZk&s=EZCpx1XS6E0RlPrXwJwQ-rjXlv1eIef8v1YTrtbjHZ8&e=> >> is p=quarantine >> yahoo-inc.com >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__yahoo-2Dinc.com&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=VZB3mxoaHOufiSM5PmcFdSC3X7QyR-UqbTVl9O2GXVI&m=klV6EMNwQMR-SLjw1Y6EMpKCOL2cOUzCfRhYlKqIsZk&s=-hb-p4StcL11rm8kVxjALkpozYMuHSpBT2kM6HfV_E0&e=> >> is p=reject >> microsoft.com >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__microsoft.com&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=VZB3mxoaHOufiSM5PmcFdSC3X7QyR-UqbTVl9O2GXVI&m=klV6EMNwQMR-SLjw1Y6EMpKCOL2cOUzCfRhYlKqIsZk&s=lSvflBjO4CTTS40XQzyG-i55yHF4hxO7Oa73V5xHN6k&e=> >> is p=quarantine >> paypal-inc.com >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__paypal-2Dinc.com&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=VZB3mxoaHOufiSM5PmcFdSC3X7QyR-UqbTVl9O2GXVI&m=klV6EMNwQMR-SLjw1Y6EMpKCOL2cOUzCfRhYlKqIsZk&s=HVYtBaLvaLL64MGFFzjMs5nsCuxKUD8AaAQRZzkgwJs&e=> >> is p=reject >> >> You will find other resources at dmarc.org >> >> >> google.com is p=reject FWIW >> >> I’m interested in how these companies got to that point. What >> workarounds are they relying on if any? >> Are they enforcing DMARC policies inbound? >> >> >> As for the Gmail question, I think it is linked to the release of ARC. >> >> >> So I’ve heard. I hope that turns out to be useful for the rest of us :) >> >> >> On Mon, Sep 19, 2016 at 12:06 PM, Payne, John via dmarc-discuss < >> dmarc-discuss@dmarc.org> wrote: >> >>> >>> > On Oct 22, 2015, at 3:43 PM, Payne, John <jpa...@akamai.com> wrote: >>> > >>> > >>> >> On Oct 22, 2015, at 3:36 PM, Andrew Beverley via dmarc-discuss < >>> dmarc-discuss@dmarc.org> wrote: >>> >> >>> >> On Thu, 2015-10-22 at 10:19 -0700, Franck Martin via dmarc-discuss >>> >> wrote: >>> >>> The fun is moving to ARC >>> >>> >>> >>> https://dmarc.org/2015/10/global-mailbox-providers-deploying >>> -dmarc-to-protect-users/ >>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__dmarc.org_2015_10_global-2Dmailbox-2Dproviders-2Ddeploying-2Ddmarc-2Dto-2Dprotect-2Dusers_&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=VZB3mxoaHOufiSM5PmcFdSC3X7QyR-UqbTVl9O2GXVI&m=klV6EMNwQMR-SLjw1Y6EMpKCOL2cOUzCfRhYlKqIsZk&s=RY-gGeFkzI6d-8J-08vlsFsISSguMO0jJBoGASk9_UE&e=> >>> >> >>> >> Sad to see that Gmail plan to move to p=reject >>> > >>> > I’m hoping that it encourages the mailing list folk who have been >>> reluctant to become DMARC safe to reconsider, whether thats ARC or wrapping. >>> > As an enterprise hoping to go p=reject, this is potentially a big deal >>> for me :) >>> >>> >>> I’m not exactly in the loop, but besides this article almost a year ago, >>> I haven’t seen anything else about gmail going p=reject… and it’s now 3 >>> months past the advertised date. >>> Any word there? >>> >>> Somewhat related (to my earlier post) - are there any _enterprises_ on >>> this list that have experience or are currently attempting to either go >>> p=reject or enforce DMARC policies inbound? >>> >>> Thanks >>> John >>> >>> >>> _______________________________________________ >>> dmarc-discuss mailing list >>> dmarc-discuss@dmarc.org >>> http://www.dmarc.org/mailman/listinfo/dmarc-discuss >>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.dmarc.org_mailman_listinfo_dmarc-2Ddiscuss&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=VZB3mxoaHOufiSM5PmcFdSC3X7QyR-UqbTVl9O2GXVI&m=klV6EMNwQMR-SLjw1Y6EMpKCOL2cOUzCfRhYlKqIsZk&s=eMppF7rXKy9Ae992X-v1YNrKhFN1KplgK27cUZrxuTo&e=> >>> >>> NOTE: Participating in this list means you agree to the DMARC Note Well >>> terms (http://www.dmarc.org/note_well.html >>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.dmarc.org_note-5Fwell.html&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=VZB3mxoaHOufiSM5PmcFdSC3X7QyR-UqbTVl9O2GXVI&m=klV6EMNwQMR-SLjw1Y6EMpKCOL2cOUzCfRhYlKqIsZk&s=TgyMWJzUPFzT0ty-VIZaQeIReOkrro70rp5gZkRzHjg&e=> >>> ) >>> >> >> >> > > _______________________________________________ > dmarc-discuss mailing list > dmarc-discuss@dmarc.org > http://www.dmarc.org/mailman/listinfo/dmarc-discuss > > NOTE: Participating in this list means you agree to the DMARC Note Well > terms (http://www.dmarc.org/note_well.html) > -- PAUL ROCK Principal Software Engineer | AOL Mail P: 703-265-5734 | C: 703-980-8380 AIM: paulsrock 22070 Broderick Dr.| Dulles, VA | 20166-9305
_______________________________________________ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
