SPF to allow all servers in domain to send email

just remove the plus(+). You may also want to make sure that your MX rcords are included in the SPF.

v=spf1 a include:spf.protection.outlook.com -all

Here is a good place to look at SPF syntax

http://www.openspf.org/SPF_Record_Syntax

Your usage looks fine.  But I might add ptr to it.

v=spf1 a ptr include:spf.protection.outlook.com -all

A            If the domain name has an address record (A or AAAA) that can be resolved to the sender's address, it will match.

More on SPF:

http://en.wikipedia.org/wiki/Sender_Policy_Framework

You can also use MxToolBox to validate your SPF records:

http://mxtoolbox.com/spf.aspx

-saige-

According to spec, a and +a are identical (the + is default)
I'll try, though.
I just changed to a:company.com, even though the "own domain" chould be default as well. Let's see that happens when DNS refreshes...

I now note that the spec (openspf) says, for the A mechanism, that:
  All the A records for domain are tested. If the client IP is found among them, this mechanism matches.

Does this mean that a zone transfer is performed? And this that the DNS must allow zone transfers for the SPF "a" to be working? I don't find any information on that, though...

@it_saige, yes using "ptr" seems to solve the problem.
However, openspf docs states that:
  If at all possible, you should avoid using this mechanism in your SPF record, because it will result in a larger number of expensive DNS lookups.

I had guessed that "a" would be the perfect mechanism to use - but, evidently, it does not work in my situation.
Could it really be a problem with zone transfers? Or what else would make "a" fail?

Well changing to
  v=spf1 a:company.com include:spf.protection.outlook.com -all

did not solve the problem, but changing to
  v=spf1 a:srv1.company.com/24 include:spf.protection.outlook.com -all

fixed it.

Maybe I don't understand what "a" does check? From openspf I understood that all A records in the domain (that the mail claims to originate from) are checked and compared with the actual sending MTA.
However, it seems (?) like only the A record for "company.com" itself is checked?

With a:srv1.company.com/24 it works, as it seems like the receiving MTA looks up the A-record for the server srv1 (one of the mailing servers) and then allows all other servers on the same C-net (due to /24) which includes srv2

I cannot find any better documentation on that "a" mechanism really does. Any pointers to more reading?

I cannot imagine that it would be a problem with zone transfers.  One possibility is that you have mismatched IP's between where the mail is being sent from and where it is recieved to.

Check the outbound mail headers to see if the Received: from [xxx.xxx.xxx.xxx] matches the IP that is associated with your A records.

-saige-

I found a great tool at http://emailstuff.org/spf

With
  v=spf1 a:company.com include:spf.protection.outlook.com -all

this tool explicitly stated that (apart from outlook servers) only the ip address in the A record for "company.com" would be accepted for mail sending. Not any of the other A record ip addresses in the same domain

Thus, I understand that the "a" mechanism does not really take a "domain name" argument, but rather a "server name" argument (unless, of course, a domain name argument is further investigated with a zone transfer for all A records in the domain -- our DNS however does not allow zone transfers)

I really need to catch up on SPF syntax :-)

If someone could let me know if this issue (is it "domain name" or "server name" that is the argument to "a"), then I would be grateful...

Well according to the specification:

v=spf1 a:company.com include:spf.protection.outlook.com -all

Is synonymous with:

v=spf1 a include:spf.protection.outlook.com -all

Excerpt from www.openspf.org/SPF_Record_Syntax

"v=spf1 a -all"
The current-domain is used.

"v=spf1 a:example.com -all"
Equivalent if the current-domain is example.com.

"v=spf1 a:mailers.example.com -all"
Perhaps example.com has chosen to explicitly list all the outbound mailers in a special A record under mailers.example.com.

"v=spf1 a/24 a:offsite.example.com/24 -all"
If example.com resolves to 192.0.2.1, the entire class C of 192.0.2.0/24 would be searched for the client IP. Similarly for offsite.example.com. If more than one A record were returned, each one would be expanded to a CIDR subnet.

Which is what leads me to believe that your A record points to one IP but the IP in the mail is comming from a different IP.

-saige-

@it_saige, your last two quotes are quite good. I saw them previously (on the net) while looking for input, but I obvisouly didn't really get it then...

With the "a:mailers.example.com" mechanism, I understood it such as that ALL of the A-records in the sub domain mailers.example.com would be allowed (like srv1.mailers.example.com, etc)
Instead, it seems more and more obvious that the "a" mechanism ONLY checks for the A record (or records) with the specific name "mailers.example.com" (which, to me, then is considered a server name, rather than a domain name)

Normally (right?), a company domain name by itself is used in an A record to complement the "www" server on the domain.
Thus, a simple "a" SPF mechanism will then only mean that the www webserver in the domain is allowed to send email.

Do you agree? If this is correct, I'd say that much info on the internet is a little confused on this matter :-)


