In addition to Vladimir's post, M3AAWG just published an SPF best practices
paper that might be useful:
https://www.m3aawg.org/sites/default/files/m3aawg_managing-spf_records-2017-08.pdf
Seth
On Thu, Oct 12, 2017 at 1:00 PM, Pete Holzmann via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:
>
Vladimir,
Thanks for that article. You did cover all of the issues I've seen to date...
including one I
saw just this morning for the first time!
An organization's SPF has:
v=spf1 mx include:smtproutes.com include:smtpout.com ~all
include:spf.protection.outlook.com -all
This is a pretty common practice for domains that people own for brand
protection as well - a0l.com has a -all SPF, p=reject DMARC policy, and no
MX.
On Thu, Oct 12, 2017 at 1:22 AM, Pete Holzmann via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:
> Awesome! Thank you SO much :)
>
> On 12 Oct
Awesome! Thank you SO much :)
On 12 Oct 2017 John Levine said...
>If you want no mail sent or received by ds.org (as opposed
>to any other domains you host) it is just fine to say
>that.
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
In article <59de991d.29608.10e74...@webbed.pete.gmail.com> you write:
>2) I was under the impression that a "real" email server needs to be able to
>both receive
>(postmaster@) and send (MAILER-DAEMON@) administrative emails.
Yes, but only for the domains for which it handles real mail. If you
Hmmm...
I think I'm about to learn something.
1) aster.ds.org is our email server
2) I was under the impression that a "real" email server needs to be able to
both receive
(postmaster@) and send (MAILER-DAEMON@) administrative emails.
What I have for SPF now is: email is ONLY valid from
Typical scenario is message is forwarded by recognized but DMARC-unaware
forwarder. There are still many large mailbox providers and even more
enterprise mail system where DMARC is not implemented.
Probably, you did everything you can, so just accept some messages are
not DMARC-blocked, because
In article <59dd1c2e.27060.b174...@webbed.pete.gmail.com> you write:
>Is there anything I can do to fix this?
I'd start by publishing an SPF record that just says "-all" rather
than what's in there now which says that there's all sorts of places
that real mail can come from. A lot of places
Hi all,
New to this list, not to the 'net (I registered octopus.com -- that will tell you
more about me than anything ;) )
I have an interesting situation.
Our context combines:
- A very old domain name that we ONLY use for infrastructure. No web site, no
email. (ds.org)
- Other domains
