Tag Info

New answers tagged

0

A properly implemented SPF checker will short-circuit on a mechanism match and the check_host() function will return the qualifier value as the result. I don't have any "real world" data to provide to you regarding whether or not most email servers follow the RFC or not. Source: RFC7208 (see page 17)


2

RFC 7208 § 5.1 is explicit about this: after all appears, everything after it MUST be ignored. Mechanisms after "all" will never be tested. Mechanisms listed after "all" MUST be ignored. Any "redirect" modifier (Section 6.1) MUST be ignored when there is an "all" mechanism in the record, regardless of the relative ordering of the terms. The RFC ...


2

"v=spf1 include:_spf.google.com ~all a mx ip4:X.X.0.0/23 include:spf.example.com ?all" says in order: "email coming from _spf.google.com is valid for our domain" "softfail on all other senders for our domain" "email coming from our a records are valid for our domain" "email coming from our mx records are valid for our domain" "email ...


0

Unfortunately, it's a well-known fact that DMARC and some mailing lists are effectively incompatible. The same problems originally stemmed from SPF itself, and have prompted mailing lists (as well as forwarding services) to implement a feature known as SRS (Sender Rewriting Scheme), which is a feature that must be implemented by the mailing list operators. ...


2

Actually, I would say that your configuration is fine. At least if your TXT record does in fact have a trailing dot as it does in your example. The most likely scenario is that Mandrill is checking for a variant of sub.example.com. that is missing its trailing dot, with the expectation that it is a typo. While you do not have a ...


0

In my understanding, Google relies not only on SPF, but also on DKIM and ultimately DMARC to evaluate e-mails. DMARC takes into account both SPF and DKIM-signing. If either is valid, Gmail will accept the e-mail but if both fail (or softfail), this will be a clear indication that the e-mail may be fraudulent. This is from Googles DMARC-pages: A message ...


1

Yahoo now provides an SPF record: $ host -t txt yahoo.com yahoo.com descriptive text "v=spf1 redirect=_spf.mail.yahoo.com" Details on their policy here.


4

Just add the include statement that Google is recommending: v=spf1 a mx ip4:67.231.248.250 include:_spf.google.com ~all Do not create multiple SPF records.


2

Yes, that is normal. Anyone can spoof any email address, but SPF (Sender Policy Framework) gives email service providers & clients the ability to better identify & flag as spam or eventually bounce messages entirely if that is part of their process.


6

SPF can't prevent this. It gives just an indication to other servers that the mail is spoofed, but most use this only a one of several factors to decide if the mail should be blocked.


12

The fact that you advertise an SPF record in no way obliges anyone else to honour it. It is up to the admins of any given mail server what email they choose to accept. I think they're foolish if they don't check SPF records and reject accordingly, but it's up to them. I know some people like DMARC, but I think it's a hideous idea myself, and I won't be ...


2

Yes, you should include Google's SPF include for this domain, even if no SPF record was set up previously. Your record for example.com will probably look something like: v=spf1 include:_spf.google.com include:spf.mandrillapp.com ~all when all is said and done. You don't need anything additional for example.com unless you are sending email directly (e.g. ...


6

I kind of see where you're going with this. Let me add my two cents: Do I need to add an MX record to my internal DNS? No. That doesn't have any bearing on external to internal or internal to external email delivery. Do I need ask my ISP if they're able to change their PTR to mail.domain.org? That would be recommended so that when ...


3

Usually this line is enough: domain.com. IN TXT "v=spf1 mx a ~all" ^1 ^2 It allows all servers listed as an MX for domain.com to send emails for this domain. It allows the server with the IP of domain.com to send emails for this domain. So … No No, but it would be good. No, to all. Change it. No, internal hostnames and ip ...


6

SPF is not a security credential I think the big misconception here is that SPF records provide a trusted credential. In truth SPF is not a secure credential, at least in the real world of security. DNS is an inherently insecure protocol. It's based on UDP (no transport level handshake), the protocol itself does not implement a handshake, and there is no ...


2

resource owner to restrict the access to one or more domain names. The closest thing to this I can think of would be to run all your own name servers, and use ACL's to restrict who is allowed to query a given zone. Example config excerpt (for bind): acl trusted_src_ip { 192.168.2.0/24; 2001:db8::/64; }; zone "mysecretdomain.com" IN { type ...


5

Think about how this would work. SPF works because it allows remote mail servers to verify their incoming mail to ensure that the mail has in fact come from where it's meant to. This puts the onus on the sender to have the SPF record in the first place. How would this work with a DNS record for web access? It publishes a list of clients who are allowed to ...


10

The first MX means that the IP addresses in the MX record(s) for the domain you're actually attaching the SPF record to should be accepted as valid. The second one means that IP addresses in the MX record(s) for the domain mail.mydomain.com should be accepted as valid. If this SPF record is for the domain mail.mydomain.com, then the second one is redundant. ...


3

I believe what you are encountering is a Backscatter email, check wikipedia for detailed description. In brief, backscatter happens when someone sends out spam using forged addresses, in this case yours, and the bounce messages send back to your address. Many mail servers resolve this by tagging every email they send out, using a technique called Bounce ...



Top 50 recent answers are included