The RFC 7208 however states this a little clearer (I'm sorry I didn't begin by checking this):

5.3.  "a"
   This mechanism matches if <ip> is one of the <target-name>'s IP
   addresses.  For clarity, this means the "a" mechanism also matches
   AAAA records.
      a = "a" [ ":" domain-spec ] [ dual-cidr-length ]
   An address lookup is done on the <target-name> using the type of
   lookup (A or AAAA) appropriate for the connection type (IPv4 or
   IPv6).  The <ip> is compared to the returned address(es).  If any
   address matches, the mechanism matches.

This quite clearly states the the "target name" (the name following the "a:" - defaulting to the mail sender domain name) is looked-up in DNS for its A record. No other A records are looked-up.

So - if I've got an A record for company.com which is 11.22.33.01 (which is the www web server, of course) and then an A record for srv1.company.com which is 11.22.33.44 - then my "a" mechanism does not at all allow the srv1 server to send mail.

Much of the info on the net describes the "a" mechanism with something like the following, which seems to be completely wrong. Don't you agree?

In this SPF record, the “a” mechanism defines that all A records in this domain are permitted to send emails for this domain. The “mx” mechanism defines the same for all the MX records. The “-all” mechanism defines that everything else is not permitted. In most cases, that is what you need if you have a mail server that is just running for this domain.

At least myself am led to Believe, by such text, that ALL of the A-records in all of the domain, are allowed by SPF, with the "a" mechanism (just as is the case with the "mx" mechanism, which allows ALL of the MX servers)
However, all seems to indicate that ONLY the ip address (or addresses) in the A record for the domain name itself, is allowed...

I think you may be over complicating this which is leading to a tiny bit of confusion.

SPF works off the premise of reverse-lookup.  An SPF is not resolved until an email is received.  So using your scheme:

example.com DNS Zone file

A Record	Points To
@		11.22.33.01
srv1		11.22.33.44

CName Record	Points To
www		@

TXT Record
v=spf1 a -all

Select allOpen in new window

@ in this case simply means example.com.

Now, when an email is sent from example.com, the email has the ip address it was sent from in the headers.  When the recipient email server receives the email, it uses the IP in the email to see if it conforms to what is allowed by the SPF record.  In this case, it should not fail if the IP in the headers is either 11.22.33.01 or 11.22.33.44 as they are both A records that are registered in example.com's DNS zone.

-saige-

Nope, sorry - not as I see it, and have tested it.

With the sample zone that you describe above, emails sent from 11.22.33.44 will not be allowed by SPF

The receiving MTA will see the "a" in the SPF record, and will lookup the A-record for the domain "company.com" (being specified as the domain name in the "MAIL FROM" email address)
This lookup will result in ip address 11.22.33.01

As this does not match the sending 11.22.33.44 - the mail will not be allowed.

However, much info on the net does indicate, more or less, that ALL of the A-records (including 11.22.33.44) in the domain will be checked and allowed by the "a" mechanism. But that is obvisouly not the case.
(and also, such a solution would need a costly and quite commonly disallowed zone transfer)

FYI I just talked to some guys at MxToolbox, asking this (rather long:-) question:

You describe the “a” SPF rule as: “Match if IP has a DNS 'A' record in given domain”

This suggests that if a mail sending server is named mailsender.domain.com and contains an A record in the domain.com DNS, then the SPF rule matches.
Thus, with a domain.com DNS with the following A-records:
www 1.2.3.4
@ 1.2.3.4
mailsender 1.2.3.98
otherserver 1.2.3.99

…then your “a” description for domain.com seems to mean that the mailsender (1.2.3.98) would match the rule, just because that it exists as an A record in domain.com
However, this is (as far as I know) not correct. Or am I wrong?
I’ve been working quite a lot on such issues, and to my experience this is not the way the “a” rule works.

The SPF “a” rule for domain.com instead means (as I’ve understood it) that mail from any IP address that has an A record for the name “domain.com” (thus the @ record in the example above) matches.
To allow mailsender.domain.com, one must use an “a” rule that specifically identifies this particular host, or else declare a subnet like “domain.com/24” in the “a” rule, to allow all IP addresses in the same subnet as the address 1.2.3.4 (the A record for @)

To my knowledge, this “misunderstanding” on how SPF “a” works, is quite common on the internet.
As you are such an authority on the matter, perhaps you could either tell me that I’m wrong :-) or else make some clarification in your SuperTool to avoid that people misinterprets the results.

I then got the answer below, clarifying that the "a" rule only mathces the A record for the domain itself, not all A records that exists in the whole domain

We mean that if the Ip is in the domain's A record then it matches. I'll forward this along to our engineering team to clarify the entry. Thanks for taking the time to let us know it's not confusing. Sometimes things make sense to us since we write them and not to anyone else.

In particular, the response from the MxToolBox people (authorities on the matter) seems to settle this issue.